for later - retrotruestory/M1DEV GitHub Wiki

Find out the mount point the CF card reader with the lsblk command. https://www.cocoacrumbs.com/blog/2020-09-04-romwbw-and-linux-how-to-copy-images/ This is what I see when I issue an ls /dev/sd* command without a card reader attached:

$ ls /dev/sd* /dev/sda /dev/sda1

This is what I see when I issue an ls /dev/sd* command with the card reader attached:

$ ls /dev/sd* /dev/sda /dev/sda1 /dev/sdb

From which we can conclude that we have to write our image to /dev/sdb.

The usual way of cloning a drive is with the 'dd' tool. I've never personally tried this with a CF card or any other type of flash memory card, but I don't know of any reason why it shouldn't work.

Your card probably appears as something like /dev/sda1 depending on where you plug it in (USB slot or memory card). So you would normally clone the partition with: dd if=/dev/sda1 of=cf-card.img But since it's a bootable card, you might need to clone the whole thing: sudo dd if=/dev/sdc of=cf-card.img status=progress

The above commands read the partition (or drive) device into a file that's a bit-for-bit image of the device. You then write that image back out to another card with one of these: dd if=cf-card.img of=/dev/sda1 sudo dd if=cf-card.img of=/dev/sdc status=progress

sdc = CF cart

Nobody seems to know this trick... dd is an asymmetrical copying program, meaning it will read first, then write, then back. You can pipe dd to itself and force it to perform the copy symmetrically, like this: dd if=/dev/sda | dd of=/dev/sdb. In my tests, running the command without the pipe gave me a throughput of ~112kb/s. With the pipe, I got ~235kb/s. I've never experienced any issues with this method. Good luck! – mistiry Commented Oct 19, 2010 at 20:50

add a "bs=100M conv=notrunc" and it's much faster in my experience.

To save space, you can compress data produced by dd with gzip, e.g.:

dd if=/dev/hdb | gzip -c > /image.img.gz

You can restore your disk with:

gunzip -c /image.img.gz | dd of=/dev/hdb

To save even more space, defragment the drive/partition you wish to clone beforehand (if appropriate), then zero-out all the remaining unused space, making it easier for gzip to compress:

mkdir /mnt/hdb mount /dev/hdb /mnt/hdb dd if=/dev/zero of=/mnt/hdb/zero

Wait a bit, dd will eventually fail with a "disk full" message, then:

rm /mnt/hdb/zero umount /mnt/hdb dd if=/dev/hdb | gzip -c > /image.img.gz

Also, you can get a dd process running in the background to report status by sending it a signal with the kill command, e.g.:

dd if=/dev/hdb of=/image.img & kill -SIGUSR1 1234

Check your system - the above command is for Linux, OSX and BSD dd commands differ in the signals they accept (OSX uses SIGINFO - you can press Ctrl+T to report the status).

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.)

The source disk must not have any mounted filesystems. As a user able to read the block device (root works), run 'dd if=/dev/sda ....'

Now, one of the neat things here is that you're creating a stream of bytes... and you can do a lot with that: compress it, send it over the network, chunk it into smaller blobs, etc.

For instance:

dd if=/dev/sda | ssh user@backupserver "cat > backup.img"

But more powerfully:

dd if=/dev/sda | pv -c | gzip | ssh user@backupserver "split -b 2048m -d - backup-hostname -s.img.gz"

The above copies a compressed image of the source harddrive to a remote system, where it stores it in numbered 2G chunks using the source host's name while keeping you updated on progress.

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.

dd if=/dev/sda of=/dev/sdb bs=4096 conv=sync,noerror

This will copy the disk, and skip blocks with errors, which is very important.

These are the basic and essential options for using dd to clone or rescue a disk.

I did not want to post another answer, but there were no good answers with the essential "conv=sync,noerror" options among the 25 already posted.

I formatted the target CF with the command mkfs.ext3 /dev/sdb1

Then copied form the original CF using dd if=dev/sdb1 of=/home/frank/CFdisk.image

To check that the image was good: mount -o loop CFdisk.image /media/frank/compactflash

Then.. ls /media/frank/compactflash

https://ask.metafilter.com/135554/Copying-a-CF-card-written-in-a-special-format

You are probably copying the entire device (i.e. /dev/sdX) instead of just copying the partition (i.e. /dev/sdX1). Which is not entirely wrong, if you want to preserve the partition table, but it also is copying the empty disk area behind your partition.

A space-saving approach would

just copy the partition (e.g. by using the dd if=/dev/sdX1 notation)
store the partition table data either in binary (dd if=/dev/sda bs=512 count=1 of=sdX.partitiontable) or in a more handy human-readable format like the one offered by [sfdisk](http://linux.die.net/man/8/sfdisk) (sfdisk -d /dev/sdX > sdX.sfdisk) which can be re-imported easily (sfdisk /dev/sdX < sdX.sfdisk)

You also might consider using a tool like ntfsclone which only would copy the file system data actually marked as "used" and omit all unused blocks.