[ale] Backing Up and Restoring Fedora 30 KDE Plasma Spin

[Jeff Hubbs]

You *can* try to back up a running system via tar or rsync, but it's 
really not a safe way to go; if it's a database server and the daemon is 
running while its files are read, you can forget about having a reliably 
restorable instance.

If you can stand the downtime, the absolute safest thing to do is to 
bring the system down, boot it to e.g. SystemRescueCD, mount the 
partitions readonly in the same tree arrangement that you ordinarily 
boot with, and *then* tar or rsync the mount point contents off 
somewhere. A hybrid alternative method is to utilize some sort of kernel 
snapshotting (lvm or appropriate filesystem function) behavior, close 
everything you can close down momentarily, fix your snapshot, put 
everything back in running condition again, and then tar/rsync from the 
readonly-mounted snapshot.

In the case of database servers it's really best to just stay clear of 
the DBMS daemon's disk space entirely and use its dump/restore powers, 
whether you write the dump output to the machine's own disk and then 
back up the system a la the above or write the dump out to 
somewhere/something else.

Even VM snapshots need care with respect to what's running while the 
snapshot is being taken. The basic problem is the same no matter how the 
volume data is copied.

I've heard of people running backups of system(s) and then performing a 
restore back to the same system(s) *every night*. Can't say their 
restore process ever want untested.

On 10/21/19 7:49 PM, Ryan Spencer via Ale wrote:
> Ideally, I want to be able to restore my computer like how you can 
> restore VM's with snapshots - to a previous state.
>
> So far, I have checked out tools like rsync and Borg but I am 
> uncertain of how to exactly use them in my use case. I just don't want 
> to blow up my system (again... Can neither confirm nor deny that I 
> have had to reflash Fedora back on to my computer 3 times in the span 
> of a week).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20191021/bb45c5a1/attachment.html>