[BBLISA] Native backup/restore partition options
Edward Ned Harvey
bblisa2 at nedharvey.com
Fri Jun 29 07:49:06 EDT 2007
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: bblisa-bounces at bblisa.org [mailto:bblisa-bounces at bblisa.org] On Behalf
Of Scott Ehrlich
Sent: Thursday, June 28, 2007 11:39 PM
To: bblisa at bblisa.org
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
bblisa at bblisa.org
http://www.bblisa.org/mailman/listinfo/bblisa
More information about the bblisa
mailing list