A quick guide to setting up BTRFS Timeshift on Fedora 33

This guide is based on an excellent blog post by Will Mutschler found here.

Timeshift uses a specific subvolume layout when using BTRFS snapshots. Fedora 33 does not follow this layout thus we must edit them slightly.

All we will have to do is to change the subvolume names from the root and /home to @ and @home.

Step 1.

Install Timeshift. Timeshift-autosnap-dnf, and grub-btrfs are also great add-ons to have.

These applications are not available on Gnome-Software store for some reason. either use DNFDragora, KDE Discover, or the terminal,

$ sudo dnf install timeshift timeshift-autosnap-dnf grub-btrfs

Step 2 Use lsblk and blkid to learn the partition layout.

$ sudo lsblk
$ sudo blkid

will output currently installed drives. You will have to find the name of the partition where Fedora is installed.

Step 3 Mount the btrfs top-level root filesystem

do

$ mkdir /btrfs_pool
$ sudo mount -o subvolid=5 /path/to/fedora/install/partition /btrfs_pool

Step 4 Create @ and @home subvolumes

Using the following commands, we will create the required subvolumes with the appropriate names

$ mv /btrfs_pool/root /btrfs_pool/@
$ mv /btrfs_pool/home /btrfs_pool/@home
$ btrfs subvolume list /btrfs_pool

Step 5 Make changes to fstab

You’ve added new subvolumes, now correct fstab to reflect these changes. Simple change the subvolume names of both / and /root. It should look something like this.

cat /etc/fstab
# UUID=11fa3de5-bfb4-4227-a5ee-d8a3d2d2304a /                       btrfs   subvol=@,ssd,noatime,space_cache,commit=120,compress=zstd,discard=async,x-systemd.device-timeout=0      0 0
# UUID=7d52fc6e-8804-4a34-8d16-b185d6d62319 /boot                   ext4    defaults                                                                                                1 2
# UUID=4FD9-A843                            /boot/efi               vfat    umask=0077,shortname=winnt                                                                              0 2
# UUID=11fa3de5-bfb4-4227-a5ee-d8a3d2d2304a /home                   btrfs   subvol=@home,ssd,noatime,space_cache,commit=120,compress=zstd,discard=async,x-systemd.device-timeout=0  0 0
# UUID=11fa3de5-bfb4-4227-a5ee-d8a3d2d2304a /btrfs_pool             btrfs   subvolid=5,ssd,noatime,space_cache,commit=120,compress=zstd,discard=async,x-systemd.device-timeout=0    0 0

Notice the subvol=@ and subvol=@home.

Step 6 Update grub.

We have changed our drive layout and fstab, We should now update Grub to allow the system to boot properly.

$ grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

now reboot the system, and with any luck, the system will start and Timeshift will now allow btrfs snapshots.

4 Likes

this is not supported anymore on Fedora 34 or i can not find it :slight_smile:

yep, it seems they are abandonded

I seem to recall there being a GitHub repo with it in it, I’ll post it if I can find it.

great guide, was easy to follow and managed to get timeshift working easily. In case anyone else wonders, the timeshift-autosnap-dnf and grub-bt packages were not strictly needed (indeed no longer in fedora 34 repos)

Thanks! It really works

Update: this guide may have an issue as of Fedora 38. Updating to a new kernel might cause a complete system failure. I’m looking into the issue. Please hold this modification for new installs!

(1) The “space_cache” mount option could create problems if the filesystem is created with a recent Fedora version (btrfs-progs> 5.15):
From the version of btrfs-progs 5.15 “space_cache=V2” is the default setting.

  1. Remove space_cache from btrfs mount options by dalto8 · Pull Request #1824 · calamares/calamares · GitHub
1 Like

Hi,

I have a fresh install of F38, default settings with luks encryption. I have nothing like Paul’s fstab. In fact mine is like:

#
UUID=974a92ad-75ce-4957-9258-975411396cab /                       btrfs   subvol=root,compress=zstd:1,x-systemd.device-timeout=0 0 0
UUID=8424fe94-203a-4c47-88d6-969b7c50661f /boot                   ext4    defaults        1 2
UUID=974a92ad-75ce-4957-9258-975411396cab /home                   btrfs   subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0

Are there benefits to modify the default settings as far as timeshift is concerned. Timeshift works actually pretty bad, but it kinda works as is as long as I’m with the same kernel and I run those 2 commands after restoring and rebooting:

restorecon -r v /
chmod 640 /etc/*shado*

I understand the changes from / to @ and home to @home. But what is btrfs_pool?

As for the other mount options, I was already told never to use discard nor discard=async but use fstrim weekly instead. I use noatime only on temporary filesystems. I could benefit from ssd option, I wasn’t aware of it. As of space_cache and commit=120, I understand them but am not sure whether or not to use any. I’m new to btrfs.

All in all, are these changes still required in F38 and how would I benefit from them? This thread is from 2021. My understanding is that Timeshift is a lost cause. I opened a bug report, but I don’t even count on a reply.

If you don’t want to rename the root and home subvolumes you can use Btrfs Assistant for snapshots/rollbacks.
Sure, Timeshift is simpler, but you have to rename the subvolumes.
Also you have separate “/boot” partition in ext4, create snapshots close together in time, otherwise rollback fails, You can find yourself in a similar situation: Failed to boot when restoring a Btrfs snapshot with systemd-boot - #2 by dalto

Hi Emanuele,

Thanks for your reply. As a matter of fact, I ended up with an unbootable system from a F38 backup after upgrading to F39 and decided to roll it back with a timeshift restore because of some of my favorite applications rely on python 3.11 and F39 is shipped with 3.12. The backup was a few hours old only. Do you think renaming the subvols would have prevented this from happening? Ended up recloning back from a dd backup I make for those occasions (I don’t particularly trust timeshift but i have yet to learn snapper and btrfs-assistant. Priorities, you know. Will do that when I have a fresh dd clone, just in case. Could take weeks though before that finally takes place.

Last remark, it’s not that I don’t want to rename the subvols, it’s rather that I wonder if it’s still the thing to do. After all timeshift works bad, but it works to some extent. Will do that after a fresh dd of course, just in case.

Oh, and before I forget, I restored a 3 hrs old timeshift backup earlier today because installing mythtv-pvr broke my Kodi. Had to run the 2 commands in my last message to mitigate SElinux notices flooding though. After that, everything looks fine so far. BTW I use timeshift in rsync mode to include the ext4 partition, although I’ve never checked whether or not it was included in the backups. I don’t use EFI.

Best!

Hello everyone. I’ve recently stopped using Timeshift and use Snapper via BTRFS-Assistant. It is an easy-to-use Application with some BTRFS stuff, mainly Snapper snapshot support.

It requires no modification of the subvolumes and works out of the box for Fedora.

I’m still learning the ins and outs of the program, so I don’t know how to snapshot everything but the home directory. I need to figure that out. But so far, it seems to be a better alternative to Timeshift for BTRFS systems.

Python 3.12 has major changes to build system and Fortran compiler (from gfortran to flang). It will take a while to get apps ported. Meanwhile, as mentioned by Sam Miller in Will sagemath return? you can use conda or mamba to create an environment with python3.11.

Hi Paul,

Thanks a lot for your intervention. That’s probably what will happen for me as well when I have some time to learn it and a full backup ready. I had them installed but the config was unmeaningful and possibly destructive for someone not familiar with it. There is some learning curve. Priorities, you know. IMHO Timeshift is doomed.

Best!

Hi George,

Interesting reading. Wich means more reading in perspective. Thanks for your comment. Last time I used Fortran actively was in 1977. With perforated cards and a keypunch made by IBM.

I wish Fedora has a checklist, well maybe it does and I haven’t yet find it, to help you upgrade major versions like debian e.g. Release Notes for Debian 12 (bookworm), 64-bit PC

Granted, something could go wrong nevertheless, but you’re warned of differences between versions and potential problems after the upgrade. Debian 12 for example completely broke CUPS for old printers so if you have network printers and machines on your LAN rely on them, prepare yourself to reconfigure the printer on all of them. An earlier version of Debian broke the MTA system when they switched from exim3 to exim4; the motion package’s new maintainer changes the configuration variables names constantly which in turns breaks every program willing to read them. Hopefully, the list is short and most upgrades just go well.

Best!