Retention points vs. retention days

[RubinCompServ]

With the upcoming release of v13.1, we're starting to prepare for our upgrade from v12. One of the changes that has our customers concerned is the forced move from retention points to retention days. Often times, they'll configure one-off (or manual-run) backup jobs because they need/want to keep a VM at a certain point in time (compliance, audit, dev/test, etc) and they're concerned that they'll lose some required points unless they configure a crazy-long retention time, which then sticks them with unnecessary points. Another concern is that if a job is configured for 14 days of retention and fails for 2 days (e.g. over a weekend), they're going to lose the 2 oldest points, which drops them below the 14 restore points that they want to actually keep. Finally, they're concerned that retention for their weekly/monthly/yearly backup jobs will become less clear as, instead of saying "Run yearly and keep 7 points", they're going to have to say "Run yearly and keep 2562 days", which isn't nearly as clear.

Does anyone else's customers have any of these concerns? If so, how did/do you address them?

[david.domask]

Hi RubinCompServ,

Few points here:

1. Note that day-based retention always keeps at least 3 restore points by design. (Configurable with a config parameter), so even for a one-off job, you will keep at least 3 restore points.

2. For additional options for a one-off backup, consider VeeamZIP or Exporting Backups from an existing backup chain -- both can be used to create a standalone full backup (VBK) with or without retention as they desire.

3. For their long-term retention, why not use GFS? It sounds like it matches what they're looking for pretty solidly.

[RubinCompServ]

1. I wrote...poorly. When I said "one-off", I really meant "ad-hoc" (as opposed to scheduled), where they run it before various events, but need to keep more than just the three recent points

2. This brings us to a limitation of the Veeam Self-Service portal. We are a vCD provider and present our Veeam backup environment to our customers via the Self-Service portal. VeeamZIP and backup export aren't available to the customer from there.

3. This would be exactly what they need, except that each GFS point is a Full backup. As we use XFS, that doesn't translate into a huge storage increase on our side, but Veeam sees it as consumed space and it reflects in their configured quota (within the Self-Service portal). For example, their 5TB of data may back up to 1TB of space. Keeping a monthly GFS backup of that will only use 1.2TB (on disk), but report as 12TB. Since we charge based on quota, they end up paying for an extra 10TB of space that they don't need and aren't actually consuming. What they're doing now is just creating a monthly that keeps 12 points. It only has a single Full so they're only consuming an additional 1.2TB, which is much cheaper than 12TB (even though it actually consumes more space than GFS).

[david.domask]

Got it, I think then the main blocker sounds like your reporting needs being hampered by the fast clone space savings. This is something we're reviewing for improvements as we've heard such requests from other providers as well, so request is noted.