Image backup error for Ubuntu 22.04.2 with btrfs


I’m trying to get the image backup to work on a Ubuntu 22.04.2 with kernel 5.19.0-46-generic having a btrfs root partition. The client version is 2.5.24, installed directly from the server. The file backup is already working. Also, on another system with lvm/ext4 and dattobd the image backup is working.

I installed dattobd as I did for another system and I think it is working (I see the datto-ctl device). I selected dattobd snapshot type when I installed the client, because if I select btrfs snapshot the server says that image backup is not supported.

I am trying to get the backup image for /dev/sda2

I added some debug infos in the image snapshot scripts (in italic below) and set log level debug for urbackupclient. I can see the following in /var/log/urbackupclient.log :

2023-07-18 13:22:41: Started connection to SERVICE_COMMANDS
2023-07-18 13:22:41: ClientService cmd: #Iw9FCjc75LiGXVRG7yRsa#MBR driveletter=_dev_sda2&disk_path=%2Fdev%2Fsda2&image_full=1&running_jobs=1&token=nN5s49CSjUrt9a9w8ukw
2023-07-18 13:22:41: dl_devnum=a2
2023-07-18 13:22:41: gpt_style=true
2023-07-18 13:22:41: GUID partition table found
2023-07-18 13:22:41: GUID partition table size is 16 KB
2023-07-18 13:22:41: rc=0 hasError=true state=0
2023-07-18 13:22:41: SERVICE_COMMANDS finished
2023-07-18 13:22:41: Started connection to SERVICE_COMMANDS
2023-07-18 13:22:41: ClientService cmd: #Iw9FCjc75LiGXVRG7yRsa#FULL IMAGE letter=/dev/sda2&token=nN5s49CSjUrt9a9w8ukw&bitmap=1&status_id=37&running_jobs=1&zero_skipped=1
2023-07-18 13:22:41: Script “/usr/local/etc/urbackup/preimagebackup” does not exist
2023-07-18 13:22:41: WARNING: Could not open snapshot at “//.urbackup_snaps/2edf609a55276425138c39286e4531cf2f47bac8cf4a6826”
2023-07-18 13:22:41: WARNING: Removing reference because shadowcopy could not be openend
2023-07-18 13:22:41: WARNING: Restarting shadow copy of / because it was started by this server
2023-07-18 13:22:41: Releasing /dev/sda2 orig_target=/dev/sda2 target=//.urbackup_snaps/2edf609a55276425138c39286e4531cf2f47bac8cf4a6826
2023-07-18 13:22:41: Deleting shadowcopy for path “//.urbackup_snaps/2edf609a55276425138c39286e4531cf2f47bac8cf4a6826” -2
2023-07-18 13:22:41: Snapshot at //.urbackup_snaps/2edf609a55276425138c39286e4531cf2f47bac8cf4a6826 was already removed
2023-07-18 13:22:41: Started connection to SERVICE_COMMANDS
2023-07-18 13:22:41: ClientService cmd: #Iw9FCjc75LiGXVRG7yRsa#2PING RUNNING pc_done=0&status_id=37&speed_bpms=0&total_bytes=-1&done_bytes=0&paused_fb=1#token=nN5s49CSjUrt9a9w8ukw
2023-07-18 13:22:41: Deleting Shadowcopy for dir “/”

2023-07-18 13:22:41: dattobd_create_snapshot called as sh -c /usr/local/share/urbackup/dattobd_create_snapshot 8af5185e6c1657fc8408d5d459f0bad58d64efc37530330f “/” “/dev/sda2” “/dev/sda2” 2>&1 from
2023-07-18 13:22:41: SNAP_ID=8af5185e6c1657fc8408d5d459f0bad58d64efc37530330f
2023-07-18 13:22:41: SNAP_MOUNTPOINT=/
2023-07-18 13:22:41: SNAP_DEST=/mnt/urbackup_snaps/8af5185e6c1657fc8408d5d459f0bad58d64efc37530330f
2023-07-18 13:22:41: SNAP_MOUNTPOINT_SAN=_
2023-07-18 13:22:41: SNAP_NUM_PATH=/mnt/urbackup_snaps/cbt_info/_-snapdev
2023-07-18 13:22:41: SNAP_COWFILE_PATH=/mnt/urbackup_snaps/cbt_info/_-cowfile
2023-07-18 13:22:41: DEVICE=/dev/sda2
2023-07-18 13:22:41: TYPE=btrfs
2023-07-18 13:22:41: btrfs_create_filesystem_snapshot START
2023-07-18 13:22:41: SNAP_ID=8af5185e6c1657fc8408d5d459f0bad58d64efc37530330f
2023-07-18 13:22:41: SNAP_MOUNTPOINT=/
2023-07-18 13:22:41: SNAP_NAME=/dev/sda2
2023-07-18 13:22:41: SNAP_ORIG_PATH=/dev/sda2
2023-07-18 13:22:41: TYPE == btrfs
2023-07-18 13:22:41: btrfs snapshot command is: btrfs subvolume snapshot -r / //.urbackup_snaps/8af5185e6c1657fc8408d5d459f0bad58d64efc37530330f
2023-07-18 13:22:41: Create a readonly snapshot of ‘/’ in ‘//.urbackup_snaps/8af5185e6c1657fc8408d5d459f0bad58d64efc37530330f’
2023-07-18 13:22:41: btrfs_create_filesystem_snapshot FINISHED
2023-07-18 13:22:41: exiting with RESULT=0

2023-07-18 13:22:41: Shadowcopy path: //.urbackup_snaps/8af5185e6c1657fc8408d5d459f0bad58d64efc37530330f
2023-07-18 13:22:41: Disabling CBT on volume “/dev/sda2”
2023-07-18 13:22:41: ERROR: Error reading device file name from //.urbackup_snaps/8af5185e6c1657fc8408d5d459f0bad58d64efc37530330f-dev
2023-07-18 13:22:41: ERROR: Opening filesystem on device failed. Stopping.
2023-07-18 13:22:41: Device file: “//.urbackup_snaps/8af5185e6c1657fc8408d5d459f0bad58d64efc37530330f”
2023-07-18 13:22:41: Sending full image done
2023-07-18 13:22:41: Removing running process (1) id 6 server_id 37 token nN5s49CSjUrt9a9w8ukw action 3
2023-07-18 13:22:41: SERVICE_COMMANDS finished
2023-07-18 13:22:42: Started connection to SERVICE_COMMANDS
2023-07-18 13:22:42: ClientService cmd: #Iw9FCjc75LiGXVRG7yRsa#2LOGDATA 1689675761 0-1689675761-Starting unscheduled full image backup of volume “/dev/sda2”…
2-1689675761-Request of image backup failed. Reason: Opening filesystem on device failed. Stopping.
0-1689675761-Transferred 750 bytes - Average speed: 35.496 KBit/s
0-1689675761-Time taken for backing up client bogdan-ubuntu: 193ms
2-1689675761-Backup failed

2023-07-18 13:22:42: rc=0 hasError=true state=0
2023-07-18 13:22:42: SERVICE_COMMANDS finished

The first error is “Error reading device file name from //.urbackup_snaps/8af5185e6c1657fc8408d5d459f0bad58d64efc37530330f-dev”. But nothing creates that file in the “dattobd_create_snapshot” script, because the script ends after creating the snapshot: $CDIR/btrfs_create_filesystem_snapshot “$@”
The part where that file is created is at the end of the dattobd_create_snapshot script ( echo “/dev/datto$NUM” > ${SNAP_DEST}-dev ), but it never gets called because the script exits as shown above.

Can you please help me get this thing working?

Thank you,

I’m confused. Are you trying to use dattobd on a btrfs? Not sure that is how it’s supposed to work, I think there is another snapshot mechanism available to use on btrfs when you install the client.
I have never done img backups on linux, that was the next thing I was going to learn so this is just me speculating.

In my notes I found this link referencing snapshots. Might be something to read?

If you like me, have multiple filesystems you back up from (I do file backups from btrfs, ext4 AND ntfs on the same client) this read could be good. But then again, this might not have anything to do if you do img backups.

And I don’t know what filesystem you store your backups in but this link could be good to read if it’s in btrfs.
Create the file /etc/urbackup/backupfolder containing the path to the backup directory for btrfs.
Test with urbackup_snapshot_helper test

Hope that can give you a little help even though I have not done img backups myself.

Hi Bedna and thank you for finding the time to answer!

I included the full log in case it would help someone debug the problem.
The first part of the log deals with a previous (uncompleted, stale) image backup, and gives some warnings indeed while deleting it, but is ok.
But the second part, starting at “dattobd_create_snapshot…” (the part with italics) does create a new snapshot, as it should.

Regarding the use of dattobd on btrfs… I agree, it is strange, but, as I said in the previous message, if I select the btrfs snapshot mechanism during the client installation, the server will report that image backup can’t be performed or is not supported. It is also strange because although I select dattobd as snapshot mechanism, the snapshot is actually done with btrfs snapshot. Maybe there were some limitations during the development, idk …

I saw before the first link that you suggested, but it doesn’t really help me because it shows only how to change the snapshot mechanism. I did it already, but by uninstalling and then reinstalling the client.

I saw also the second link, but it refers to lvm snapshots. I understand that they say that one should use the filesystem path (“/” in my case) instead of the device (/dev/sda2). I tried that, but urbackupclient was complaining about something (don’t remember exactly what, but I’ll check it later). At least with /dev/sda2 the snapshot appears on the drive…

And finally, the third link I think it is related to server storage options, not the client snapshots, so I don’t think it helps.

I must mention also that I use the latest linux snapshot scripts… There were some changes made 6 months ago, but nothing changes.

I think that the problem is in client.cpp, but maybe someone else knows better.

The file backups are ok, and they work. But in case something bad happens, having an image backup saves A LOT of time, because I don’t have to reinstall everything and then copy the latest versions of files.

So you have tried to restore an image with the tools provided by urbackup and it worked?

Then you can ignore the errors, because, well, your img backup worked.

I’m going to look into this img backup thing on linux, I thought it wasn’t really supported and the path in the imgage backup section of the server gui, is that C = / (I read that somewhere).

So for my own curiosity, you set the device-path in “volumes to backup” in the webgui img-backup section?
Have you tried to do it device wise? ie /dev/sda?
Just out of curiosity if it works? As said, I haven’t looked into img backups very much.

Hi bedna,

The images are not created (they don’t appear in the urbackup server interface), so I can’t restore them. I checked also the client folder on the server and I can see some folders for each failed image, but each one contains only one “mbr” file.

I tested also backing up “/”, “/dev/sda” and “C” besides “/dev/sda2”. I attached the log files for each of these cases along with the client configuration files. For “C” it behaves similar to “/dev/sda2”, so I can confirm your hypothesis that C = /.

I don’t think it has anything to do with the server, because the error appears on the client, so having btrfs on the server wouldn’t help. Moreover, I’m storing the data on the server on a ZFS partition, and I can’t change it.

I’ll reinstall the client and change the snapshot method again to btrfs and see if I can force it to make an image.

For all of these cases the snapshot.cfg is the following:

settings_dev_sda.txt (15.6 KB)
settings_dev_sda2.txt (15.6 KB)
settings_root.txt (15.6 KB)
settings_C.txt (15.6 KB)

log_dev_sda.txt (3.0 KB)
log_dev_sda2.txt (3.8 KB)
log_root.txt (766 Bytes)
log_C.txt (6.1 KB)

Oh, I misunderstood your last message, it was the FILE backups that was working, my bad.

Ok, so the image backups are per partition, not per device it seems, maybe.
What I would do is try to do an image backup on a disk with only ext4.

I remember briefly looking into img backups and reading first that it wasn’t supported, but then a while ago experimental features were introduced or something.

I honestly have no more input to give you.

I found where I read the C = /, it was a blog post from 2 years ago. It’s mentioned doing it without the dattodb…

The blog post invites discussion on this forum, maybe try that. xD
Have a look.

Edit 2
You might want to disregard most of my message and read this.

Hi bedna,
And thank you so much for your help!
I read all those posts, but it didn’t help. The only system that can perform image backups has LVM and uses datto as snapshot mechanism. Btrfs is not working, and lately I tried switching to elastio, but that doesn’t work either. I’ve written in another (old) topic about switching to elastio.
Maybe @uroni knows more about this subject.
All the best,

Dont use btrfs for root partition /
, personally i recommend to have special partition for btrfs and on physical separate disk.


Or do you mean not to create it directly on the device but rather on a partition?
I think that is old news, I think it works perfectly both ways.

Or do you mean img backups is not doable if the root is in btrfs?

Ok , lets clarify some stuff

Don’t use btrfs for your root partition its bad idea, btrfs is meant to be used on external drives like usb flash drives and another harddrives.
You can “easy” corrupts btrfs , i saw like many times if btrfs mounted with corrupted id well , than it wasnt easy to recover the data.
Advantage of btrfs its fast then other and this why urbackup use it for doing backups

Additionally i can say from practice its hard cloning of btrfs partition, even with the native tools .
If you mean business with backups, you need at least 2 harddrives running in raid 1, with this you can forget loosing important stuff or think about possible disk failure.

Final advise, do have separate harddrives one for the os and one for doing backups.

Where on earth did you get that from?? :open_mouth:

Where are you getting your information from??!?! Also not true!

Cloning? Like you mean like make an img of the whole disk with lets say clonezilla is “hard”???
This is starting to get really crazy how misinformed you are. I restored a PARTITION in btrfs last month, crazy it just worked!!
If you mean “clone” like making an img with urbackup, that you might be correct in.

Please inform me of a raid 1 that can be run on ONE drive. LMAO

That one I agree with, but isn’t that pretty obvious?

I have been running urbackup on btfrs for, I think 18 months, NEVER have I experienced anything bad with it.
On top of that, I have been running btrfs (as subvolume) on / on my personal computer for, I think 8-10 months, NEVER had any trouble, like EVER. No problem in grub, no kernel trouble, NOTHING!
What it HAS done though, is on at least 2 occasions, SAVED ME from having to reinstall (or at least endless amount of trouble shooting), because, snapshots…

I have ZERO clue what you are talking about dude.