Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Dec 2003 11:14:14 -0500
From:      "C. Ulrich" <>
To:        Joachim Dagerot <>
Subject:   Re: Incremental backup solution. was: What logs etc do I need tocheckfrequently?
Message-ID:  <>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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
( 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/
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.

# script to automatically back up the important stuff on /nfs/share
budirs="code emu images media music school software text webpage"
mount /backup
for dir in $budirs
  $prog $src/$dir $dst/$dir
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

The crontab entry looks like this:

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

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

Want to link to this message? Use this URL: <>