Protecting data on Mac server?
August 2, 2005 2:01 PM Subscribe
Mac OSX Server Backup question: what's the best way to ensure that my small office doesn't lose the data we store on our file server? Right now we use Retrospect with a tape drive, but it's not an ideal solution, because finding stuff on the tape is a huge pain, and the time required to maintain it is lost time. Should we go with a portable external hard drive (someone brings the tapes home just in case of fire or explosion)? Or purchase an off-site solution?
Perhaps an offsite solution is for you if you consider the maintenance of your backups 'lost time'. Then you will be buying someone elses time instead of spending your own.
Seriously, and not to be catty, Retrospect and a tape drive (I assume its DDS 3 or 4 at least?) is a very cost-effective solution for a small office backup. Depending on your backup schedule you may spend more time each week getting the data onto a removable drive, which Retrospect could also do. And you should also rotate a backup offsite at least weekly, for just the reasons you list.
Before you abandon Retrspect you should examine why your users keep requesting you to find stuff off the tapes (do they consider them archives rather than disaster recovery tapes?); and make a case to management that time spent maintaining the backups is not 'lost', but rather an essential insurance program. Surely losing the knowledge base of the entire company would be a greater loss.
posted by pgoes at 3:26 PM on August 2, 2005
Seriously, and not to be catty, Retrospect and a tape drive (I assume its DDS 3 or 4 at least?) is a very cost-effective solution for a small office backup. Depending on your backup schedule you may spend more time each week getting the data onto a removable drive, which Retrospect could also do. And you should also rotate a backup offsite at least weekly, for just the reasons you list.
Before you abandon Retrspect you should examine why your users keep requesting you to find stuff off the tapes (do they consider them archives rather than disaster recovery tapes?); and make a case to management that time spent maintaining the backups is not 'lost', but rather an essential insurance program. Surely losing the knowledge base of the entire company would be a greater loss.
posted by pgoes at 3:26 PM on August 2, 2005
We also use Retrospect and a tape drive to backup the Macs in our small office. How often are you having to go back to the tape?
(And hopefully someone is already taking out-of-rotation tapes off-site already.)
posted by lpqboy at 3:35 PM on August 2, 2005
(And hopefully someone is already taking out-of-rotation tapes off-site already.)
posted by lpqboy at 3:35 PM on August 2, 2005
How much data are you talking about?
posted by realcountrymusic at 3:52 PM on August 2, 2005
posted by realcountrymusic at 3:52 PM on August 2, 2005
I've asked this before, but never received a response so please forgive the slight derail - why do you all recommend Retrospect so highly? I use it (v6.5) at work to backup two Windows 2003 servers to LTO2 tape, and I find the interface to be nigh-on incomprehensible. Perhaps it's a Windows/Mac thing and the Mac version is easier to use?
I mainly mention this because I've had similar issues, which may be what miss tea is seeing -- in order to restore a file from tape, you must first select the tape, choose a snapshot (that isn't clearly labelled as a snapshot of anything in particular ("D:" on the db server? The exchange server??)), state to where you wish to restore the file, and only then are you able to search for the file.
For contrast, BackupExec / ArcServe offer a folder list of the catalog _first_, so you can see if the file has even been backed up.
posted by coriolisdave at 4:10 PM on August 2, 2005
I mainly mention this because I've had similar issues, which may be what miss tea is seeing -- in order to restore a file from tape, you must first select the tape, choose a snapshot (that isn't clearly labelled as a snapshot of anything in particular ("D:" on the db server? The exchange server??)), state to where you wish to restore the file, and only then are you able to search for the file.
For contrast, BackupExec / ArcServe offer a folder list of the catalog _first_, so you can see if the file has even been backed up.
posted by coriolisdave at 4:10 PM on August 2, 2005
In order to restore a file from tape, you must first select the tape, choose a snapshot (that isn't clearly labelled as a snapshot of anything in particular ("D:" on the db server? The exchange server??)), state to where you wish to restore the file, and only then are you able to search for the file.
You're doing it wrong, unless I'm losing my mind in remembering that the Windows version works like the Mac version. To restore from backup, first you pick where to restore it (it can be on the local drive or on a remote machine), then you pick the backup script you want to restore from which will permit you to search all backup sessions and volumes for that script, then you search for the file(s), then it tells you which tape to pull, then you pop the tape in the drive, then it finds the file on the tape and restores it. If you've labeled your tapes so that they match the backup script name, it's easy. You can also view the backup catalog, too, of any session.
To answer the poster's question: Off-site solutions are expensive and not practical unless you can manage them yourselves, typically only a choice made by large companies. For most small offices, say, of 75 employees or less, a tape solution is perfect. I used to recommend a Firewire-based VXA solution. With Retrospect, once the backup scripts are in place, it's a cinch to manage—the most hassle is managing the tapes, but with a rotating system, you always have one tape (or set of tapes) out of the office, one set of tapes set for the next backup, and one set of tapes (usually the previous day's or week's) on hand to recover from if necessary. It's still far, far less of a hassle than losing your data.
posted by Mo Nickels at 4:47 PM on August 2, 2005
You're doing it wrong, unless I'm losing my mind in remembering that the Windows version works like the Mac version. To restore from backup, first you pick where to restore it (it can be on the local drive or on a remote machine), then you pick the backup script you want to restore from which will permit you to search all backup sessions and volumes for that script, then you search for the file(s), then it tells you which tape to pull, then you pop the tape in the drive, then it finds the file on the tape and restores it. If you've labeled your tapes so that they match the backup script name, it's easy. You can also view the backup catalog, too, of any session.
To answer the poster's question: Off-site solutions are expensive and not practical unless you can manage them yourselves, typically only a choice made by large companies. For most small offices, say, of 75 employees or less, a tape solution is perfect. I used to recommend a Firewire-based VXA solution. With Retrospect, once the backup scripts are in place, it's a cinch to manage—the most hassle is managing the tapes, but with a rotating system, you always have one tape (or set of tapes) out of the office, one set of tapes set for the next backup, and one set of tapes (usually the previous day's or week's) on hand to recover from if necessary. It's still far, far less of a hassle than losing your data.
posted by Mo Nickels at 4:47 PM on August 2, 2005
Mo Nickels: the biggest problem seems to be historical backups - restores from an end-of-year tape, for instance, require that the catalog be rebuilt (fair enough). Despite specifying that the catalog be rebuilt to a different file location, it still uses the same name as the original tape (eg, Wednesday). So when you restore the old Wednesday catalog, you lose your current Wednesday catalog. And it takes ALL Wednesday tapes out of the tape cycle.
This may be a reflection of our tape-rotation, and Retrospect would prefer us to have each tape labelled individually (having Wednesday A/B/C/etc rather than whipping "Wednesday" out of rotation, but that would require figuring out ahead of time (i.e. when setting up the backup script) which tapes will be end-of-month/year/etc.
Also, it doesn't support five-friday weeks as part of a normal rotation. Grr!
posted by coriolisdave at 5:10 PM on August 2, 2005
This may be a reflection of our tape-rotation, and Retrospect would prefer us to have each tape labelled individually (having Wednesday A/B/C/etc rather than whipping "Wednesday" out of rotation, but that would require figuring out ahead of time (i.e. when setting up the backup script) which tapes will be end-of-month/year/etc.
Also, it doesn't support five-friday weeks as part of a normal rotation. Grr!
posted by coriolisdave at 5:10 PM on August 2, 2005
Of course, that should be five-friday months. Don't mind me ;)
posted by coriolisdave at 5:27 PM on August 2, 2005
posted by coriolisdave at 5:27 PM on August 2, 2005
that would require figuring out ahead of time (i.e. when setting up the backup script) which tapes will be end-of-month/year/etc.
You should have a separate end-of-month backup script, probably, and they should be set to ask for new media every time, or something similar. Alternatively you could start a new StorageSet every month -- that's probably what I would recommend. That way each month's backups are self-contained and doesn't rely on any previous month.
Also, no, restoring shouldn't require the catalog to rebuilt no matter how old the tapes are. The whole idea of the catalog is that it stores information on every file backed up ever, so you won't have to do time-consuming things like searching every tape for the file you want.
Searching, by the way, can span multiple catalogs, if you hadn't noticed that.
I find the interface to be nigh-on incomprehensible.
Yes, that's largely true, but that's because the program needs to be able to adapt to whatever the local backup policy is. In a large company, management decides the backup policies and the software is required to implement those policies; they don't get the software first and look at what it can do and then make their policies. For this reason Retrospect has a lot of features that make a good deal of sense in enterprise environments but are just complete overkill and obfuscation for single-user and even small companies.
posted by kindall at 5:30 PM on August 2, 2005
You should have a separate end-of-month backup script, probably, and they should be set to ask for new media every time, or something similar. Alternatively you could start a new StorageSet every month -- that's probably what I would recommend. That way each month's backups are self-contained and doesn't rely on any previous month.
Also, no, restoring shouldn't require the catalog to rebuilt no matter how old the tapes are. The whole idea of the catalog is that it stores information on every file backed up ever, so you won't have to do time-consuming things like searching every tape for the file you want.
Searching, by the way, can span multiple catalogs, if you hadn't noticed that.
I find the interface to be nigh-on incomprehensible.
Yes, that's largely true, but that's because the program needs to be able to adapt to whatever the local backup policy is. In a large company, management decides the backup policies and the software is required to implement those policies; they don't get the software first and look at what it can do and then make their policies. For this reason Retrospect has a lot of features that make a good deal of sense in enterprise environments but are just complete overkill and obfuscation for single-user and even small companies.
posted by kindall at 5:30 PM on August 2, 2005
pgoes makes an excellent point- Tape backups are a necessary evil for disaster recovery, but a poor archiving tool. If your users are coming to you for a file they worked on last year, as opposed to something they accidentally deleted, consider a true archiving tool like Cumulus or MediaBeacon. Get yourself a nice, keyworded catalog and start burning CD's.
posted by mkultra at 5:44 PM on August 2, 2005
posted by mkultra at 5:44 PM on August 2, 2005
Tape backups are a necessary evil for disaster recovery, but a poor archiving tool...Get yourself a nice, keyworded catalog and start burning CD's.
I disagree. Tapes are perfect for archiving: they have a higher per-unit capacity, are easily indexed with backup software like Retrospect, and, most importantly, they last longer. CDs, like floppies, should be used for short-term storage only. Clients have lost so much data by storing it on CDs, and so have I. The capacity issue cannot be over-emphasized, at least in a creative environment. It's not uncommon for a single project to spawn gigabytes of data. CDs simply won't cut it, and data storage on DVDs is just as volatile as on CDs.
If you're using Cumulus or MediaBeacon, you're not actually archiving your data. You're simply storing it in a different place—a place which needs its own backup.
posted by Mo Nickels at 6:20 PM on August 2, 2005
I disagree. Tapes are perfect for archiving: they have a higher per-unit capacity, are easily indexed with backup software like Retrospect, and, most importantly, they last longer. CDs, like floppies, should be used for short-term storage only. Clients have lost so much data by storing it on CDs, and so have I. The capacity issue cannot be over-emphasized, at least in a creative environment. It's not uncommon for a single project to spawn gigabytes of data. CDs simply won't cut it, and data storage on DVDs is just as volatile as on CDs.
If you're using Cumulus or MediaBeacon, you're not actually archiving your data. You're simply storing it in a different place—a place which needs its own backup.
posted by Mo Nickels at 6:20 PM on August 2, 2005
Sure, backup your data.
I'm surprised nobody has mentioned yet...
Add a raid 1 or a raid 5 (or a raid 10 if necessary).
I don't know if your server configuration has that laready (or possibly all OSX servers do, I searched apple's site and it didn't tell.)....but if you're not running a raid, this would be the first thing I'd do to insure data safety.
posted by filmgeek at 6:27 PM on August 2, 2005
I'm surprised nobody has mentioned yet...
Add a raid 1 or a raid 5 (or a raid 10 if necessary).
I don't know if your server configuration has that laready (or possibly all OSX servers do, I searched apple's site and it didn't tell.)....but if you're not running a raid, this would be the first thing I'd do to insure data safety.
posted by filmgeek at 6:27 PM on August 2, 2005
I use a series of 40GB Firelight Firewire drives, rotating through them like tape drives, using Carbon Copy Cloner. It's relatively cheap, totally easy to retrieve data from, and is as straightforward as it gets. Once a month, a DVD is burned and put in the safe deposit box.
I've had tapes break -- once when retrieving data. The drives have to be cleaned all of the time. They're expensive, slow, and noisy. I hope never to use them again.
posted by waldo at 9:03 PM on August 2, 2005
I've had tapes break -- once when retrieving data. The drives have to be cleaned all of the time. They're expensive, slow, and noisy. I hope never to use them again.
posted by waldo at 9:03 PM on August 2, 2005
Response by poster: Thanks, all. The main problem with the current system is, in fact, that it is nigh impossible to recover specific files, which is time-consuming and annoying. The distinction between archiving and backing up is a good one; however we are a tiny organization (6 people) and ANY time devoted to this stuff is wasted time, in my view. We don't have a dedicated IT department or anything like that-- we have an Art Director who deals with the tape drive.
It sounds like the problem is that he doesn't really understand how the cataloging system works, or it's set up poorly. I'll devote my energies in that direction.
posted by miss tea at 9:56 AM on August 3, 2005
It sounds like the problem is that he doesn't really understand how the cataloging system works, or it's set up poorly. I'll devote my energies in that direction.
posted by miss tea at 9:56 AM on August 3, 2005
data storage on DVDs is just as volatile as on CDs
Actually, way more volatile. DVD discs need to store 7-8 times as much data on the same surface area as a cd. This means even smaller amounts of damage can destroy larger amounts of data, or an entire disc. In the archiving trade, the conventional wisdom is that DVD is the worst choice for backup.
posted by realcountrymusic at 6:35 AM on August 5, 2005
Actually, way more volatile. DVD discs need to store 7-8 times as much data on the same surface area as a cd. This means even smaller amounts of damage can destroy larger amounts of data, or an entire disc. In the archiving trade, the conventional wisdom is that DVD is the worst choice for backup.
posted by realcountrymusic at 6:35 AM on August 5, 2005
DVDs were designed for video, not data. If a bit or two is missing, a video can go on with no noticable glitch. Your backup won't be so lucky.
posted by voidcontext at 2:00 PM on January 12, 2006
posted by voidcontext at 2:00 PM on January 12, 2006
This thread is closed to new comments.
posted by kindall at 3:16 PM on August 2, 2005