
Unfortunately, this process has become more and more painful as CrashPlan keeps updating their clients. The last step is to set up our local PC for remote administration of the Linux VM.

Edit /etc/fstab to auto-mount your NFS shares on boot.So in my case, I made new directories on my local Linux VM for /volume1/backups, /volume1/documents, etc Make your local Linux directory structure, which should match what the Synology structure is.For example, here are the directories that I was using CrashPlan to backup: If you have the packages installed and NFS set up correctly on the Synology, then you should be able to validate the configuration by using showmount.Install NFS tools: yum -y install nfs-utils nfs-utils-lib.Make sure you get the latest package updates first: yum -y update.Don’t forget to use the same IP address that we entered in the Synology for NFS.Build a CentOS VM – This can be on an ESX host like I used, or just a standalone PC.Set privilege to Read-Only (you could probably leave this read-write, but CrashPlan only needs read permissions to back up data).Enter the IP address for your CentOS VM (or other linux system).Click the tab for NFS Permissions, then click Create.For each folder you need to back up via CrashPlan:.Still under Control Panel, visit Shared Folders.Scroll down to the NFS section, and check the box for Enable NFS.Open up the Control Panel and go to File Services.This VM is running the CrashPlan client, and my backups have resumed! Here is how I got this all set up: So I finally forced myself to sit down and find an alternate solution.Īlright – so as of today I now have a dedicated CentOS VM running on my ESX host, which is connected to the Synology via NFS. Re-seeding my backups whenever I picked up a replacement NAS would take forever (I think I have ~2TB backed up currently). It makes sense why they do that – but I didn’t want to lose my backups before I could replace the device. Well a few days ago, I received an email from CrashPlan threatening to delete my backups since my NAS hadn’t connected in over 6 months. Since my DS411 is reaching the end of it’s life anyways, I figured I would just wait until I replaced it with one of the new Synology devices that use an Intel processor. For the past 6-7 months, I’ve been unable to back up my primary storage device at home. This ran great until late 2016 when CrashPlan updated to 4.8.0 and ended support for ARM processors (which is what the DS411 uses). I found a great community package ( here), which allowed me to install the backup client directly on the NAS. This was amazing to me, because I had around 1.2TB of data at the time. I started using CrashPlan, because they offer unlimited cloud storage for only $5.99 a month.

So in late 2014 I decided that I needed to find a good backup solution for it. Of course, I’ve also been using the NAS for general file storage (photos, videos, documents, etc). I’ve been using the device since then with 4x 3TB drives as an iSCSI backend to my ESX host. This is to help support my blog and does not have any impact on my recommendations.Īs part of my home lab, I have an older Synology DS411 that I picked up in early 2012. Note: I may receive commissions for purchases made through links in this post.
