Properly restoring a backup to a fresh drive from an older drive

General Discussion
1

So just looking to make sure I’m understanding the process before I start this…

I have an old mechanical HD that I’ve created a backup of onto a mounted USB called sysbackup. I’ve since installed a newer SSD in the same machine running alongside the HD that I have imaged Dietpi onto then restored the backup from sysbackup. Only problem is with the GUID/UUID on the SSD not being the same as the previous HD backup so when I attempt to boot the SSD it always boot the HD.

I gather I’ll need to change the UUID of the SSD to match that of the HD but I’m confused on reading some previous forum posts about this… one says to change the UUID from (I think) the /etc directory to match the new one or possibly it’s the other way around. I just don’t want to make a mess of my system like changing the boot id and being unable to boot or something.

2

Pls share following

lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
cat /etc/fstab
3

lsblk
lsblk1035×710 47.8 KB

This is the output when I’m running off the mechanical HD, sdb is that drive and sda is the SSD. I figured a screenshot might be more neatly formatted vs copy/paste text output

4

You don’t need to change the UUIDs/PARTUUIDS of the devices, you just need to modify the UUIDs in your /etc/fstab to match the drive you wanna boot from.

It’s much better to paste text instead of a screenshot.
You can just wrap everything in a code tag and formatting is not a problem for you.

5

Yee just adjust /etc/fstab but would be needed on the SSD as well.

What could be done as well, unplug the HDD, flash a new image to SSD. This should allow to boot from SSD correct? This way you can restore your system to SSD.

As alternative, you can clone the whole system from HDD to SSD. This will align UUIDs as well. Once system has been cloned, unplug HDD.

6

Awesome I figured it was sort of easy. So pretty much just change the fstab file from B4CD-3439 (mechanical drive) to whatever the SSD is yeah? Does the longer part of 882fff15 need to be changed as well? Assuming it booted to the HD instead of the SSD no matter what because of that UUID line in fstab

7

Does you x86 device has some kind of boot order?

8

I think so, it should be sda then sdb. Just to clarify, I can boot from the SSD on a fresh image. Just restoring the backup to the SSD results in the HDD being the boot drive for now but guessing the changes to fstab will take care of that

Edit: I’m confused on what I’m missing… this keeps booting to sdb (mechanical drive) no matter what. Here’s the contents of fstab on sda (SSD):

# You can use "dietpi-drive_manager" to setup mounts.
# NB: It overwrites and re-creates physical drive mount entries on use.
#----------------------------------------------------------------
# NETWORK
#----------------------------------------------------------------


#----------------------------------------------------------------
# TMPFS
#----------------------------------------------------------------
tmpfs /tmp tmpfs size=15993M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid

#----------------------------------------------------------------
# MISC: ecryptfs, vboxsf, glusterfs, mergerfs, bind, Btrfs subvolume
#----------------------------------------------------------------


#----------------------------------------------------------------
# SWAP SPACE
#----------------------------------------------------------------


#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
UUID=92020909-1025-4319-aaf4-dc74eff844ce / ext4 noatime,lazytime,rw 0 1
UUID=42AA-35B1 /boot/efi vfat noatime,lazytime,rw 0 2
UUID=cfcd253f-5f85-4e21-b6be-f5737d5c7574 /mnt/HDD ext4 noatime,lazytime,rw,noauto,x-systemd.automount
UUID=32c9e664-273e-4443-b36a-4cb80c181b36 /mnt/sysbackup ext4 noatime,lazytime,rw,noauto,x-systemd.automount

Here’s the contents of fstab on sdb:

# You can use "dietpi-drive_manager" to setup mounts.
# NB: It overwrites and re-creates physical drive mount entries on use.
#----------------------------------------------------------------
# NETWORK
#----------------------------------------------------------------


#----------------------------------------------------------------
# TMPFS
#----------------------------------------------------------------
tmpfs /tmp tmpfs size=7949M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid

#----------------------------------------------------------------
# MISC: ecryptfs, vboxsf, glusterfs, mergerfs, bind, Btrfs subvolume
#----------------------------------------------------------------


#----------------------------------------------------------------
# SWAP SPACE
#----------------------------------------------------------------


#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
UUID=882fff15-6747-4c76-ba34-e110fe714272 / ext4 noatime,lazytime,rw 0 1
UUID=B4CD-3439 /boot/efi vfat noatime,lazytime,rw 0 2
UUID=cfcd253f-5f85-4e21-b6be-f5737d5c7574 /mnt/HDD ext4 noatime,lazytime,rw,noauto,x-systemd.automount
UUID=32c9e664-273e-4443-b36a-4cb80c181b36 /mnt/sysbackup ext4 noatime,lazytime,rw,noauto,x-systemd.automount

Even during the restore, dietpi understood the backup was from another system and made the changes to update UUID so I’m not understanding why I can’t boot to sda after a restore. BIOS has debian and debian for boot devices and even disabling one at a time, still always boots to sdb

9

What I would recommend, to clone the HDD to your SDD directly, once done remove your HDD and your system should boot from SSD. Or do you plan to continue to use the HDD? Moving a running DietPi system to a USB stick/disk or an onboard eMMC – DietPi Blog

10

I’d rather continue to use the HDD for backup storage etc after I get SSD working. The issue with what you linked is the HDD is 1TB, I don’t have a USB that big so I can’t do that efficiently.

I’d like to figure out why ssd won’t boot after a restore from the backup, despite the UUID being updated in fstab and the drives being disabled in BIOS. It should boot to the ssd now right? Is there anything other than fstab that needs to account for the new drives UUID? I’ve done everything as it’s laid out in this thread as I understand it so I don’t know what I missed. I can try disconnecting the HDD to see what happens but trying to avoid that as my computer is a pain in the butt to physically access.

11

This is an x86 system? And GRUB has been flashed to the SSD?

Can you define a boot order in the BIOS? Else I guess you need to adjust the GRUB config on the HDD as well, so that it uses the SSD as default boot media.

There is also the os-prober package and command to detect and add all bootable systems to the GRUB config.

12

It is an x86 system, I would assume GRUB has been flashed as it’s just an exact copy of the HDD. I’ll try to edit the GRUB config later tonight but failing that it might be quicker to just reinstall all programs and services from scratch on the SSD

13

It is a dd bit-by-bit copy of the raw drive, or a copy of the root filesystem? Because the bootloader is not part of the filesystem, but located outside of any partition.

dietpi-backup should have detected it and flashed the bootloader, but I did not test this feature since a long time.

A bit-by-bit clone on the other hand causes a UUID and PARTUUID conflict, so that the system cannot differentiate between both drives/filesystems, as long as the HDD is still attached.

14

I would do following, clone the drive as describe on our blog. This is working between HDD and SSD same way. Once done, switch off the system unplug HDD and start again. Once online connect the HDD again via USB adapter and change UUIDs of the HDD

15

The issue with this is having to shrink my 1TB HDD to fit on my 120gb usb stick and move that. I also don’t have access to a USB adapter for this. I’m thinking I’ll be quicker to just start from scratch on the SSD and reinstall/configure all the services and programs. I must’ve misunderstood what dietpi-backup does as it works great for restoring on the same drive but doesn’t seem to work on restoring to a new drive.

16

You could also use dietpi-imager to create a minimised image from the drive: DietPi/.build/images/dietpi-imager at 5f69eebea01ce277d48333ffa21b844d5a068c3b · MichaIng/DietPi · GitHub
It will expand again automatically once you boot it. But needs to be executed from another system on when booting from another drive. Hmm, actually we could implement even image generation from root drive, trying to remount it in read-only mode :thinking:. That would enable a nice alternative backup solution.

The dietpi-backup way at least requires to unplug the old drive or change UUIDs. Here is a good article about that: https://www.baeldung.com/linux/uuid-change-storage

17

you can clone from HDD to SSD directly. No need to use a USB stick

1 Like