Cross-Platform Backup Software

[Ian Petersen]

On 10/3/07, Kareem Shehata <kareem-d+8TeBu5bOew5LPnMra/2Q at public.gmane.org> wrote:
> This is exactly the type of problem that I'm thinking of.  Since this is a
> "production" server, how do I prevent the backup from suffering the same
> fate as the data in the event of a disaster?

When I "designed" my backup system, one of the first steps was to get
some new harddrives.  I have a mirrored pair of 250GB drives for my
main system, but I added a mirrored pair of 500GB drives to hold my
backups.  I figured that the backup drives won't get as much use as
the main drives (since I only ever write backups to them once a day),
so they're less likely to fail (short of the kind of failure that
takes out an entire machine).  On my todo list are getting a UPS to
help with power problems, and automated copying of the backup
repository to Amazon's S3, both of which are supposed to help with the
kind of failure that takes out an entire machine.

Regarding security, I followed the instructions at the rdiff-backup
wiki for an automated, unattended backup.  Basically, I have a user on
my system named backup that has write access to the backup repository,
sudo privileges for some very specific tasks, and nothing else.
Nobody but root and backup can read or write to the repository.

I backup my server and one of the laptops in the house (the other
laptop is also on the todo list).  The server backs itself up once a
day, shortly after midnight.  The laptop has a cronjob to initiate a
backup every time it boots.  It's a bit overkill, but I haven't spent
the time to save backup space by only following through once a day
because an incremental backup only cost a couple of megabytes, and the
transfer over an 11Mb wireless network takes less than a minute, so
the effort outweighs the savings.  The laptop initiates a backup by
ssh'ing to the server and using the at command to schedule a backup
some random number of minutes (between 5 and 20) from when the cronjob
executes.  (The randomness is there to reduce the perceived impact on
the system of doing a backup--my wife can't distinguish it from other
system processes--on the other hand, it might be a bit Rube
Goldbergish.)  The actual backup is controlled by the server, so I
occasionally get an error report saying that the backup terminated
unexpectedly or couldn't be started because the laptop wasn't on long
enough.  I just ignore these reports because rdiff-backup
automatically fixes an unfinished backup the next time it's run.

> Yea, I'm not sure that I like the idea of individual file diffs.  It just
> seems somewhat fragile, and that level of efficiency is really uncalled for
> in this application.

I'm not sure exactly what your concern is with diffs.  In
rdiff-backup's case, diffs are only used for previous versions--the
current version of the backup is always available as real files.  If
you run the backup process as root (not otherwise recommended) the
current backup is a mirror of the backed-up files, right down to
permissions and ownership.  If you run the backup as an unprivileged
user, the extra information that can't be recreated by the
unprivileged user is stored in ancillary data files.

On the other hand, I think rsnapshot keep full versions of every file
at every backup point and it saves space by reducing unchanged files
to single files with multiple hard links.

> Is there a better solution, or just use EXT2 and worst-case use a Live CD to read it?

I'd use a journalling filesystem if only to handle the unlikely
situation of a system crash _during_ a backup, so I wouldn't recommend
ext2.  My attitude towards readability is also that you just need to
keep around one system that can read the backup, which is probably the
machine that contains the backup itself.  If that system appears to be
"going out of style", then make a new system and copy the files over.
Ideally, you'll have two backups--one on-site and one off-site.  If
either one gets so hosed that you can't use the backup system itself
to read its backup, you need to rebuild that backup system anyway,
right?

Ian

-- 
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists