The dd command is a simple, yet versatile and powerful tool. It can be used to copy from source to destination, block-by-block, regardless of their filesystem types or operating systems. A convenient method is to use dd from a live environment, as in a Live CD.
if=) and output file (
of=) and do not reverse them! Always ensure that the destination drive or partition (
of=) is of equal or greater size than the source (
Cloning a partition
From physical disk
/dev/sda, partition 1, to physical disk
/dev/sdb, partition 1.
# dd if=/dev/sda1 of=/dev/sdb1 bs=64K conv=noerror,sync
sdb1in the example) does not exist, dd will create a file with this name and will start filling up your root file system!
Cloning an entire hard disk
From physical disk
/dev/sdX to physical disk
# dd if=/dev/sd<i>X</i> of=/dev/sd<i>Y</i> bs=64K conv=noerror,sync
This will clone the entire drive, including the MBR (and therefore bootloader), all partitions, UUIDs, and data.
noerrorinstructs dd to continue operation, ignoring all read errors. Default behavior for dd is to halt at any error.
syncfills input blocks with zeroes if there were any read errors, so data offsets stay in sync.
bs=sets the block size. Defaults to 512 bytes, which is the «classic» block size for hard drives since the early 1980s, but is not the most convenient. Use a bigger value, 64K or 128K. Also, please read the warning below, because there is more to this than just «block sizes» -it also influences how read errors propagate. See  and  for details and to figure out the best bs value for your use case.
The dd utility technically has an «input block size» (IBS) and an «output block size» (OBS). When you set
bs, you effectively set both IBS and OBS. Normally, if your block size is, say, 1 MiB, dd will read 1024*1024 bytes and write as many bytes. But if a read error occurs, things will go wrong. Many people seem to think that dd will «fill up read errors with zeroes» if you use the
noerror,sync options, but this is not what happens. dd will, according to documentation, fill up the OBS to IBS size after completing its read, which means adding zeroes at the end of the block. This means, for a disk, that effectively the whole 1 MiB would become messed up because of a single 512 byte read error in the beginning of the read: 12ERROR89 would become 128900000 instead of 120000089.
If you are positive that your disk does not contain any errors, you could proceed using a larger block size, which will increase the speed of your copying several fold. For example, changing bs from 512 to 64K changed copying speed from 35 MB/s to 120 MB/s on a simple Celeron 2.7 GHz system. But keep in mind that read errors on the source disk will end up as block errors on the destination disk, i.e. a single 512-byte read error will mess up the whole 64 KiB output block.
status=progressoption. See dd for details.
- To regain unique UUIDs of an ext2/3/4 filesystem, use
tune2fs /dev/sdXY -U randomon every partition.
- Partition table changes from dd are not registered by the kernel. To notify of changes without rebooting, use a utility like partprobe (part of GNU Parted).
Backing up the partition table
Create disk image
1. Boot from a live media.
2. Make sure no partitions are mounted from the source hard drive.
3. Mount the external HD
4. Backup the drive.
# dd if=/dev/sd<i>X</i> conv=sync,noerror bs=64K | gzip -c > <i>/path/to/backup.img.gz</i>
If necessary (e.g. when the format of the external HD is FAT32) split the disk image in volumes (see also the split man pages).
# dd if=/dev/sd<i>X</i> conv=sync,noerror bs=64K | gzip -c | split -a3 -b2G - <i>/path/to/backup.img.gz</i>
If there is not enough disk space locally, you may send the image through ssh:
# dd if=/dev/sd<i>X</i> conv=sync,noerror bs=64K | gzip -c | ssh user@local dd of=backup.img.gz
5. Save extra information about the drive geometry necessary in order to interpret the partition table stored within the image. The most important of which is the cylinder size.
# fdisk -l /dev/sd<i>X</i> > <i>/path/to/list_fdisk.info</i>
bs=) that is equal to the amount of cache on the HD you are backing up. For example,
bs=8192Kworks for an 8 MiB cache. The 64 KiB mentioned in this article is better than the default
bs=512bytes, but it will run faster with a larger
To restore your system:
# gunzip -c <i>/path/to/backup.img.gz</i> | dd of=/dev/sd<i>X</i>
When the image has been split, use the following instead:
# cat <i>/path/to/backup.img.gz*</i> | gunzip -c | dd of=/dev/sd<i>X</i>
ddrescue is a tool designed for cloning and recovering data. It copies data from one file or block device (hard disc, cdrom, etc) to another, trying to rescue the good parts first in case of read errors, to maximize the recovered data.
To clone a faulty or dying drive, run ddrescue twice. First round, copy every block without read error and log the errors to rescue.log.
# ddrescue -f -n /dev/sdX /dev/sdY rescue.log
Second round, copy only the bad blocks and try 3 times to read from the source before giving up.
# ddrescue -d -f -r3 /dev/sdX /dev/sdY rescue.log
Now you can check the file system for corruption and mount the new drive.
# fsck -f /dev/sdY <a href="https://wiki.archlinux.org/index.php/disk_cloning" target="_blank">Источник</a>