CrashPlan-Logo

Ich nutze seit einigen Monaten CrashPlan für die Online-Sicherung meiner Bilddaten, zusätzlich zur hier laufenden Sicherung auf externe Platten. Und ich muss sagen es läuft wirklich ohne Probleme. Es läuft aber eben sehr langsam. Ok, da kann CrashPlan jetzt nicht wirklich dafür, das dürfte eher ein Problem der Datenmenge (ca. 1 Terabyte) und des relativ langsamen DSL-Uploads (1024 Kilobit) sein. Zumal die Sicherung auch nur laufen kann wenn mein Rechner läuft, und der läuft zwar oft aber eben nicht ständig.

Immerhin, vor einigen Tagen hat mir CrashPlan mitgeteilt, das nun 50% der Sicherung geschafft wären. Dann könnte ja bis Weihnachten sogar die erste komplette Sicherung durch sein. Wahnsinn! Vielleicht sollte ich mir zu Weihnachten einen schnelleren DSL-Zugang gönnen. Bei den Datenmengen die heutzutage bei einem Shooting dazu kommen wird das Backup ja sonst nie fertig.

CrashPlan Statusmail
CrashPlan ist toll, aber laaaaannnngggggssssaaaaaammmmm
Markiert in:                 

One thought on “CrashPlan ist toll, aber laaaaannnngggggssssaaaaaammmmm

  • 19. September 2014 um 19:06
    Permalink

    Schau mal hier, dadurch wird’s schneller: http://networkrockstar.ca/2013/09/speeding-up-crashplan-backups/

    Hier gleich die Kurzform:

    So… being a geek, I figured I’d check to see if I could do anything other than spend a bunch of money to upgrade the CPU in that system.

    I navigated to the CrashPlan configuration directory, /usr/local/crashplan/conf/ (this is on Linux; Windows users, you’ll have to figure out there this is yourself, sorry!), and started digging. I stumbled across this gem in the file my.service.xml :

    1073741824
    0
    Hmm. Interesting. “0” is often used as a metavalue that means “unlimited”… so maybe CrashPlan will ALWAYS dedupe EVERYTHING when going over a WAN link, but only dedupes files smaller than 1GB when going over a LAN link, presumably because they recognize that there’s a balance between CPU capacity and network capacity. It seems that they assume everyone has ridiculously slow upload speeds that are typical of most residential Internet connections.

    Being the smarty that I am, I figured I’d set it to not dedupe any files larger than 1 byte when going over the WAN:

    1
    (Note: If you use backup sets, you will have more than one of these lines, one per backup set. I suggest changing them all; I have not done any testing to see what happens if you disable it only for some of the backup sets.)

    I then restarted the CrashPlan engine (/etc/init.d/crashplan restart).

    And… VOILA. My CPU usage dropped from 100% of 1 core down to ~10% of 1 core, and my upload jumped from 2.5Mbps (and dropping) to 7.5Mbps (and holding/fluctuating between 6.9Mbps and 7.5Mbps). I’m now seeing patterns that more accurately cover the “variable network bandwidth due to shared service” theory, without seeing logarithmic decay in performance.

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.