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