Advanced CrashPlan backup strategy

Some lessons I’ve learned in my year and a half with CrashPlan. Please note, this is an advanced guide to CrashPlan. You have been warned. I assume you’re already familiar with CrashPlan and understand their backup sets, etc.

This post covers several topics (and I might update it later if I remember or discover more).

  • cron vs anacron
  • backup speed
  • file selection verification

Cron vs Anacron

Personally, I consider this a bug, and one that CrashPlan ought to have fixed a long time ago. When configuring “Verify selection every”, if you choose a number of days and a time of the day (which is the default), your backup verification will only happen if your computer is on at the scheduled time. Ala cron.

However, if you choose a number of hours < 24, and your computer is off at the scheduled time, the backup verification will run as soon as the computer is on again after the scheduled time. Ala anacron.

Bottom line, for your most important data, set the verification to run every 23 hours and accept that it’ll happen at inconvenient times of the day.

Backup speed

For a long time I felt like CrashPlan took forever to run backups. Eventually, more than a year after using the service, I decided to investigate. I found some excellent articles.

tl;dr Change the advanced settings. If you’re backing up compressed media, turn off compression. For backup sets that rarely change, change “Data de-duplication” to minimal.

I discovered this after I decided add ~500GB of media on a USB disk to my backup sets. After making these changes, the backup took about 6 weeks instead of 3 months! I regularly saw upload speeds of >6Mbps on connections that would support it, I was moving a lot during the 6 week upload period!

File selection verification

This is an optimisation I’m only now figuring out nearly 2 years into my CrashPlan adventure. If you’re backing up a large folder of very infrequently changing data, put it into its own backup set. For example, I backup ~500GB of audio and ebooks. I almost never add to the collection.

By putting this into a separate backup set from my photos I can run a manual file verification of the photos without also waiting for the verification of 1’000s of book files which I know have not changed. My advice is the more backup sets the better.

Note that if you split one backup set into multiple smaller sets, you will lose the history, including any deleted files, previous versions, etc. Best to set this up from the beginning. But remember CrashPlan is a backup system, and it should not be confused with external storage.

Conclusion

CrashPlan’s java app is horrible. It’s slow, ugly, and a PITA to use. If I could find a better alternative, I’d switch in a heartbeat, I have zero loyalty to CrashPlan. However, having said that, as of my last research, CrashPlan is simply the only contender in the market. The defining characteristics for me are:

  • Client side encryption with key that is unknown to my backup provider.
  • Sensible pricing (unlimited space, 10 computer family plan for $150/yr).
  • Indefinite retention of external drive backups (BackBlaze for example deletes these after 30 days, or after 6 months if your computer is off, even while you continue paying, completely outrageous).
  • Cross platform, even if I only actually use OSX, the idea that I can also backup a Linux based server is a necessity with a 10 machine plan.

Find me another service that has these features and I’m there. In the meantime, I continue to use CrashPlan and endure its peculiarities and shortcomings.

One thought on “Advanced CrashPlan backup strategy”

  1. “CrashPlan’s java app is horrible. It’s slow, ugly, and a PITA to use”

    Couldn’t agree more, and I’m running the engine (not the UI) on a Synology NAS; pegs the underpowered CPU on the NAS, can’t leave it running. If you meant the UI, yeah, it blows too, as you described.

    The Google Drive sync agent (on Windows) also runs in Java. Couldn’t figure out why my laptop was so hot, and the fan was always maxed. Java !@#$%^&*(!

    Started a basic dev course for Android via Coursera, using the Eclipse SDK. Took forever, for any virtual Android device I configured to launch. Like 10 minutes or more, unless I pushed all the parameters way, way down.

    Java !$%^&*$%!!

Leave a Reply

Your email address will not be published. Required fields are marked *