SOLVED: File backup of subvolume of btrfs filesystem does not work (no error message but empty backup)

client
1

Hello,
first of all, Urbackup is awesome! It works well and is fast! Nevertheless I have an issue in a small setup.

Server A
OS: Openmediavault 4 (Debian 9)
UrBackup server: via Openmediavault UrBackup Plugin (UrBackup 2.3.7)

Server B (alias UrBackup client A aka OMV-DESS)
OS: Openmediavault 4 (Debian 9)
UrBackup client: installed manually like described here (urbackup-client-2.3.4.0)
Backup type: file backup only
Backup method: BTRFS snapshot (I was asked during installation of urbackup client)
Backup Path: BTRFS Filesystem =/srv/dev-disk-by-label-SSD1TB/DATEN
Status: UrBackup says that the backup was successful, but not data was backed up.
grafik
Logs: Please find /var/log/urbackupclient.log with DEBUG enabled urbackupclient.log (16.9 KB)
BTRFS filesystem: /srv/dev-disk-by-label-SSD1TB/
BTRFS subvolume: /srv/dev-disk-by-label-SSD1TB/DATEN

Server C (alias UrBackup client B)
OS: Windows Server 2016
UrBackup client: installed (UrBackup urbackup-client-2.3.4.0)
Backup Path: NTFS Filesystem D:\files
Status: File Backup works on daily basis for weeks, no issues

What did I already try?

  1. Backup of other path
  • I removed the backup path /srv/dev-disk-by-label-SSD1TB/DATEN
  • did add a path which resides on a ext4 volume
  • and it got backed up (only an error message that snapshot was not possible on ext4 filesystem)
  1. extended log level to DEBUG
  • log file got bigger
  • no more insights for me
  1. modified btrfs_create_filesystem_snapshot to create snapshot in visible folder
  • therefor I modified /usr/local/share/urbackup/btrfs_create_filesystem_snapshot
  • removed the dot from line mkdir -p “$SNAP_MOUNTPOINT/.urbackup_snaps”
  • removed the dot from line SNAP_DEST="$SNAP_MOUNTPOINT/.urbackup_snaps/$SNAP_ID"
  • this worked, the folder is available
  • but didn’t helped me with the issue

Any ideas?
Help is much appreciated

2

Thanks for the detailed error description, log file etc.

What I think is going on is that the client corrects /srv/dev-disk-by-label-SSD1TB/DATEN to /srv/dev-disk-by-label-SSD1TB (via https://github.com/uroni/urbackup_backend/blob/dev/urbackupclient/client.cpp#L352 ), because it thinks it needs to create a snapshot of the file system. So this needs some special handling for btrfs, I guess (test if each folder up to the mount point is a subvolume or something).

To work around, either:

  • Mount the btrfs subvolume directly, such that it appears in /proc/mounts
  • Or work-around manually in the snapshot script
  • Or add volumes_mounted_locally=0 to the snapshot.cfg (then it won’t correct the backup path to the mount path)
3

Hello and thank you for your answer.

I did try two of your ideas:

I started with the idea 3: add volumes_mounted_locally=0 to the snapshot.cfg
…as I thought it would be the easiest way…
I then triggered a full file backup, but it didn’t use snapshot mechanism. Nevertheless it managed to backup all files.

|Errors|05.03.19 19:03|Creating snapshot of "/srv/dev-disk-by-label-SSD1TB/DATEN" failed|
|Errors|05.03.19 19:03|Cannot create snapshot of file system with type ext4|
|Errors|05.03.19 19:03|Creating snapshot of "DATEN" failed.|
|Info|05.03.19 19:03|Indexing of "DATEN" done. 4184 filesystem lookups 0 db lookups and 0 db updates|

and the backup runs without snapshot method.

Then I tried idea 1: Mount the btrfs subvolume directly, such that it appears in /proc/mounts
This was really challenging. After trying, I ran into different error messages
e.g. ... already mounted or mount point busy.

I finally modify /etc/fstab so that I have a new entry like this:
/dev/sdb1 /srv/dev-disk-by-label-SSD1TB/DATEN btrfs defaults,nofail,discard,ssd,subvol=DATEN 0 2
This works fine. I no longer have the whole btrfs file system of SDB1 mounted, but only the subvolume called DATEN which is possible for a test, but couldn’t be my final setup, as I also need the full file system mounted.
So with this mount nothing changed in respect to the path, as the mountpoint for the subvolme results in the same path as before: /srv/dev-disk-by-label-SSD1TB/DATEN
Nevertheless I still get this error:

|07.03.19 19:56  |ERROR  |Creating snapshot of "/srv/dev-disk-by-label-SSD1TB/DATEN" failed|
|---|---|---|
|07.03.19 19:56  |ERROR  |Cannot create snapshot of file system with type ext4|
|07.03.19 19:56  |ERROR  |Creating snapshot of "DATEN" failed.|

Now, I can try idea 2 work-around manually in the snapshot script
but I really have no idea what to change in file /usr/local/share/urbackup/btrfs_create_filesystem_snapshot
Any idea?

#!/bin/bash

set -e

SNAP_ID=$1
SNAP_MOUNTPOINT="$2"
SNAP_NAME="$3"
SNAP_ORIG_PATH="$4"

CDIR=`dirname $0`
. $CDIR/filesystem_snapshot_common
exit_exclude_snapshot_mountpoints "$SNAP_MOUNTPOINT"

set_filesystem_type "${SNAP_MOUNTPOINT}"

if [[ $TYPE == "" ]]
then
        if btrfs subvolume list -o "$SNAP_MOUNTPOINT" > /dev/null 2>&1
        then
                TYPE="btrfs"
        fi
fi

if [[ $TYPE == "btrfs" ]]
then
        mkdir -p "$SNAP_MOUNTPOINT/.urbackup_snaps"
        SNAP_DEST="$SNAP_MOUNTPOINT/.urbackup_snaps/$SNAP_ID"
        btrfs subvolume snapshot -r "$SNAP_MOUNTPOINT" "$SNAP_DEST"
else
        echo "Cannot create snapshot of file system with type $TYPE"
        exit 1
fi

echo "SNAPSHOT=$SNAP_DEST"

exit 0
4

W.r.t. to the file system type being detected as ext4, could you post the output of df -T -P ?

Idea 2… you have to only find one work-around that works, you know, but you can do it manually of course. Something like

if [[ $SNAP_MOUNTPOINT == “/srv/dev-disk-by-label-SSD1TB” ]]
then
SNAP_DEST="$SNAP_MOUNTPOINT/.urbackup_snaps/$SNAP_ID"
mkdir -p $SNAP_DEST
btrfs subvolume snapshot -r “$SNAP_MOUNTPOINT/DATEN” “$SNAP_DEST/DATEN”
echo “SNAPSHOT=$SNAP_DEST”
exit 0
fi

5

Correction: I forgot to undo snapshot.cfg before trying idea 1
I did that now and it works :slight_smile:

Unfortunately it’s not a solution for me as I need to access the whole file system of /dev/sdb1 an not only the subvolume DATEN.

At the end the solution was pretty simple:
I modified the /etc/fstab to first mount the subvolume DATEN to /mnt/SSD1TB_DATEN of the btrfs filesystem and in second line the whole file system to /srv/dev-disk-by-label-SSD1TB. It seems to be a BTRFS bug, as it will not work when I’m trying to mount the full file system first and in addition a subvolume of that file system to another path…

/etc/fstab:

/dev/sdb1 /mnt/SSD1TB_DATEN btrfs defaults,nofail,discard,ssd,subvol=DATEN 0 2
/dev/disk/by-label/SSD1TB /srv/dev-disk-by-label-SSD1TB btrfs defaults,nofail,discard,ssd 0 2

and I did switch the backup path from urback to /mnt/SSD1TB_DATEN

urbackupclientctl add-backupdir -x -f -d /mnt/SSD1TB_DATEN

Thanks uroni for your ideas and work on this!
For anyone, who has trouble with BTRFS subvolumes and Urbackup these different solutions may help :slight_smile: