Everything has been working fine in my Duplicati instance until around 19 days ago when I started getting these warnings:
2024-12-18 03:03:34 +00 - [Warning-Duplicati.Library.Main.Operation.FilelistProcessor-BackendQuotaNear]: Backend quota is close to being exceeded: Using 930.028 GB of 45.000 GB (10.540 GB available)
The thing is, the location I am backing up to is 2 TB in size and there are 777 GB of space remaining. The log message does not make sense.
My Duplicati instance is currently on v2.1.0.2_beta_2024-11-29 installed within a Docker container. I can see by running df -h inside my container I have these mount points with various amounts of free space:
Evidently, Duplicati is checking for free space on /etc/hosts (/dev/loop2) rather than my configured location of /TowerBackup (/dev/sdf2).
This is not a problem with Duplicati being able to “see” my /TowerBackup mount because the actual backup works fine and I am able to see restore points for every day. I have a few questions:
Why has this only just started happening when I have not changed my configuration? Duplicati has been working fine for well over a year before this.
Why is Duplicati able to correctly use the /TowerBackup for the backup but not for the free space validation?
Hi @pepperywasp, I assume that you are using “file” backend as destination.
There was a change on that backend on specifically on quota estimation that might be the source of this discrepancy that triggers the warning. The part that is responsible for the backup is unchanged so that explains why the actual backup its working.
With limited time to deal with this I have decided to automatically bin any e-mails with this (and only this) warning and wait for a beta release that fixes the root cause.
The problem with that plan is the root cause doesn’t get fixed until someone figures it out.
Reading the size from the wrong partition got fixed, but quota-disable still doesn’t work.
Or at least it doesn’t stop that warning on the latest Canary release, so it deserved a look.
My guess about the code change that broke the quota-disable workaround was posted:
Test used Linux with a 1 MB tmpfs filesystem, and a file made using dd and /dev/urandom.
When a Warning began, I tried quota-disable=true and quota-size=1TB. What worked was
quota-warning-threshold=0
--quota-warning-threshold (Integer): Threshold for warning about low quota
Set a threshold for when to warn about the backend quota being nearly exceeded. It is given as a percentage, and a warning is generated if the amount of available quota is less than this percentage of
the total backup size. If the backend does not report the quota information, this value will be ignored.
* default value: 10
where math sounds like warning would need an available quota of less than zero to go off.
I believe the root cause of me getting the error in the first place is (as you say) the issue of using the wrong partition for the size and it appears to be fixed in #5734.
Of course, the quota-disable issue should be fixed as well. But I don’t think that is the root cause for me.