Using DD for disk cloning
Solution 1:
dd is most certainly the best cloning tool, it will create a 100% replica simply by using the following command. I've never once had any problems with it.
dd if=/dev/sda of=/dev/sdb bs=32M
Be aware that while cloning every byte, you should not use this on a drive or partition that is being used. Especially applications like databases can't cope with this very well and you might end up with corrupted data.
Solution 2:
To save space, you can compress data produced by dd with gzip, e.g.:
dd if=/dev/hdb | gzip -c > /image.img
You can restore your disk with:
gunzip -c /image.img.gz | dd of=/dev/hdb
To save even more space, defragment the drive/partition you wish to clone beforehand (if appropriate), then zero-out all the remaining unused space, making it easier for gzip to compress:
mkdir /mnt/hdb
mount /dev/hdb /mnt/hdb
dd if=/dev/zero of=/mnt/hdb/zero
Wait a bit, dd will eventually fail with a "disk full" message, then:
rm /mnt/hdb/zero
umount /mnt/hdb
dd if=/dev/hdb | gzip -c > /image.img
Also, you can get a dd process running in the background to report status by sending it a signal with the kill command, e.g.:
dd if=/dev/hdb of=/image.img &
kill -SIGUSR1 1234
Check your system - the above command is for Linux, OSX and BSD dd commands differ in the signals they accept (OSX uses SIGINFO - you can press Ctrl+T to report the status).
Solution 3:
CAUTION: dd'ing a live filesystem can corrupt files. The reason is simple, it has no understanding of the filesystem activity that may be going on, and makes no attempt to mitigate it. If a write is partially underway, you will get a partial write. This is usually not good for things, and generally fatal for databases. Moreover, if you screw up the typo-prone if and of parameters, woe unto you. In most cases, rsync is an equally effective tool written after the advent of multitasking, and will provide consistent views of individual files.
However, DD should accurately capture the bit state of an unmounted drive. Bootloaders, llvm volumes, partition UUIDs and labels, etc. Just make sure that you have a drive capable of mirroring the target drive bit for bit.
Solution 4:
When using dd to clone a disk which may contain bad sectors, use conv=noerror,sync to ensure that it doesn't stop when it encounters an error, and fills in the missing sector(s) with null bytes. This is usually the first step I take if trying to recover from a failed or failing disk - get a copy before doing any recovery attempts, and then do recovery on the good (cloned) disk. I leave it to the recovery tool to cope with any blank sectors that couldn't be copied.
Also, you may find dd's speed can be affected by the bs (block size) setting. I usually try bs=32768, but you might like to test it on your own systems to see what works the fastest for you. (This assumes that you don't need to use a specific block size for another reason, e.g. if you're writing to a tape.)
Solution 5:
To clone a disk, all you really need to do is specify the input and output to dd:
dd if=/dev/hdb of=/image.img
Of course, make sure that you have proper permissions to read directly from /dev/hdb (I'd recommend running as root), and that /dev/hdb isn't mounted (you don't want to copy while the disk is being changed - mounting as read-only is also acceptable). Once complete, image.img will be a byte-for-byte clone of the entire disk.
There are a few drawbacks to using dd to clone disks. First, dd will copy your entire disk, even empty space, and if done on a large disk can result in an extremely large image file. Second, dd provides absolutely no progress indications, which can be frustrating because the copy takes a long time. Third, if you copy this image to other drives (again, using dd), they must be as large or larger than the original disk, yet you won't be able to use any additional space you may have on the target disk until you resize your partitions.
You can also do a direct disk-to-disk copy:
dd if=/dev/hdb of=/dev/hdc
but you're still subject to the above limitations regarding free space.
As far as issues or gotchas go, dd, for the most part, does an excellent job. However, a while ago I had a hard drive that was about to die, so I used dd to try and copy what information I could off it before it died completely. It was then learned that dd doesn't handle read errors very well - there were several sectors on the disk that dd couldn't read, causing dd to give up and stop the copy. At the time I couldn't find a way to tell dd to continue despite encountering a read error (though it appears as though it does have that setting), so I spent quite a bit of time manually specifying skip and seek to hop over the unreadable sections.
I spent some time researching solutions to this problem (after I had completed the task) and I found a program called ddrescue, which, according to the site, operates like dd but continues reading even if it encounters an error. I've never actually used the program, but it's worth considering, especially if the disk you're copying from is old, which can have bad sectors even if the system appears fine.