|This document is available in: English Castellano ChineseGB Francais Indonesian Turkce|
by Gerrit Renker
About the author:
Obtained a computer science degree in 2001.
LF Tip:Cloning entire PCs over the network
Often the problem arises that you have to replicate data from one computer
another. A safe, easy-to-do and effective method is to
use network-based cloning as described in this howto.
The underlying idea common to all methods described below is to establish a network connection between the ''source'' computer (which is to be cloned) and the ''target'' computer (the clone). This is straightforward if both are plugged into a hub, otherwise you can connect the network cards via a crossover cable (normal straight cables can not be used). For the target PC, a Live-CD (such as Knoppix or LNX-BBC) or a minimalist installation is needed such that the network card is operable and ssh and/or netcat can be used. There are even some floppies which allow this (although in my case tomsrtb hung on initialising the network card). If you intend to install another (fresh) distribution anyway, this is an easy alternative. Both computers need to be configured with IP addresses on the same network such that they can ''talk'' to each other, as shown in the above picture.
With given basic set-up there are several ways of performing the act of cloning:
ssh-keygen -t rsaTo keep things simple, do not enter a passphrase. The public key is now in the file /root/.ssh/id_rsa.pub. Copy this file to your source PC via
scp /root/.ssh/id_rsa SourcePC:/tmpwhere SourcePC is the IP address of the source PC. When asked whether you are sure, enter a full ''yes'' (''y'' alone sometimes does not work). You are still being prompted for the root password on the source PC. Now add the target PC as a trustworthy network node by issuing
cat /tmp/id_rsa.pub >> /root/.ssh/authorized_keyson the source PC. To check whether everything is ok, repeat the above copy command on the target PC. You should no longer be prompted for a password.
The first step is always to partition the hard drive on the target system and then to create the ext2/ext3 filesystem. The latter is the preferable journalling variant and is enabled simply by setting the -j (journalling) option in mke2fs (requires to have ext3 support in the kernel). You can even convert an ext2 system to ext3, see tune2fs(8). So let's say on the source PC we have the following configuration:
I recommend to always do some kind of partitioning. If not, then any failure in using the filesystem or a hard-drive knock-out of just some sectors will destroy all your data. And according to Murphy's law, this is sure to happen if no precautions are taken in form of using different partitions instead of a single monolithic one. I had such a case recently with a funny kernel and had I not partitioned the drive, I would have lost all my data along with the munched root file system. The above actually shows that /usr was growing too big, therefore /usr/share had been added. Time for a bigger hard drive.On the target PC, fire up parted (recommendable) or your favourite partitioning program (Qtparted is a nice GUI-variant, said to be a Partition Magic clone). Create partitions which are all at least as big as the ones on the source PC. Don't forget the swap partition. After saving the partition table, put a filesystem on all newly created partitions, using
mke2fs -j -L <label> /dev/xxxwhere xxx is the partition name and <label> a label string. I usually just use things like ''/usr'' as labels (you will see that at boot-time). You can set various things via tune2fs(8), such as the regular file system check interval.
mount /dev/xxx /mntWhen cloning, it is necessary to chdir into the target directory
cd /mntNow the network bit, on the target PC type
ssh sourcePC 'dump -0 -f - /' | restore -r -f -where targetPC is the IP address of the target PC. The options mean ''-0'' for a full backup, ''-f -'' tells it to use stdin/stdout as file descriptors and ''-r'' instructs restore to re-create the filesystem being piped over the network on the target PC. For more options see dump(8) and restore(8). Below you see the output for transferring the root filesystem.
$ ssh 10.42.3.42 'dump -0 -f - /' | restore -r -f - DUMP: Date of this level 0 dump: Tue Feb 22 15:50:12 2005 DUMP: Dumping /dev/hda3 (/) to standard output DUMP: Label: debian DUMP: Writing 10 Kilobyte records DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 547312 blocks. DUMP: Volume 1 started with block 1 at: Tue Feb 22 15:50:14 2005 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Volume 1 completed at: Tue Feb 22 15:51:43 2005 DUMP: Volume 1 546590 blocks (533.78MB) DUMP: Volume 1 took 0:01:29 DUMP: Volume 1 transfer rate: 6141 kB/s DUMP: 546590 blocks (533.78MB) DUMP: finished in 89 seconds, throughput 6141 kBytes/sec DUMP: Date of this level 0 dump: Tue Feb 22 15:50:12 2005 DUMP: Date this dump completed: Tue Feb 22 15:51:43 2005 DUMP: Average transfer rate: 6141 kB/s DUMP: DUMP IS DONERestore always creates a file restoresymtable which can be removed once you are certain that no errors occurred during the file system restoration. When done with the root filesystem, we now proceed with each mounted sub-filesystem, starting with /usr (assuming your current work directory is the root of the future filesystem).
mount /dev/xxx ./usr cd ./usr ssh targetPC 'dump -0 -f - /usr' | restore -r -f -The mount-cd-dump/restore cycle is now repeated for all the directories you may have. With regard to /usr/share (which on the source PC had its own partition), you can, after the above step, simple chdir into ./usr/share (note the ".") and then repeat
ssh targetPC 'dump -0 -f - /usr/share' | restore -r -f -Restore only complains if files already exist in the filesystem being restored, so when putting two different partitions of the source PC into a single one on the target PC there is no problem. Cloning an entire PC took just about one hour with ssh and 100MB network cards (crossover cable a bonus).
Note: To dump a filesystem, it need not necessarily be mounted. You can also pass a partition name, such as /dev/hda6, instead of the directory name of a mounted partition.
An alternative to use instead of ssh is netcat(1), which is abbreviated as nc. Netcat is a simple-to-use TCP/IP client-server swiss army knife which allows to create a pipe over the network. The above examples are then merely modified as follows. We assume that the partition mounted under /var/backup is to be transferred via dump/restore from the source PC to the target PC.On the receiving end (target PC) create a listening instance of netcat via -l which pipes its output to restore.
nc -l -p 2000 -q 1 | restore -r -f -On the source PC, create another instance of netcat which takes its input from a pipe where target-IP is the IP address of the target PC.
dump -0 -f - /var/backup | nc <target-ip> 2000The -q option is supposed to stop nc after receiving end-of-file, but I had to terminate it manually in my case. Would recommend using ssh anyway.
grub> root (hd0,xxx) ... filesystem is ... grub> setup (hd0) ... lots of output here grub> quitor run grub-install /dev/xxx where xxx is your hard drive. Here, check both for the root (hdn,xx) and the appended root=/dev/xxx settings.
In the likely case of now having better hardware in the newly cloned PC, you may want to update the settings for your custom-kernel. If you are using systems which come with lots of pre-configured modules (such as RedHat, SuSe, Mandrake, Fedora ...) don't worry, it is quite likely that there will be a suitable module. If not, lspci -vv and kernel compilation as usual and described elsewhere. If your video card is different now, update /etc/X11/XF86Config-4 (or xorg.conf under RH/Fedora) to reflect this, otherwise you will get no output. If possible use the graphical tools for setting up X by booting in runlevel 3 if you have such tools. Under debian, some investigation is necessary, I was lucky to find out that the driver changed from r128 to radeon and that did it.
This howto explained the cloning procedure for ext2/ext3 filesystems. Much similar commands can be found on many other Lunix systems. For instance, several Unices such as FreeBSD, HP-UX, IRIX also provide dump/restore commands; in Solaris this is called ufsdump/ufsrestore. There are filesystems which do not offer filesystem dump functionality, e.g. ReiserFS. Here it would suggest itself to use rsync. See  for a report of successfully using rsync to clone a Linux system.
Webpages maintained by the LinuxFocus Editor team
© Gerrit Renker
"some rights reserved" see linuxfocus.org/license/
2005-03-27, generated by lfparser version 2.52