Anyone whose ever had to rebuild a server just fromtapes might agree

[cbbrowne-HInyCGIudOg at public.gmane.org]

> 
> >> 1. Getting a true backup of a system onto tape is often difficult due to
> >> open files of the OS and various(important)  data and programs.
> 
> IMHO, simply backing up to tape isn't enough. Tapes are slow write
> devices, and any changes to data during the write process isn't
> captured accurately. I also don't like backing onto tape direct from a
> live server for the same reason. A solution is simple as using rsync
> to copy the data to a back-up server so the data snapshot has a lower
> timestamp spread and make the backup to the tape from the snapshot.
> 
> This gives 2 copies of the data, and allows fast access to the most
> recent backup from a hard drive, and also gives you the time to make
> the tape transfer without any time pressures.

This _may_ be helpful, but isn't forcibly a solution.

I recall "bad old days'" of finding that Novell backups would NEVER do
successful backups of some MS Access databases because there would
perpetually be at least one user connected overnight that would outright
_prevent_ ArcServe from backing up the file.  (Because Novell Netware
would lock the files...)

The same is likely to be true for just about any sort of "database"
application; backup regimens MUST use database-specific tools in order
to get consistent backups.

Unix may not have the same sort of locking regimen as Novell; all that
means is that, on Unix, you'll silently get corrupted backups if you try
to back up data that is undergoing change.

The only relatively "safe" way to get a quasi-atomic backup is to use
LVM, so that you can atomically "split off" a temporary copy of the
filessystem.  That makes the backup "atomic," which can allow satisfying
databases' needs for consistency.  You may need to recover the database,
but that usually fits into its design.

The same is not likely to be true for half-written-to-disk document
files.
--
"cbbrowne","@","acm.org"
http://www3.sympatico.ca/cbbrowne/nonrdbms.html
Rules  of the Evil  Overlord #45.  "I will  make sure  I have  a clear
understanding of who  is responsible for what in  my organization. For
example, if my  general screws up I will not draw  my weapon, point it
at him,  say "And here is  the price for failure,"  then suddenly turn
and kill some random underling." <http://www.eviloverlord.com/>
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml