Re: Incremental backup solution. was: What logs etc do I need tocheckfrequently?

2003-12-29 Thread C. Ulrich
On Mon, 2003-12-29 at 04:35, Joachim Dagerot wrote:
> This solution sounds nice, I can even imagine setting up an additional
> machine (on the same location though) to have a somewhat galvanic
> isolation between the disks. Only fire, earthquake and a neutronbomb
> would affect such a backup solution.
> 
> However, I could use a push in the right direction when it comes to
> how to configure and what software to use for achieving the
> incremental backup tasks.
> 
> Could you hint me in how your system is doing this in a more detailed
> way?
> 
> Cheers,
> Joachim

I'd be glad to. First, it's actually a Linux system, though there's
nothing particularly Linux-specific about it except the device names and
the method of spinning down the backup disk after the job. 

The cornerstone of the solution is the rdiff-backup program
(http://rdiff-backup.stanford.edu/ or in ports at
/sysutils/rdiff-backup). rdiff-backup is a python script that mirrors
one directory to another. It can do incremental backups and it can do
them either locally or remotely. It's really a slick piece of software
and I'm continually surprised that it doesn't get more publicity.

First, there's the (trivial) script /usr/local/sbin/backup-share.sh.
This is run by a daily cron job to backup directories on the disk that
contain Important Data. Mine is very specific to my system. It is *not*
pretty and I plan to overhaul it sometime soon to include error handling
and an external config file.

#!/bin/bash
# script to automatically back up the important stuff on /nfs/share
prog=/usr/local/bin/rdiff-backup
src=/nfs/share
dst=/backup/share
budirs="code emu images media music school software text webpage"
mount /backup
for dir in $budirs
do 
  $prog $src/$dir $dst/$dir
done
umount /backup
# put backup drive in sleep mode since we won't be needing
#   it again for the next 24 hours or so
hdparm -qY /dev/hdd

A note about the last line: it appears that FreeBSD can only spin-down
SCSI disks on command. (See camcontrol(8).) The best way to power down
IDE disks seems to be just setting a suspend timeout in the power
management section of your BIOS. Once the disk is unmounted, FreeBSD
won't touch it thereafter and the system should put it in suspend mode
automatically.

The crontab entry looks like this:

# backup selected dirs in /nfs/share @ 0730 daily
30 07 * * * sh /usr/local/sbin/backup-share.sh

That's really about it. Like I said before, moving the backup disk to a
separate machine would be trivial. If there are any questions, I'd be
glad to answer them.

Charles Ulrich
-- 
http://bityard.net

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Incremental backup solution. was: What logs etc do I need tocheckfrequently?

2003-12-29 Thread Joachim Dagerot
 | Before certain events in New York, we used to talk about
"hypothetical
 | jumbo jets" when considering our disaster plans.  Secure off-site
 | backups are a necessity.  Take care thought that the off-site
location
 | really is secure.  I did hear that some of the businesses in the
World
 | Trade Center had considered "the other tower" as a suitable
location
 | for their off-site backups.

I know a company whom's(?) office burned down to the ground. They
where saved by the secretary who forgot to put the backup-tape in the
safety box, instead she brought it in her handbag.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Incremental backup solution. was: What logs etc do I need tocheckfrequently?

2003-12-29 Thread Matthew Seaman
On Mon, Dec 29, 2003 at 10:35:49AM +0100, Joachim Dagerot wrote:
> This solution sounds nice, I can even imagine setting up an additional
> machine (on the same location though) to have a somewhat galvanic
> isolation between the disks. Only fire, earthquake and a neutronbomb
> would affect such a backup solution.

Before certain events in New York, we used to talk about "hypothetical
jumbo jets" when considering our disaster plans.  Secure off-site
backups are a necessity.  Take care thought that the off-site location
really is secure.  I did hear that some of the businesses in the World
Trade Center had considered "the other tower" as a suitable location
for their off-site backups.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   26 The Paddocks
  Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614  Bucks., SL7 1TH UK


pgp0.pgp
Description: PGP signature