Clone Disc Free
Lyle Roblez
There's been a number of questions regarding disk cloning tools and dd has been suggested at least once. I've already considered using dd myself, mainly because ease of use, and that it's readily available on pretty much all bootable Linux distributions.
What is the best way to use dd for cloning a disk? I did a quick Google search, and the first result was an apparent failed attempt. Is there anything I need to do after using dd, i.e. is there anything that CAN'T be read using dd?
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.
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.
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.)
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.
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.
The reason behind this is that, on read errors, dd keeps trying and trying and trying - potentially waiting for a long time for timeouts to occur. dd_rescue does smart things like reading up to an error, then picking a spot further on on the disk and reading backwards to the last error, and dd_rhelp is basically a dd_rescue session manager - cleverly starting and resuming dd_rescue runs to make it quicker again.
The end result of dd_rhelp is maximum data recovered in minimum time. If you leave dd_rhelp running, in the end it does the exact same job as dd in the same time. However, if dd encountered read errors at byte 100 of your 100Gb disk, you'd have to wait a long time to recover the other 9,999,900 bytes*, whereas dd_rhelp+dd_rescue would recover the bulk of the data much faster.
Note that depending on the size of disk, speed of cpu on source, speed of cpu on destination, speed of network, etc. You may want to skip compression, or do the compression on the remote side, or enable ssh's compression.
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). Once complete, hdb.img will be a byte-for-byte clone of the entire disk.
This will do nothing in the watch output window, but back in the original DD shell, DD will start outputting status reports every 10 seconds. You can change the -n 10 in the watch command to any other time frame of course.
It works by storing the pid via file descriptor 3 in /tmp/pid, which is then used for the subsequent kills with signal USR1. A wrinkle was to filter the output of the progress on stderr to only one line via filtering stderr through a subshell.
At first, destination should not be in use, secondly source should be not used, or remounted into read only mode. Otherwise copy will be damaged.If remounting is impossible, please make bootable drive (hdd/ssd/pendrive) any linux live distro. I prever knoppix, but this is your choose. If it is possible, you can boot or change system level into 1, for single user mode, or you can directly reboot system into single user mode, it is distro depended.If you'll clone only one partition, this partition should be unmounted or remounted into RO:
You must identify source and destination device. please look at the dmesg, here is stored all needed info about device, with vendor etc. alternatively identifying can be based on device size, if it is different.Next, destination should be the same or bigger than source. you must calculate source, for example:fdisk -l /dev/sdaexcept partition geometry (there can be GPT), you will fetch:1. total disk size wigh GB and bytes2. historical geometry and total sector number, very important info3. block size in bytes, usually it is 512.
If you try rescue data on damaged source disk, better use native sector size, usually this is 512 bytes, and add option conv=notrunc . otherwise holes in source dropped by bad sectors will be joined by sector shifting on destination. This will damage copy with few chance for repair. then command will be:
dd is usefull tool for moving partition into new place. Simply create partition, make dd to new partition (this can be bigger, much bigger), and if it is possible, expand copied file system for filling all new partition, ext3/ext4/xfs/zfs/btrfs have this facility. Finally you must change /etc/fstab , then umount/mount if it is possible, or reboot system.
Of course you can clone any type of partition. dd command doesn't look into file system type, it do nothing with its structure. then this command can be usable for cloning NTFS or other partition types.
, then all sda hard drive will be overwritten by this backup, and all current data will be lost. You can do this also with NTFS windows partition and hard drive used by this. Of course you can use other compression command, depended by your choose.
One thing you must be aware of when dd-ing a full disk is that doing so will overwrite the master boot record of the receiving disk. This contains the partition table and other vital information. If the new disk is not the same as the old disk, this can create all sorts of tables. Copying over partitions is generally safer (and swap partitions do not have to be copied over)
I've been out of the admin role for many years now, but I know that 'dd' is up to the job. I used this technique regularly in the late 80s on Sun Sparc and 386i computers. I had one client order over 30 386i systems running CAD software that was distributed on multiple QIC tapes.
As others have mentioned above, one of the gotchas with cloning a mounted file system is potential data corruption. This obviously won't apply to full drive clones, but if you're using LVM you can Snapshot the LogicalVolume and dd from the snapshot to get a consistent image.
Just a warning to beginners that needs to be said: At least with some Versions, bs=X means that memory to the size of X will literally be allocated. bs=2GB on a system with 1GB of RAM and insufficient swap WILL cause bad things to happen.
The benefit is that I can then use 7-Zip to inspect the contents of the image without decompressing the entire archive. That's made possible by the fact that xz supports random seeking, and that 7-Zip can interpret many file system types.
c80f0f1006