On 10/21/05, Shawn Fertch <sfertch at gmail.com> wrote: > > > I've been working on an OS backup script off and on for a little while, but > have as of yet come up with a good solution that can fit as universally > across all Linux systems in house. I've gotten to the point where I need to > get it done, tested and put into production over the next couple of days. > Any help or guidance on this would be beneficial. tar is probably going to be the most portable and is not filesystem specific. If you currently have an ext3 filesystem and later decide to move to xfs or reiserfs, tar will allow you to do that. dump on the other hand will not. There are supposedly corruption issues with ext3 and dump with the 2.4 kernels. http://dump.sourceforge.net/isdumpdeprecated.html That said, I've used both tar and dump for years without problems, and I have restored a number of systems due to failed drives. I run a full (dump level 0 once/wk) and partials (dump level 1) the other 6 days of the week. I dump to an NFS mounted partition and that goes to tape once/wk. It works well for me. Make sure you have statically linked versions of whatever program you need to restore your backups: restore(1), tar(1), etc. Otherwise you're the media you boot off of to do the restore will need to contain the required libraries. RH used to have a separate package that contained a statically linked version of /sbin/restore (dump-static, I think it was called). Debian stable ships a dynamically linked version of dump/restore so it's an issue on that OS. /tmp by nature, is "temporary" so you might choose not to back that up. Just make sure you inform your users of that if you decide NOT to back it up. Scot