[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Tool for semi-cloning a hard drive: recommendations?



Dan Thurman wrote:
On Friday 11 January 2008 10:52:50 am Phil Meyer wrote:
Dan Thurman wrote:
Is there a [Fedora/Linux] clone/partition tool that will clone a hard
drive with features that allows one to specify any partition size to the
target new drive?  For example, the original drive may have a partition
with a size of say, 10GB and instead of a direct clone, I'd like to
specify a larger target partition size of say, an increase of 25GB?

As a feature, I'd also like the capability if need be, to be able to
change the source drive's partition sizes and to be able to move
partitions around so as close partition gaps?  System Commander was such
a tool for windoes but is there one for Fedora/Linux?

Any suggestions?
Copying the contents of one drive to another is as simple as:
cp -a <source> <target>
Or there is the most correct way:
cd <source>
find . -depth -print | cpio -pdmu <target>
If both file systems are LVM or hardware raid, then that solves the
other part of your question.
But lets look at a specific example since you did not provide one:
Lets assume that /var keeps filling up and its currently on / which is a
fixed partition.
You have hardware based raid from a SAN or new shoebox.
Use whatever tools are appropriate to create <new volume>.
Mount the new raid device on /mnt
mount <new volume> /mnt
Quiesce applications
cd /var
find . -depth -print | cpio -pdmu /mnt
umount /mnt ; mv  /var  /foo ; mkdir /var ; mount <new volume> /var
revise /etc/fstab to correct the new /var
restart apps or reboot
rm -fr /foo
You need to MOVE /var because there will surely be something running
with a file open in /var
You need to be quick making the changeover to the new /var, thus the
commands all on the same command line.
Don't remove the old /var until you are positive that all apps that use
/var have been restarted.  Sometimes a reboot will be necessary.  If
unsure, reboot.
Tried and tested many times. :)
Good Luck!


First, thanks for your tips! I am sincere here and please do not be offended if I come across as an ignorant idiot, of which I can be at times.

What happens when you have a multiboot drive, of which there are windoes of many variants (98,2K,XP,...), Solaris, Linux(Fedora,Ubuntu,...)?

Which is why it is not so simple. :-/

Also - manually "walking through" each partition of the source drive and manually creating/copying partitions to the target drive could be quite a chore I think, and getting all of the MBRs for each partition could be a nightmare?

Which is why I said: "semi-clone" tool...

I must be joking, right? Unfortunately, no. Am I asking for a "pie in the sky"? Maybe.

But then that is why I am asking - although you are absolutely right, I did not 'specify' the conditions and I apologize for that - must be getting old at my age and forget important details. *sigh*


No worries, I know about getting old. :)

Remember, dd originally meant 'disk duplicator'.

There has been much discussion here recently about what dd can and cannot do.

Maybe I can sum up. :)

1. Target drive cannot be smaller than the source drive, period.

2. inode and/or other fs related resources will be sized to the old drive.
This is only problematic when going to a much larger drive, or when the drive contains mostly small files.

3. udev/hal/+friends do not like foreign disk drives, and will duplicate some devices, causing new eth, sd and other devices. It is fine, and does mostly the right things, but may come as a surprise. Windows almost NEVER works from a cloned drive, sorry. For Windows, you really need a backup or 'ghost' type program.

4. Moving a 'cloned' bootable drive to another host does not guarantee it will be bootable on the new host. A rescue on the new host may still be necessary to reinstall grub.

5. Trying to 'use' a cloned drive on the original host while the original drive is present is problematic due to the way Fedora mounts partitions by LABEL. Other Linuxen use the hard drive id (UUID, I think) just for this purpose.

Those are the CAVEATS that come to mind, but with a bit of care, cloning with dd works just fine for ufs (Solaris) ext3/reiser, etc.

One last thing: its best to use a proper bs (block size) argument for dd so the sector boundaries will be honored. On drives with multiple fs types, you may need to punt back to the lowest common denominator which is likely 1k. Using block writes instead of single byte writes is also a bit faster.

Good Luck!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]