Find the answer to your Linux question:
Results 1 to 3 of 3

Thread: Disk Cloning

Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Unhappy Disk Cloning

    Was wondering if anyone knows of any software capable of cloning RHEL3 from a large disk to a small disk. I currently have a 160G drive that only has ~100G used on it and would like to transfer it onto a 128G solid state hard drive. Anyone know of any software that I could do this with?

  2. #2
    SuperMod (Back again) devils casper's Avatar
    Join Date
    Jun 2006
    Chandigarh, India
    Hi and Welcome !

    You can use PartImage to clone Partitions. It doesn't include free space and creates bootable ISO Image.
    It is amazing what you can accomplish if you do not care who gets the credit.
    New Users: Read This First

  3. #3
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Cloning system drives that are the same size is simple. Cloning to a different size disc has some issues and requires more steps. In either case, you really need a separate temporary drive to hold at least the root file system image (/) in a tarball (compressed if need be). All the other partitions can be created (swap), or cloned (/boot, /home, /tmp, etc).

    Assuming that the drive is going into the same system, the main things you need to be concerned with are the partition table and boot loader.

    1. Create partitions on the new drive that mirror the old one, but with a smaller size where needed (likely /home) - I expect you want to keep the /, /boot and swap partitions about the same size.
    2. Clone with dd all partitions but /: dd if=/dev/hdXX of=/dev/hdYY ---- where XX is the disc/partition of the old file system, and YY is the disc/partition of the new file system. Cloned file systems don't need to be formatted first.

    Cloning / is the hardest since it has all the mount points for everything else. This requires unmounting any mounted file systems except /.

    3. Create two temporary mount-points, such as /mnt/tmpdir, and /mnt/newroot.
    4. Mount the external drive (a USB thumb drive of a few GB will probably suffice unless everything is on /) on /mnt/tmpdir and the new root partition on /mnt/newroot.
    5. CD to / and create a tarball (compressed if necessary) and store on the temporary drive, using the following command: tar -cf /mnt/tmpdir/root.tar <file-list>
    Where <file-list> is a list of the directories and files in / except /mnt and other special directories such as lost+found (ext3 file systems).
    6. Format the new root partition with mkfs.
    7. Mount the new root partition: mount /dev/hdNN /mnt/newroot, where hdNN is the device id of the new root partition.
    8. cd to the new root directory: cd /mnt/newroot, and restore the tarball with the command: tar -xf /mnt/tmpdir
    9. The last thing you need to do is to write the boot loader (grub or lilo) to the new drive.

    Now, you should be able to shut down your system and boot from the new drive. Either it will work, or it won't, but since you still have your original drive installed in the system, you can easily reboot to the old disc and fix whatever is broken.

    One last thing. You probably want to do some research on life-expectancy of a solid-state disc. Swap space is written to a lot, and this will likely be the first place you will find longevity issues with your SSD, especially as they have limited write-cycles, which depending upon the flash cell types they are using, can run from 100,000 to 1M writes to a cell. Most of these discs have onboard code to spread the writes out so that when you write to the same sectors on the disc frequently, they actually get written to a logical sector, and the hardware will swap them around as necessary to maximize the lite expectancy of the disc. A lot of this technology is just getting off the ground, so IMO, solid state flash-based storage devices are good for read-mostly access (really fast seeks and raw I/O) now, but not so good for write-intensive data (databases, swap, frequently compiled code, etc).

    Good luck, and keep us posted as to your progress.

    P.S. I disavow any responsibility for mistakes in the directions above... Caveat user!
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts