1

I'm trying to create a full disk ISO image of a 250GB HDD but I had to cancel the operation about 80% of the way through, it'd taken nearly 16 hours to get to this point and I'd rather not have to wait through that all again. I used the command:

dd if=/dev/sdc of=ssd.iso

When I had to cancel it with Ctrl+C it showed

445056121+0 records in
445056121+0 records out
227868733952 bytes (228 GB, 212 GiB copied, 62735.8 s, 3.6 MB/s

Is there a way to resume creating the ISO image? I'd rather not have to wait for it to do the whole thing again which would take almost 24 hours. I saw some people use the seek= command to resume but I don't know how to use it.

Kamil Maciorowski
  • 19,242
  • 1
  • 50
  • 94
  • 2
    Is the disk full? – Rui F Ribeiro May 01 '19 at 06:51
  • 1
    Note: Are you sure it is an ISO; [ISO 9660](https://en.wikipedia.org/wiki/ISO_image) is a standard for CD images (probably not what you have on your HDD). I see nothing else wrong with this question so +1. I think the answer is Yes, but you probably want advice from someone that has done it, so you get it correct first time. However don't for get to test, the finished product. – ctrl-alt-delor May 01 '19 at 08:00
  • dd is not a back up tool. It's just for creating raw (non-ISO) images. Use some better tools like `ddrescue` which skips unused blocks so it's much faster. See [Is "dd" a reliable tool to make an SSD image?](https://unix.stackexchange.com/q/649996/44425) – phuclv Sep 23 '21 at 04:02

3 Answers3

4

Yes, you can resume. Note if any data on /dev/sdc changed since the first try, you're risking something similar to panorama fail (but with binary data, not graphics).

Use the same input and output files with identical value of skip and seek, which in your case should be at most 445056121.

But this assumes the default value of bs you have already used, which is 512. Such small value is probably the culprit of slowness you experienced.

I would recompute to some larger value of bs, say 8M:

mv ssd.iso ssd.img   # because it's not really an ISO
dd if=/dev/sdc of=ssd.img bs=8M skip=27164 seek=27164

where 27164 tells how many full chunks of 8 MiB fit into these 227868733952 bytes you already have.

In the future consider GNU ddrescue (with a mapfile). Advantages:

  • The tool allows you to resume by repeating the original command.
  • It works better when there are errors while reading from the device, because it's designed to handle them, while dd needs special options (these are conv=sync,noerror but it's a myth they always work well by themselves, you need iflag=fullblock as well). But even then dd may not read all data ddrescue would read, if bs is larger than physical sector size on the source device.
Kamil Maciorowski
  • 19,242
  • 1
  • 50
  • 94
  • For this answer to be perfect, it just needs to explain the advantages of ddrescue with broken media. The question seems to already know about continuing it, it seems more about math/thinking a bit, than unix. +1 – Rui F Ribeiro May 01 '19 at 06:43
  • Another note, as you have read @roaima answer. Please take out the .iso from there, dd does not create iso images. – Rui F Ribeiro May 01 '19 at 07:20
  • @RuiFRibeiro And Linux doesn't care about extensions. :) My goal is to *resume* with the *already existing* files. The file in question is `ssd.iso`. But OK, I will. – Kamil Maciorowski May 01 '19 at 07:24
  • Conventions exist for a reason. Also some graphical/text interfaces take actions based on extensions. – Rui F Ribeiro May 01 '19 at 08:02
0

Don't use dd. At least not without knowing why you need to use it. And never without options. Instead, use cat

cat /dev/sdc >ssd.img

I've changed the suffix because you're not creating an ISO (you'd need the mkiso tools for that and it doesn't seem to be what you really want to do).

roaima
  • 107,089
  • 14
  • 139
  • 261
  • `cat` is easier to use, but much slower than the alternatives. – Rui F Ribeiro May 01 '19 at 06:44
  • -1. The question is about resuming. While what you wrote makes sense, `cat` doesn't resume at all. – Kamil Maciorowski May 01 '19 at 06:47
  • @Kamil, agreed it's about resuming. But actually the question is about copying a disk to an image file, and `dd` is the wrong commanf for this situation. I won't tell someone to continue using the wrong tool for a job. – roaima May 01 '19 at 06:49
  • dd a couple of magnitudes faster using the bs option. – Rui F Ribeiro May 01 '19 at 06:50
  • @KamilMaciorowski I would not downvote it. `cat` works and is useful for smaller media. – Rui F Ribeiro May 01 '19 at 06:50
  • @Rui on Linux platforms `cat` never under performs `dd`, regardless of chosen blocksize. – roaima May 01 '19 at 06:51
  • Giving you a +1 and making a mental note to test it. I actually prefer to (ab)use tar for disk backups. – Rui F Ribeiro May 01 '19 at 06:53
  • @RuiFRibeiro My point is this answer doesn't answer the *explicit* question. The OP wants to resume. Sole pointing `cat` (which doesn't resume) is better in the first place is just a comment. – Kamil Maciorowski May 01 '19 at 06:55
  • @Rui, a filesystem-aware backup tool would be best, yes. But there's possibly not a lot in it if the source disk is almost full. – roaima May 01 '19 at 06:56
0

A way to continue a "dd" should be to do the following command on Mac

dd if=/dev/sdc of=ssd.iso skip=$(expr $(stat -f%z ssd.iso) / 512) seek=$(expr $(stat -f%z ssd.iso) / 512)

Before running this I suggest you first make sure that the current size of ssd.iso can be divide by 512.

You can also run:

echo "dd if=/dev/sdc of=ssd.iso skip=$(expr $(stat -f%z ssd.iso) / 512) seek=$(expr $(stat -f%z ssd.iso) / 512)"

To see if that makes sense. It should return

dd if=/dev/sdc of=ssd.iso skip=27164 seek=27164

If the copy is cut you can keep running the first command until the file is completely copied.

tolbard
  • 101
  • 1