For extundelete,
IIRC (been a few years since I’ve deployed),
When you install/execute initially, it walks you through the whole process of specifying what you want to snapshot and on what schedule.
So,
It’s not really in separate documentation,
IIRC the walk-through is pretty clear.
And, I’ve messaged with the author, he’s very receptive and responsive to any questions/suggestions for improvements.
TSU
Weird, I thought one of the greatest reasons for installing OpenSUSE were its great built-in disaster recovery system through snapper and BTRFS. It’s really handy for botched upgrades, etc. too. The subvolume layout is really useful and well thought-out.
The snapshots and grub-bootable snapshots are really useful when using a rolling distro, too, because it’s common for new updates to bork the system. I definitely recommend it for tumbleweed or arch (arch on ZFS rpool is a pretty beast).
I try to re-create this on CentOS, Fedora and Ubuntu when I install them. BTRFS is an option on CentOS and Fedora, just partition your own system. LVM+XFS, the default, has some nice options, too, but BTRFS really is the most feature-laden and doesn’t require the extra abstraction layer LVM provides, which can cause disaster recovery issues - i.e., you can’t use basic partition tools like gparted to get at your partition with LVM, but with BTRFS you can.
On Ubuntu, if you set up a BTRFS root with separate home you can do snapshots with Mint’s “Timeshift” program which is not nearly as detailed as YaST with all the subvoluming, but it works pretty well. https://www.maketecheasier.com/backup-computer-timeshift-linux-mint/
Also important to:
Make a separate /var with at least CoW turned off if BTRFS, or use XFS, EXT4
Have a separate /home so your personal files aren’t rolled back accidentally
Don’t fill your drive up too much - leave about 10-20% for slop space - this is an issue with ZFS, as well.
CoW FS are the way of the future once the issues get worked out. There’s plenty of work being done upstream through Facebook, who use it for containers: https://facebookmicrosites.github.io/btrfs/docs/btrfs-facebook.html
It’s a good read - it details how BTRFS solves some of FB’s issues they saw with containerization (“Tupperware”) and cgroup2 IO with EXT4. It also has a list of stuff they’re working on at the end. FB is a pretty heavy hitter, dare I say… bigger than RedHat?
The premise of this thread is ridiculous on its face - BTRFS isn’t going anywhere.
https://www.phoronix.com/scan.php?page=article&item=linux-50-filesystems&num=4
btrfs has more options but is also the slowest
Hi
Those results are very questionable at best… I see no where near those times with GNOME and btrfs…
Neither do I, on KDE. And phoronix … well, it’s phoronix.
I’m sure you have better Benchmarks to say that these are not reliable;)
On Fri 03 May 2019 11:56:03 PM CDT, enziosavio wrote:
Knurpht;2901352 Wrote:
> Neither do I, on KDE. And phoronix … well, it’s phoronix.
I’m sure you have better Benchmarks to say that these are not reliable;)
Hi
For me sure, the computers in front of me, The only benchmark I’m
interested in… 
They all work as expected with btrfs and xfs…
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
Tumbleweed 20190430 | GNOME Shell 3.30.2 | 5.0.9-1-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
Slower by a second or two on an NVME SSD at its worst which is insignificant in real life usage.
The random IO tests are completely pointless because they’re never encountered by your ‘average user’ in a real life situation and as for those of us who do encounter them, we have other ways to go around them. Random IO is almost never an issue, anywhere - even on systems where I have thousands to tens of thousands of clients per second.
Hello
Mine is a different approach, I use ext4 even though it’s not the first in Benchmarks, and I don’t even try to justify my choice, also because I’m not competent enough to say this is better than that, but in my own way I had a 'negative experience with btrfs … what I never had with any other previous file system, and I’m sure many were unhappy with btrfs
Still using “ext4” here.
I am using “btrfs” in a VM running Leap 15.1. And thus far, it is mostly fine. There was one time when the system seemed frozen for a couple of minutes while something “btrfs” related was going on. But, apart from that, it seems okay.
I’m just not seeing a benefit to “btrfs”. And until I do, I’ll stick with “ext4”.
On Sat, 04 May 2019 14:16:03 +0000, nrickert wrote:
> I’m just not seeing a benefit to “btrfs”. And until I do, I’ll stick
> with “ext4”.
Same here. If it ain’t broke…
Nice example of the last couple of days: Due to the unnecessary install of apache-commons-parent a while ago, an updated version suddenly pulled in ~130 maven packages. I simply rolled back to a snapshot of just before the maven invasion, rebooted, ran ‘zypper dup’ again and no maven packages …
Nrickert: I use the feature a lot. User asks about certain software, I install it, help if I can, then later roll back, en rerun ‘zypper dup’ if needed. Has not failed on me once in the couple of years I use btrfs .
Yep, and many are unhappy with systemd, KDE>3, GNOME3 and want icon sets back that don’t even cover half of the installed software.
Bluntly said; BTRFS is mature, and it’s snapshot features provide a safety no other FS has.
Okay, that’s a pretty good example of finding a good use for “btrfs”.
I’m so surprised to learn someone so into OpenSUSE isn’t a huge fan of BTRFS! I always thought the snapper+Yast+BTRFS integration was like the most amazing feature OpenSUSE implements by default!
It’s even lightyears ahead of beadm+timeshift on ZFS for solaris/illumos, which was the previous top-spot, because the snapper+yast integration has such granularity.
Mint has a new version of Timeshift but kind of obscures its usage since it doesn’t install BTRFS by default so most users won’t know how to implement it. There was apt-snapper for a while but it looks like development has died. I just can’t believe it.
That leaves OpenSUSE essentially alone in offering this feature.
Try it - make a TW VM with just the default BTRFS partition scheme, ‘zypper in’ some stuff, then look at snapper in yast and check out all the ways you can roll back if you want.
Also, like beadm, you can boot snapshots straight from grub (might be only if you do a full ‘zypper up/dup’ - not sure).
Look at the subpartition structure - it’s incredibly well planned:
@averyfreeman](https://forums.opensuse.org/member.php/105813-averyfreeman)
Thank you for your observations and link to the BTRFS SDB.
Saves me a bit of investigation and some testing.
A quick skim answers a lot of questions I had in my mind regarding the 15.1 disk layout, configuring /home as a BTRFS sub-volume.
In particular,
By excluding /home from snapshots, there is file system auto-repair but no rollbacks and “undo deletes.” For that those fault tolerant features to be implemented, I expect that
Plenty of other locations not mentioned in the SDB should be excluded as well so there is a big flashing “Warning! Your Data can be at Risk!” when deploying a database like MySQL/MariaDB and PostgreSQL… I sometimes see data files not located in /var. SQLite data files can be anywhere, noted for its lack of Application(Manager). And some webserver technologies like Java web servers rarely deploy their Java components in the web server directory tree.
Because of the above potentially disastrous issues, it could become even more important to use YaST to set up applications, assuming YaST modules will be made aware of these new BTRFS issues… But may become very hard to manage if/when /home is snapshot-enabled.
In other words,
It looks like the move to deploy /home as a BTRFS subvolume excluded from snapshots is a safe “baby steps,” and any attempt to more fully enable BTRFS features can wait for another day.
TSU
It depends on the usage. I rarely expect to rollback. And my backup strategy is to backup “/home” and plan on a complete reinstall in case of hardware failure. So the rollback capability doesn’t off much that is interesting to me.
I think exactly the same way
It stands to reason that snapshots of /home should just be done manually, while the configuration for yast+snapper should exclude /home since those snapshots are focused on system disaster recovery.
You could always make a separate configuration for /home with different triggers.
as far as the database or java software installing transactional data elsewhere than /var, chances are at least some package maintainers have thought of this and moved their directories - of course, some may not.
This is the beauty of the BTRFS subvolume being default, though - it’s much more likely to be adopted properly across the OpenSUSE ecosystem than if it were offered as add-on technology.
I also haven’t tried snapper YAST integration yet. For me the problem with BTRFS is that it is so confusing for somebody used to traditional filesystems and can cause more headaches then benefits. I agree the features are great and BTRFS definitely is not dead. Recently I’ve learned BTRFS is extensively used on Facebook production. If it’s stable enough for them that it’s certainly fine for home usage. Here is the article on Facebook BTRFS experience 