So while I was updating my Mac Pro VM host, I decided to test the upgrades for my backup environment. It should have been straightforward but as usual I must have done a little too much clean up from the last time.

For my backups I’m using Code42’s Crashplan Enterprise platform. It’s surprisingly affordable and robust which is why I recommend it to my clients. Upgrades, however, are a bit of a tricky mess. Code42 recommends you test the upgrades and for good reason. You don’t want to lose your backups. And sometimes these upgrades don’t go as smoothly as expected.

I have 2 test VMs setup as Master and Storage servers for CP Enterprise mirroring what I have in production (except for the backup data). I had expected that since the last upgrade they would be at the current production version so I could just restore the prod databases to them an get on. But it turns out I had decided last time to wipe clean these VMs and so my CP Enterprise directories for both VMs stood bare with nary an installation to be found.

This meant that before even testing an upgrade, I had to get them back up to the version in prod. Why didn’t I just copy the production VMs across? They’re simply too big. Why didn’t I take a snapshot from the last time? Well, because I’m a noob. Anyway, I still had the DB dumps from the previous upgrade and the installer and after figuring out I needed to turn the clock back a year for the upgrade to take (Code42 won’t let you upgrade if your license has expired), it was all good. I was back to production parity. This time I did take snapshots after patching Windows and restoring the latest prod database.

The upgrade process is fairly finicky. While testing the upgrade to 4.2.x I found that it would fail to complete if it couldn’t find my original prod storepoints. This took a while to figure out as I restored my snapshot a couple of times thinking that I had screwed up somewhere. Luckily, I could rename my test storepoints and the upgrade finally completed. It also complained about an expired token when I tried to upgrade the storage server but it turns out I just needed a fresh login.

After all, that it seemed to settle down and work fine which means I can start upgrading my production instances in the next scheduled maintenance.

Some notes for me: 4 things I need to test an upgrade.

1. Current database dump from production.
2. The CrashPlanPROServer_y.y.y.y_from_x.x.x.x_arch.upgrade file from the current version to the next.
3. The CrashPlanPROServer-x64_y.y.y.y_Win.msi base installer. (Handy if you need to start again from scratch.) These will go away from the Code42 website so best grab them when you’re testing.
4. Any CrashPlan app versions needed for the new server version.

So you may have noticed, I use Crashplan for my backups. Even though many people complain about it’s slow upload speeds (mainly in the US). It’s one of the few cloud backup services that actually has a presence in Australia. Since Australia is more or less known for it’s backwater internet speeds, there isn’t much more you can expect living here. Fortunately, I am lucky enough to live in an area where I can get fibre and the upload speeds really aren’t anything to complain about.

The short is Crashplan is a great choice despite the limited choices I do have. But enough about that.

As you may have gathered from the title, I run my Crashplan instance on my Synology NAS. This has the benefit of providing a local backup for all my family’s machines and also a way for me to backup the data on the NAS to Crashplan’s cloud.

Unfortunately, this isn’t exactly a supported configuration for Crashplan. One of the brilliant members of the Synology user community, namely PC Load Letter (patters), has packaged the Linux version of Crashplan that we may all reap the benefits. He even regularly updates it too.

However, being an unsupported configuration, sometimes updating the instance gets a bit tricky. There are three main points I need to remember.

The Short List

1. Java needs to be either installed separately or downloaded separately.
2. After installation, Crashplan will likely download an upgrade and it will fail causing the package to stop running. The upgrade will need to be run manually from the Synology’s shell.
3. A new UI token will probably be generated and I’ll need to update the VM where I manage the NAS’s instance in order to connect to it again.

This is the short list. If you remember what you need to do from this, you need read no further. Otherwise, detailed steps will follow. Continue reading “Updating Crashplan on the Synology” →