ДЄn interval of 0 would mean keep everything in that time frame, which I though might be useful. The format for the time frames and intervals is the same as for -keep-time: s=seconds, m=minutes, h=hours, d=days. For the three time frames above that would be 1d:1h,30d:1d,90d:2d Is there any preference for the format of the option parameter? I'd go with a comma seperated list where the values of each pair are seperated by collons. How would you expect the time frames to behave? Should each time frame always count from day 0 or does the 30 days time frame mentioned above start after the 2 days time frame and the 90 days after that, effectivley resulting in 2, 32 (2+30), 122 (2+30+90) days as time frames? Coming from Crashplan and their wording in the GUI I'm kinda biased and would chose the first option, meaning the 90 days time frame really ends at 90 days from 'now'. Here are some things maybe worth discussing: I don't really like the idea of having to specify the amount of backups to keep, since that doesn't explicitly say anything about how distributed the backups should be within the time frame.

for 90 days : keep backups in 2 days interval.

for 30 days : keep backups in 1 day interval.

for 2 days : keep backups in 1 hour interval.

The idea is to add an advanced option 'keep-staggered-versions' which allows the user to specify multiple pairs of time frames and intervals.

I decided to go with the easier Grandfather-Father-Son method as mentioned above. Though before writing any code, I'd like to hear a few opinions from other potential users of this feature: )ДЄlright, so want to give implementing this a try. If you need versioning that bad, setup a git repo to track changes on versions. I'd say the chance of needing a 'version' of a file that is outside your normal retention policy, but with your 'version' policy, is slim to none. If they are, well then you don't need to worry about losing the versions, they'll be in the backup sets. If I make 5 edits in 1 day, unless I had backups run multiple times during the day to catch each revision, they won't be in my backup sets. Unless you are running backups at an extremely frequent rate, the likelihood of actually grabbing all file versions, is low. I would also make sure to separate the use of the word Version for it's true meaning whether related to actual snapshots (in which case that's what we're talking about with G-F-S method) vs File Versions akin to things like MS OneDrive or Google Drive individual file revisions. That's a recipe for disaster and tracking becomes difficult. Versions aren't tracked in the backups as I saw some comments on other threads of similar idea to mix/match. It fits all broad sorts of use cases for folks. Alternatively you can still achieve maintenance of Infinite with all 0's, or just straight dailies for 365 days to equate a single year worth of EVERYTHING. We use this exact mechanism to limit backups so that you can retain dailies for X period, weeklies after that for X period, and monthly after that for X period. I currently work for an organization who sells an Enterprise Only Cloud based backup solution (hence I can't use it at home for free).

This is exactly the grandfather-father-son methodology that most modern backup softwares employ.

Backup scheduler for time machine 1 6 1