Announcement

**oshunluvr** · Oct 31, 2022, 11:47 AM

You did it wrong or you have to change the way you mount home. Based on your description, you copied the FILES in /home instead of the /home subvolume, so you no longer have to ability to snapshot and backup your home using btrfs functions or use timeshift or snapper. You must use a subvolume to use the snapshot features of BTRFS.

Here's what you should have done:

Turn off timeshift/snapper.
Create a BTRFS file system on /dev/nvme0n1p1 (which you did, I believe).
Mount /dev/nvme0n1p3 somewhere
Mount /dev/nvme0n1p1 somewhere
Make a read-only snapshot of @home
Use the BTRFS function to SEND|RECEIVE @home from /dev/nvme0n1p3/@home to /dev/nvme0n1p1/@home
Change the read-only status of /dev/nvme0n1p1/@home to read-write.
Edit /etc/fstab so that /home mount points to /dev/nvme0n1p1/@home
Log out and back in.
Assuming all went correctly, mount /dev/nvme0n1p3/ and delete the old @home subvolume.
Clean up (delete) all the old @home timeshift and snapper shapshots
Re-configure timeshift/snapper to use your new /home location.

Command example using /part3 and /part1 as mount points:

Code:

sudo -i
mkdir /part3 /part1
mount /dev/nvme0n1p1 /part1
mount /dev/nvme0n1p3 /part3
btrfs su sn -r /part3/@home /part3/@home-ro
btrfs send /part3/@home-ro | btrfs receive /part1/
btrfs su sn /part3/@home-ro /part3/@home
btrfs su de -c /part3/@home-ro

Then edit /etc/fstab and change this:

Code:

UUID=f6e56409-da8e-43b1-b238-d041419bbce4 /home  btrfs subvol=home,compress=zstd:1,ssd,noatime,space_cache=v2,discard=async 0 0

to this:

Code:

UUID=54678ba4-0944-45a9-8027-497aee5cfba4 /home  btrfs subvol=home,compress=zstd:1,ssd,noatime,space_cache=v2,discard=async 0 0

Then step 9 above and continue. That should do it.

I can't help you with timeshift or snapper because I don't use either. They have a tendency - as you've discovered - to fill your drive space without warning.

**sunnyod** · Oct 31, 2022, 01:19 PM

Yeah i think you probably nailed it, I missed the steps 3-8! Thanks, I'll have another go and let you know how I get on.

Super Star, thanks!
S

**jlittle** · Oct 31, 2022, 01:29 PM

As a snapper user, I'll add that often after moving or renaming snapper-managed subvolumes, I've had to recreate the .snapshots subvolume in them, for snapper to start working on them.

When snapper has been not working, or has been hitting the space limit, nothing has told me about it. I've learned to check things out (snapper-gui is a quick way) after moving or renaming subvolumes, or release upgrades.

On my desktop I'm trying the Arch recommendation for snapper, which is to use a subvolume at the top level (say, @home_snapshots) symlinking /home/.snapshots to it. Snapper has not objected. For the symlink to work, the btrfs top level has to be mounted in /etc/fstab.

**sunnyod** · Nov 01, 2022, 02:47 AM

Originally posted by jlittle View Post

As a snapper user, I'll add that often after moving or renaming snapper-managed subvolumes, I've had to recreate the .snapshots subvolume in them, for snapper to start working on them.

When snapper has been not working, or has been hitting the space limit, nothing has told me about it. I've learned to check things out (snapper-gui is a quick way) after moving or renaming subvolumes, or release upgrades.

On my desktop I'm trying the Arch recommendation for snapper, which is to use a subvolume at the top level (say, @home_snapshots) symlinking /home/.snapshots to it. Snapper has not objected. For the symlink to work, the btrfs top level has to be mounted in /etc/fstab.

Thanks, John. Thats super useful. I'm using BTRFS-Assistant to do my snapper backups. I'll make sure to set that up too

**oshunluvr** · Nov 01, 2022, 05:54 AM

Just for kicks, I'll give myself a plug. I don't like adding yet another application where something I am familiar with can do the job, so I wrote this service menu for Dolphin quite awhile ago:

https://store.kde.org/p/1214134

It provides manual management of BTRFS subvolumes using Dolphin.

**sunnyod** · Nov 01, 2022, 08:16 AM

Originally posted by jlittle View Post

As a snapper user, I'll add that often after moving or renaming snapper-managed subvolumes, I've had to recreate the .snapshots subvolume in them, for snapper to start working on them.

When snapper has been not working, or has been hitting the space limit, nothing has told me about it. I've learned to check things out (snapper-gui is a quick way) after moving or renaming subvolumes, or release upgrades.

On my desktop I'm trying the Arch recommendation for snapper, which is to use a subvolume at the top level (say, @home_snapshots) symlinking /home/.snapshots to it. Snapper has not objected. For the symlink to work, the btrfs top level has to be mounted in /etc/fstab.

I’ve gotten to the snapper setup stage now. Just wondering what would be the advantage of setting up the root level @home_snapshot subvolume with symlink? Does that stop snapper from filling up the filesystem?

**sunnyod** · Nov 01, 2022, 08:18 AM

Originally posted by oshunluvr View Post

Just for kicks, I'll give myself a plug. I don't like adding yet another application where something I am familiar with can do the job, so I wrote this service menu for Dolphin quite awhile ago:

https://store.kde.org/p/1214134

It provides manual management of BTRFS subvolumes using Dolphin.

Nice! I’ll take a look

Btw, your work earlier was excellent. Everything is working beautifully now! Thanks

**oshunluvr** · Nov 01, 2022, 10:46 AM

Great, glad it worked for you.

I''ll go ahead and mark the thread solved for you. You can do that yourself next time by editing your initial post in the thread and changing the Prefix to [Solved].

BTW, welcome to the forum.

**jlittle** · Nov 01, 2022, 02:02 PM

Originally posted by sunnyod View Post

Just wondering what would be the advantage of setting up the root level @home_snapshot subvolume with symlink?

A typical use case is one wants to revert to an older snapshot of the Linux root. Let's say that's called @, and there's a snapshot in /.snapshots/3294/snapshot. A quick way to do this is

If it's not already mounted, mount somewhere the btrfs root (aka subvolid=5, subvol=/, FS_TREE). Let's say that's /mnt/top.
Change directory to /mnt/top and rename @ to @old with mv.
Snapshot /.snapshots/3294/snapshot to @ (to get a non read only @).
Reboot.

This leaves behind the /.snapshots in @old, and snapper doesn't run on root after the reboot. I suppose one can move .snapshots from /mnt/top/@old/ to /, but there's limitations on doing that, I think one has to be booted from somewhere else so that nothing is open. So one has to rmdir /.snapshots, and recreate it as a subvolume, and either remember to later manually clean up the snapshots from @old/.snapshots, or snapshot them from @old/.snapshots to /.snapshots. If the revert has gone well, and @old is to be discarded, all of the subvolumes nested in it have to be moved or deleted before @old can be deleted.

But with the arch set up, the snapshots stay in @snapshots, and all the symlinks to it are all fine, nothing to do. That's the theory; I haven't yet done this in the heat of necessity.

Originally posted by sunnyod View Post

Does that stop snapper from filling up the filesystem?

No. Setting SPACE_LIMIT in the snapper config is intended to stop that.

Announcement

Upgrading btrfs @home mount with dedicated drive

[SOLVED] Upgrading btrfs @home mount with dedicated drive

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment