[K12OSN] re: Got to rebulid -- how to take an image for checkpointing (Robert Moskowitz) (Matt Oquist)

Sat Aug 26 18:10:38 UTC 2006

I knew I would forget something... /proc *must* exist on your restored
system before it will boot. So when you restore, you must also do
this:

If you're in the chroot of your new / partition:
$ mkdir /proc

In a non-chroot shell on a LiveCD:
$ mkdir /mnt/newroot/proc

(This assumes you've created your new / partition and mounted it to
/mnt/newroot.)

/dev can also cause confusion. It must exist just like /proc must
exist, and depending on whether your system is using udev or devfs
it'll behave differently if you boot the system with device special
files pre-existing in there. It's my habit to wipe out everything
under /dev on a restored system:

in a chroot:
$ rm -rf /dev/*

In a non-chroot shell on a LiveCD:
$ rm -rf /mnt/newroot/dev/*

I'm sure I've forgotten some other details, too.

More tar Trivia:
    Here's a way to change the remote destination directory of your
    tarball, while we're still in the neighborhood of the subject:
    $ tar czvf - / | ssh user at remotehost "cd /some/other/directory; cat > systembackup.tgz"

    And here's a way to accomplish the same thing rsync accomplishes,
    without rsync's ability to minimize network traffic:
    $ tar czf - / | ssh root at remotehost "cd /some/other/directory; tar xzvf -"

    Note that I took the 'v' out of the first tar command and put it in
    the second; if you put it in both you'll get twice the output on your
    console, and what you really care to know is that all the files end up
    on the remote side, hence the 'v' on remotehost.

    Also, keep in mind that in this last example I'm sshing as ROOT at
    remotehost. This matters because the ownership and permissions of the
    transferred files will be correct in my backup. If you rsync (or
    dual-tar) as a normal user on remotehost, your system files will all
    be owned by some user other than root, and your restore will not be
    feasible without a *TON* of chowning and chmodding work that I've
    never even bothered to attempt.

    Also, all of these things can be automated in your crontab; I use
    nightly rsync backups, personally.

--matt

> Date: Fri, 25 Aug 2006 14:30:01 -0400
> From: Matt Oquist <moquist at majen.net>
> Subject: [K12OSN] Got to rebulid -- how to take an image for checkpointing (Robert Moskowitz)
> 
> > Date: Thu, 24 Aug 2006 17:19:28 -0400
> > From: "Robert Moskowitz" <rgm at htt-consult.com>
> > Subject: [K12OSN] Got to rebulid -- how to take an image for checkpointing
> > 
> > I was in the habit with Win2000 to have GHOST images, so I could simply 
> > go back in time.  It was really nice for test systems.
> > 
> > So how can I take a real good snap shot of my drive.  I would want 
> > something like GHOST where I would boot from CD and image to a USB 
> > harddrive or network drive....
> 
> With a (p)OS like Windows(TM), you need a "ghosting" program because
> the system has loads of secret binary data that keep it from working
> if you just copy the filesystem contents of the OS to another system.
> Thankfully, Linux is part of the UNIX tradition and the entire system
> is portable.
> 
> 1. To create a complete, compressed, ready-to-roll system backup on a remote system:
> $ cd /
> $ tar czvf - / | ssh user at remotehost "cat > systembackup.tgz"
> 
> 2. Or, if you like rsync and the compression of the backup isn't important to you:
> $ ssh root at remotehost "mkdir /root/systembackup"
> $ rsync -avuessh --exclude=/proc** --exclude=/sys** / root at remotehost:systembackup
> 
> #2 is also a way to duplicate a running system to another system... so
> if you rsync to a fresh partition on the remotehost you can then boot
> that partition and you'll be up and running.
> 
> Of course, you may want to change your network settings and hostname
> on a duplicated host, and you can't boot unless you have a bootloader
> installed and configured.
> 
> There are all kinds of ways to restore from either #1 or #2, all of
> which will involve some form of copying the backed-up data onto
> a fresh partition, ensuring your bootloader is installed and
> configured, and booting your new-again system.
> 
> My favorite way to do this (harkening back to my Gentoo days) is to
> boot a liveCD (pick a liveCD, any liveCD!), get a command line, use
> fdisk, mkfs.ext3, and swapon to prepare my new system, make sure sshd
> is running on the liveCD system (or use it as the ssh client depending
> on the availability of 'rsync'), rsync or tar the backup onto my new
> system, chroot into the new-again root filesystem and install grub
> (the bootloader), reboot the liveCD system and take out the CD --
> presto!
> 
> I used this method to move a single installation of Gentoo from my
> original laptop through the next two laptops I had, all without
> reinstalling. (This is meaningful when you run Gentoo...)
> 
> Linux isn't proprietary so there's no need for superstition - ghosting
> is unnecessary.
> 
> I've never explored Mondo/mindi myself, but I expect that it must be
> doing some automation of what I've just described here.
> 
> Going through this process is well worth your time; you'll learn more
> about your system and it'll make you better at troubleshooting any
> Linux system. (In fact, I still recommend running Gentoo for a while
> if you haven't before, for exactly this reason.)
> 
> --matt

--
Open Source Software Engineering Consultant
http://majen.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/k12osn/attachments/20060826/3fc66773/attachment.sig>