It just so happens, I use dump/restore all the time. Occasionally I post a very detailed message to this group. ;-)
Dump/restore is written by the same guys who write the ext3 code. In fact, dump/restore is part of the ext3 package, just like mkfs.ext3 is part of that package. This package, of course, is part of every "base install" distribution - you have no choice about it - but if some nerd (such as myself) were to build a linux from scratch (say... for academic purposes) then I'd have to download the ext3 source, compile it, and presto there's dump/restore and mkfs.ext3. There is no tool better at backing up ext3 partitions. That being said, dump is not dump. Also, dump is not ghost. (Dump is not dump.) At least one time I experienced data corruption because I used different versions of dump & restore. Specifically (and this sure seemed like a good idea at the time) I created the backup with the dump that was installed with my OS, and I used the RedHat installation CD in rescue mode to restore. It turns out that the dump on the CD was not quite the right version for the filesystem that I installed from that CD. Go figure. I needed to install my OS again minimally, and use the restore from the OS, in order to restore without corruption. See below for my suggested solution. (Dump is not ghost.) Ghost is able to reliably backup an OS while the OS is running. Ghost is able to restore your partition tables and boot record too. Ghost will compress on the fly, but dump really benefits by filtering through gzip. Dump will warn you about the perils of backing up a mounted filesystem. These are very real perils; basically it comes down to - files that are in use cannot be backed up. Unfortunately, files that are in use are also the most important files, and more files are in use than you think. Most people will dump a mounted filesystem, and accept the risk of data loss, but best practice is to take the system offline for dump. After you create a dump, before you can restore, you need to partition your new computer, restore the backup into a partition, and install grub to the MBR. It requires real expertise. You probably even need to modify your fstab before the system will boot. Here is a suggested best practice, which I follow religiously. This has saved my ass many times: Before you install your OS, first create a 2G partition with no swap, and install "Minimal" into that partition. Then, using the same set of CD's, perform your real OS installation. When you're done, modify grub.conf to make your system dual-boot with the minimal OS, but default to "normal." When you want to create a reliable dump, reboot into your minimal OS and use dump. This way, you are guaranteed to have the same version of dump that's known to be stable on your system, and you are backing up a filesystem while it's not mounted. Nothing is more reliable than this. When you want to restore... First create a 2G partition with no swap, and install "Minimal" into that partition. Boot into the minimal OS, and use fdisk, mkfs.ext3, mkswap, and restore to recreate your "normal" OS. Again, nothing is more reliable than this. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ehrlich Sent: Thursday, June 28, 2007 11:39 PM To: [email protected] Subject: [BBLISA] Native backup/restore partition options This afternoon I performed a full installation of CentOS 5 on a dual-boot system. I used ghost 2003 to perserve the WinXP side (before CentOS was installed). Now, to prevent having to reinstall CentOS (or any variant of linux for that matter) time after time on other systems, what would be the best way to preserve the [linux] installation I've completed, and possibly restore it to different-sized partitions/drives? My first thought was dd, but last I read, it keeps the disk size intact, such that dd'ing a restore from, say a dd'ed backed up 160 GB drive, will restore the image to 160 GB of space, even if I have a 500 GB drive installed. I checked out tar and dump/restore, but am not sure if they will do what I want. It would be great to preserve at least the Linux partition in full, all filesystems intact, and permit possibly dynamically sized drives to accept the restore. Also, last I experimented, dd for backing up took up a ton of disk space because it went from start to finish on the source drive, regardless of piping it through gzip, and it took forever (hours). I waited so long I realized it would have simply been faster to just install from original media. Ideas/hints/experiences welcome. Thanks. Scott _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
