Bareos refuses to backup container subvolumes

[Jan Hebler]

Hi

Bareos does it's job very well, except that it not want to backup my container subvolumes, which are btrfs-subvolumes as well:

....
02-Dec 06:22 blaster-fd JobId 153: Disallowed filesystem. Will not descend from / into /srv/gitlab/.local/share/containers/storage/btrfs/subvolumes/253efabb1b8f1d77d6e481a36fbd429c0a077583740fa548dca112d9516670ee
....

The stats of the parent directory:

blaster:/etc/bareos # stat /srv/gitlab/.local/share/containers/storage/btrfs/subvolumes
File: /srv/gitlab/.local/share/containers/storage/btrfs/subvolumes
Size: 1152 Blocks: 0 IO Block: 4096 directory
Device: 0,278 Inode: 302 Links: 1
Access: (0700/drwx------) Uid: ( 485/ gitlab) Gid: ( 470/ gitlab)

The stats of the entry:

File: /srv/gitlab/.local/share/containers/storage/btrfs/subvolumes/253efabb1b8f1d77d6e481a36fbd429c0a077583740fa548dca112d9516670ee
Size: 154 Blocks: 0 IO Block: 4096 directory
Device: 0,280 Inode: 256 Links: 1
Access: (0555/dr-xr-xr-x) Uid: ( 485/ gitlab) Gid: ( 470/ gitlab)

btrfs-info:
blaster:/etc/bareos # btrfs subvolume show /srv/gitlab/.local/share/containers/storage/btrfs/subvolumes/253efabb1b8f1d77d6e481a36fbd429c0a077583740fa548dca112d9516670ee
.local/share/containers/storage/btrfs/subvolumes/253efabb1b8f1d77d6e481a36fbd429c0a077583740fa548dca112d9516670ee
Name: 253efabb1b8f1d77d6e481a36fbd429c0a077583740fa548dca112d9516670ee
UUID: bf8a44fb-f7d5-5447-9f79-100512e68408
Parent UUID: 03f24745-8420-6945-bb31-b0ff20375173
Received UUID: -
Creation time: 2023-10-15 11:25:16 +0200
Subvolume ID: 257
Generation: 33
Gen at creation: 32
Parent ID: 5
Top level ID: 5
Flags: -
Send transid: 0
Send time: 2023-10-15 11:25:16 +0200
Receive transid: 0
Receive time: -
Snapshot(s):
.local/share/containers/storage/btrfs/subvolumes/86d9eaee6681085d31997c5d96883fbba46d136066a63330c5e749bef070c150
blaster:/etc/bareos #



The Fileset for this is:

FileSet {
Name = "LinuxAll"
Description = "Backup all regular filesystems, determined by filesystem type."
Include {
Options {
Signature = MD5 # calculate md5 checksum per file
One FS = No # change into other filessytems
FS Type = btrfs
FS Type = ext2 # filesystems of given types will be backed up
FS Type = ext3 # others will be ignored
FS Type = ext4
FS Type = reiserfs
FS Type = jfs
FS Type = vfat # UEFI
FS Type = xfs
FS Type = zfs
wilddir = /shared/media/video/2*
}
File = /
}
# Things that usually have to be excluded
# You have to exclude /var/lib/bareos/storage
# on your bareos server
Exclude {
File = /var/lib/bareos
File = /var/lib/bareos/storage
File = /proc
File = /tmp
File = /var/tmp
File = /shared/media/video/other
File = /shared/media/video/receiver
File = /shared/media/video/music
File = /.journal
File = /.fsck
File = /.snapshots
}
}

Regards, Jan

[Philipp Storz]

Hello,

Am 02.12.23 um 07:13 schrieb Jan Hebler:

> Hi
>
> Bareos does it's job very well, except that it not want to backup my container subvolumes, which are btrfs-subvolumes as well:
>
> ....
> 02-Dec 06:22 blaster-fd JobId 153: Disallowed filesystem. Will not descend from / into /srv/gitlab/.local/share/containers/storage/btrfs/subvolumes/253efabb1b8f1d77d6e481a36fbd429c0a077583740fa548dca112d9516670ee

The subvolume seems to be of a different type than what you have specified in your fileset.

Probably it makes sense to set the debug level to 200 and enable tracing in the filedaemon.

-> setdebug trace=1 level=200 client=<your-client-fd>

That should tell you the exact reason in the trace file.

see: https://github.com/bareos/bareos/blob/master/core/src/findlib/find_one.cc#L111-L121

--
Mit freundlichen Grüßen

Philipp Storz philip...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221 63 06 93-92
http://www.bareos.com Fax: +49 221 63 06 93-10

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Geschäftsführer: Stephan Dühr, J. Steffens, P. Storz

[Jan Hebler]

Hi

Am Samstag, 2. Dezember 2023, 12:20:29 CET schrieb Philipp Storz:
> Hello,
>
> Am 02.12.23 um 07:13 schrieb Jan Hebler:
> > Hi
> >
> > Bareos does it's job very well, except that it not want to backup my
> > container subvolumes, which are btrfs-subvolumes as well:
> >
> > ....
> > 02-Dec 06:22 blaster-fd JobId 153: Disallowed filesystem. Will not
> > descend from / into
> > /srv/gitlab/.local/share/containers/storage/btrfs/subvolumes/253efabb1b8f
> > 1d77d6e481a36fbd429c0a077583740fa548dca112d9516670ee
> The subvolume seems to be of a different type than what you have specified
> in your fileset.
>
> Probably it makes sense to set the debug level to 200 and enable tracing in
> the filedaemon.
>
> -> setdebug trace=1 level=200 client=<your-client-fd>
>
> That should tell you the exact reason in the trace file.
>
> see:
> https://github.com/bareos/bareos/blob/master/core/src/findlib/find_one.cc#L
> 111-L121
> > ....
> >

I think this points me in the correct direction. According to https://btrfs.readthedocs.io/en/latest/Subvolumes.html, btrfs subvolumes can, but does not need to be mounted
like a "normal" Filesystem, but have their own dev-id anyway. This seems to confuse bareos, as (at least this is my understanding of
https://github.com/bareos/bareos/blob/6f35a0436dd9e9428f100f28ea931fb37c2f3199/core/src/lib/mntent_cache.cc#L227-L237) bareos reads /proc/mounts into an cache
and search for an entry for the device id afterwards. As the subvolumes is not explicit mounted, this fails.

Regards, Jan

[Bruno Friedmann (bruno-at-bareos)]

With container, you may need to add the overlay as fs type in your fileset 

```

overlay on / type overlay (rw,relatime,context="system_u:object_r:container_file_t:s0:...

```