Hello,
How would I set up a retention policy that keeps a single daily backup, a single weekly backup, and a single monthly backup?
I thought this would do it:
1D:1D,1W:1W,1M:1M
But this results in the error:
ErrorID: RetentionPolicyParseError
An error occoured while processing the value of --retention-policy
Return code: 100
Thanks for any help
I entered this very stanza in a test backup and it was accepted, maybe you are using an outdated software version ?
I am running Duplicati - 2.0.6.3_beta_2021-06-17 which appears to be the latest version available?
this is with 2.0.6.104_canary_2022-06-15
Welcome to the forum @rhys
Was that run in the GUI Commandline? The clue for that is the return code. The help text there says:
and you can see from above example that the time frame is typically longer than the interval. It insists…
is lacking detail. For how long would you like 1 backup per day, etc.? That what the time frame controls.
Is your eventual goal to run this as CLI or a GUI job? In the GUI, you might consider this Options choice:
which is 1W:1D,4W:1W,12M:1M
There is no calendar behind this. It’s just times, to the second (which causes odd effects if your backup schedule is using the same interval – but this can be fixed by changing the custom retention, if desired).
This was done in the GUI, I ran it both by clicking “Run now” and via the GUI command line option. I included the error from the GUI command line as it seemed more informative.
What I would like essentially is that at any one time there would be three backups: one from the last day, one from the last week, and one from the last month.
If I write 2D:1D,2W:1W,2M:1M I assume I will end up with 6 backups? 1 from each of the last 2 days, 1 from each of the last 2 weeks and 1 from each of the last 2 months. I want half that 
And in fact that policy does seem to work so it seems like there is either a bug or an undocumented rule that the time frame must be greater than the interval?
I updated to 2.0.6.104_canary_2022-06-15 and I still get this error (on Windows).
oh well, I just checked it was accepted in the Gui 
Actually running it produces:
Details: Duplicati.Library.Interface.UserInformationException: An error occoured while processing the value of --retention-policy ---> Duplicati.Library.Interface.UserInformationException: An interval cannot be bigger than the timeframe it is in
this is a slightly misleading error message, the actual test is <=, not <.
So Duplicati refuses to have an interval equal to the timeframe.
Why so few? Unless source changes heavily, additional backups take very little incremental space.
Or both, but both face the same challenge of lack of volunteers (care to be one?) to do anything for it.
GUI smart and custom backup retention aren’t covered #83 asks for documentation (maybe not this).
seems inconsistent, saying IntervalCannotBeBiggerThanTimeFrame but actually using >= as its test.
(oh, I see I said that too late, but I’ll keep going anyway)
The intent of retention policy is to progressively thin out the backup versions as the versions get older.
I’m not sure if what you want can be wedged in that. The calendar here is for the reader. Do you want
SMTWRFSSMTWRFSSMTWRFS
D
D
D
D
D
D
D
WD
W D
W D
W D
W D
W D
W D
WD
W D
W D
W D
W D
W D
W D
If you do a daily backup, it’s kept because the most recent backup is always kept, but I think thinning within a time frame favors the first backup in the time frame, so if you try to thin to 1 weekly per month, it might do
SMTWRFSSMTWRFSSMTWRFS
D
D
D
D
D
D
D
WD
W D
W D
W D
W D
W D
W D
W D
W D
W D
W D
W D
W D
W D
Code is below if anyone wants to look through it.
Ah, thank you for looking into it. Reading that Github issue I appreciate why this is a tricky topic to explain so thanks for your replies 
I guess I expected that I would end up with backups that were no older than 1 day, and no older than 1 week, and no older than 1 month which I think is like the first calendar you wrote?
You make a good point about the incremental backups being small, I have no specific need for so few backups. I just also don’t think I have much need for very many so my first thought was to try something very minimal.
I will just set it to something that works
To bypass the maybe-off-by-one error, you can add a second (1s) to every time frame.
Before anyone decides to fix the inconsistency, the code should be read through. Also:
occoured
could be fixed.
If you want to log the retention decisions, the code looks like it logs at Information level.
There’s also Profiling level, but that’s super heavy. Or you could try to set up a log filter.