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.
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.
AUTO_SETUP_BACKUP_RESTORE=0
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: https://dietpi.com/forum/t/upgrade-to-bullseye-apt-upgrade-errors/5736/11
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?
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.
