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 resticif 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).
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.
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)
btrfs subvolume find-new by doing man btrfs subvolume, you can specify a “since” value in the form of an older generation value than the current value, and it’ll show new and modified (not deleted) files that have happened since that generation.
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.
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.