Snapper questions about home configs (Post-restore)

Support Software & Applications
, ,
1

I have been using Snapper within my main VM I use for work for some time now. (It gets a dedicated GPU and SSD, so it runs like native.) With a hard drive failure and needing to restore quick, I manually restored the snapshots to @ and @home from another btrfs file system over the network.

I normally have a more streamlined method for other hosts (using Timeshift, or other snapshotting means), but Snapper was in limbo until I mastered it. And I just rebuilt the host way I knew starting with the partitions with fdisk. (A process that has worked countless times with btrfs.)

It all works great! Except for home snapshots..

The one time I messed with my /home config, and I lost all snapshots along with them. And this alone makes me leery to move Snapper to my host system.

So I would like to fix my home snapshots, without destroying the root config and snapshots. (Just for the future, if possible.)

So this is what I have so far..

/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=5BEB-20F3 /boot/efi vfat umask=0077 0 2
UUID=751920f1-5f97-449d-8dd2-10187991b13b / btrfs subvol=/@,defaults 0 0
UUID=751920f1-5f97-449d-8dd2-10187991b13b /home btrfs subvol=/@home,defaults 0 0
UUID=751920f1-5f97-449d-8dd2-10187991b13b /var/cache btrfs subvol=/@cache,defaults 0 0
UUID=751920f1-5f97-449d-8dd2-10187991b13b /var/log btrfs subvol=/@log,defaults 0 0
UUID=751920f1-5f97-449d-8dd2-10187991b13b /.snapshots btrfs subvol=/@snapshots,defaults 0 0
UUID=a9ddc99c-63fa-454f-9692-a5d3bb0e961a swap swap defaults,noatime 0 0
lsblk -f 
AME   FSTYPE  FSVER            LABEL             UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
vda                                                                                                   
├─vda1 vfat    FAT32                              5BEB-20F3                             299.1M     0% /boot/efi
├─vda2 btrfs                                      751920f1-5f97-449d-8dd2-10187991b13b  198.6G    18% /mnt
│                                                                                                     /home
│                                                                                                     /.snapshots
│                                                                                                     /var/cache
│                                                                                                     /var/log
│                                                                                                     /
└─vda3 swap    1                swap              a9ddc99c-63fa-454f-9692-a5d3bb0e961a                [SWAP]
btrfs subvolume list

You can see the root snapshots already working fine.

ID 260 gen 231 top level 5 path @log
ID 261 gen 92 top level 5 path @cache
ID 262 gen 282 top level 5 path @
ID 263 gen 282 top level 5 path @home
ID 264 gen 230 top level 5 path @snapshots
ID 265 gen 82 top level 264 path @snapshots/1/snapshot
ID 266 gen 86 top level 264 path @snapshots/2/snapshot
ID 267 gen 116 top level 264 path @snapshots/3/snapshot
ID 270 gen 229 top level 264 path @snapshots/5/snapshot
ID 271 gen 230 top level 264 path @snapshots/6/snapshot

Everything about the restore from the snapshots is fine, except for:

sudo snapper -c home create -p -d Test
IO Error (.snapshots is not a btrfs subvolume).

I know they were in /home/.snapshots, which of course came over with the restore (as a folder).

I have been going through the Arch Snapper wiki, among other sources, trying to remember what the blank I did there.

I did not want to do this, but just to get home snapshots working again, I tried:

sudo snapper -c home create-config /home
Creating config failed (subvolume already covered).

sudo snapper -c home delete-config
Deleting config failed (deleting snapshot failed).

Edit: Cleaned up garbage

2

I have very little experience with btrfs - none with snapper - but the error message

seem to indicate that your /home is already included in another snapshot configuration.

Thus is appears to as you will have to modify the other configuration to exclude /home only then you can configure a snapshot for it.

3

I’m not sure where your mistake lies, but I’ll describe how Snapper intends to work (and in some parts, it’s completely different from how Timeshift does it):

Timeshift (rw) <-> Snapper (ro)

Snapper creates snapshots and wants them to be visible (in the file system). Since they are always read-only, this is safe and allows you to easily view or copy a few files from an older version.

Timeshift makes its snapshots writable (to make them easier to boot). Therefore, they are not mounted but must be hidden. The risk of someone accidentally making changes to them is simply too high.

For snapper you need an additional subvolume(B) for each subvolume(A) from which snapshots are taken(A), where the snapshots are stored(B).

Example (note that this deviates from the default, but it might be a good thing):

My snapshots from subvolume @ (A) end up in subvolume @snapshots (B) (shown with sudo btrfs subvolume show /)

	Name: 			@
	UUID: 			be4c2f1e-6928 ... 
...
	Parent ID: 		5
	Top level ID: 		5
...
	Snapshot(s):
				@snapshots/40620/snapshot
...

My snapshots from subvolume @home (A) end up in subvolume @home.snapshots (B) (shown with sudo btrfs subvolume show /home)

@home
	Name: 			@home
	UUID: 			8c86e0e6-b40e ...
...
	Parent ID: 		5
	Top level ID: 		5
...	Snapshot(s):
				@home.snapshots/29167/snapshot
...

The names of these two subvolumes (A), (B) are arbitrary!

It only needs to be ensured that the two subvolumes appear together in the file system (via mount or automount) so that Snapper can find them.

Snapper always looks for the subvolume containing the snapshots in the file path of the mounted subvolume / (A) with the name appended by .snapshots/ (B) , i.e., /home/.snapshots.

Mount points (A → B):

  • / → /.snapshots/
  • /home/ → /home/.snapshots/
  • /something/ → /something/.snapshots/
  • /opt/something/ → /opt/something/.snapshots/

The names of the subvolumes and their btrfs layout are irrelevant.

What matters is the location of the mount points. That’s what Snapper looks for. And of course, both related subvolumes must reside on the same btrfs volume. :footprints:

How the mount is done:

One option is to explicitly mention each of these subvolumes in the fstab file so they are mounted accordingly. That’s how I did it because I use a flat layout. This way, I understand better what btrfs is doing.

UUID=3487ba3d-..	/			btrfs	rw,noatime,space_cache=v2,compress=zstd:9,subvol=@			0 0
UUID=3487ba3d-..	/.snapshots		btrfs	rw,noatime,space_cache=v2,compress=zstd:9,subvol=@snapshots		0 0
UUID=3487ba3d-..	/home			btrfs	rw,noatime,space_cache=v2,compress=zstd:9,subvol=@home		0 0
UUID=3487ba3d-..	/home/.snapshots	btrfs	rw,noatime,space_cache=v2,compress=zstd:9,subvol=@home.snapshots	0 0
UUID=3487ba3d-..	/var/nosnap		btrfs	rw,noatime,space_cache=v2,compress=zstd:9,subvol=@nosnap		0 0
UUID=3487ba3d-..	/var/nosnap/.snapshots	btrfs	rw,noatime,space_cache=v2,compress=zstd:9,subvol=@nosnap.snapshots	0 0

Alternatively, a nested layout can be used. Then the nested subvolumes are automatically mounted with the subvolume above them. This is elegant, but in my opinion, not very clear.

Therefore, there are different opinions about which layout type (nested, flat, etc.) is best. You can find more information in the btrfs documentation.

1 Like
5

Timeshift isn’t even a part of this in no shape or form. (Ever since I could boot a Solaris root ZFS snapshot 25+ yrs ago, I could never look back. It took a loooong time for Linux to catch up in many repects.)

I thought there was a trick I was missing (to hack a flat layout from SuSE’s). When laying out the new btrfs file system, I almost did a: btrfs sub create @snapshots-home, but I thought I remembered it couldn’t have a different volume name from @snapshots.

That’s all I needed. Simple.

Wait what?

!!?

1 Like
6

The medium compression (over all files) on my hard drive is better than 2:1, even though I have a lot of already compressed images on it. This compensates for the fact that I’m using Btrfs RAID with two SSDs.
:footprints:

7

It’s been a while since I benchmarked btrfs zstd. But it followed the same logarithmic curve as others; compression level 9 being extremely too high for real time compression. Which in turn creates massive performance bottlenecks for me even at default levels (on fast SSDs).

But that is another topic I would be happy to discuss! (Branch this? :smiley: )

Who knows, maybe my tests from a few years ago weren’t even accurate.

8

I just want to express my gratitude for the insights into the black magic of BTRFS that andreas85 continues to deliver. I think I’ve learned more from his posts and comments than from any other source.

2 Likes
9

I :100: agree.

I knew nothing about btrfs a few years ago, besides reading about it from articles (from Phoronix and the like). And I just decided to try it, because the option just magically appeared in the Manjaro Calamares installer. I knew it wasn’t there before even just weeks before! (I saw nothing about it in the forums, or maybe just missed it.)

I learned much of it from here, and @andreas85 has definitely been the majority of it.

And I love learning new things about it!

Hence me wanting to branch this, as it’s off topic..

3 Likes
10

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.