When you use
dd to clone an SD card make sure the SD card partitions are not mounted. Before starting, it is useful to know about how to list devices and mount points with “
lsblk”. If you run “
lsblk” on your host PC prior to having the SD card present you’ll see what partitions and devices your PC uses normally. For example, this is from an NVMe drive on a system which boots both Linux and Windows, plus it has a spare partition for future releases of Linux:
├─nvme0n1p1 vfat 7199-294E /boot/efi
├─nvme0n1p2 ntfs 26E36D5F78BC0006
├─nvme0n1p3 ext4 ROOTS1 129f5c55-57fe-4d55-bdd3-286744c9346b /
└─nvme0n1p4 ext4 ROOTS2 6da04e95-d046-4514-a507-6a478417db7d
The NVMe itself is “
/dev/nvme0n1”. This could have also been an ordinary SATA device, in which case it might have a name like “
/dev/sda” or “
/dev/sdb”. Individual partitions are appended to the name, e.g., “
nvme0n1p1” is the first partition on the NVMe device, while “
sda1” would be the first device on a SATA disk. For the examples I am going to say “
/dev/sdb”, but you’ll need to make sure you use whatever device name the SD card is.
If you monitor “
dmesg --follow” prior to connecting the SD card to your PC, then you’ll see log lines added as you insert the SD card. Part of that tells you the name of the device to use, e.g., it might tell you that it sees the device as “
sdb”. Remember that designation.
Also, in the example “
lsblk”, note that the last column is the mount point. That example shows two partitions are mounted. “
/dev/nvmen0p1” is mounted on “
/boot/efi”, and “
/dev/nvmen1p3” is mounted on “
/”. You definitely don’t want to unmount the wrong thing, but as you connect the SD card it is likely an automounter will mount some partition of the SD card.
For every mounted partition of the SD you want to first unmount it. So lets pretend automount has mounted “
/dev/sdb1”. To unmount (command is short one letter, it is “
sudo umount /dev/sdb1
…and after this, “
lsblk” should show the partition no longer has a mount point.
Before you start be absolutely sure your host PC has room to hold the clone if your destination is to the host PC. Most people would clone to PC, and then later use that PC’s clone file to write to some new SD card. It is possible, if your PC does not have enough disk space, to name a clone as directly to a second SD card, or to a thumb drive, or to an external storage device if you have one. Let me know if you need to use an alternate destination…my example will be cloning directly to the host PC.
The command “
df -H -t ext4” will list how much space is used or available on any partition which is both mounted and of type
ext4. You’ll need extra space which is the size of the SD card, plus spare space. So if your SD card is 64GB, then your spare PC space needs to be significantly more than 64GB at the destination location, e.g., I’d say have an extra 16GB or 32GB on top of the example 64GB. If your SD card is smaller, then required size goes down.
Now that your source SD card is present and there is no mount of any partition of that particular SD card you have to find a place where you want to clone to. As an example I am going to create this directory:
mkdir -p ~/nvidia/clone
Then I will go there since that is to be my destination:
Now I am going to clone the entire SD card (pretending it is “
sudo dd if=/dev/sdb of=my_clone.img bs=1M status=progress
In the above command you could actually leave out the block size ("
bs=1M"), and you could leave out the “
status=progress”. The block size just makes it go a bit faster by using a buffer, and the “
status” just gives you messages to the console as the clone progresses to tell you have far it has gone. If I were doing a data recovery process on a failing drive I would use a block size which is the same size as the disk’s sector size, but you can ignore that since you want to know about errors.
When done you will have a file “
~/nvidia/clone/my_clone.img” which is an exact byte-for-byte match to the SD card, including hidden metadata plus all partitions.
Note that the destination could name some specific location other than where you start from, but in the example this just happens to be where the user is at the moment (which happens to be “
~/nvidia/clone”. A full path could be named to something else, e.g., to a thumb drive or external drive.
Let’s say you have finished and the source SD card is no longer there. Now you’ve plugged in a new SD card which equal to or larger than the original SD card size. We’re going to pretend that since the old SD card is removed, then the new card has designation “
/dev/sdb” (this could just as easily been enumerated as “
/dev/sdc”…you need to check “
dmesg” to see if you have the correct device…using the wrong device will destroy the content on that device, and
dd will happily destroy your operating system if you tell it to). The restore to the new sdb is:
sudo dd if=my_clone.img of=/dev/sdb bs=1M status=progress
In that example the input file is “
my_clone.img”, and the output file is “
/dev/sdb” (which is a disk and not a file). Once done your new SD card will be a 100% exact match to the original.
Incidentally, you can mount and examine a clone file from the PC using loopback to make the file appear to be a disk. Something like this:
sudo mount -o loop my_clone.img /mnt
sudo umount /mnt
Thus you can pick and choose things to copy or modify on the clone at any time.