Maximum number of rollbacks

[aqualityplace]

Is there a limit to the number of rollback points veeam will support? Thinking of performing a backup every 4 hours with a rentention of 14 days, so that should be 84 rollbacks sorry if my maths is wrong

[Gostev]

There is no known limits (if we are talking about reasonable numbers and scenarios). One hundred or less is certainly fine. Thanks!

[Bunce]

On this topic, wondering if Veeam has considred expanding the flexibility of its retention policy by implementing a 'purge' facility similar to that of a competing product?

This could offer the following advantages:
- Better support for organisational retention policies (eg maintaining daily's for the past x weeks, maintainin weekly's for the past x months, maintaining monthly's for the past x years, etc)
- Matching retention to 'time' as opposed to a set 'number of rollbacks' which could vary depending on how often backups are performed
- Negates the necessity to setup complex schedules / multiple jobs / manual deletions to achive a particular retention policy similar to the above.
- Automatically frees up space on backup targets instead of wasting that space on old rollbacks that are no longer required (eg We wouldn't require the daily backups from 2 months ago as long as we had our weekly's from that month)


A

[Gostev]

Yes, we are considering this feature for future releases.

[matthadley]

So, for a point of clarification, is there a way, even indirectly, to accomplish a tiered retention approach today within a specific replication job?

Consider the following:

I would like to run a replication job every fifteen minutes, but I only want to keep one retention for each two-hour window, for the first day, and one retention per day for seven days back.

If there isn't a way to use Veeam to accomplish this directly, might I call a script, of my own design, at the end of each job run, that scans the VBK files, in the replica folder, and deletes those that match my script's criteria? While I am not excited about running a script to purge VBKs, outside of Veeam, I don't mind doing so if that is my only choice and if it is technically OK -- i.e. Veaam's process won't mind having certain VBKs purged outside of its control.

If yes, I can easily set the retention count high enough to insure that I purge the VBKs rather than Veeam.

Yes? No? Thoughts?

Thanks,
Matt

[Gostev]

Matt, no - this is definitely not possible today. This would require merging reversed increments files, and you cannot do this with script. Thanks.

[matthadley]

Ok, then I look forward to having this feature added in the future (as soon as possible )

For now, I am struggling with how I might accomplish a near-CDP replication and yet keep enough retentions to prevent getting caught in the squeeze: an error occurs inside the VM that requires we revert back to an older instance, say 96-hours, and we haven't accounted for such a large retention count.

For example, if I wanted to achieve a 10-minute near-CDP cycle, with a four-day look back (to account for issues that might have occurred over a weekend or other extended period), I would have to keep 6/hr x 24hr/day x 4day = 576 vbks. That's a big number. Is that realistic?

Matt

[vbussiro]

I would set up one job for each "period". every 10min during a day, every 3 hour during 4 days, if there's a way to stop the "10min job" during the "3hour" backup. Need more storage, but with only with 104 rollback max in a job. By the way, do you know the max period covered by block tracking ?

[Gostev]

Matt, in order to revert a few days back customers usually use their daily backups. If the issue is not recognized in a few days, this usually means you do not really have any rush to revert, and can take time to perform regular restore. Near-CDP protection is usually days to cover time span between daily backups. But I agree this feature is useful in all cases (even for backups).

vbussiro, there is no limitation for time period with changed block tracking.

[smeilicke]

Yes, we are considering this feature for future releases.

Yes, please consider this feature. The lack of it is holding me back on this product.

Are there any suggestions on mimicking this behavior? Separate jobs for each type of retention, ex)
Daily job: Run backup 1/day for 14 days
Weekly job: Run backup 1/week, keep 5 copies
Monthly job: Run backup 1/month, keep 13 copies
Yearly job: Run backup 1/year, keep 3 copies

Are their concerns for

Pretty inefficient for dedupe?

Any other ideas?

Thank you!

[smeilicke]

OK, after thinking about this for more than a few minutes, will enabling CBT make this not work? If the same set of servers is in all four jobs, it seems like CBT would get confused about which blocks to copy over so that, for example, a monthly backup has all of the required blocks since the last monthly backup. It also looks like I would have to manually schedule this type of scheme with the windows scheduler, correct?

Thanks!

[Gostev]

Hello Scott, no - CBT is definitely not a concern here, with Veeam change IDs are tracked separately for each job, so you can backup the same VM with any number of jobs.

[smeilicke]

Thanks Anton, much appreciated.

-Scott