The Answer Gang

Duping a Drive Under Linux

From Leon

Answered By The Linux Gazette Answer Gang

I need to move my entire redhat 6.2 installation to another hard drive. It currently resides on a portion of DRIVE-2. I want to move it to DRIVE-3 and use the whole drive for the system. After I move the files I intend to remove the partition from drive 2. DRIVE-3 has no files and has not been formatted.

I have files installed in the system that I need and it would take days to re-install and reconfigure them.

In windows, Laplink enables you to transfer or move files and their subdirectories across drives or computers.

Do you know of a utility that can do this?

Leon

[JimD] Linux comes with several utilities for archiving your files.

In the simplest case you can simply use the GNU cp command with the -a (--archive) and possibly the -x (--one-file-system) options.

Here's an example. Assume that you are using /dev/hda now and that you've adding a new /dev/hdc to your system. (I'll assume that /dev/hdb is your CD-ROM, not that it matters). Let's say that your Linux system is on /dev/hda5, /dev/hda6 and /dev/hda7 (and that OS/2, Windows or whatever is on /dev/hda{1,2,3}). Let's assume that you have /dev/hda5 mounted on /, /dev/hda6 mounted on /usr, and /dev/hda7 on /home (a minimal but reasonable fs arrangement).

First I'd suggest partitioning /dev/hdc (using fdisk or cfdisk) making your new filesystems (using mke2fs -c --- check for bad blocks just in case; I know they're quite rare on modern hard drives: but if the drive remaps out enough to spares it will have to show some of them). You can make the new filesystems any size you like; though you should probably make them at least as large as your existing filesystems. Perhaps you'd like to also move /var off of / and onto it's own filesystem (often a good idea). So you might make a one or two hundred Mb / on /dev/hdc1, a 127 Mb swap on hdc2, an "extended" container for hdc3, and three filesystems (5, 6, and 7) for /usr, /var, and /home restectively. So you create all of those. (/dev/hdc4 is unused in this example, since it is a "primary" partition and we didn't need three primaries; in fact we could have just created one primary for the / or /boot filesystem and put all of the rest, including our swap partition into the extended container as "logical" partitions from 5 through whatever).

Because I'm so studly at the command prompt I could (after writing my new partition table) make all of these filesystems with a short and a long command like:

mkswap /dev/hdc2
for i in 1 5 6 7; do mke2fs -c /dev/hdc$i; done

... and I can then mount them like so:

mount /dev/hdc1 /mnt && cd /mnt && mkdir proc usr var home && mount /dev/hdc5 usr && mount /dev/hdc6 var && mount /dev/hdc7 home

(all those && thingies ensure that each previous step was completed without an error before going to the next step. The backslash just marks a line continuation. Of course we can enter each command one at a time and just manually make sure that it went O.K for ourselves. Sometimes I'm just too studly for my own good).

Now, I'd have all of my new filesystems mounted under /mnt in a way that corresponds to their intended arrangement on / (the root directory). In other words, if /mnt were my root directory then *it's* /usr, /var, and /home would be properly mounted.

Thus my target disk space is prepared and arranged for a full copying. Here's how:

cp -ax / /usr /home /mnt

That's all! We're directing the GNU cp command to "archivally" copy (-a) everything below /, /usr, and /home (including all of their subdirectories; which is one of the implications of the -a option) but excluding any external filesystems. That's why we have to list / and /usr and /home (our three mounted local filesystems).

This command will not copy /proc (which is a special, virtual filesystem that represents the kernel's PROCess state as if they were files and directories). It will also skip any devfs, /dev/pts, and other virtual filesystems as well as any NFS or other filesystems that we didn't explicitly list on our command line.

Now you might understand why I spent so many paragraphs "setting up" this example. If you had 11 filesystems (/, /usr, /var, /home, /opt, /var/spool, /var/cache, /var/spool/news, /var/spool/mail and /tmp, and /usr/local) then you'd probably want to list all of them on your cp command.

If you left off the -x and just did a cp -a / /mnt then you'd have two problems. You'd be making a copy of /proc to /mnt/proc (which would waste lost of disk space and be hard to track down after you rebooted and mount the virtual /proc over the /proc containing "regular" files). Of course you could simply follow your cp command with an 'rm -fr /mnt/proc' --- but that's a waste of time and CPU cycles; and an extra opportunity of mess things up (particularly since you're doing all of this as 'root' where any mistake can destroy the whole system). Worse, you'd copy some things from twice (once into /mnt and again into /mnt/mnt). That's a classic recursion problem. Again, you could follow up such a mistake with an rm -fr command --- but you still might cause problems (you might fill up your /mnt filesystem with duplicate /mnt/mnt and /proc junk).

So, it's wise to use -x (limit the cp command's recursion or "descent through subdirectories" to those filesystems that the cp command "started on").

There are similar ways to accomplish this task using any of tar, cpio, rsync or the dump/restore pair of utilities. In fact it's even possible using these with ssh to security duplicate your system or any of its directory trees across a network to another system. However, I'll defer discussion of that for a more comprehensive "Recovery and Backup HOWTO."

This page edited and maintained by the Editors of Linux Gazette Copyright © 2001
Published in issue 64 of Linux Gazette March 2001

HTML script maintained by of Starshine Technical Services, http://www.starshine.org/

	1   2   3   4   6   7   9
	11   12   15   16   18
	20   22   24   25   26   28   29