Full Backup - Off-Site

[johnbentleyii]

I am using Retrospect 7.7 SBS and have requirements to backup to perform a full backup to a removal drive each day. I have tried a couple of different schemes but have run into problems with each.

 

What Backup Script and Backup Set domination would be best suited for performing a full backup each day to a removable hard drive cartridge?

 

Thanks!

[Richy_Boy]

It would probably help to tell us what you have already tried so we don't cover old ground...

 

Assuming these drives will be rotated then it would be easiest to setup an off site script for each day of the week (or at least for each disk you're rotating). If you already have backup stored on your network then you can just do a backup set copy so your machines don't get hit with a second backup during working hours.

 

Assuming there's a disk per day then don't recycle the backup set, just do a 'normal' backup which will add a weeks worth of changes to the backup set.

 

Just plug the correct days disk into the server (hotswap or USB caddy) and when the script launches it'll copy the required data to that backup set, ready to take out the office.

 

Don't forget though, if you put the wrong disk in on the wrong day the backup will stall waiting for the correct backup set/disk to inserted.

 

I used this system for a few years and it worked really well - I have more recently switched to an rsync-over-ssh duplication over the internet so I don't have off site backup problems if I'm ill or forget to bring the offsite disk in!

 

Something I found odd which I would class as a bug (?) is that when a user tries to recover a file then Retrospect will sometimes try and access the off site disk instead of the internal 'master' copy. Very odd..

 

Rich

Edited May 4, 2010 by Guest

[robertdana]

This all hinges on what you consider to be a "full" backup.

 

Retrospect is VERY DIFFERENT from other backup systems and doesn't follow the normal full / differential / incremental regime. The first time you back up to a backup set is a "full". Each subsequent time is something like an "incremental", in that only the changed files are backed up.

 

The difference is most obvious at restore time. In normal backup systems, you have to restore the most recent "full", and the the most recent differential, and then each incremental that has happened since that differential. This is painful, and is one of the reasons why people specify things like "full backup every night".

 

How Retrospect works: each backup to a backup set looks like a "full" backup at restore time (even though only changes were copied). It hides all of the "incremental" complexity, and when you restore from the most recent snapshot in a backup set, all of the files are put back just like it was a "full" backup in a traditional system with a single operation. So you get the efficiency of incrementals, but the convenience of "fulls".

 

So in other words, a "full" backup every night in the traditional sense is not the "retrospect way". There's literally no way to store more than one full backup in a backup set. Relax. This is OK. The system works very well the way it was meant to be used.

 

If you are in some way forced by inflexibly-enforced requirements to do a true full backup every night, the key is to do a "recycle" before each backup, which will blank the previous backup and force a full. "Recycle" is an action available in the script scheduling, so you can set up a "recycle" to occur a few minutes before the backup. You'll have to explicitly schedule each day's backup set. Things will not fail gracefully if the wrong disk is inserted. If you need to keep multiple week's worth of history, you'll have to have separate removable disks / backup sets for each day / week combination (Week1Monday, Week2Monday, etc...). This is a REAL pain to administer.

 

The "right way" would be to create a single backup set for each day of the week, and throw them all into a proactive backup script. The server will automatically back up to whatever set is attached, so you'll get a backup even if someone forgets to change the media. The main downside of a proactive script is that you won't get errors if a particular volume or host isn't available to be backed up. Just let the incrementals build up over time, then recycle or groom as needed.

[railes]

Can I ask here why you would not advise John to run a "Duplicate" script onto his removable hard drive, choosing the "replace all contents" option? Then he gets a mirror copy of his data, a full backup as he needs, everytime he uses the removable.

[rhwalker]

Or, my suggestion would be to set up a RAID 1 mirror, then split the mirror at an appropriate time, giving an instantaneous copy. That's how we (and many others) have always cloned our servers while keeping them up. There are a few minor details to watch (shut down services and databases prior to the mirror split so that everything is sync'd to disk, etc.).