Now that I’ve covered how to backup a Synology NAS to Amazon Glacier in this post, I thought it would be appropriate to go through the process for network backups. Fortunately, a large capacity ioSafe 1513+ review unit has landed in my lap thanks to the friendly folks over at ioSafe, which lets me experiment with realistic use cases for network backups. Also, Synology released DSM 5.1, which has forced me to delete the content I had written earlier and completely re-write this post using their newer features. So be it!

Let’s get nerdy.

Upgrading to DSM 5.1

The first step in this process is to validate that your Synology NAS is running DSM 5.1. It just came out a short while ago, so chances are you’ll need to take a quick outage window to push the update. Once completed, your array is going to undergo a consistency check and offer this DSM Update Settings menu upon first login.

I opted for the third option – which avoids any automatic updates – just to get passed the screen.

Because I have four different arrays, I control update settings via Central Management System (CMS) on my DS2411+.

As soon as the array connects into CMS, my policy is pushed into the box (which is to download important updates but not apply them). Otherwise, managing so many NAS boxes would be a pain.

It’s a very handy feature that lets you scale out without adding much additional overhead for day-to-day administration tasks. I will likely create a new policy for my capacity arrays to auto-update (NAS1 and NAS4), but will keep a tight leash on the updates applied to my arrays that are running virtual machines (NAS2 and NAS3).

ioSafe as a Backup Target

Back to what I was saying about ioSafe. The review unit I have is the ioSafe 1513+ with Data Recovery Service, which is a fireproof and waterproof safe with a 5-bay Synology 1513+ inside; details can be found on the ioSafe website. It has eSATA and USB ports, along with 4x 1GbE interfaces, with about 60 pounds of solid protection wrapped around the NAS inside (I felt bad for the poor UPS delivery person who had to bring this to my door). I still think it’s relatively compact for what it does, and I have it sitting on the bottom shelf of my home lab rack.

Here’s a few photos to get your head wrapped around the array look and feel.

I took apart the waterproof enclosure to check out the drives. It’s serious business, requiring a hex tool to get the front face plate off, followed by a waterproof shield that is sealed up against the drive enclosure. Here’s a pic of the five SATA drives sitting at the heart of the ioSafe.

Although a good number of folks were enthusiastic about testing ioSafe’s claims around the 1513+ being fireproof and waterproof, I have yet to validate the claims. Mostly because the rest of my gear is certainly not happy about fire nor water, and I think my neighbors might call 911 if they saw me burning and then hosing off a “mysterious black box” in my yard.

Let’s just take this one on faith, OK? 🙂

Configuring a Backup Destination

The first thing I like to do is configure t he backup destination on the source NAS. This is done by opening up Backup & Replication > Backup Destination. Once there, create a new network backup destination.

If you spotted that Public Cloud option as something new to DSM 5.1, you win a prize. You’re now granted the ability to use public cloud backups like Microsoft Azure, CHT hicloud S3, and SFR Stockage. However, that’s another post entirely.

Continuing on with the network backup destination configuration, input your remote server details. In my case, it’s Synology to Synology replication, but any rsync server will do the trick.

Now you can choose a few different methods for backup.

• Back up data to volume: The nice thing here is that I get versioning and deduplication. This is what I’m going to choose.
  • Backup destination name: Name the backup destination something interesting.
  • Volume: My ioSafe is a single, giant volume. I usually don’t mess around with Disk Groups or multiple volumes, so /volume1 is the only choice. It’s up to you how you slice and dice your box, but I’d advise keeping it simple.
• Back up data to remote shared folder: I haven’t enabled the network backup service on my ioSafe, and so the second option is grayed out. This might be a good way to do file mirroring, but I’m looking for more of a backup solution with versioning.

Once you click apply, the destination is created. If you browse the Backup & Replication menu on your target NAS, you’ll see the destination side of the backup set. It was auto named Local Archiving Storage 1.

Creating a Backup

Make sure you’re back on the source NAS. Head to Backup & Replication > Backup > Create. I’m going to create a new data backup because I don’t have any of those silly LUN things. Select your existing backup destination that was created in the previous section.

Next, you’ll get to choose which folders are worth backing up. I’m going to pick my Code folder because it’s small and easy to demonstrate in this post.

The last step is to set a schedule. I turn off the thumbnail backups because I don’t want those little buggers, but you might. I’m also not going to set a schedule in this example, but rather back up the data a bunch of times to show how that looks. You can edit the scheduler later, if desired.

Kicking Off a Backup

I’ll go ahead and send over a few backups manually to populate the destination array with some backup sets. Just select the backup and click the Backup Now button at the top.

After a short bit of time, my small backup job is done. I repeated the process two additional times.

Validation of Stored Backup Tasks

Backups are worthless unless you can restore them, so let’s validate that we have data first, and then restore it in the next section. Browse to the backup NAS and find the local archive.

Expand the Local Archiving Storage 1 set to see more details.

Click on the clock icon to view backups.

There they are! And all of them show successful, which is good. Note that you can also delete backup versions from here by selecting a backup and clicking the Delete button.

Restoring a Backup Version

There’s two ways to do a restore:

1. Pull your backup data back to the source NAS and restore to the original location. For when you goofed a file and need to get it back, similar idea to Volume Shadow Copies.
2. Restore your backup data to the remote NAS using a new shared folder with identical names and structure. If your source NAS is dead or  unavailable, this is likely the route to go.

Both processes are quite similar to one another. The major difference is that a source NAS restore must go out over the network to get the backup data, while the backup NAS considers the restore to be local.

If you’re on the source NAS, head to Backup & Replication > Restore, then select your backup job and click Restore. Or, you can choose the Restore From… button to find some other backup set.

If you’re on the remote NAS, head to Backup & Replication > Restore, then choose Restore From… and choose Data. Then pick the Local Restoration option.

The next few steps will assume that you’re restoring files to the backup NAS, and will be from the perspective of my ioSafe (which is holding the backups). I’ll want to restore data from my volume, and specifically the Code Backups task.

I’m going to skip restoring the system configuration because I don’t care about it. These are just files. I can, however, pick a specific point in time to restore. Choose a path to restore, then either use the left and right arrow graphics or click on the number of backups. In the screenshot below, I clicked on the number 3, which opened up a menu showing each backup timestamp. I then chose the latest timestamp, the one that says 12:08:12, for my restore.

And finally, a summary of the restore details before committing. You can see that the restore will be local on the ioSafe, in Volume 1, to a new shared folder (that it will create) called Shared/Code.

Progress is displayed while you wait on the restore. The paltry 9.22 MB I backed up was instantly restored.

And here’s my new shared folder on the ioSafe with the files restored. The same ACLs were applied, too.

That’s pretty much it.

Why Local Backups?

While I do like the idea of getting data off my site via Amazon Glacier, it’s a very sluggish process to get data back out, and potentially costly for single file / folder restores. The idea of having data in a fireproof and waterproof safe is a nice mix: I get speedy restores and access to my data (using either versioned backups or file sync) while still having some trust that it can survive something nasty.

A diskless ioSafe 1513+ lists for $1,999.99 with a 1 year warranty, but I’ve seen it a tad lower on the street. You can scale the box 5 TB – 90 TB on the configuration page, with 1, 3, or 5 years of Data Recovery Service (which they shorten to DRS). The idea behind DRS is that you get a one shot access to data and hardware recovery services. They’ll pay to ship your unit back to their HQ and recover your data, then ship back a replacement product with your data intact. If they can’t do this, they’ll pay a 3rd party ninja data service to extract your data. It looks like they’ll shell out $2500 per TB of data (or more) in 3rd party services fees. It’s nice knowing that my review unit (10 TB) is covered by $25K worth of data recovery protection. 😉

I can see a hybrid strategy here. Either use an ioSafe as primary storage, or as a central backup storage fed by smaller NAS boxes (like I’m doing), and trust that the few grand you’ve put into the box will keep your data safe. Additionally, do daily or weekly backups into a public cloud for epic levels of backup safety. If you need to restore because someone goofed, you have a local copy. If something horrible happens, the ioSafe should be able to survive it, and you can get back up and running elsewhere like a Regus office or shared work space. And if that all fails, you have the cloud backup as your final line of defense.