New retention policy deletes old backups in a smart way

My main thoughts/concerns are:

  • Specifying a number should Always main: I want at least this number of versions and not: I want no more than this number of versions. So 1M:30,1Y:1M should not mean “Delete all versions older than the first 30 versions”, but “Stop deleting when there are 30 remaining versions”. This will prevent deleting more versions than intended.
  • I was thinking about some way to define the total number of versions, not the versions in a specific time frame. Not thought of the exact syntax, but somehow a trailing number could be supplied, indicating the minimum number of versions to keep. You could add an optional K: to supply the minimum total number of versions.
    Alternatively, you could add an optional third value for each time frame, so 1M:1W would mean "one backup for every week last month, and 1M:1W:3 would be interpreted as “one backup for every week last month, but stop deleting backups this months if there are 3 remaining backups in this time frame”.

My main concern is a common use case like 1M:1D. If I choose this policy, my intention is that I have (around) 30 versions to choose from when doing a restore operation.
If my computer is switched of for 1 month (holiday), all backup versions are deleted except 1, resulting in destroying all file versions with doing nothing. I see this as a potential problem.
Combining with --keep-versions is not supported, so there is no way to keep my retention policy (if I backup twice a day, 50% can be deleted) and keep at least 20 versions. Something like 1M:1D;K:20 would resolve that.

1 Like