Many that have a small home or office server wonder if it is possible to use it to backup their data to adequate Cloud Backup services; and many of those NAS systems do offer native support for some services, such as Synology‘s DSM package for Amazon‘s Glacier.
But in the particular case of Synology, it shouldn’t come as a surprise that there aren’t more official packages, for CrashPlan or for other services, as they’re preparing to roll out their own Cloud Backup service, named Synology C2 Cloud Backup. I’m focusing here on the CrashPlan+ services and not specifically CrashPlan Pro.
CrashPlan can be installed on our NAS’ in somewhat easy ways thanks to the work of proactive developers such as patters (Synology), providing neatly packages that can be installed without much trouble on Synology, QNAP or Drobo devices. In any case, any new user will soon be stumped to find that there are some caveats and inconveniences with these installs, meaning that unlike other services with native support, you’re bound to do some maintenance work every so often:
- Regardless of the platform it’s running, the CrashPlan app is actually an “enclosure” running a Java app. This is valid for all operating systems (including Windows and macOS), except mobile apps. There were some threads going around some years ago, where Code42 was supposedly developing a native app for macOS, but I guess it must have been abandoned or put aside.
- Code42 does not provide official support for this type of setup. You’ll find an official guide at the bottom where they state this clearly. In any case, from my experience, it’s one thing to have an issue with the setup – for which they won’t give support – but another if there are actual service issues. In the case of the latter, if the issue is significant, they will probably, at least, comment on it.
- CrashPlan is a Cloud BACKUP solution, it is not for Cloud STORAGE. Cloud Storage services, such as Dropbox, OneDrive, Google Drive and the bunch, do not – in general – support adequate data reliability nor versioning; meaning that if a glitch makes you lose your data and that syncs across supported devices, you’ll be left with no simple solution for recovery. As an example, I use OneDrive as my main Cloud Storage service and have that data being replicated (realtime one-way mirror) to my Synology box using the official Cloud Sync package, and that copy is being uploaded to CrashPlan from the NAS.
The most useful CrashPlan has been to me is when I discover that some files aren’t where they are supposed to be, being that my fault or not: as it has unlimited versioning and retains deleted files, I can easily recover those files – which is something you cannot do with common Cloud Storage solutions.
- CrashPlan is quite RAM-hungry, which can be a deal-breaker with a lot of NAS devices. At the time of this writing, the current linux package installs with a 1024Mb default Java heap limit (maximum RAM it can use), which is ok for most users. This is the most common source for issues with running CrashPlan on any platform: if it is crashing or constantly restarting, the most likely culprit is that you don’t have your Java heap set to a large enough number. If you have a moderately large data set don’t buy a NAS that cannot take at least 2Gb of RAM – read more about in this article
- You need an Intel CPU based NAS – CrashPlan no longer supports with ARM processors, ever since version 4.8.
- The current Java Heap figures Code42 recommends are as follows:
Backup Selection Size / Recommended Memory Setting (MB)
– 1.5 TB or 1.5 million files /1536
– 2 TB or 2 million files / 2048
– 2.5 TB or 2.5 million files / 2560
– 3 TB or 3 million files / 3072
- Considering the last figures, I would stay away from backing up millions of small files, which is easy to happen if you happen to be backing up sparsebundle “image” files (macOS) as well as large files that are constantly being updated (such as Outlook PSTs on Windows). If you want these backed up I would say one possible way is to have some sort of mirrored copy, which is not being updated in realtime.
- From my experience, when CrashPlan is monitoring the file-system or uploading files it will use a lot less memory than when its scanning the entire dataset. That may justify why it stopped working after some time, even without user interaction or a package upgrade – if the data set grows large enough it can break in the next scheduled scan. One possible method to make this easier on the device is to create separate backup data sets and making sure these don’t scan at the same time.
- AFAIK, the CPU throttling options on the GUI settings do not function on Linux headless setups, but scheduling does and it is actually recommended if you don’t want your bandwidth to be fully capped while uploading. Code42 states otherwise, but again, they don’t test these setups.
- While we’re on the subject of bandwidth, know that there are methods to increase the upload speeds for CrashPlan, not without its caveats.
- The second most critical issue is that CrashPlan has an auto-upgrade process builtin that [currently] breaks every headless install. This is what most of the topic replies on the forum are about – Code42 rolls out an upgrade and it breaks a lot of installs. The only proven method to delay CrashPlan from breaking is to block the auto-upgrade process (here it is for Synology, though it should work easily on other linux platforms), even though it is also known that it will eventually be necessary to go ahead and fix the upgrade.
- At the time of writing this, the most common solutions for solving package upgrades are based on copying the cpio file before reinstallation and some patience with repeating the process maybe two or three times. The issue with reinstallation is that it might have to do a block synchronisation run afterwards, which can take many hours to complete.
- Keep in mind that a possible alternative is to install CrashPlan in a Docker container, available for most NAS’.
I’ll try to write a straightforward guide for installing CrashPlan on Synology NAS’ and maybe other boxes if users contribute with information on that. In the meantime, here are the “official guides” for installing CrashPlan on headless computers:
- Code42 (official): https://support.code42.com/CrashPlan/4/Configuring/Using_CrashPlan_On_A_Headless_Computer
- QNAP (official, may be outdated): https://www.qnap.com/en/how-to/tutorial/article/how-to-set-up-crashplan-on-qnap-nas-to-back-up-important-data-to-the-qnap-nas-or-to-the-cloud
- Synology (unofficial, but from the DSM package author patters, constantly being updated): https://pcloadletter.co.uk/2012/01/30/crashplan-syno-package/
- Synology with Docker (more GUI centered, 2 May 2016): https://miketabor.com/run-crashplan-docker-synology-nas/
- Synology with Docker (command line, 22 May 2016): http://chrisnelson.ca/2016/05/22/crashplan-and-crashplan-pro-on-synology-using-docker/
- For Drobo I didn’t find anything relevant other than using the NAS as a mount point for a non-headless install.
Do comment below if something is not correct, if clarification is needed or if you have better links for installation guides.