Group: Forum Members
Posts: 14K,
Visits: 82K
|
Hey Danilo,
Interesting idea, although this would definitely require some care in terms of how it's built into the interface and explained to users, because I see a lot of possible confusion on this -- even the current retention policy functionality generates a fair number of questions! For example, in your scenario above, you said you were using a retention policy of 3, and yet Reflect built 4 Incs in your original set, and 7 total, before it actually purged anything. I understand why that's the case because I personally understand what you're trying to achieve, but an average user likely would not.
The option that your design is looking for would basically say, "Purge previous Incremental sets when X Incs exist in the most recent set." But here's another case to consider: I know this isn't true for you, but what if someone wants to retain the child Incs of multiple previous parent Full/Diff backups? For example, they capture monthly Fulls and daily Incs, they want to retain 6 Fulls, but want to keep the Incs from the last 3 Fulls (without ever merging), rather than only keeping the Incs from the most recent Full? Now this "alternative Inc retention strategy" would have to allow the user to specify the number of Incs that have to exist in the latest set before purging any previous Inc sets and how many Inc sets to retain when the purge occurs. So maybe a new "Incremental Sets" retention setting would appears underneath the existing "Incrementals" setting when this proposed "Merge Incrementals" option is unchecked.
Or maybe a better way to convey this option would be using a dropdown -- for example: Name: Incremental Retention Strategy Option 1: Consolidation (purge one Inc at a time) Option 2: Set Purge (purge all Incs with common parent together)
|