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?
Copying the contents of one drive to another is as simple as:
cp -a <source> <target>
Or there is the most correct way:
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
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
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
Tried and tested many times. :)
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
Which is why I said: "semi-clone" tool...
I must be joking, right? Unfortunately, no. Am I asking for a "pie in the
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
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.