Enhancement proposal for prune command

Hi Gilbert,

I find myself wishing I had a bit more control of granularity over snapshot retention with the prune command. I do hourly backups for some particularly sensitive and fast-changing files and would like the ability to define a retention policy that deals with hours. Currently prune’s -keep is hardcoded to days.

Moreover, it can sometimes be difficult to reason about how a particular policy will actually materialize over time, because the more recent retention periods dictate what will be rolled up to the further out periods.

Some time ago, I wrote a simple tool to manage droplet snapshots for Digital Ocean and my implementation for retention was heavily inspired by duplicacy, but I believe I improved on it in two ways:

  • Intervals and durations take a time unit, so you can describe either (and independently) in hours, days, weeks, and months
  • there is a --simulate option that runs a simulation of how your retention policy will look after a given period (where you describe how frequently you run the backup and how over how many times). This helps you spot stupid mistakes in your retention policy before actually implementing.

I think it’d be cool if duplicacy implemented either or both of these ideas (but especially #1 :slight_smile: ).

Thanks!

4 Likes

Hi, I know this is an old post, but I just submitted an update for duplicacy that adds a -keep-max option to the duplicacy prune command. I don’t know if/when gilbertchen will review the update and/or decide whether or not to include in a future duplicacy version or not.

If you’d like to read about it, here’s the post I just made today:

Duplicacy prune -keep-max option