There are several large .datto and .overlay files in the root of a linux client box.
I think they are related to old failed backups.
Is it safe to delete them?
These are snapshot backing files created by dattobd, and yes, likely still exist due to not cleaning up after an interrupted backup. You should use dbdctl to destroy the snapshots. https://github.com/datto/dattobd/blob/master/doc/dbdctl.8.md
I have no experience with dattobd to assist further.
Those files can just be deleted.
If you want to help, try creating steps to reproduce the problem (leftover snapshot files) with the newest version and post them.
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!