Hi all, just a quick check with others, because im not 100% sure if this is indeed its just me again, but i had coincidentally mounted my arch rootfs on /mnt/tmp1 while on Debian, when restoring data to a different mount (/mnt/DUMP). Checking the log for the restore i see this:
After unmounting and attempting to recover another backupdir, i notice some weird errors:
Ok so it happened again. Because i had some unclean shutdowns while messing around (i know how that sounds, i know) with Arch, i run scrubs on my btrfs filesystems. All were good except for 2, one holded mostly a steam library on a nvme-backed lv, the other a lvm cached lv that is backed by 2 classic spinning rust disks, well of course the cache went bad. So for the first filesystem i simply recreated it, as it only holded a Steam library and i can simply reinstall the games. From the backups i had, i restored the steam compatibility data (proton/wine prefixes really) the screenshot in my earlier post reflects that (“Steam Runtime” and “Steam compatdata GamesNVME”, there i noticed the errors in the logs that i still wonder why those came from, as the files for which the errors are thrown had nothing to do with the restore attempt.
The other filesystem, with the lvm cache, is huge. From the journal entries that popped up during the btrfs scrub i was able to identify which files were corrupt. Only about 10 files. All except for 2 of them i had included in my backups. Again the files that i needed to recover that were left were related to steam. So again i attempted a restore (which btw all seem to succeed!) and i noticed during that icons from my taskbar were starting to vanish. I looked at first like untattended upgrades was upgrading some packages in the background. Then when i opened htop i could see some binaries that were running were not present anymore on the disk. Huh? So i decided to reboot. To find my system would not boot.
Fortunately i had re-setup Arch and from there with the help of the snapper snapshots i do run for the Debian rootfs i was able to sync back a snapshot from before the restore attempt. But at that time i did not think the restore was the cause. Until i got back in Debian and opened the urbackup webinterface and checked the restore log:
And it happened again. At this moment i am scared of using restore via the webinterface.
Im detailing the situation.
I have server_confirms enabled, so to initiate a restore i go onto the server webinterface, pick a backup, browse to the subfolder i need to restore and select restore, the restore action starts at that moment, without any interaction on the client side.
First i restored a subfolder on /media/DUMP. In particular /media/DUMP/Games/Blizzard/ which is in the “Games_DUMP” “backupdir” Everything went fine, no issues reported in the log on the server side. Nothing at all mentioned at the client log.
Then i needed to restore “/media/gamesnvme/SteamRunTime/steamapps/compatdata/4230314876/” which is part of the “Steam Runtime” “backupdir”. As i was waiting for the restore i was watching a youtube video from level1techs and had the folder opened in dolphin on the other monitor (on the same client that the restore was running on). Then Dolphin just closed, and i tried to reopen it. An errormessage appeared at the right bottom, saying the Dolphin executable existed, but didnt have the execute bit set (what??) then the youtube video hang, looping a couple of seconds of the audio constantly. The machine was completely frozen (ctrl-alt-f2, -del, no response) and i had to hard-reset. Grub greeted me and after that a kernel panic. Used Finnix to restore a snapshot (basically rsync -avHXp /snapshot /rootfs) to restore a working state of my rootfs. After that it booted.
The moment it froze:
Is part of the urbackup restore to “walk through” the data of the backup that is not relevant but somehow it restores that irrelevant data in my case? Looks like it to me. Like say you include 2 backupdirs in a backup FolderA and FolderB, for (obviously) different non-nested paths. Then when trying to restore FolderB, it walks through the backup archive until it reaches the contents of FolderB, but in my case, for some reason, it also restores the contents of FolderA. But im just guessing ofcourse.
I might run some tests this weekend like restoring from the commandline to a different path, to see if it somehow creates the files/paths that should not be part of that restore, but insightful responses are very welcome!
EDIT: it seems the photos i took with my phone are not displayed and i tried to re-insert them without success. If relevant ill look into that later.
You probably have some symlinks to the root directory. E.g. wine has those.
When restoring with the command line you can use --no-follow-symlinks to not follow symlinks during restore. You can also change the backups to not follow symlinks.
I think it might be best to change it to not follow symlinks when starting the restore from the web interface…
