Linux backup
Kenneth Goodwin
kgoodwin at datamarktech.com
Thu Aug 19 12:34:28 UTC 2004
> -----Original Message-----
> From: redhat-list-bounces at redhat.com
> [mailto:redhat-list-bounces at redhat.com]On Behalf Of
Malcolm Kay
> Sent: Thursday, August 19, 2004 8:26 AM
> To: General Red Hat Linux discussion list
> Subject: Linux backup
>
>
> Some weeks ago I enquired here about 'dump' for
> use with ext3 file systems; and was strongly advised
> the Linux and 'dump' don't play well together.
>
> So 'dump' leads to corrupt backups, 'tar' leads to
aborted backups.
> The abort message is undoubtably correct -- the file in
question is a
> temporary file used during circuit simulation analysis.
Individual
> simululation runs can take from a few second upto a week.
So
> it is not
> practical to close down everything for backup. (If it was
then
> partitions could be dismounted for backup and the
principal problem
> espoused for 'dump' would disappear.) Such files are not
> crucial to the
> backup. If tar simply skipped them or indicated that they
> were corrupt
> in the archive while correctly preserving the rest of the
file system
> then this would be satisfactory -- but instead it aborts.
>
I use CPIO on all my systems, it whines about missing files,
etc, but does not abort.
You could use DD if you want something "dump" like.
But I stay away from dump and DD because it is a lot harder
to recover a system if the replacement
drive has a different geometry, etc as they are disk image
copies. You also have to fsck the filesystem
because it will be out of synch especially in your
environment where I/O is continuing to the drives
while backups are underway. So they really wont guarantee a
stable backup in your environment.
You can also use Legato's Networker (bought out by someone
else I hear... or other similiar
commercial solutions. Never had the problem with Legato
either and it can handle multiserver backup
to a single tape farm/jukebox
More information about the redhat-list
mailing list