Backing up active filesystems

Hi.

I'm going to be deploying a backup system for a small school with asingle file server, as well as possibly backing up some PC's remotely.I have not had any experience before in deploying one.

I'm going to be using DAT tapes in a DAT tape drive. For now, we can'tafford a backup drive with a tape changer, but that's all right. Wewon't have more than 20 GB compressed to back up to start with anyway.(And when we do, we can just throw in another tape drive, whichprobably is a lot cheaper.)


My question is, though, how do you handle filesystems that are active?

Do you have to schedule downtime, say between 0000 and 0600 everymorning? BSD dump does not do very well on active filesystems I'vegisted from amanda documentation, but according to GNU tar's manual:

Full dumps should only be made when no other people or programs aremodifying files in the filesystem. If files are modified while tar ismaking the backup, they may not be stored properly in the archive, inwhich case you won't be able to restore them if you have to. (Filesnot being modified are written with no trouble, and do not corrupt theentire archive.)

The same thing probably applies to incremental backups as well, no?Although according to your manuals, GNU tar ususally handles filesbeing modified quite well.

So, do I have to write a script that pulls the system into single usermode during the backup and remounts the filesystems read-only, or isthere a smart way you could perform backups anyway?

One theoretical way that I could think of spontaneously would be to usesome kind of journalling filesystem and tell it not to flush changes todisk while backups are being performed to prevent clashes.

Another way is to run a RAID-1 array and "simulate" a faliure, wherethe first disk would be the one being read/written to by people, andthe second disk would be used to back up from?

I guess the proper question is, how do people do this for HighAvailability servers in The Real World(TM)? Not that we'll be a HAserver, just that there may be some lessons to be learnt.


Thanks in advance!

--
Per von Zweigbergk <pvz AT e.kth DOT se>