Similar functions like RPS Dewin

When you schedule fulls (synthetic or actual full), it picks up the retention on the day it was created.   In short it does not change the chain length (but it does change the chain size).

So if you have retention as daily 30.  normally there would only be 1 full in the chain (unless you scheduled others).   The chain is still 30 days.

weekly, monthly, yearly retention are GFS.   It can get confusing as to where are these GFS points (actual day), as it varies based on repository type.   For example in object storage these will be on the day the GFS is marked/scheduled, vs. other repo types it may be the nearest earlier full that was created will be marked for this GFS.   The GFS point will have the longest retention for the GFS point based on the longest GFS schedule that uses/marked it.

Eric,

You just described a chain with 30 days with forever forward incremental. That doesn’t describe periodic weekly and/or periodic monthly. If you have 30 days with weekly fulls, your chain will not be 30 days/points. Also, days and points matter in this too so that’s another thing to consider. 

For weekly, set at 30 points (sticking with points as it’s easier to calculate)

You’ll have 

1 Full + 6 Incrementals - 7

1 Full + 6 Incrementals - 14

1 Full + 6 Incrementals  - 21

1 Full + 6 Incrementals - 28

1 Full + 6 Incrementals - 35

That is 35, until the previous chain falls off as 30 points doesn’t matter with weekly + dailies as it’s 7 per chain at that point. RPS Dewin accounted for this and also accounted for throwing in monthly, without GFS. --If you hover over the info button for the retention, it indicates weekly fulls by default. GFS is a whole other beast when it comes to calculating the points, but I’m referring to simple retention, not GFS :)

What I don’t see stated in this discussion is for weekly or monthly points, what are their retention?  (this would be the GFS setting or it will be the picked up daily retention).

So you can have a Job that is 30 days retention.   This job may for forever forward or forward incremental  - it depends on if fulls were scheduled or done manually.   regardless, there is 30 days of retention for *all* points.

So discuss the retention for weekly or monthly - these are GFS settings.   and I agree the chain will be longer / there will more retention points.    Yes there can be a few more due to intermediate dependencies on the fulls, but that will be the next rounding based on the full schedule.   The point being schedule fulls alone does not change retention of visible points.

I agree the chain behaves differently due to active vs. inactive chain, and that is related to the full schedule pattern.

This all get even more complicated if you turn on immutability and depending on what type of repository it is.

Eric,

There is short-term retention and then GFS (long term retention)

https://helpcenter.veeam.com/docs/backup/vsphere/forward_incremental_backup.html?ver=120

https://helpcenter.veeam.com/docs/backup/vsphere/retention_policy.html?ver=120

https://helpcenter.veeam.com/docs/backup/vsphere/gfs_retention_policy.html?ver=120

Short-term retention removes the fulls when the points or days reaches what it is set to be (depending on points and if able to drop the chain or not) whilst Long-term retention ignores the short-term retention because the weekly/monthly, etc are flagged as such. GFS is not related to the initial inquiry as you can use short-term retention using synthetic or active (or both even) weekly or monthly. I’m not sure you’ve used rps.dewin but we had checkboxes that allowed you to incorporate these configurations, completely outside of GFS. GFS is not standard retention or short-retention. Adding immutability and the like isn’t really relevant to the inquiry (Feature request) either. You can use wayback machine to find rps.dewin.me to see what I mean by this. You can’t run simulation because the backend is gone but you can see all the configurations I am speaking of.

Thanks

ok. 

I think sizing based on chain length will not be very accurate.

Running fulls outside of GFS either is done by pattern (which GFS could do), or it is  ad-hock.

You can look at active chain lengths, which if you have regularly schedule weeklys will add on average 7/2 days, but it really has a min/max of 1 day or 7 days based on cyclic behavior.  If retention is consistent (say 30 days) the monthly won’t matter for adding days if you are running regular weeklys.

In short, I don’t understand if you are not using GFS, how you are extending retention beyond the daily setting.   In that case it falls back to the shortest full schedule (weekly) is driving the active chain (at its longest) and you have the averages / min / max mentioned above.

I am of the view that everything should be immutable, so that is why I bring it up if working this sizing exercise.

​@a-a-ron, I took a look a the calculator earlier today and found the same thing, it seems to force the assumption of a forward incremental chain with a weekly full, with no option to set it to a forever forward incremental chain.

I agree that the rps.dewin.me calculator had that functionality and the current calculator is lacking in that respect. It sounds like a feature request or a post in the R&D forums may be in order.

Hi ​@a-a-ron , not sure about the described scenario..do you want to size legacy repo, right?

To answer your question, what is your definition of a legacy repo? Non-object storage? Non-immutable? 

I mean legacy block-storage repo (no xfs/refs, no dedup, no immutability, no object storage)

​@marco_s ,Calling those a legacy repo would imply that they are no longer supported by Veeam as backup targets, while they actually are. Yes, xfs and refs would certainly make a big difference in actual storage use, however even on the old calculator, those were accounted for and visualized.

​@a-a-ron has identified missing/reduced functionality in the new calculator. Hopefully that can be addressed. 

Just as Tommy pointed out, calling those legacy mean it’s outdated and will be dropped. In fact, xfs/refs is still using your ‘legacy’ but includes fast/block clone. Retention is very much the same. Dedupe as well, that has no functionality on retention as it’s simply deduplication. But again, this wasn’t a sizing scenario but seemingly turned into one. I know how retention works 😎

I didn’t notice the “Veeam Employee” badge.. 😅 ​@a-a-ron