I need a little help with brtrfs-assistant restore feature

General system Applications
1

Hello,

a happy new year 2024 to all!

Here’s my problem:

I’d like to do without the multiplicity of graphical tools for managing btrfs.

I’ve come across btrfs assistant, which seems to be the “Swiss army knife” for this.

I’m missing one thing: I can’t get the “restore a backup” function to work (I use a 100% functional script for that, but if it can be done with btrfs-assistant, that’s even better).

in fact, under the Snapper / Browse/restore tab, the select target drop-down list doesn’t display anything. Do you have the same problem? I have the same problem with mint , Debian Sid and Endeavour. Snapper’s other tab functions work perfectly normally, which is a bit strange.

Could it be due to the fact that I adopted a different layout configuration than the default snapper configuration (in fact I adopted the layout suggested on the archlinux wiki.

Last subsidiary question, probably a bit silly: can btrfs-assistant run without snapper to do all the operations (snapshot, restore etc…)?

thank you all for your feedback.

2

Probably. If you use a non-standard layout instead of using Snapper’s default, you may need to add the subvolumes layout to the btrfs configuration file. Otherwise, it has no way to know where to restore snapshots to. Although, it depends what your layout is. It does handle some common alternative layouts.

It can take manual snapshots and restore backups. However, it uses Snappers to handle scheduled snapshots, pruning and most other automation so it is better to use Snapper unless you are doing something one-off.

3

hello,

good morning,

I’m adding this link with the solution for those who might be interested. However, for my configuration I still haven’t found the right settings, so I’ll have to re-read the post again.

https://forum.garudalinux.org/t/btrfs-assistant-not-showing-snapshots-to-restore-to-when-booted-into-a-snapshot/27851

4

I mean, I know a little bit about btrfs-assistant so if you shared your layout, I could help you with the config.

Alternatively, it would be probably easier to simply switch to Snapper’s default setup.

5

@dalto , @BluishHumility (who’s laughing)

i’ve seen you helped Emeraldenigma who posted on the garuda forum.

so i’m writing to you out of desperation (lol),

my configuration seems to be exactly the same as his, I used the same layout…

two differences though:

  • my root sub-volume is called @endeavour and not @ (in fact I have three distros with @ (mint) @sid (deb sid) @endeavour (eos) as root respectively)

  • my default subvolume is the root of the btrfs file system (so my’s @xx lie under /, so /@xx (and not @/)

Emerald seems to have set its default subvolume on @ (id 256), not me… see its post 27/37 point 14…
I don’t know where this instruction comes from, it can’t be found on the archwiki concerning the layout recommendation.

I also send you the output of btrfs subvolume list / and btrfmt --real.

falke@falke-macbookair72 ~]$ sudo btrfs sub list /
[sudo] Mot de passe de falke : 
ID 260 gen 192821 top level 5 path @cache_endeavour
ID 261 gen 192847 top level 5 path @log_endeavour
ID 264 gen 191473 top level 5 path @donnees
ID 266 gen 192819 top level 5 path @sid
ID 302 gen 191388 top level 5 path @home
ID 332 gen 191545 top level 5 path @home_sid
ID 513 gen 191388 top level 5 path @
ID 633 gen 192848 top level 5 path @home_endeavour
ID 634 gen 191912 top level 5 path @.snapshots
ID 663 gen 179741 top level 5 path btrbk_snapshots/@donnees.20231124T1444
ID 746 gen 192848 top level 5 path @endeavour
ID 754 gen 185077 top level 746 path var/lib/portables
ID 755 gen 185077 top level 746 path var/lib/machines
ID 829 gen 191698 top level 5 path @cache_sid
ID 830 gen 192118 top level 5 path @log_sid
ID 834 gen 191388 top level 5 path @cache_mint
ID 835 gen 191388 top level 5 path @log_mint
ID 870 gen 189139 top level 634 path @.snapshots/73/snapshot
ID 872 gen 189181 top level 634 path @.snapshots/74/snapshot
ID 875 gen 189319 top level 634 path @.snapshots/76/snapshot
ID 885 gen 191178 top level 5 path btrbk_snapshots/@.20240106
ID 886 gen 191194 top level 634 path @.snapshots/77/snapshot
ID 887 gen 191416 top level 5 path btrbk_snapshots/@sid.20240106T1726
ID 888 gen 191456 top level 634 path @.snapshots/78/snapshot
ID 889 gen 191551 top level 5 path btrbk_snapshots/@endeavour.20240106T1827
ID 890 gen 191608 top level 634 path @.snapshots/79/snapshot


[falke@falke-macbookair72 ~]$ sudo btrfmt --real
sudo: btrfmt : commande introuvable
[falke@falke-macbookair72 ~]$ findmnt --real
TARGET     SOURCE       FSTYPE      OPTIONS
/          /dev/sda2[/@endeavour]
                        btrfs       rw,relatime,ssd,discard=async,space_cache=v2,subvolid=746,subvol=/@endeavour
├─/.snapshots
│          /dev/sda2[/@.snapshots]
│                       btrfs       rw,relatime,ssd,discard=async,space_cache=v2,subvolid=634,subvol=/@.snapshots
├─/run/user/1000/doc
│          portal       fuse.portal rw,nosuid,nodev,relatime,user_id=1000,group_id=1000
├─/run/media/falke/usb_snapshots
│          /dev/sdc1    btrfs       rw,nosuid,nodev,relatime,space_cache=v2,subvolid=5,subvol=/
├─/run/media/falke/ce91d466-2c4d-43
│          /dev/sdb1    ext4        rw,nosuid,nodev,relatime,errors=remount-ro
├─/data    /dev/sda2[/@donnees]
│                       btrfs       rw,relatime,ssd,discard=async,space_cache=v2,subvolid=264,subvol=/@donnees
├─/var/cache
│          /dev/sda2[/@cache_endeavour]
│                       btrfs       rw,relatime,ssd,discard=async,space_cache=v2,subvolid=260,subvol=/@cache_endeavour
├─/home    /dev/sda2[/@home_endeavour]
│                       btrfs       rw,relatime,ssd,discard=async,space_cache=v2,subvolid=633,subvol=/@home_endeavour
├─/var/log /dev/sda2[/@log_endeavour]
│                       btrfs       rw,relatime,ssd,discard=async,space_cache=v2,subvolid=261,subvol=/@log_endeavour
├─/mnt     /dev/sda2    btrfs       rw,relatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/
│ └─/mnt/btr_pool
│          /dev/sda2    btrfs       rw,relatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/
└─/efi     /dev/sda1    vfat        rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,e


[falke@falke-macbookair72 ~]$ cat /etc/fstab 
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>

UUID=d80981ac-56fb-4c4d-ac42-01e566f6ffc7 /              btrfs   defaults noatime, compress=zstd 0   0 
UUID=d80981ac-56fb-4c4d-ac42-01e566f6ffc7 /home          btrfs   subvol=@home_endeavour ,defaults,noatime,compress=zstd 0 0
UUID=d80981ac-56fb-4c4d-ac42-01e566f6ffc7 /var/cache     btrfs   subvol=@cache_endeavour ,defaults,noatime,compress=zstd 0 0
UUID=d80981ac-56fb-4c4d-ac42-01e566f6ffc7 /var/log       btrfs   subvol=@log_endeavour ,defaults,noatime,compress=zstd 0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
tmpfs		 /home/falke/.cache/yay			 tmpfs	uid=1000,gid=1000,mode=750 0 0


# config propre au triple boot

UUID=d80981ac-56fb-4c4d-ac42-01e566f6ffc7 /data           btrfs   defaults,subvol=@donnees   0       0 # ancien donnees
UUID=d80981ac-56fb-4c4d-ac42-01e566f6ffc7 /.snapshots     btrfs   defaults,subvol=@.snapshots 0       0 # snapshots snapper

UUID=d80981ac-56fb-4c4d-ac42-01e566f6ffc7 /mnt            btrfs   defaults                   0       0

# /boot/efi was on /dev/sda1 during installation
UUID=C80D-E885	                	  /efi       vfat    umask=0077                 0       1

/dev/sda2  /mnt/btr_pool  btrfs  subvolid=5    0 0   # repertoire de base pour snapshots btrbk

contents of the configuration file btrfs-assistant.conf as I imagine it :

# The location of the snapper command
snapper = /usr/bin/snapper

# The path to the btrfsmaintenance configuration file
bm_config = /etc/default/btrfsmaintenance

# The absolute path of the script to run for btrfs maintenance to reload the config file
bm_refresh_script = "/usr/share/btrfsmaintenance/btrfsmaintenance-refresh-cron.sh"

# In this section you can manually specify the mapping between a subvol and it's snapshot directory.
# This should only be needed if you aren't using the default nested subvols used by snapper.
#
# The format is <name> = "<snashot subvol>,<source subvol>,<UUID>"
# All should be paths relative the root of the btrfs volume and the UUID is the UUID of the filesystem
# For example, a line might look like this:
# root = "@snapshots,@,48bee883-0eef-4332-9bc5-65f01295e470"
[Subvol-Mapping]

root = "@.snapshots,@endeavour,d80981ac-56fb-4c4d-ac42-01e566f6ffc7"

question , my configuration’s name in snapper is snapshot_root_endeavour.

Edit :

falke@falke-macbookair72 etc]$ sudo btrfs subvolume get-default /
[sudo] Mot de passe de falke : 
ID 5 (FS_TREE)

in my case the default sub-volume is 5

I think that’s all,

nb I want to restore from with my real configuration not from a booted snapshot, I don’t use boot from snapshots utility…

thanks in advance…

6

Did you create any Snapper configs? Mine only shows subvolumes I have configured a Snapper config for. The configs should be in /etc/snapper/configs/, and /etc/conf.d/snapper should have a SNAPPER_CONFIGS= line which lists out the configs in use.

If you are not using Snapper’s default subvolume layout, setting up the config is a little tricky. See the note in this section of the ArchWiki article: https://wiki.archlinux.org/title/snapper#Creating_a_new_configuration:

Note: If you are using the suggested Btrfs partition layout from archinstall then the @.snapshots subvolume will already be mounted to /.snapshots, and the snapper create-config command will fail [1]. To use the @.snapshots subvolume for Snapper backups, do the following:

  • Unmount the @.snapshots subvolume and delete the existing mountpoint.
  • Create the Snapper config.
  • Delete the subvolume created by Snapper.
  • Re-create the /.snapshots mount point and re-mount the @.snapshots subvolume.

I am pretty sure this is unrelated, and maybe not important, but:

The subvol= mount option to specify this in fstab seems to have been left off somehow:

It appears to be mounting the correct subvolume anyway, so maybe it doesn’t matter.

7

A few things:

  • It doesn’t matter what your default subvol is. Btrfs Assistant ignores that.
  • Your /etc/fstab is incorrect for your root filesystem, you are missing the subvol option. It is probably only working because the kernel cmdline is correct
  • You shouldn’t use a dedicated @.snapshots in a triple boot scenario anyway. That will be totally broken if you share that across installs. It makes much more sense to use nested subvolumes in that case. This is the default with snapper.
  • Is your snapper root config for endeavouros named root? If not you need to change the name in the btrfs-assistant config to match the name of the snapper config.
8

hi @dalto @BluishHumility , I all

apparently it was a question of the default sub-volume,

by setting the subvolume corresponding to the root of my system (@endeaour) as the default subvolume rather than the root of the btrfs / (volid-5) file system, I see the configuration in the list and the snapshots to restore them.

I haven’t tried to restore though. Well, I don’t really understand this default sub-volume thing and its implications.

Any idea ?

9

If that really fixed it something in your setup is very broken. That shouldn’t matter at all.

The default subvolume is what gets mounted when you mount the btrfs partition without specifying a subvolume.

10

i dont think so, for example when I restored (before I changed de defaut subvol id) any of the root sub-volumes corresponding to one of the distros, I find what it contained in its previous version.

my fstab does not contain references to subvolume ids, but their respective names @ , @sid, @endeavour,

but I can’t rule out the possibility that restoring a subvolume after changing the default subvolume id won’t mess things up.

11

In this case, changing the default subvol shouldn’t impact your system. If it does, something is not right somewhere.

Btrfs Assistant never uses the default subvol. It always mounts subvolid 5 to ensure it has the root of the partition. It needs to support the default subvol being set to different things for different setups.

12

I hear your argument, but you did see the output of the orders, which are completely normal… so mystery indeed.

what does your layout look like?

on my system, it’s very similar to the one suggested by the snapper wiki page for implementation on a system other than SusE, i.e.

subvolid 5 /

  • subvolid top level 5
  • subvolid top level 5
    … etc
13

I have tested with many different layouts. Flat, nested, a mix of both. A single partition, multiple partitions in a single filesystem.

I will say that using a flat subvolume for /.snapper like you are doing will make everything more difficult. It is much, much easier to use nested subvolumes as snapper does by default.

Further, if you are multibooting different distros in a single btrfs partition then you must not share a flat subvolume for /.snapper between distros. That will result in unpredictable behavior.

In general, the reason for creating a flat subvolume for that makes no sense when you are multi-booting like that. You just shouldn’t do it.

This one of those cases where you shouldn’t be blindly copying the layout in the wiki but understanding why it is suggesting that and deciding if it applies to your situation.

1 Like
14

hi, thanks for testing different configurations for me :slight_smile:

I used the flat layout because I realized that it would allow me to easily restore a sub-volume because all the sub-volumes beeing under subvolid=5, all without using live-cd.

now my system is indeed strange:
even if, for example, I mount subvolumes by id, no account is taken of the change after reboot…
Even better, if I put the id of the @(mint) root sub-volume in the endevour fstab for the root, it’s ignored :-)…

I really wonder where the configuration to the right path is (maybe in the initramdisk). All right, it’s a crazy story. It’s annoying me not to understand anything.

I don’t like wobbly configurations… I’m going to have to understand the problem in depth and in English.

15

Hehe…I maybe I should be more clear. I didn’t test them for you specifically. I tested them while I was writing Btrfs Assistant because I wanted it to be able handle any combinations of layouts.

Using a flat subvolume layout is fine. Creating a flat subvolume for /.snapper is the only challenge. You don’t need that…really…trust me. If you deleted that and recreated your root snapper configs, I would bet everything would “just work”.

A few comments on this:

  • Never mount subvolumes by ID in fstab. That will break restores because the id changes in that scenario. Always mount them by name with subvol=
  • The root subvolume isn’t actually mounted via fstab in most distros. It is mounted via the options on the kernel command line. It often gets remounted from fstab but that usually doesn’t change the subvolume.
  • You need to rebuild the initrd after making changes to fstab
16

@dalto,

I was well aware of it. it was to confirm that I could blow it all up while doing :-),

I had kept a good old clone of my entire disk aside ;-), and fortunately the initrd avoided this scenario.

17

Hello,

I’m editing this ticket to make an important clarification for those who may have found themselves in the same boat trying to get btrfs-assistant to work.

i can now get it to work without any problem, and @dalto (the dev :wink: ) was absolutely right…

manips suggested here :

https://wiki.archlinux.org/title/snapper#Configuration_of_snapper_and_mount_point (point 5.3.1)

have the worst effect on the operation of btrfs-assistant and yes, you have to keep the default snapper layout…

My worries were due to a lack of understanding of the logic behind Btrfs, to which was added an amalgam between .snapshots designating sometimes a directory and sometimes a sub-volume in the Arch wiki, not being able to clearly distinguish one from the other (personally, I always name my sub-volumes @something…), so I was convinced that my configuration was functional.

Thus don’t follow any receipt until you understand btrfs enough :wink:

another question arose in Emeralenigma’s post here :

if I restore the snapshot of the root by exple: /@ , will the snapshots /@/.snapshot/xx/snapshots in the subtree of /@ disappear? (originally the idea of placing the .snapshot subvolume outside the /@ subvolume caused all these debits)

according to my tests, the answer is no, you won’t lose them. @dalto seems to have studied the question very well.