0

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?

1

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 netcat to 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 clonezilla instead.

3

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?

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 iflag=fullblock.

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 conv=sync and 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 bs (strictly: 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 dd over ddrescue:

  • (trivial) When dd is available and ddrescue is not.
  • When I need to stream (pipe) the output. ddrescue needs a seekable output file; with dd I can pipe the output to nc, pv, 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.