Now that I think about it, it’s probably calculating everything from the oldest day as after 30:70 stops at May 22nd as the test shows, it would enter 7:14 and jumps 7 days from there and if being inclusive next candidate would be May 28th which is Monday and then keeps picking up Monday but since 30:70 has ‘eaten’ everything up until 70th day (which is around June 10th), 7:14 would pick up from June 11th until 14 days ago (again, being inclusive to be August 6th) and rest are 1:1.
Yes, when a new retention period starts, the first snapshot is always kept and used as the base. Then subsequent snapshots are checked one by one. If a snapshot is too close, then it will be deleted. Otherwise it will be kept and become the new base.
One issue with the current implementation is that actual times of the day that snapshots may vary a bit (as well as the time at which the prune is run). As a result a few seconds in the time difference may cause a completely different set of snapshots to be deleted (for example this issue: Impact of Prune on storage Copy operations). I think the solution is to consider only the days when comparing the time different between two snapshots.
by “first”, do you mean youngest or oldest?
And could you explain
This is a good point, by my understanding is the youngest.
im confused with it as well…more for what happens with a customer of mine
they have a sub folder off of the root folder we will call it jobs
they work on a job and then when its done its moved to another sub folder called jobs complete…different sub folder from root
in b2 i think (don’t know) but think the files are backed up twice…
how do i go about pruning files that have been moved…
i want to be careful not to prune something that was deleted or changed by accident under the root in the other folders… if that even makes sense
So what is it that you don’t understand?
Pruning is not about removing individual files. It’s about removing revisions from snapshots.