Raw image backups fail after enabling btrfs support

Hi,

I’m running UrBackup docker for a few years now on a linux server (currently Debian 11) with btrfs filesystem but just recently enabled btrfs support with setting --cap-add SYS_ADMIN as a parameter when updating 2.4.11 to the latest version (server is currently on version 2.5.32 and Windows clients are on 2.5.25).

Now all my raw image backups fail with something like:

2023-12-29 13:42:01: Basing image backup on last incremental or full image backup
2023-12-29 13:42:01: Creating writable snapshot of previous image backup...
2023-12-29 13:42:01: ERROR: Could not create snapshot of previous image backup at 231220-1618_Image_C "ERROR: Not a Btrfs subvolume: Invalid argument"
2023-12-29 13:42:01: ERROR: Error creating image backup destination.
2023-12-29 13:42:01: Time taken for backing up client WINDOWS_ONE: 2s
2023-12-29 13:42:01: ERROR: Backup failed

Does anyone know how to fix this without purging all my current raw image backups?

UrBackup server started and updated successfully, also btrfs test worked fine and file backups are created flawlessly using btrfs snapshots:

2023-12-25 23:35:09: Starting HTTP-Server on port 55414
2023-12-25 23:35:09: HTTP: Server started up successfully!
2023-12-25 23:35:09: SQLite: recovered 99 frames from WAL file /var/urbackup/backup_server.db-wal code: 283
2023-12-25 23:35:09: SQLite: recovered 44994 frames from WAL file /var/urbackup/backup_server_files.db-wal code: 283
2023-12-25 23:35:09: SQLite: recovered 3707 frames from WAL file /var/urbackup/backup_server_link_journal.db-wal code: 283
2023-12-25 23:35:11: SQLite: recovered 158374 frames from WAL file /var/urbackup/backup_server_links.db-wal code: 283
2023-12-25 23:35:11: SQLite: recovered 60 frames from WAL file /var/urbackup/backup_server_settings.db-wal code: 283
2023-12-25 23:35:11: SQLite: recovered 99 frames from WAL file /var/urbackup/backup_server.db-wal code: 283
2023-12-25 23:35:11: SQLite: recovered 60 frames from WAL file /var/urbackup/backup_server_settings.db-wal code: 283
2023-12-25 23:35:11: SQLite: recovered 44994 frames from WAL file /var/urbackup/backup_server_files.db-wal code: 283
2023-12-25 23:35:14: SQLite: recovered 158374 frames from WAL file /var/urbackup/backup_server_links.db-wal code: 283
2023-12-25 23:35:14: SQLite: recovered 3707 frames from WAL file /var/urbackup/backup_server_link_journal.db-wal code: 283
2023-12-25 23:35:14: Started UrBackup...
2023-12-25 23:35:14: Removing temporary files...
2023-12-25 23:35:14: Recreating temporary folder...
TEST FAILED: guestmount is missing (libguestfs-tools)
2023-12-25 23:35:14: Image mounting disabled: TEST FAILED: guestmount is missing (libguestfs-tools)
Testing for btrfs...
Checking /backups/testA54hj5luZtlorr494 for dependencies...
Create subvolume '/backups/testA54hj5luZtlorr494/A'
Create a snapshot of '/backups/testA54hj5luZtlorr494/A' in '/backups/testA54hj5luZtlorr494/B'
Delete subvolume (commit): '/backups/testA54hj5luZtlorr494/A'
Delete subvolume (commit): '/backups/testA54hj5luZtlorr494/B'
BTRFS TEST OK
2023-12-25 23:35:14: Backup destination does handle subvolumes and snapshots. Snapshots enabled for image and file backups.
2023-12-25 23:35:14: InternetService: Server started up successfully!
2023-12-25 23:35:14: UrBackup Server start up complete.
2023-12-25 23:35:14: Looking for old Sessions... 0 sessions
2023-12-25 23:35:14: Server started up successfully!
2023-12-25 23:35:14: Broadcasting on ipv4 interface eth0 addr 172.17.0.2
2023-12-25 23:35:16: Downloading version file...
2023-12-25 23:35:16: Downloading version file...
2023-12-25 23:35:16: Downloading server version info...
2023-12-25 23:35:16: Downloading dataplan database...
btrfs subvolume list /media/hdd1/backups/WINDOWS_ONE/
ID 1014 gen 582352 top level 5 path backups/WINDOWS_ONE/231227-1120
ID 1015 gen 582359 top level 5 path backups/WINDOWS_ONE/231228-1144
ID 1016 gen 583638 top level 5 path backups/WINDOWS_ONE/231229-1211
ID 1023 gen 584224 top level 5 path backups/WINDOWS_ONE/231230-1221
ID 1034 gen 584814 top level 5 path backups/WINDOWS_ONE/231231-1225
ID 1039 gen 585336 top level 5 path backups/WINDOWS_ONE/240101-1455
ID 1045 gen 585840 top level 5 path backups/WINDOWS_ONE/240102-1504
ID 1050 gen 586329 top level 5 path backups/WINDOWS_ONE/240103-1506
ID 1055 gen 586926 top level 5 path backups/WINDOWS_ONE/240104-1508
ID 1061 gen 586951 top level 5 path backups/WINDOWS_ONE/240105-1514

Thank you in advance.

It probably used reflinks for the previous raw image backups?

Currently it cannot switch from those to the snapshot based ones, I guess (It would be possible but not implemented).

You might have to run full image backups. Maybe you need to force it by running echo "UPDATE backup_images SET version=99;" | sqlite3 /var/urbackup/backup_server.db

1 Like

Thank you very much for your reply, helped me to solve this problem. I executed the sqlite command in the docker container, a following image backup attempt by UrBackup failed though but after I tried to delete the last non-btrfs snapshot full image backup (which gave me an error) UrBackup made a new attempt which succeeded:

13.01.2024 23:23:23
Starting scheduled full image backup of volume "C:"...
Basing image backup on last incremental or full image backup
Error retrieving last image backup. Doing full image backup instead.
Transferred 39.0567 GB - Average speed: 236.03 MBit/s
Time taken for backing up client WINDOWS_ONE: 23m 43s
Backup succeeded

Old image backups have been kept and now they are created as btrfs snapshots :slight_smile:

btrfs subvolume list /media/hdd1/backups/WINDOWS_ONE/
[...]
ID 1131 gen 591394 top level 5 path backups/WINDOWS_ONE/240113-2323_Image_C

I’m not sure about if reflinks were used before though, images were previously saved in a folder as .raw files.