> -----Original Message----- > From: redhat-list-bounces@xxxxxxxxxx > [mailto:redhat-list-bounces@xxxxxxxxxx]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 -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
