[plug] Dumb stuff recovery

[Brad Campbell]

On 26/8/24 08:27, Juneidy wrote:
> 
> One thing I am curious though, does that actually work for source OS that is currently running? Is there any caveat?
> 

Yes it does, and the real caveat is restoring to a running system you change the inode number of every file and directory on the system.

Binaries that hold dirs/files open are fine but anything that tries to do an open() on a file will may well crap out depending on how it's managed.
Always safer to do a reboot straight after the rsync restore.

Restores are not the sort of thing you do on a day to day basis, but I do running system root fs backups all the time.

Things like databases or vm backing images can be left in inconsistent states, but I've never really had it be a problem. In most cases the backups are last resort system backups, so very much best effort. Having said that I've used them for restores many times and not encountered an issue.

In this instance, my conventional recovery would have been to reboot systemrescuecd, manually bring up the RAIDs, open the LUKS partitions and mount up the filesystems by hand, then rsync everything else back.
Because the LUKS keys are normally automated they are really, really, really long and complex. So it was probably faster for me to fart around and figure out a way to do it on what was left of the system than to reboot and start from zero.
Plus, it's a bad day when you don't learn something.