What are you backing up to? The procedure I use is to copy all home directories from one machine to another every night from the backup server: rsync -arp --delete -e /usr/bin/ssh mainserver:/home /home I have RSA keys in place to avoid password prompts... ----- Ryan Golhar Computational Biologist The Informatics Institute at The University of Medicine & Dentistry of NJ Phone: 973-972-5034 Fax: 973-972-7412 Email: golharam@xxxxxxxxx -----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. Reading the arguments including Linus Torvalds's comment ' Right now, the cpio/tar/xxx solutions are definitely the best ones, and will work on multiple filesystems (another limitation of "dump"). Whatever problems they have, they are still better than the _guaranteed_(*) data corruptions of "dump".' I was and am still convinced that 'dump' is not the way to go under linux. So I've spent some time scripting to marry in 'tar' backups for recently acquired Linux machines with a backup system that uses 'dump' for our unix machines. Yesterday I ran this for the first time on one of the Linux machines and found the backup aborted with the following error in the log file: /bin/tar: /home/thi/OM5438/test.hir1: file changed as we read it /bin/tar: Error exit delayed from previous errors Backup /data/pstar/root-0-z.tgz FAILED at Wed 18 Aug 2004 15:29:20 CST 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. So is there someway to get 'tar' to continue when an odd file or two exhibits this sort of problem? I know about the option: --ignore-failed-read don't exit with non-zero status on unreadable files but from my interpretation of the man page it is not relevant to this problem. Does 'cpio' have the same problem? Some have suggested 'amanda', but my understanding is that this is just a wrapper that optionally uses 'dump' or 'tar' so this seems to take us nowhere. What else is there out there for backup? I am not looking for a backup system; just a reasonably reliable backup utility that can be used so that the linux machines can be incorporated into the backup system that works well for our unix machines. Some advice please. Malcolm Kay -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
