The adventures continue!
I run a number of computers at home, almost entirely GNU/Linux-based. As the hardware continues to age, data integrity had become more and more of a concern. I am particularly worried about sudden disk failures, and with a combination of ddrescue and timeshift I have been setting up whole-partition/whole-disk and incremental backups on critical systems.
I have also been trying to use SMART monitoring of SSDs and HDDs to stay ahead of failures. For example, I monitor key log messages and flags for signs of errors or warnings ahead of serious errors. I also watch the clock on these drives. The older they get, the more I should replace them. I have set time-based warnings and “red alerts” based simple disk age alone.
I use Raspberry Pis for some of my small applications at home. Recently, I wanted to upgrade one of them from Debian bullseye to Debian bookworm. However, while I clone the main drive on the RPi I was afraid that if the upgrade rendered the system un-bootable, I would have lots of down time while I restored the main drive.
To avoid this, I purchased a second microSD card and imaged it with the cloned partitions from the original. Here is a key lesson I learned from this.
All of my past experience with disk cloning (see the related posts in this blog) came in handy, from originally cloning the disk images to writing those images to a new drive and then running partition checks to make sure the cloned partitions are properly expanded to the new disk size, etc.
All of that went swimmingly. But, the new microSD would not boot when inserted into the RPi.
The problem turned out to be a mismatch in the PARTUUID of the two cloned partitions. While the UUIDs were identical to their original counterparts, the RPi boot process uses the PARTUUIDs to boot the correct things … and these were completely different from the originals.
So, it was an easy thing to then correct the mismatch. First, I needed to see the PARTUUIDs of the new partitions on the new microSD card. I simply executed
blkid <DEVICE>
on the microSD card (e.g. /dev/sdc). This printed lots of information, including the PARTUUIDs. When I compared them to running blkid on the original disk, they were VERY different.
One then must edit two files on the new cloned drive: /boot/cmdline.txt and /rootfs/etc/fstab. In both places the PARTUUIDs of the /rootfs partition (needed to get the booting to succeed) and the /rootfs and /boot partitions (needed to mount partitions correctly during boot) are present. It was simple to edit in the new PARTUUIDs.
After the fix, the system booted like gangbusters! I hope this helps other people looking to operate backup clones of key systems like this.
