Is it safe to clone a hard drive to an image file in a bigger hard drive using dd and an arbitrary big block size for better speed? is the resulting image the same when using different bs? How about when restoring that image to original drive?
Yes no problem with whatever block size.
That said, using
dd you will copy empty/unused space as well, wasting space in the destination file. Which is OK if you are like using
dd across a network direct to a target disk, but not so good if you are makign a "master image" to clone a bunch of machines off of or for backup purposes. If that is what you intend to do, I'd look at an imaging program like
Is it safe to clone a hard drive to an image file in a bigger hard drive using
ddand an arbitrary big block size for better speed?
It depends. In general: no.
If the hard drive you read is healthy,
dd will generate the same output, regardless of block size (
bs) used (unless it's insanely big and you get
memory exhausted right away and no output file at all). This is not true for all devices (see this question) and you need
If the hard drive you read is not healthy,
dd will stop after encountering a read error. You need
conv=noerror to deal with this. Additionally you need
iflag=fullblock. It's a myth
conv=sync,noerror is enough (see this answer and this comment).
If the hard drive you read is not healthy, you may get different images even with
conv=sync,noerror iflag=fullblock, depending on
ibs). Imagine a single erroneous physical sector on the hard drive. The sector may affect one or more read operations and the outcome will depend on the block size and how blocks align with physical sectors. You may get a "hole of zeros" in your image bigger than the erroneous sector. If block size matches the physical sector size, you will get a "hole of zeros" of exactly this size, which is the best (minimal "hole") you can get.
On the other hand larger
bs can improve throughput.
And there is one more aspect. If the hard drive you read is healthy (or at least you assume it is), you may want to prepare it so the image takes less space as a sparse file (this answer, sparse file method).
dd will try to create a sparse output file with
conv=sparse. The effectiveness of this approach depends on
bs; strictly: on
obs, so it's reasonable to use large
ibs and small
obs separately in this case.
All these reasons make
dd not the best tool for creating disk images in general, especially if you don't know its quirks very well. (Note: "not the best" can still be "good"). Use GNU
ddrescue with sector size (
-b) matching the physical sector size of the source device and relatively large cluster size (
-c) for performance. With
-S it will take advantage of sparseness.
There are two scenarios when I prefer
- (trivial) When
ddis available and
- When I need to stream (pipe) the output.
ddrescueneeds a seekable output file; with
ddI can pipe the output to
gzip(this answer again, compressed file method) or whatever.
How about when restoring that image to original drive?
The premise is you can read the image without errors and the original drive is healthy. If so,
dd will do fine, big block size is OK.
If there are read errors while reading the image (which indicate the device or/and filesystem holding the image is corrupted) you should proceed like with an unhealthy source device (elaborated above) and acknowledge that the resulting data on the original drive may be (partially) corrupted.
If there are write errors while writing to the original drive then restoring the image makes little sense; you shouldn't use this drive at all.