Incorrect Free Space Warnings

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:

Filesystem      Size  Used Avail Use% Mounted on
/dev/loop2       45G   34G   11G  76% /
tmpfs            64M     0   64M   0% /dev
shm              64M     0   64M   0% /dev/shm
shfs             14T  9.7T  4.0T  71% /source
/dev/sdf2       1.9T  1.1T  777G  59% /TowerBackup
/dev/loop2       45G   34G   11G  76% /etc/hosts
tmpfs           7.8G     0  7.8G   0% /proc/acpi
tmpfs           7.8G     0  7.8G   0% /sys/firmware
tmpfs           7.8G     0  7.8G   0% /sys/devices/virtual/powercap

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?
  • What can I do to fix this?

Thanks!

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.

  • What can I do to fix this?

You already did bringing it up. Thank you.

I have raised an issue.

Flaw in big code change. File backend reports incorrect quota on Linux & MacOS #5733

and old one still would, but you got new one.

Code has various parts. Only quota part broke.

Or you can carefully run a Canary test release, or you can wait for fix in future Beta or Stable.

Thank you I have subscribed to the issue.

Thank you, I’ll keep an eye out for this making it to a Beta release and will post back on whether this fixes my issue.

Unfortunately, I still get the warning using this option set to true.

Where did you put the option? If in job Advanced options, you also need to check it, like below:

If it doesn’t do what it says, maybe it’s a bug, but you can also see if quota-size option helps it.

I set the option here:

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.

Thanks for your help.

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:

Duplicati Warning - BackendQuotaNear

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.

It might be the root cause for

but if you’d rather bin e-mails, fine. If you try new workaround attempt, feedback would be nice.

This appears to be fixed in the latest beta.

2 Likes