How to clone to a smaller harddisk?

Question

How to clone a harddisk to a smaller sized one.

1. Clonezilla is great but it doesn't support such functionality.
2. Also dd and PartImage don't support this demand.
3. rsync will not copy the MBR since an MBR is not a file.

I need to clone a HDD not to take a backup, so rsync is not an acceptable answer.

Any suggestions?

Answer 1

You clearly cannot clone a larger partition to a smaller partition (using dd and the like) since there is simply not enough space.

However, if the files that are on the larger partition would also fit on the smaller partition, you could use rsync to copy those files. The exact options to use depend on your particular use case, but to simply copy all the files the following should do:

rsync -av /mount/point/of/large/partition/ /mount/point/of/small/partition

Edit: Once again: You cannot clone a larger partition onto a smaller partition. (But do read on, your problem can be solved yet.)

The reason is simple: your source partition is bigger than your target partition. What do you expect? Should some blocks just be dropped? Which ones? And how should dd know? Of course, you could use dd's bs= and count= options to only copy the first so-and-so-many blocks of your source partition such that it fits onto your target partition, but you will end up with a broken partition. That is certainly not what you want.

So, since you cannot clone a larger partition onto a smaller partition, the only thing you could do is to first reduce the size of your source partition to a size smaller or equal to that of your target partition with something like gparted which is aware of the filesystem specifics, such that you do not lose data. And only then could you use dd to clone the partition. Ideally, the new size of your source partition should be equal to the size of your target partition (and not just smaller or equal), or else you will end up with some unallocated space on your target partition after the cloning.

Please also note that you should not simply copy an MBR of a larger drive onto the MBR of a smaller drive (or vice versa, for that matter). The MBR, which has a size of 512 bytes and is the first section of your hard drive, contains information on the layout of the harddrive:

• 446 bytes - Bootstrap.
• 64 bytes - Partition table.
• 2 bytes - Signature.

(Note that 446+64+2=512.)

If you insist on cloning the MBR, then only clone the first 446 bytes like so:

dd if=/dev/source of=/tmp/mbr.bak bs=512 count=1
dd if=/tmp/mbr.bak of=/dev/target bs=446 count=1

...replacing /dev/source and /dev/target with the device names of the source and target harddrives, e.g., /dev/sda and /dev/sdb, respectively. (More information is available here.)

However, the proper way to do it would be to do a clean Grub reinstall (or whatever you have on your MBR) on the new harddrive.

Summing up, if you want to clone a larger drive onto a smaller drive, proceed as follows:

1. Lay out a partition table on the target drive with as many partitions as on the source drive. There should be a one-to-one correspondence between the partitions on your source drive and the partitions on your target drive, except that (some of) the partitions on the target drive can be smaller than their corresponding partitions on the source drive. Use a tool such as fdisk or cfdisk for that.

2. For each partition on the target drive which is smaller than its corresponding partition on the source drive, reduce the size of this corresponding partition on the source drive to match the size of the partition on the target drive. Use a tool such as gparted for that.

3. For each partition on the source drive, issue the command

   dd if=/dev/sdaX of=/dev/sdbY
   

   ... to clone the partition /dev/sdaX from the source drive to the corresponding partition /dev/sdbY on the target drive (replace the device names appropriately, of course.)

4. If you insist on also cloning the MBR, use the two dd commands written further above in this post (those with the /tmp/mbr.bak stuff). However, keep in mind that a clean Grub re-install would be better.

Answer 2

Exact cloning is not possible as Malte Skoruppa already posted. However clonezilla is able to do this task as long as the larger disk is not full (Malte mentioned this already).

Basically you need to enable the advanced options and "ignore" the warning message about a smaller disk. See Clonezilla docs for details with screenshots. I had the same issue when restoring a backup of a 160GB HDD to a 64GB SSD. For me this worked well.

Another solution which should be the result you want would be restoring to a same size disk and repartition to fit the new partition schema into the smaller disk. See jsm-techblog.blogspot.de for details how to do this.

Answer 3

Gparted should do the job

1. After resizing with gparted, boot from the drive to give the OS a chance to fix any errors before imaging with Clonezilla.

2. Then runs Clonezilla and make a copy of the needed hard disk partitions

Another Option which I found great for me: MondoRescure

Mondo Rescue is a GPL disaster recovery solution.

It supports tapes, disks, network and CD/DVD as backup media, multiple filesystems, LVM, software and hardware Raid.

A simple guide can be found here

I will post some screenshots:

STEP 1 BACKUP (PARTITION SCREENSHOT)

1.Choose from the list of supported backup media types.

2.If you are backing up to CD/DVD-+R[W] then Mondo will ask you if your CD burner has BurnProof technology, is inside a laptop, or is otherwise eccentric. If you are backing up to a tape streamer then you will not see this message

3.How much compression do you want? None, if your tape streamer has built-in hardware compression. Maximum, if your CPU is blazingly fast. Average should do just fine for most situations.

4.If you want to backup the whole computer (excluding /sys, /run and /proc, naturally as well as /tmp) then leave this as / which is the default. Otherwise, specify subsets, (e.g. /usr/local|/home ) being sure to put a pipe in between each path.

5.If you are backing up your whole computer then you might want to exclude certain directories, e.g. /shared/MP3. Please specify them in the 'exclude directories' dialog box. Please put a pipe in between each path, e.g. /shared/private|/scratch|/nfs|/windows

6.Is your kernel sane? Red Hat, Mandrake, SuSE, Debian and Slackware users should in general say 'yes' because these vendors are good at producing reliable kernels. If you are using Gentoo or LFS then your kernel might be non-standard, in which case say 'no' to use Mondo's failsafe kernel (provided separately).

7.If you want to verify the archives after writing them to media, say 'yes' here. If you have absolute faith in your hardware and your Linux distribution, say 'no'... and a little prayer.

8.If you are sure you want to go ahead, say 'yes' and find something else to do while Mondo backs up your computer. If you say 'no' then you will be unceremoniously dumped at the shell prompt. :-)

9.The backup process will now commence. There are some pre-backup tasks to be carried out first but the backup is essentially underway. To simplify the backup process, you were asked a series of questions. Next time, if you like, you could call mondoarchive with various command-line switches to control its behavior, instead of answering a series of questions. See the man page for details.

10.Mondo will make a catalog of all files to be backed up. This may take up to five minutes. The list of files will be divided into sets, approximately 4 MB (before compression) of files per set. This typically takes one minute.

11.Mondo calls Mindi. Mindi generates bootable media image and auxiliary data disk images which are based on your existing Linux distribution and filesystem. That way, you can be sure Mondo's tools will be compatible with your existing filesystems and binaries: Mondo's tools are your tools. Mindi takes up to five minutes to run.

12.Finally, Mondo begins backing up your computer. This process may take a few minutes or a few hours, depending on how much data you are archiving, how fast your CPU is, how much RAM you have, and so on. It will backup your regular files and then your large files (files larger than approximately 32MB). If you have opted to verify your backups, Mondo will do that too.

STEP 2 RESTORE (PARTITION CLONE)

1.Choose your type of backup media. The live restoration process is very similar to what you'll experience if you type mondorestore with no parameters after booting from a Mondo media.

2.Hit 'OK' when you have inserted the tape/CD. If you generated a tape backup, the tape itself should be enough. If you generated a CD backup, the first CD should be enough. Otherwise, you may need the boot media.

3.Flag the files and directories you wish to restore. Use the 'More' and 'Less' buttons to open and close subdirectories.

4.Specify the location to restore the files to. In general, '/' is appropriate. If you do not want to overwrite newer versions of the files you are restoring then specify /tmp/BKP or similar as the restore path.

5.Mondorestore will retrieve configuration information from the media. (The sample screen is for tape users. CD users will see something different.)

6.Data will be restored to the hard disk - first the regular files, then any big (32MB or greater) files in the restore set.

Answer 4

Most examples suggest re-sizing your original drive or using cloning.

• resizing: there is a risk of loosing your data as you modify it.

• cloning: (CloneZilla) you cannot clone to a smaller disk and it will take time copying the entire drive, even unused space

Another way which is less risky although very manual that I use. Since it leaves the source drive untouched in case you want to fall back because something failed.

This method also allows you to switch filesystem on the destination drive

With the procedure below, you only need to create the file system of your choice on the destination drive.

Install new destination drive alongside original drive into your computer:

• Boot computer from Ubuntu live cd.
• On the destination drive use gparted to create: an ext4 fs (or any fs of choice) volume, and a swap volume and swap -- filesystem
• In gparted set the bootflag on the new ext4 volume

In my example source (original drive) is: /dev/sda the destination (new smaller drive) is: /dev/sdb In your setup it might be different

# Mount src as read only under `/mnt/source`:
sudo mkdir /mnt/source ; sudo mount -o ro /dev/sda/mnt/souce

# Mount the destination drive under `/mnt/destination`
sudo mount /dev/sdb1 /mnt/destination/

# copy src filesystem to destination filesystem with:
sudo rsync -log /mnt/destination/rsync-copy.log  --progress -avr --exclude=/mnt/source/dev/ -A -H  -X   --numeric-ids  /mnt/source/* /mnt/destination/

Ubuntu uses UUID instead of device name to find and mount the drive. Since we have a new disk, we want to change the destination fstab to use the new drive's UUID to mount the disk.

# list disk UUID:s and pick the appropriate one for your drive
ls -la /dev/disk/by-uuid

Now replace / and swap with the UUIDs in /mnt/destination/etc/fstab. Don't forget to change the filesystem for the the mount point if you decided to change it to something different from the original drive.

If it's important that GRUB is the same version, boot from the original disk again and run and run the command below to install GRUB to the new drive

sudo grub-install /dev/dev/sdb

Now remove the source drive from your computer and boot the destination drive. GRUB will fail to boot completely and exit to a recovery shell in the GRUB recovery shell:

# load some needed grub modules
insmod ext2 
insmod linux
# lists your disk devices
ls

Pick the proper device (in my example its is hd0,msdos1)

set root=(hd0,msdos1)

Find the exact name of vmlinuz-xxx and initrd-xxx to configure GRUB to use

ls /boot/

See and use the proper name for vmlinuz and initrd you got from ls above and use them instead of the example version I'm using here below

linux /boot/vmlinuz-2.6.32-5-amd64 root=/dev/sda single

If /dev/sda is the device the drive will be the rootfs disk next time you reboot the machine with only the destination disk.

initrd /boot/initd.img-2.6.32-5-amd64
boot

This should have successfully booted the machine

Finally to update GRUB to use the new disk UUID so you don't need to repeat this manual procedure every time:

sudo update-grub

Answer 5

"Pseudo-cloning" of a larger hard drive to smaller one may be accomplished by using Clonezilla. Effectively you can save and restore the disk's partitions. The following steps (developed for HDD to SSD transfer) will get you there:

1. The first trick is to use Gparted to resize the partitions on the hard drive, shrinking each partition so as to reduce the amount of unused space it contains. Obviously, the partitions must be sized such that the total space required for all the partitions is less than the capacity of the SSD.

2. One then runs Clonezilla and makes a copy of the individual hard disk partitions (using the saveparts option), storing these temporarily on an external USB drive. Note that it is necessary to save the partitions (saveparts) rather than making an image of the entire disk (savedisk).

3. With the SSD installed in the target machine, the second trick is to use the partition manager once more to create the desired partition structure on the SSD.
4. Clonezilla is then used to restore the saved partitions (using restoreparts) onto the SSD.

See: "Cloning” a hard drive to a smaller SSD for more discussion on the process and a number of links for reference sources.

Answer 6

You can transfer your data to a smaller drive using Clonezilla and GParted.

Using the GParted Live CD shrink your partitions such that they will fit on the new drive. Move your partitions such that the empty (gray) space is at the end/right of your drive. If there was already empty space before your first partition leave that space as it may contain boot or other hidden information.

Using Clonezilla do a device-device clone. Select the advanced options and enable the -icds option to skip disk size checking. Proceed with the clone, remove the old drive, and attempt to boot up from the new drive. If you get errors try the -fsck-src-part option which helps you repair errors on the source disk.

From the Clonezilla docs:

If you are sure all the data from the image could fit the smaller disk, i.e. it won't be written to the wrong disk space, you can check the option "-icds".Warning! To select this option, you have to know what you are doing!.

One FAQ I read suggested using both the -icds and -k1 options with Clonezilla however that did not work for me. Others have mentioned that you can copy partitions using GParted however it cannot copy all partitions types and I could not get my machine to boot after using that method, likely due to some hidden information between partitions not being copied.

Answer 7

Disclaimer: I am the original author of WereSync

This is possible using WereSync. WereSync follows the general process of Malte's answer but requires only one command rather than several. Additionally, if you're using your clone as a backup, it can incrementally update that backup, since it employs rsync in the backend.

To install WereSync use pip:

pip install weresync

From there you can simply use the WereSync command

 weresync -C -g 2 -E 1 /dev/sda /dev/sdb

The above command copies data from /dev/sda to /dev/sdb. The -C flag marks that WereSync should check if the partitions on the two drives are equivalent, and if they are not WereSync should copy the partitions from /dev/sda to /dev/sdb and resize them so they fit. The UUIDs of the new partitions will be different. The system used for testing if the partitions are valid can be finicky, so after your first backup I recommend omitting this flag.

The -g and -E commands could be omitted, but the boot loader installation would almost surely fail in that case.

-g refers to the "grub partition", or the partition grub should be installed on. Generally this is the partition mounted on /. So if you have /dev/sda2 mounted on /, you pass -g 2 to WereSync, as in the above example. If this is omitted WereSync will try and discover the proper partition on its own, but this is error prone. I recommend simply passing the flag.

-E refers to the EFI partition. If your EFI partition is on /dev/sda1, pass -E 1 to WereSync as in the above command.

If you have a seperate partition for the /boot folder, you need to let WereSync know as well. If you have that on /dev/sda3, then pass -B 3 to WereSync.

More detailed information on the possible flags to this command can be found on the WereSync Command Documentation.

Answer 8

I wanted to clone a old 256Mb compact flash card into a 32Mb one which got busted. The flash card contains a small Linux appliance which manufactures small spring coils.

Solved this way:

(Of course, the effective space used in the 256Mb was < 32Mb, so it fits in well)

1. Create an image of the 256Mb flash card with dd (this example is assuming the card is mounted in /dev/sdb) :

   dd if=/dev/sdb of=image256.iso
   

2. Use unetbootin to read the image256.iso ISO ( Diskimage option).

3. Select the USB drive where the 32Mb card is and proceed to dump the image into the 32Mb card.

That's all, the 32Mb card successfully started my machine again.

Answer 9

You could try to make it in two steps first make a clone of the System into an Sparse-Image (Image is getting bigger on adding more stuff to it) Now restore from this Image to the second smaller disk.

Answer 10

After shrinking the file system in the larger disk using GParted, I put the two disks in a RAID case in mirroring mode, where the larger disk is the source and the smaller disk is the target. I just had to click the reset button inside the case (not change the mode,i.e. Raid 1 to Raid 0) for cloning to begin. Worked perfectly! :) I used GW3.5AX2-SU3/MB Raid case.

Answer 11

i post my experience shrinking a boot disk with 250gb(sda) to a 120gb(sdc) disk

sda contains 2 partitions:

• sda1 --> /boot (ext3)
• sda2 --> lvm2: /(245gb) and swap(5gb)

so i do:

• dd sda mbr to sdc
• fdisk sdc and write the changes, so it creates the structure in sdc
• dd sda1 to sdc1

then as my gparted NOT works with lvm:

from a rescue disk:

• first umount VG/LV00
• e2fsck VG/LV00
• resize2fs /VG/LV00 xxxxxxxxK (i give a 1gb more than the used space)
• lvreduce -L xxxxxxxxxK VG/LV00 (i give 1gb more than the fs space)

• pvresize /dev/sda2 --setphysicalvolumesize xxxxxxxxxxxxK (i give 1 gb more than thre LV space) (i have an ERROR here... so:

  • pvs -v --segments /dev/sda2 (to see the segments)
    • pvmove --alloc anywhere /dev/sda2:segment_min-segment_max (from the segments i saw "at the right" of the disc)

But still the partition was big, as i only shrink the FS-LV-VG, so:

i recreate the partition with fdisk:

fdisk /dev/sda 
d --> 2
n --> p --> 2 --> default --> (new reduced
size!!!)
 w

then system prompt that the old partition table be in use till next reboot. But i forgot to reboot and do the image:

dd if=/dev/sda2 of=/dev/sdc2 bs=4096 (at this point i thought that something will be wrong and i couldn't boot with sdc since the partition table does not reflect the end of new sda2)

BUT all was OK and after the reboot, and even the system choose the sdc partition to boot(it complaining about duplicate PV, LV and /boot)

I dont know if im lucky or if i do unnecessary steps...any comment be appreciate.

Answer 12

It can be done..

With a live cd just shrink the filesystem (resize2fs), than lvm (if any) of the last partition (like /dev/sdc3) from the big disk so it can fit on the small disk.

With fdisk delete and recreate with smaller sectors the last partition (/dev/sda3), so the last sector of the big disk has the same value as the last sector of the small disk.

Then do your

sudo dd if=big of=small bs=10M  

until it runs out of space.

Extra caution while shrinking since one bad value will cause data loss.

Answer 13

I came to this problem because Win 10 update to 1607 would break after reboot, caused by my NVMe (Samsung 950 Pro) not being recognized, so I cloned the NVMe to the other (larger) internal drive (in my case Toshiba), updated the Win 10 and restored the system back to NVMe.

Here are the steps I needed to do to achieve that (as restoreparts with -icds did not work).

Tools:

• Windows 10 1607 DVD (bit-depth and language depending on your current OS)
• Clonezilla Live DVD (2.4.5 +)
• or Clonezilla Live DVD (20160203-xenial +),as it can boot with UEFI set in BIOS
• (optional) GParted Live DVD (0.27.0-1)

Preparation:

1. Burn all tools on CDs/DVDs
2. Run Clonezilla and clone (drive to image) the NVMe to an image (on e.g. external drive)

Note:

If you used Clonezila from the stable branch, you must switch to Legacy boot mode in BIOS to be able to boot from the CD. Otherwise, if you use download from the alternative branch, it should support UEFI boot.

Disclaimer:

Follow the guide on your own responsibility. Steps and commands here are checked and double checked, but typos could cause you loss of data or hardware failure, so first learn what you're doing and take these steps as hints towards right direction.

The procedure:

1. Run Clonezilla and clone (drive to drive) the NVMe to Toshiba (in my case, the other internal drive, which I cleaned/backed-up beforehand)
2. the 1st time around I think I had some conflicts in Windows with NVMe still having Win boot info, so this time I immediately after the initial cloning to Toshiba (so, before the switch to UEFI boot) deleted all the partitions on NVMe drive

• deleting is easily done in Clonezilla shell with:

  sudo dd if=/dev/zero of=/dev/nvme0n1 bs=512 count=1
  

• alternatively, boot to GParted and do it visually there

3. (Switch to UEFI boot in BIOS)

4. Boot (Toshiba will be used)

5. Run Win 10 1607 install DVD and choose Install, check Download updates and choose Keep apps and data. That should upgrade the Toshiba to latest version of Win 10.

6. (Switch to Legacy boot in BIOS) just in case, backup the Toshiba to an image (via Clonezilla)

7. Since copying MBR did nothing for me, the GPT is important in this story, so enter the (Clonezilla) shell and copy the GPT from Toshiba to NVMe with

   sudo sgdisk /dev/sda -R /dev/nvme0n1
   sudo sgdisk -G /dev/nvme0n1`
   

   (explanation)

8. since Clonezila (even with Expert switch -icds) refuzes to restore partitions, again enter the shell and do:

    sudo partprobe #forces kernel to reload partition infos
    sudo fdisk -l #shows all disks info
    sudo dd if=/dev/sda1 of=/dev/nvme0n1p1 bs=64K status=progress
    sudo dd if=/dev/sda2 of=/dev/nvme0n1p2 bs=64K status=progress
    sudo dd if=/dev/sda3 of=/dev/nvme0n1p3 bs=64K status=progress
    ...
   

   (more info)

9. Back up the Toshiba MBR and GPT:

    sudo sgdisk --backup=sda.gpt /dev/sda
   

10. Copy the backup to a safe place (so we can restore it and not the whole drive image we did in step 6)

    sudo mkdir /mnt/usb
    (put in usb flash or similar)
    sudo mount /dev/sdb /mnt/usb
    sudo cp sda.gpt /mnt/usb
    sudo umount /dev/sdb`
    

11. Clear the Toshiba partition info so it doesn't cause conflicts with Windows

    sudo dd if=/dev/zero of=/dev/sda bs=512 count=1
    

12. (switch to UEFI boot in BIOS) boot from Windows 10 (1607) DVD, choose Repair > Troubleshoot > Command prompt and execute all these:

    bootrec /fixboot
    bootrec /scanos
    bootrec /fixmbr
    bootrec /rebuildbcd
    exit
    

    (more info)

13. reboot to Windows 1607 on your NVMe disk

14. Win!

15. (re-initialize Toshiba in Disk Management)

16. (optional) backup the updated NVMe disk (clone to image with Clonezilla)