Prune does not seem to work as expected

Support
#1

I would appreciate if someone could help me understand prune and what revisions are kept. I am using the Web GUI in a Docker environment. I have the following options enabled on a prune command set to run after every scheduled backup:

-d | -keep 7:7 -keep 0:30 -a -exhaustive -threads 10

I interpret this as follows:

  1. Keep one revision every 7 days after seven days
  2. Keep no revision after 30 days
  3. Do this for all backupIDs

That would then lead me to believe that - assuming daily backups - across a 30 day period I would have:

  1. a daily revision every day for 6 days
  2. 4 revision - one on each day 7, 14, 21, and 28
  3. No revision older than 30 days.

I also periodically (read: when I see how much storage I’m using) run a prune command with the following options: -d | -all -exhaustive

However, my storage usage endlessly climbs. This hinted to me to check what revisions I have available. In the Restore tab, I see revisions back 6 months (to March 25th) for some snapshot IDs that I’ve had around for that long.

Am I wrong in understanding the prune command and thus the expected outcome? Or is something else going on? Either way, I’d appreciate help in trimming down my storage used.

#2

Reverse the order of these. See prune · gilbertchen/duplicacy Wiki · GitHub

There is no reason for this, it will makes things slower and cost you a lot in avoidable api usage.

So your command shall look like so:

-keep 0:30 -keep 7:7 -a
#3

image
Well, that’d be what I missed. If they aren’t in descending order, is neither “keep” option used?

I’ll try that command and report back, thank you!

#4

I’m not sure what should happen – I’d expect that the first matching rule should take precedence – i.e. second rule will have no effect, and you would end up with only revisions older than 7 days affected, keeping each every 7 days.

If this is not what you see – perhaps it may have something to do with -exhaustive flag – perhaps it takes too long and times out somewhere.

Why does not duplicacy sort the rules itself – I don’t fully understand.

Yeah, let’s start with what’s known to work…

#5

I actually only just added the -exhaustive flag two days ago in a new attempt to fix the issue so I don’t think it relates to the issue.

And to reinforce that belief, after changing the order of the keep commands, my storage usage dropped by 2TB and now my revisions are as expected. Thank you for helping fix this!

1 Like
#6

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.