XServe-RAID Offsite Backup

Question

I was hoping to use the left controller of the RAID to backup all my clients using TimeMachine and then have the right controller mirror that on the fly (so that would be RAID 50). I was then hoping that I could swap out ALL the right controller drives to store them off-site each week.
Would that plan be possible do you think? OK to take out all drives from the right controller at the same time, leaving the left RAID5 running on its own until the new set is put into the right controller to rebuild the RAID50 again? Make sense? Possible?
Thank you, Grant

Answer 1

However there just doesn’t appear to be any failsafe easy solution to backup the XServe RAID for offsite storage is there. Is is quite unfortunate and surprising and I would have thought there would have been a methodology worked out for this somewhere. But from what I am hearing, there isn’t.
Xserve RAID is a storage array box, and (somewhat confusingly) it's exceedingly uncommon to back up "just a storage box." I do know a few storage controllers that offer replication capabilities, but I'm extremely suspect that the tools work reliably. Storage controllers don't have all of the context on the processing that they need to perform reliable data replication; to ensure consistency.
It's common to perform remote replication via network and tools are available to do that. You almost certainly will end up with local customizations here, too.
The tools are specific to particular application storage involved; there's no Server Time Machine here, as you need use (for instance) mysqldump or you need MySQL replication for a MySQL database, and a different tool for another database. Or you need quiesce the databases.
Which leads various folks to punt on the process, to shut down down the server, and block-clone the disks involved. To quiesce the server. That too can likely be automated, with some scripting and a controlling host.
As for the remote storage (when not using a network), getting the data off-site then depends on what removable media is available. Ultrium tape has decent capacity and good physical reliability and speed, but tends to have poor support on Mac OS X Server, and Ultrium drives and loaders tend to be expensive. Removable disks do reasonably well here, and various options are available, but they're less physically reliable than tapes. For tens of gigabytes, flash media is a potential option, though it's not the speediest of storage.
Networking can be an option here for remote storage, depending on how small your delta (churn) and how good your compression is and how big your network pipe might be; your network pipe has to be big enough to manage your maximum available window.
If you're looking for turn-key, there are commercial products which claim to deal with this stuff. And unless they're using mysqldump or such for databases, I'm professionally skeptical at the integrity of the archives they create on an active server. (I've watched the storage and data archive folks claim to have solved this for thirty years now. They can mostly solve it, too, for some values of mostly.)
[Here is a MySQL mysqldump|http://labs.hoffmanlabs.com/node/1336] procedure, which can serve to show how to do daily, weekly or monthly archives, and how to run mysqldump tool from bash.
(I am aware of one operating system that can mirror active disk data across a data link and across hosts and across storage controllers and can operate with fully distributed shared write, and that OS obviously and specifically targets high-uptime environments, but that OS environment is not cheap. And it's not Mac OS X Server. And even that environment can't correctly capture an active database for an offline archive; even there, you need to quiesce the database or use database-specific tools.)
It'd be feasible for somebody to create a (big, hairy) tool to catch all the usual suspects on a Mac OS X Server box. But then you have to maintain it across all of the slightly-weird installations, and you also have to deal with restorations. (I'd love to write a generic one of these; this would necessarily be a superset of Time Machine. This is a big and complex project, and one that would require extensive testing.)
Server boxes are not client boxes. Servers require real work and real thought and real configuration. And as production requirements increase, they also tend to require some knowledge of the shell and of scripting and writing (or acquiring) some site-management tools.