Tool for semi-cloning a hard drive: recommendations?

[Phil Meyer]

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!