decay-scale minimum value is awkwardly high

[pm215]

The decay-scale prune parameter minimum value is 2. This is a bit awkwardly high, I think. If I understand the pruning policy correctly, this means that there will be buckets of size 1, 2, 4, 8, 16, 32, 64, 128, 256 (at which point we hit the decay-limit 366 day cutoff), so there will be a few very recent backups of age < decay-start and then at most 9 covering the rest of the year. To have more backups retained than that, I think you would need to have a lower decay-scale. For instance with decay-scale = 1.5 I think you get 13 buckets in a year. (Conversely, values higher than 2 seem to me like they would be pretty useless because of how quickly the bucket size would grow, but presumably somebody has a use for them.)

Could the parameter be made to accept floating point values? Looking at the code the prune_decay_bucket() function that calculates which bucket a backup is in already takes 'double' parameters for the window and scale arguments, so it might only be the parameter-parsing code that is enforcing integer values here.

[ewxrjk]

Yes, I think that would be possible.

[ewxrjk]

If possible please try this branch: https://github.com/ewxrjk/rsbackup/tree/issue87

[pm215]

Without a mechanism for "tell me what the set of retained backups would be with these new settings" it's not very easy to test...

[ewxrjk]

Fair point. --prune -n should tell you what would be removed but you'd have to invert it yourself. So there's a feature gap here

[pm215]

I tried a test with "--prune -n" and that branch's rsbackup. It accepts a "decay-scale 1.5" but the output of --prune -n is identical to the output if it is set to 2 (with this random in-production backup disk that happens to want a lot of pruning because it's just been swapped in today.)