<div><span class="gmail_quote">On 10/21/05, <b class="gmail_sendername">Scot Jenkins</b> <<a href="mailto:scotjenkins@gmail.com">scotjenkins@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>tar is probably going to be the most portable and is not filesystem<br>specific. If you currently have an ext3 filesystem and later decide
<br>to move to xfs or reiserfs, tar will allow you to do that. dump on<br>the other hand will not. There are supposedly corruption issues with<br>ext3 and dump with the 2.4 kernels.<br><br><a href="http://dump.sourceforge.net/isdumpdeprecated.html">
http://dump.sourceforge.net/isdumpdeprecated.html</a><br><br>That said, I've used both tar and dump for years without problems, and<br>I have restored a number of systems due to failed drives. I run a<br>full (dump level 0 once/wk) and partials (dump level 1) the other 6
<br>days of the week. I dump to an NFS mounted partition and that goes to<br>tape once/wk. It works well for me.<br><br>Make sure you have statically linked versions of whatever program you<br>need to restore your backups: restore(1), tar(1), etc. Otherwise
<br>you're the media you boot off of to do the restore will need to<br>contain the required libraries. RH used to have a separate package<br>that contained a statically linked version of /sbin/restore<br>(dump-static, I think it was called). Debian stable ships a
<br>dynamically linked version of dump/restore so it's an issue on that<br>OS.<br><br>/tmp by nature, is "temporary" so you might choose not to back that<br>up. Just make sure you inform your users of that if you decide NOT to
<br>back it up.</blockquote>
<div> </div>
<div>What are your filesystems like? Is each one a physical or logical partition of a drive instead of an lvm controlled filesystem within a volume group?</div></div>