Backing up nested Btrfs sub volumes

Hi everyone,

I’m running UrBackup in a docker container and running a UrBackup client on directly on the ubuntu host.
The file system for the ubuntu host is BTRFS.
I have a series of nested sub volumes e.g.

  • / #one subvolume
  • /home #another sub volume
  • /usr/local #another subvolume

When installing the linux client, I picked the BTRFS snapshot option.

I am finding that I am unable to backup any of the nested sub volumes. If I choose the top backup directory to be ‘/’ then all of the directories where the nested volumes start are empty. If I chose one of the nested sub volumes as the top backup directory then the resulting backup is empty.

Should I be able to backup nested BTRFS sub volumes when using the BTRFS snapshot mechanism with UrBackup?

Cheers!

I did manage to get this to work by manually mounting the Subvolumes. So, in fstab, I have something like

/dev/disk/by-uuid/9089df6a-b631-4121-9d48-5be65f41f642 / btrfs defaults,ssd,noatime,space_cache,commit=120,compress=zstd,subvol=@ 0 1
/dev/disk/by-uuid/9089df6a-b631-4121-9d48-5be65f41f642 /mnt/systemsubvols/home btrfs defaults,ssd,noatime,space_cache,commit=120,compress=zstd,subvol=@/home 0 1

Pointing UrBackup to --both-- paths as separate backup paths backs up both root and the home subvol.

I guess this needs to be handled in

and btrfs_remove_filesystem_snapshot. Changes for that would be welcome!

Just as a hint ;-):
That still isn’t working properly. I’ve just run into the same problem. When trying to backup a synology.
@uroni
Any chance that could be fixed?

What is it that is not working?

You are asking for urbackup to cross filesystem boundries without questioon so to say. Not sure that would be good to do.

Example:
You have / on btrfs, with subvolume /home and maybe even a few virtual mounts on your system.
You also use snapper to make restorepoints, those are on the same device as / but not mounted.
These will be listed with btrfs subvolume list / but not actually mounted. Should these be included automatically as well?
What if /home is on a different device, and maybe even not in btrfs, should they be included?
What about /mnt and /media?
What about virtual mounts like /tmp /var/run or /var/cache?
Where is the limit to where it should stop or should / include every single byte even on other devices mounted AND non mounted filesystems?

I think it SHOULD pretty much be expected of you to define each filesystem (in this case subvolume) in the backup locations.

backuping nested btrfs volumes.
if
/volume1
/volume1/homes
/volume1/Scanner

are all diferent subvolumes, there is no way to backup /volume1/homes and /volume1/Scanner, as the topic opener explained…
If I want to make a backup of /volume1 without the parameter -x (fs boundaries), I except that everything below /volume1 will be backuped.
But right not it’s not even possible to backup /volume1/homes directly.

Why?
Do you get an error if you include the path to /home specifically?

Again, do you also want to include everything in /var/tmp?
How about your swap, include that every time?
Cache files?

Maybe you do not fully understand?
Btrfs is not a “normal” fileystem so to say, it looks like it when you are interfacing with it in cli, file manager etc, but under the hood it acts very different to f.ex ext4.

Read the post above with a solution:

That they have to mounted I take for granted ppl understand, you backup the FILESYSTEM, not the device.

As the top poster mentioned. They are just empty.
The only easy way to backup them, is not to use a snapshot mechanism. With snapshots the nested subvolumes will not be backuped.

Nobody was talking about backuping a device, that would be an image backup.

It’s quite simple. If you tell him, to backup a certain path, and don’t tell him to stay only inside of the same filesystem (-x parameter, and up to a certain extend -f) you expect the path including all subdirectories to be completely backuped. Done.

If you mount one subvol @ /home and you have added that to the include path in urbackup then it’s a bug and you need to provide logs. But I don’t think so, I do exactly this on one of my clients and it works flawlessly.

Sure, you can just remove the btrfs snapshot mechanism from the client and rely on normal filecopy, that is one solution, but it would not be a good one imo.

No ofc not, they are subvolumes, you have to specify each volume to backup, like I have stated multiple times. Look at the script that was linked to in the thread, it gives you hints.

On a “normal” filesystem, yes. Btrfs does not work that way (unless you want to clone the entire device, that is why I keep asking you about virtual mounts etc).

The answer how to solve it is provided in the thread (I even quoted it above). You just have to understand it.