A button for that is deemed too dangerous I think. You can manually delete the destination files, then use the Database screen Delete button. This gives a fresh start, but I suggest reducing the amount of files backed up or you might run out of space again. Sometimes it’s possible to trim a backup using The PURGE command but there’s not a nice GUI for it compared to removing files from the Source tree before a restart-from-scratch. The other problem is that both version delete and purgemerely mark data blocks as wasted space, then The COMPACT command must run. Compacting files at the backend is usually automatic (unless turned off), but needs space to use.
If you’re teetering on a completely full situation (Duplicati does give advance warning typically), it possibly is easiest to start fresh with a backup having less Source. Leave room for new versions, choose a reasonable retention policy on the Options screen, and future should just maintain itself.
Understanding Backup gives some technical details if you care, but basically you’re correct that a changed file has data uploaded, but it’s only the changed data blocks. Unchanged are referenced from wherever they were first seen, so deleting the oldest backup still has to hold data that’s used later on. If you really want to get into this, you can talk about your version count, their value to you, amount of change per version (amount uploaded is in the job log “Complete log”), and work harder.
You can delete multiple versions by using a version range (start and end with dash in between). Actually freeing the wasted space is up to Compact.
If in Commandline, it’s the “Compact” command, but subject to configurable thresholds per docs. Current GUI has it on the Home screen as “Compact now”. Upcoming GUI has “Compress now”.
But after squeezing out the wasted space, the total of larger ones is smaller than the smaller ones. That’s how it frees disk space. If you want a lot freed, and don’t want a whole fresh start, you could reduce the Source, run a backup, multi-version-delete a few old ones at a time, then run Compact, maybe with smaller threshold to make sure something happens. Repeat forward until you have the reduced-Source version as the only remaining. So you effectively did a Purge without using Purge.
Risk here depends on how close things are to completely full, as 2.1.0.5 Compact uploads all new dblocks before deleting old ones. Experimental version 2.1.1.0 has a fix, but it’s still sort of for test. Complaints aren’t pouring in, but I don’t know its number of takers. After it comes Beta and Stable.
EDIT 1:
--small-file-size=<int>Files smaller than this size are considered to be small and will be compacted with other small files as soon as there are<small-file-max-count>of them.--small-file-size=20means 20% of<dblock-size>.
is the small-to-large compact. If it’s wasted space in large dblocks, you’d see large to fewer large.
EDIT 2:
And if a dblock has turned completely into wasted space, it gets deleted. Nothing to save from it… Problem is that predicting how source file blocks map to blocks in dblock files is tough for humans.