Replicating a Linux system

Joce78 · 09-11-2008, 11:16 AM

I've got a room full of very similar Linux systems, all running SuSE 10.1.

The hard disk just died in one of the machines and I want to get the system back up again the fastest/easiest way possible. All the machines have hours and hours of tweaking, so reinstalling everything would take ages.

I think I should probably replicate the disk from one of the other machines. What's the best way to do this?

I think "dd" won't work because the disk geometry will be different.

I'm thinking this:

* Install a minimal copy of SuSE 10.1 on the new machine
(this sets up the partitions and boot sector).

* Connect a USB drive to one of the other machines, boot
from a live CD, mount the internal disk on /mnt/diskA
and use "tar cvf xxx.tar /mnt/diskA" to copy all the
files off it.

* Connect the USB drive to the machine with the new disk,
boot from CD, mount the internal disk on /mnt/diskA and
use "tar xvf xxx.tar -P" to copy all the files off the
USB disk onto the system disk.

Is that the way to do it? Is it flawed thinking? Is there a better way?

TIA.
Joce

trickykid · 09-11-2008, 11:23 AM

Sounds like a job for SystemImager.

http://wiki.systemimager.org/index.php/Main_Page

Joce78 · 09-11-2008, 11:42 AM

Quote:

Originally Posted by trickykid

Sounds like a job for SystemImager.

http://wiki.systemimager.org/index.php/Main_Page

I need more of a dirty hack....

I don't own the machines and I'm not being paid by the hour. I just want to go in there one day next week and be out as fast as possible.

(Yeah, I know I didn't say that but I'm saying it now...)

TB0ne · 09-11-2008, 12:46 PM

Quote:

Originally Posted by Joce78

I need more of a dirty hack....

I don't own the machines and I'm not being paid by the hour. I just want to go in there one day next week and be out as fast as possible.

(Yeah, I know I didn't say that but I'm saying it now...)

Systemimager doesn't take long to setup or run. If you do a base installation, you can just copy the 'tweaked' files via USB, but I would strongly recommend against doing a whole copy of "/". When you try to copy back over, you'll blow away libraries and other stuff that cp might be trying to use, which will render the system unusable.

Best suggestion would be to use systemimager, mkcdrec, or mondoarchive, if the hardware is close to being identical. I'd also suggest to your client that they implement some decent backup system, so restoring a delta copy from a point in time is possible.

rob.rice · 09-11-2008, 12:50 PM

install the new hard drive in one of the still working machines

partition it run make swap format it

mount it

then copy (use the -r and -p options ) each directory in the root directory to the new drive except /proc
(in other words make a copy of a working system)

chroot run lilo,grub or whatever install the boot loader to the MBR of the new drive
(do read the man page of your boot loader installer)

intall the new drive in to it's new home

I have done this a bunch of times to install new hard drives

salasi · 09-11-2008, 01:04 PM

Quote:

Originally Posted by Joce78

I need more of a dirty hack....

You wanta dirty hacks. We gotta a dirtee hacks...

I'm assuming that you've the installation media easily available to you.

Use autotoyast to clone the installs, in the sense that you have the same apps installed on the target box. You'll probably want to keep the autoyast file for further use, in case you have similar problems in the future, or you want to upgrade to a later version of SuSE, sometime.

Assuming that everything that you have configured is configured by a file somehwere in /etc (*), copy /etc from a working machine. Boot the target machine from a live CD of some kind and copy across all the relevant files (in the spirit of dirty hacks - short cut; copy everything across and don't worry about what you are overwriting).

...and then test...

* Maybe there are some config files that weren't in /etc. Maybe you want to search for all conf files that could be somewhere else first. you know, something like

locate .conf | grep -i -v /etc

and see if anything listed there is relevant. If you've got users on the box with GUIs, there will certainly be irrelevant stuff in there.

I also need to point out that, even though this will be nearly right, there are several ways in which you could have some work still to do.

jschiwal · 09-11-2008, 01:07 PM

You don't want to tar the /proc, /dev/, or /sys directories. Taring the /tmp directory will be a waste of time.
You may have better luck if you specify the partitions you need tar'ed in the tar command line.
Look at the tar info file.

Code:

4.6 Notable `tar' Usages
========================

     _(This message will disappear, once this node revised.)_

You can easily use archive files to transport a group of files from one
system to another: put all relevant files into an archive on one
computer system, transfer the archive to another system, and extract
the contents there.  The basic transfer medium might be magnetic tape,
Internet FTP, or even electronic mail (though you must encode the
archive with `uuencode' in order to transport it properly by mail).
Both machines do not have to use the same operating system, as long as
they both support the `tar' program.

   For example, here is how you might copy a directory's contents from
one disk to another, while preserving the dates, modes, owners and
link-structure of all the files therein.  In this case, the transfer
medium is a "pipe", which is one a Unix redirection mechanism:

     $ (cd sourcedir; tar -cf - .) | (cd targetdir; tar -xf -)

You can avoid subshells by using `-C' option:

     $ tar -C sourcedir -cf - . | tar -C targetdir -xf -

The command also works using short option forms:

     $ (cd sourcedir; tar --create --file=- . ) \
            | (cd targetdir; tar --extract --file=-)
     # Or:
     $ tar --directory sourcedir --create --file=- . ) \
            | tar --directory targetdir --extract --file=-

This is one of the easiest methods to transfer a `tar' archive.

You could run it like
tar -C /mnt/disk --exclude=/dev --exclude=/tmp --exclude=/proc --exclude=/sys -cf . | tar -C / -xpv -f -

to use tar to transfer files from a mounted source partition to the system partition. It may be better to run it from an install or rescue disk and mount both drives on /mnt/src and /mnt/dest. Then run:
tar -C /mnt/src/ --exclude=/dev --exclude=/tmp --exclude=/proc --exclude=/sys -cf . | tar -C /mnt/dest/ -xpv -f -

---

You will need to reconfigure the hostname and IP address on the clone. You don't want two hosts with the same hostname or IP address.

Randux · 09-11-2008, 01:10 PM

Quote:

Originally Posted by Joce78

I've got a room full of very similar Linux systems, all running SuSE 10.1.

The hard disk just died in one of the machines and I want to get the system back up again the fastest/easiest way possible. All the machines have hours and hours of tweaking, so reinstalling everything would take ages.

I think I should probably replicate the disk from one of the other machines. What's the best way to do this?

I think "dd" won't work because the disk geometry will be different.

I'm thinking this:

* Install a minimal copy of SuSE 10.1 on the new machine
(this sets up the partitions and boot sector).

* Connect a USB drive to one of the other machines, boot
from a live CD, mount the internal disk on /mnt/diskA
and use "tar cvf xxx.tar /mnt/diskA" to copy all the
files off it.

* Connect the USB drive to the machine with the new disk,
boot from CD, mount the internal disk on /mnt/diskA and
use "tar xvf xxx.tar -P" to copy all the files off the
USB disk onto the system disk.

Is that the way to do it? Is it flawed thinking? Is there a better way?

TIA.
Joce

Make a tarball of the whole good system if it will fit on one DVD. You can bypass /dev and /proc if memory serves, someone please check me on this.

Don't need to install a minimal system, just boot a live CD and partition the fresh drive.

Then untar the DVD into your new world and reboot. You don't need to use a DVD obviously, if a CD or USB drive will hold your hold system tarred with BZIP2.

Joce78 · 09-11-2008, 01:19 PM

Another thing I thought of was to use "dd" but at the partition level.

Would that work so long as the new partition was bigger than the old partition? It's a bit of a sledgehammer but simple is good in this case.

(I don't care if any disk space is "lost"...these machines are just used for email, web browsing, etc. Nobody's storing any data on them.)

trickykid · 09-11-2008, 01:36 PM

Quote:

Originally Posted by Joce78

Another thing I thought of was to use "dd" but at the partition level.

Really only good if the partitions are exactly alike. Plus, say you have a partition that is 20GB in size and only 5% of it is being used, that means 95% of the drive is empty but with dd you'll be wasting your time and it'll still create a 20GB dump to copy over. It's sort of wasteful. Like I said, only really good to make images to copy over to exact partition, etc.

Joce78 · 09-11-2008, 01:54 PM

Quote:

Originally Posted by trickykid

Really only good if the partitions are exactly alike.

I assume the new disk they've bought will be a lot bigger than the old one (march of progress) but apart from that the installations are almost identical. Nothing fancy, basic VESA graphics drivers, etc.

dd is wasteful but 20Gb is no big deal and I can do it in parallel with the initial install of SuSE on the broken machine.

I'm more worried about whether it would actually work. I want the simplest possible method.

jschiwal · 09-11-2008, 02:48 PM

You can pipe the output of dd through gzip to reduce the size of the image. Use zcat and pipe the output of zcat to dd when restoring.

dd will still copy the bit images of deleted files on the old system. You could use dd again to fill the partitions with zeroed files, and then delete the zeroed-files. Then the image will compress as well as a new installation.

Code:

df /usr
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/system-usr
                      61927420   8978636  49803312  16% /usr
sudo dd if=/dev/zero bs=1024 count=$((49803312-1) of=/usr/zerofile
sudo rm /usr/zerofile

Dd will have a problem if you have errors on the disk. It may be the fastest way to restore a disk in an emergency using a pre-saved image, but using tar may be more dependable.

jay73 · 09-11-2008, 02:52 PM

Create the same partitions and use cp -vax *?

chrism01 · 09-11-2008, 08:13 PM

Install basic sw on new disc, then rsync from old system?
If its a purely internal one-off you can skip the ssh/encryption option, which should speed it up.

Joce78 · 09-11-2008, 09:15 PM

Quote:

Originally Posted by jschiwal

dd will still copy the bit images of deleted files on the old system.

Don't care ... so long as it works. AS noted above I could zero out the unused sectors first then compress it.

Will dd work? I never did this before...