Btrfs Snapshots and Backup Solutions

I don’t use Gnome Software at all.
DNF update is better, both because it tells me exactly what it is doing (system updates?) and because it does not require two reboots each time. I mean, I understand safety, but… Oh, and DNF doesn’t sit in the RAM doing nothing.

I also avoid flatpaks because I prefer the old idea of repositories and package maintainers to the “windows like” idea of a “store” where somebody posing as the developer distributes “stuff”.

Once I read Debian only provides software that can be compiled from within Debian infrastructure, meaning no external files are allowed. That is good.

I don’t want any “setup.exe” from untrusted source, I don’t want the “setup.exe” to make any change on my system and all the related consequences.

Back to BTRFS I don’t need much a snapshot before updates, It would be better one once in a while like a sort of system backup. Ideally the first thing in the morning. Currently I am doing backups of my files once a week and that is enough to survive a catastrophe. The condition when an update has bad consequences is rare and, besides the option of “DNF history”, you could restore a “point” of some days before, not exactly the very state before the update.


I had serious / critical issues, unbootable systems using btrfs snapshots. In fact, it succeeded only once. Made several tests from the command line, using snapper, timeshift. Those tools are very dangerous IMHO.

Not to mention patches to the kernel code are made almost on a weekly basis. That alone should let one think it’s highly unstable.

Btrfs, I far as I understand it is still highly unstable and may be potentially harmful to your computer. I, personnaly, would refrain for ever using it.

I have to mention though, some other users say it’s the best invention in the linux world because shapshots. I disagree totally. When I wanted to make changes to the file system specifying the volume label as the select parameter, I did not expect the kernel team had made redirections to the UUID in the kernel code: they did. Imagine the result with 2 hard drives (the main and an unmounted clone with same UUID and different LABEL)!

BTW I replaced snapshots with partclone.btrfs. It’s slower but foolproof.

1 Like

I insist.
I don’t see the connection between “updates” and “snapshots”.
For two reasons.

  • I could notice an issue caused by the update some time later, not necessarily right after it.
  • I don’t see the difference between updates and any other change I make on the system, by accident or on purpose.

I think “snapshots” should be considered like system backup and then they should be available for manual or scheduled execution (of course, with the “opt out” feature). Like I wrote above, ideally I would do a snapshot every day as first thing in the morning, regardless what I would do later.

Right now my option is both manual and automated backup of personal files and just a fresh install for Fedora.

I could notice an issue caused by the update some time later, not necessarily right after it.

Then keep multiple backups? I dont see how this is an argument against backups. BTRFS snapshots also use the diffs only to my knowledge, so this shouldnt be a problem.

difference between updates and any other change I make on the system

Hooking it into the package manager just makes sense. There may be apps that do random stuff to the OS, but only /etc is important here, as on Atomic Fedora all the rest is read+execute only and everything works normally.

Apart from random .run or just or whatever installs to the system. These dont work.

But normally when doing a change in any of these directories, it is done by the package manager. So hooking in a snapshot before every install or update (having an option --no-snapshot) would make sense.

should be available for manual or scheduled execution

As I said I use Atomic Fedora and the only “system” modification outside of /etc I do is via the package manager.

It is not relevant for this discussion, as this is about rpm-ostree where snapshots are not normally used.