Recommended daily backups

Ask Fedora Ask in English
,
1

What is a simple way to backup my system daily so I can rollback to the exact same state should I mess up (System files only not /home)

Ideally I would be able to restore from the Fedora recovery rescue environment something I don’t think I can do with BTRFS snapshots.

Although I would love to be mistaken.

2 Likes
2

There are several options.

  • Rsync in a cron to an external hard drive.
  • Setup a Nextcloud instance to sync your home folders you want synced and enable file versioning in Nextcloud.

Best practice is to have both an on site and off site backup, in case something catastrophic happens in one of those (cloud vendor has data loss, a fire in the office, etc).

2 Likes
3

The Fedora Magazine has done a number of articles on backups too that may be worth looking at:

https://fedoramagazine.org/?s=backup

(Please note that magazine articles are not updated once published so the information was correct at the time the article was published but may have changed since)

3 Likes
4

Original poster is looking to back up from root excluding /home, so I would assume he already has /home backups solved.

2 Likes
5

A major question you have to ask first is: against what do you want to protect?

E.g., RAID protects you if the hardware of one physical drive fails. But it does not protect you if you or a buggy application accidentally delete a file permanently. It will potentially also not protect you if there is an issue with the file system.

You mentioned BTRFS snapshots: they might protect you against the accidental deletion of files, but not against the failure of the drive hardware or file system issues.

A “full backup” that contains protection against hardware failure and accidental deletion of files/file system failures and such, might be something like rsnapshot , borg or restic if they backup to another physical drive that contains a separated file system. Check out yourself which of these solutions suit you best. There are many more. But keep focused on comparing “what you want to protect against” with “which solution/configuration incorporates which protection”.

Be carefull with rsync, because it is a generic tool like cp or dd: it is not explicitly a backup tool. This means that you have to implement the backup capability yourself: e.g., if you just make an rsync without anything else, the backup might adopt a failure of the origin and thus, fails itself, while rsync on itself does not keep copies of previous states (to which you could revert) unless you ensure this capability yourself: data loss is the worst outcome. Given the example above, and depending on how you use rsync, it might also adopt the accidental deletion of files.

Supplement: rsnapshot should be avoided if you backup large files that regularly change (it will backup the whole file in each backup/snapshot even if just one byte has changed). In such cases, borg or restic might be better alternatives, as they only backup the changes. However, rsnapshot has the advantage that it does not need any software to use the backup: you can access and use it always just by the capabilities of hardlink-capable file systems (most fs we use as of today support that).

6

You are correct. :slight_smile:

I already have a cron job setup to backup my /home to an external HDD using rsync.

To clarify the background of this post and my ultimate goal.

Yesterday I ran a command that inadvertently removed key packages required for cinnamon and networkmanager.

I could not in the recovery environment undo the transaction, I did not have packages in cache and couldn’t use the internet.

I had to reinstall fedora and luckily having my /home on a separate partition I only lost system packages and some apps.

The end goal is something similar to windows system restore but I can take daily ‘backups’ to avoid any such future mishaps and run a terminal command in recovery mode that equates to return all packages to the state of x.

where x is a date

and then I keep the past 48 hours of snapshots.

7

That is a good plan. I used to be system admin for a company where we did weekly full system backups, daily incremental backups, and kept a full months worth of tapes in storage off-site in case something happened. How extensive you plan your backups is dependent upon your needs, but obviously you should consider the worst case scenario as part of that planning. Worst case does not limit itself to the system only, but everything (hardware and all software – system and user related)

8

I agree.

Disaster planning only seems extreme until the worst happens.

However, this is my personal workstation with nothing too important on it.

Any advise on how I would accomplish the above?

Happy to use terminal, in fact I would trust it more if I could easily see verbose logging (not that that negates GUI options).

2 Likes
9

Consider checking out:

So these aren’t going to just magic button answer or solve the issue you’re asking about. But they’re tidbits of info maybe get closer to what you’re trying to do. Of course the single most reliable push button solution for this is to do a clean install, and just restore your user data. There are ideas how to preserve known working states and make updates more reliable, so that hopefully rollbacks aren’t even needed.

1 Like
10

Sadly history rollback was exactly what failed me yesterday.

Would it be possible to restore a btrfs snapshot from the rescue environment?

2 Likes
11

I would use a live system to restore the snapshot, https://github.com/digint/btrbk#restoring-backups.
https://fedoramagazine.org/recover-your-files-from-btrfs-snapshots/
And yet another interesting read: https://discussion.fedoraproject.org/t/is-there-a-plan-to-integrate-btrfs-snapshots-in-fedora-that-appear-in-bootloader-grub/72104

1 Like
12

Only if you took a snapshot before the problem happened. There are no automatic snapshots on Fedora.

Several valid approaches:

read-write snapshots can be booted just by temporarily changing the GRUB boot entry rootflags=subvol=$nameofsnapshottoboot - any changes are persistent, because the snapshot is a writable snapshot, so it’s changing pretty much immediately

read-only snapshot can be booted similarly rootflags=subvol=$nameofsnapshottoboot fstab.no systemd.volatile=overlay - which makes it a read-write environment using overlayfs and tmpfs, changes will not survive a reboot.

Boot a read-write snapshot of the read-only snapshot - in this case you need to be able to boot to a working CLI somehow (including the ro overlay method above), and then make a writable snapshot of your read-only snapshot. This writable snapshot likewise persists changes, but it can just be thrown away if the rollback doesn’t help or things get worse or you figure out the problem with the original root.

At the moment I’m kinda liking the idea of default installations having a paired down root.rescue subvolume read-only snapshot, and booting it via the GRUB “rescue” entry with the volatile overlay. At least the user gets to a graphical environment rather than a dracut shell. But it still needs some work to address the question “OK, now what?” because it’s just not obvious how to figure out what went wrong with the original root, or how to fix it. We could have a brute force hammer: snapshot the root.rescue to a new root, and then do a big group install + update to get things close to what we’d get with a clean install with updates, but without the hassle.

1 Like