DietPi bricked after backup restore

Hey there!
So, this is my problem: I had just finished updating my Raspberry 4 from Buster to Bullseye, but some of my stuff stopped working, so I thought to restore the backup I took before the update to get back to a working state, since I don’t have time to look into the issues right now.
Problem is, the SSH disconnected after a bit during the restore process (I assume something related to the network got touched). I gave it not much thought and left the raspberry alone for around 5 hours (around double of the time it took to create the backup, just to be sure), but I couldn’t SSH to it anymore (it timed out). I tried manually rebooting, but it still doesn’t work (neither SSH, nor VNC, nor any of the services I host), so I suspect that the system is compromised.

Can I salvage the situation in any way or am I forced to start anew? I have some important stuff in there so I need to recover files.

Usually the backup is not causing a network disconnect. There must be a different reasons.

But there are ways to restore it. Some questions before

  • where is the backup stored?
  • On an external USB stick or on the same SD card?
  • do you have a spare SD card?

Huh, just my luck I guess. I can’t give clues as to what caused it, but I assume it was user error.

The backup is stored in the SD card where the system resides, in /mnt/dietpi-backup (which I think is the default location)
I do not have a spare SD card of the same size, but I can order one with no problem (I was actually thinking about upgrading).

yes a 2nd SD card would be needed to flash a new system. As well you would need a USB to SD card connector that can be used to connect your current SD card to a USB slot.

Idea would be to install new system and to restore the system during first boot. This is parameter that can be activated on dietpi.txt

# Restore a DietPi-Backup on first boot: 0 => disable | 1 => interactive restore (show list of found backups) | 2 => non-interactive restore (restore first found backup)
# - Simply attach the drive/disk/stick with contains the backup. All attached drives will be mounted temporarily and searched automatically.

Can I get the backup files from the SD using an ext4 explorer from a windows machine or a Linux VM? Seems simpler

Of course you can use a Linux VM to access the SD card but what are you trying to do with the files afterwards?

I’d put them on a USB to restore from, so I can format the SD card and save some time

you need to ensure ext4 file system format on that USB disk. And while copying the data, you would need to copy permissions as well. For safety reason, I would recommend to clone your SD card using tools like W32 Disk imager. Just to have a fall back in worst case where your backup is stored on.

Progress report: I remembered that I have another SD of the same size, so I followed your suggestion and restored the backup on a fresh install. Unfortunately it still leads to system corruption, so I unfortunately have to start anew with my setup.
I will give it one last try, but I don’t have much hope.

what do you mean by system corruption. What exactly is/was broken? Did you download a new image or did you used an older one? Because our new images are based on new Debian Bullseye. And if you did not upgrade, your backup require Buster still.

Aren’t the backups full system backups, and as such supposed to downgrade your system? I remember reading as much on a related topic on this forum.
As for what was broken, I don’t know, because it wouldn’t even boot.

Yes it is a full system backup, but at least the bootloader outside of the filesystem is excluded. However, since RPi uses an actual bootloader within the FAT filesystem, indeed you should be able to downgrade the system successfully with a restore. Although we just recently observed (and luckily found a solution) for a strange issue where a system library used by curl somehow preserved Bullseye ELF headers after the restore:
How this is possible needs to be investigated, as dietpi-backup simply does a full rsync, so replaces/syncs every single file and directory.

Do you have a screen or serial cable to check boot messages, when it is failing?

well there are some boundaries. I did some test in the past to check what is possible with the restore function. :sunglasses:

For sure what not gonna work is to restore a 32bit system on a 64bit image. This always ands up in some kernel panic, at least for me.

Personally I would recommend to use the same image where the backup was build on. This should give less challenges.

Ah yeah that is true and makes. Restoring a 64-bit image onto a 32-bit image (with hence 32-bit kernel loaded) will definitely fail, in other cases also some userland parts may expect a different kernel, or the bootloader may not work with the restored kernel so that boot fails.