I was switching from a 120GB SSD on my Raspberry Pi 4, to a 240GB one.
Found this and I cloned the command in the opening question:
sudo dd if=/dev/originaldisk of=/dev/destinationdisk bs=4096 conv=sync,noerror
where I used
/dev/disk/by-id/... handles to make sure I was pointing to the correct SSD’s (otherwise, had I swapped them, a huge mess would happen).
The resulting SSD was a perfect copy down to partition ID, so the
cmdline.txt file under
/boot/mounted from a FAT partition on the SD was starting the system off the new disk as if nothing happened.
I just tested it for the inverse situation.
On a Raspberry Pi 3, the running disk was a 240GB SSD, but it was pretty much wasted space since it was hosting a less than 4GB root partition, so I wanted to switch it to the 120GB SSD that I took out of the Raspi4.
I ran the above command, and I allowed myself the luxury to just
Ctrl-C out of it after the first 10GB had been copied over, because actually just 4GB of the disk were being used.
Guess what, turned off the system, put the second SSD in place of the first, and the system booted perfectly.
So, how do you check the progress of a running
dd command, you might ask?
Well, with the
progress tool, naturally!
sudo apt install progress
first, and then, right after
dd has started,
sudo progress -wm
This will clear the screen, and have the current status of the copy being shown and updated, while the copy is still running, so use of
byobu (go search for that) is highly recommended.
sudo is there because
dd was started as
progress won’t be able to access its status unless ran with same privileges.
dd to clone a running disk might create inconsistencies where other running processes change the disk contents while the copy is running, and the resulting copy has part “old”, and part “new” content. Usually, this doesn’t matter, or might not happen at all if all the other processes access either
tmpfs partitions or another disk, but in the end only you know what your system does, so thread with caution.