How do I create a bit identical image of a usb stick?

Question

I have a usb stick which is unreadable for some reason. I want to make an image of it for storage purposes so I can try to retrieve the data from the image at a later date.

How would I go about creating such a bit identical image of a usb stick?

---

This is the error I get when using dd:

oshirowanen@desktop:~$ sudo dd if=/dev/sdd of=/USB_image
[sudo] password for oshirowanen: 
dd: reading `/dev/sdd': Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 1.00783 s, 0.0 kB/s
oshirowanen@desktop:~$ 

Solution 1

dd it!

Usage would be something like sudo dd if=/dev/sdb of=~/USB_image where /dev/sdb is your usb drive as listed by sudo fdisk -l and ~/USB_image is the image file where the copy will be made (a path where the image file will be created).

To restore the image to another USB drive just invert the process: sudo dd if=~/USB_image of=/dev/sdb will restore ~/USB_image to the device sdb. Just make sure that the new USB drive is as big or bigger than the original one.

You can also mount the image file you just created into a path without need to restore it first to another USB drive with mount ~/USB_image /mnt/USB_image -o loop.

Solution 2

Use ddrescue. It will continue after errors, where dd will simply fail.

Additionally, ddrescue is in the repos. On 13.04, I typed sudo apt-get install gddrescue to install.

Use sudo fdisk -l or dmesg to figure out the device location eg: /dev/sdb, then run a command such as

ddrescue /dev/sdb /home/user/desktop/bkp.img

there are many options to ddrescue, and you may want to read the man pages. Also I'm not sure why your hardware is failing, and dumping dd. One bad block could make dd quit, but so could intermittent power failures. dmesg may tell you more about hardware failures you may be experiencing.

MAKE SURE the device is not mounted! when you try to do data recovery, imaging, etc. This may cause problems.

There is a lot of things that can go wrong in data recovery. Post back if you have problems. testdisk is a nice utility for doing data recovery once you have an image.

Just for clarity, is this a usb hard drive or usb (solid state memory) device?

I/O errors are typically indicative of hardware malfunctions rather than file-system corruptions.

Also try obtaining the SMART data analysis of the device, if it is available. This may tell you things like if the device his been over heating, powered on for a long time, has bad sectors, exposed to more than X no. of Gs etc.

Solution 3

With regards to the second half of your question "This is the error I get when using dd": I can see a couple of possibilities.

1. Note the difference in command you typed versus the accepted answer; you're missing a ~ in front of /USB_image. In other words, you're trying to output the root of your filesystem instead of to your home directory.
2. /dev/sdd may not be the correct drive. Run sudo fdisk -l and compare the size of the drive to the known size of the USB stick. For instance, I know this is my USB stick because it's close to 16GB: Disk /dev/sdf: 15.8 GB, 15805186048 bytes.

Solution 4

You can create an image of an USB stick (or another device) by using dd.

E.g.

dd if=<usb device> of=usb.img

You can add more parameters to dd to optimize the command (e.g. bs).

Solution 5

dd, as mentioned by a previous poster, is the native way to go. You'll want it to continue over errors, though, so you'd start it with:

dd if=<usb device> of=<new file on disk with enough space> bs=<should match your blocksize> conv=noerror,sync 

The important part is the last one: conv=sync tells dd to pad all those blocks it could read only partially with zeroes, so the resulting image may have a few zeroes too many, but will structurally equal the flaky disk, minus its read errors. conv=noerror took care of those read errors, telling dd to continue with the next block. At this point, block size matters, for if it's larger than necessary to skip the error, readable data will be lost here. The Blocksize should always be a factor of two - if in doubt, 512k should do the trick.

Then I'd suggest to:

• store an unmodified copy of that image somewhere safe
• fsck a copy of the disk image
• mount the disk image
• check your files - they're readable without trouble now, but some may be missing or be truncated
• If the device itself cannot be read at all, you may be out of luck. Also, if the device happens to contain some proprietary software, it may be setup to return read errors when accessed in the first blocks.

(Partially quoting myself from an article written back in 2010)

If you don't need to remain native, you could always try tools that are trying to ease the process somewhat, such as ddrescue (package gddrescue) and its companion ddrescueview (sourceforge) to visualize the errors.

View more solutions

Comments

[sudodus]

When you cannot read from the device /dev/sdx pointing to the USB stick, there is a serious problem, and I think that there are no tools available to normal users, that will work. See this link for more details, askubuntu.com/questions/144852/…; Do not give up at once. Try according to the list of things that might get reading to work. Maybe you can pull the USB pendrive apart and find a micro SD card, that is still working according to the comment by @ubfan1 (at the linked answer).

[WiKrIe]

you have 2 options to handle your issue: 1st easy one: run sudo su and then as root run your dd command 2nd more skilled version run dd with status and ' ' sudo bash -c 'dd status=progress if=/dev/sd* | gzip > ~/Backup-USB.img.gz'

[Bruno Pereira]

Fail with what fault?

[oshirowanen]

Added the error to the original question as it was too much for a comment.

[Bruno Pereira]

Looks like you have a dead USB drive... dd would make a raw copy of anything that was in de drive, that I think is your last option when trying to rescue something like this.

[Bruno Pereira]

USB stick, there is no SMART data to analyze... I also think that you need to use sudo for ddrescue, * where dd will simply fail* is sort of not really true since you can configure dd to ignore read errors. testdisk is awesome when you can read lost data's sectors, not when the drive is dead.

[j0h]

# is the symbol for root so no, sudo not required. if it were $ then yes.

[j0h]

I also want to note, that if ddrescue, or even dd fail, but you are able to generate an image, you may still try to do data recovery on that image.

[j0h]

If fdisk doesnt display the device, use dmesg to view what is happening when the device is plugged in. dmesg is a list of kernel interactions, so basicly if hardware does something on your computer there is a message about it in dmesg.

[j0h]

This is a good description, for functional hardware. I down voted it because this answer neglects failing hardware, which is specificaly mentioned in the OP, (IO errors)

[Bruno Pereira]

I would suggest the usage of gddrescue against ddrescue since gddrescue is newer and more able to do the work that ddrescue does.

[j0h]

I dont even know man, read my post. gddrescue is the package, and ddrescue is the command.

[Wayne Conrad]

@j0h When Bruno made this answer, the question did not yet say anything about I/O errors. The OP added that to the question after this answer was made.

[serghei]

Note: On macOS the of=~/USB_image part will not work. You have to use of=$HOME/USB_image.

[Alex]

Just a warning, because dd by default does not provide a progress bar ... 16GB Stick on USB 1 Port takes hours :X .. USB 2 Port 10 minutes

[Sergiy Kolodyazhnyy]

@Alex use status='progress' with dd on Ubuntu, or figure out PID of your dd command and send it SIGUSR1 signal. Not sure about other implementations, though.