Just noticed i have the same issue, after removing the client because i didn’t see the benefit of using dm-based or datto snapshotting (i might have tried both in the past on this particular host) i tend to just remove the client “uninstallurbackupclient”, which fixed that on other hosts. But just now i noticed there are still huge .overlay_someguid and .era-meta_someguid files in the root of the filesystem. I removed the client again, rebooted but the files are still there. I can’t remove them, even offline (booting the host from a debian netinst image and go into rescue mode, mount the root volume).
At this moment the client isn’t installed, but the huge files are there and i cannot remove them. It’s a libvirtd/qemu virtual machine running pihole.
Actually i think i just found the solution. For those interested: if you are 100% convinced the .overlay and related file(s) are not needed any longer. (my trick: check if mount shows a “regular block device” like /dev/sdaX or in my case /dev/vdaX is mounted as root) you can do the following:
chattr -i /.overlay_someguid
this will remove the “immutable” (my guess) attribute from the file. It’s comparable to the “system file” in M$ terms. Once that is done you will find you can remove the file.
Hope this helps, cheers!
some context / in my case:
root@pihole:~# lsattr /.era-meta_3d41c58e-6724-4d47-8981-11c766a08a24 /.overlay_2fefd007-3e48-4162-b2c6-45ccdda22f37_746085b55125440ca8296d93cf79d81e0a8a30760cbc6e4c
----i---------e------- /.era-meta_3d41c58e-6724-4d47-8981-11c766a08a24
----i---------e------- /.overlay_2fefd007-3e48-4162-b2c6-45ccdda22f37_746085b55125440ca8296d93cf79d81e0a8a30760cbc6e4c
root@pihole:~# chattr -i /.era-meta_3d41c58e-6724-4d47-8981-11c766a08a24 /.overlay_2fefd007-3e48-4162-b2c6-45ccdda22f37_746085b55125440ca8296d93cf79d81e0a8a30760cbc6e4c
root@pihole:~# rm /.overlay_2fefd007-3e48-4162-b2c6-45ccdda22f37_746085b55125440ca8296d93cf79d81e0a8a30760cbc6e4c /.era-meta_3d41c58e-6724-4d47-8981-11c766a08a24
this recovered about 6GB of disk space. I took a snapshot of the vm before any of this and just rebooted it, no issues, got a backup via urbackup so i’m removing the snapshot and committing the qcow, if i run into related issues later i still have a backup on the urbackup server of course. I’ll let you know if that happens.
I could not find any other topics here that covered a solution, and i have the impression this might not be suitable for .datto related backups, keep that in mind!