Restore points functionality question - historical data

[KRobinson]

Good afternoon,

(If this has been covered elsewhere already, please point the way. I did a quick search but didn't find anything that seemed relevant.)

I've recently started with Veeam, and am loving what I see so far, with one sticking point. I'm coming from a StorageCraft and PHD background as those were used at my previous employer and I opted for Veeam instead of those for my new employer's new server build-out.

My question is on the historical retention of data. With both PHD and StorageCraft, when using their continuous incremental backups, after the first full backup completed it would build incrementals from there on out. We could specify to keep a certain number of restore points going back far into history with both products (for example, keep all snapshots taken during the day for the last 2 weeks, keep daily snapshots for 28 days, keep weekly snapshots for 28 weeks, keep monthly backups for the last 24 months). This way, we had file restore capabilities going back quite some time without the need for additional historical archive tapes/drives.

So far, I haven't found this capability in Veeam's B&R program, although I may just be missing it. I've mainly played around with the reverse incremental backups, where it seems I just specify the number of restore points I want - if I want to take snapshots every 4 hours, I'd need to specify 120 restore points (6/day x 30 days) to keep the last 30 days available for file restore should an employee screw up and not notice that they deleted a file for a couple weeks as there doesn't appear to be a way to merge or compress old restore points to consolidate them into daily/weekly/monthly snapshots.


Thanks,
Kyle

[foggy]

Kyle, you're basically talking about GFS type of retention, which is implemented in Veeam B&R in the backup copy jobs. Thanks.

[KRobinson]

Kyle, you're basically talking about GFS type of retention, which is implemented in Veeam B&R in the backup copy jobs. Thanks.

Eureka! I was looking for it to be built into the main backup job settings somewhere as opposed to a separate process (although it's sort of a separate process in SC, too).

So, I can run my normal backup job and keep a limited number of restore points with it, then run a separate copy job where I can build up the historical archive. Does this work with the main backup job being reverse incremental or do I need to move to a forward incremental to use the backup copy job?

[Gostev]

Primary backup job can use any backup mode. And by keeping the process separate, we are "forcing" the users to create at least one copy of their backups (our experience shows that not everyone understands this to be a mandatory requirement in backup).

[Bunce]

Veeam 'forcing' their customers again without providing choice. Disappointing and unprofessional.

[Gostev]

If being called unprofessional is the price I have to pay to ensure my customers can recover their data when they need to, then so be it... but in the past 8 years, I've seen way too many customers come to support with their one only backup set lost or corrupted, and this course was the easiest way to ensure people create at least one independent copy of their backups.

Options are certainly nice, but we can't have an option for everything, as it increases the number of test cases and bugs exponentially. So, any option requires serious justification in terms of amount of requests before we consider adding it. And this particular one has been hard for our users to justify: typical explanation why people want GFS in primary job is "because we don't want (or have space) for a copy of our backups". Well, I'd rather have this type of folks fail with some other data protection vendor, honestly. But if you have a different use case for this functionality, then please do share.

Remember that we build Veeam B&R to support our reference architecture, and all decisions are taken with this architecture in mind. That's the story we believe in, stick to and keep enhancing, instead of jumping back and forth like competing vendors. Particularly, from reading the blog post is should be obvious why GFS on primary storage makes no sense with our reference architecture. But then, why give users an option allowing them to implement our product in a sub-optimal way that will additionally cause them various issues in future (which they may not even be thinking about right now due to lack of experience with our product, or with backup in general).