Any advice on backing up the Drobo FS?

I’m using my Drobo FS as primary storage, with backups on my Time Capsule. I used to use SuperDuper when I was backing up local hard drives to disk images on the TC, but sadly I discovered that neither SuperDuper nor Carbon Copy Cloner are capable of using a network share as a backup source - which of course, the Drobo FS is.

How are others backing up the data on their Drobo FS units? I’d really like to set this up for incremental backup nightly - so one-way updates only (I definitely don’t want to set up any form of two-way synchronization, lest a bug or backup corruption propagate errors back to the original data).

Also if possible I’d like to avoid DroboApps, as I’ve read nothing but problems with them on this forum and their “unsupported” status. If such apps are the only way possible and using them won’t introduce security holes or risk data integrity, then alright - but only as a last resort.

Start Dashboard, righ click on icon in taskbar, “Drobocopy Settings”.

Edit: Don’t expect too much though, files and folders, so if you want to backup anything else besides that I’d suggest creating the backup file locally and then transfer it to Drobo, be sure to set time between local and network backup far apart :stuck_out_tongue:

I don’t run Drobo Dashboard except when I need to administer the FS, and I’d still need to run external scripts to mount external volumes and images. (Does DroboCopy handle incremental backups from the Drobo to elsewhere? Honestly, I’ve never quite understood the point of it - I must be missing something).

So far, SuperDuper and Carbon Copy Cloner are out (don’t work with network share sources). rsync looks like it’s out because it takes hours to scan all of the files to determine that nothing needs to be backed up. This is starting to look pretty hopeless for a nightly incremental backup.

I use Acronis to backup Drobo FS shares to (either network or local) dives.

I use ChronoSync to backup my entire DroboFS to an iSCSI JBOD. This has worked flawlessly. I will say that it is much slower than it used to be when backing up one FW800 to another, but almost positive that this is the “slow AFP with listing of small files” issue discussed elsewhere.

Hope that helps.

I HAVE been using SuperDuper to a DroboFS. There are instructions in the SD help file. Basically you have to create (within SD) a sparse bundle on the DroboFS.

True, except the question is backing up from a DroboFS. I’m using a somewhat hacked-together and customized rsync, but it doesn’t work terribly well (which is why I haven’t posted on it - still looking for a better solution).

Backing up the FS is so important and it’s a shame that there is no reasonably simple solution. Makes you wonder about the whole FS product philosophy, apart from the possibility that it doesn’t work with Lion anyways.


Well, it depends on what you want to back up. If you just want the files, that’s trivial. If you want to preserve Mac-specific metadata like icons, labels, comments, etc, that becomes very difficult. All of that data is handled by netatalkd, so there’s no way to access it without going through netatalkd. This means you can’t run it off the DroboFS itself; the backup must occur from another machine on the network that can mount the share via AFP (netatalkd) and understands the metadata (i.e. a Mac).

Then you’re stuck with finding Mac OS X software that will backup from a network share. This is actually very hard to do, as the file semantics are very different for local volumes and network volumes, and there are a lot of corner cases and things that “can’t fail” that do when you’re dealing with network volumes.

I think Carbon Copy Cloner added experimental support for backing up from a network volume. Since I’m looking for a more “script it and forget it” solution, I haven’t checked on how well it works, but it’s an option.

Backing up the FS is so important and it’s a shame that there is no reasonably simple solution. Makes you wonder about the whole FS product philosophy.


I agree with philip. Why Drobo can’t provide a software (App) on Drobo FS that makes Backup from Drobo to an other Device ore a Folder on Drobo self? Other NAS can do this!
i’m seeking a solution that makes every day an incremental backup to Drobo. So I could backing up the data from yesterday in case of a data losst.

I’m a lidle disappointed!


The tools you are after are called rsync and robocopy, linux and windows respectively.

For one thing, doing backup right is hard. Really Hard.

If you’re doing a block-based image of a disk, that’s simple - blast the bits at a file (dd or similar) and you’re done. But you can’t do incremental backups easily or efficiently. Backing up file data (and stripping away all metadata) is also fairly simple, although even so you’ll run into differences between timestamp accuracy on different filesystems which makes it very hard to tell if something changed or not (is the timestamp off because it changed, or because the filesystem is imprecise?). Throw a network filesystem like the DroboFS into the mix, and you bring on a whole host of other issues, especially the fact that network filesystems act very differently from local filesystems in ways that really mess with making a proper backup.

Even worse, If you do file-based backups properly, now you have to find some way of storing each OS’s metadata properly, whether that’s Spotlight info on the Mac, ACLs and file bits on Windows, permissions and such on Linux, etc. And now you have to make sure you can access that metadata over whatever protocol you’re connecting with (netatalkd, samba, nfs). And if you screw up any of it - you may have hosed someone’s data.

This is why we tend to pay money for backup solutions. Data integrity is paramount, and you want people who know the quirks of the platform you’re backing up, or else stuff breaks. Find a backup product for your platform (Acronis, Time Machine, SuperDuper to a disk image, etc) and use that. Trying to do a backup direct to a network filesystem is extremely hard to do without something going wrong.