How do I do keep a specific number of restore points without regular backups (v13)

[RubinCompServ]

With v13 removing the ability to configure retention based on points, how can I keep a specific number of restore points on a backup job that isn't run regularly?

Usage case:
We have a team that applies patches irregularly to one of their servers, and they run a backup of the server before applying the patches. In the current configuration, this allows them to keep the last 5 versions of the server, regardless if the oldest version is from 2 weeks ago or 6 months ago. In the new configuration, they either have to configure an absurdly-long retention period and risk having many more points or configure a much sorter time and risk not having sufficient points.

Variation on the theme:
We have a number of Financial-sector customers who perform multiple backups per day. Sometimes, one of those backups fail. When that happens, they don't want the oldest backup to drop off. In the new configuration, all of the oldest backup will drop off every day, regardless of the number of failures during the day.

In the original [V13] Deprecated and Discontinued features for our 2025 release thread, @Dima P. suggested "VeeamZip, GFS or at least take an active full", which all present a problem:
VeeamZip: We have a vCD environment and access to backups is presented via the BEM Self-Service portal. VeeamZip doesn't exist in that environment.
GFS: This doesn't resolve anything, as there remains the virtual guarantee of having too many/too few points
Active Full: In addition to this still being subject to the retention policy, this will also require a substantial amount of time to run

[tommy.oshea]

According to the Veeam Help Guide, the minimum amount of restore points held while using the "Days" setting is 3. You can change the minimum number of retained restore points with a registry value. You need to contact Veeam support to get this registry key.
However I assume this would be applied to the entire Veeam server, and not configurable on a per-job basis like you'd probably prefer.

[Gostev]

Unfortunately, you cannot keep a specific number of restore points on a backup job with V13, as the only option for automated retention is time-based.

However, you can use the existing Export Backup functionality to create an independent backup file from any required restore point which will not be a subject to any retention policy. And if you use a backup repository with block cloning, then such backup will not require extra disk space nor a substantial amount of time to run.

Besides, I believe we always had functionality where the last N restore points are never deleted, in order to prevent all existing backups from being deleted in a situation where backup job does not run for extended time for whatever reasons. However, I will need the responsible PMs to confirm this functionality still works and what N is by default (pretty sure it's 3 and that there's a registry value to control it).

P.S. Oops, Tommy has beaten me to that.

[RubinCompServ]

However I assume this would be applied to the entire Veeam server, and not configurable on a per-job basis like you'd probably prefer.

This creates a new problem for customers who configure a backup job to run weekly and keep 4 weeks.

GFS doesn't fix this problem because, even though the "extra" fulls don't actually use additional space on the storage, they do count against the configured quota in BEM.

you can use the existing Export Backup functionality to create an independent backup file from any required restore point which will not be a subject to any retention policy.

No I can't because the only functionality exposed to my users is via the BEM Self-Service portal, which AFAIK doesn't offer that (which is good, because I don't want them trying to download a multi-TB file).

[Gostev]

It certainly should not create any significant new problems because all your current jobs are subject to this logic already while one could imagine corner cases like you did where it results in an extra restore point kept, but these are very much exceptions and not what vast majority of users are doing as far as typical retention policies.

In any case, in V13 this *is* the best answer for what you're trying to achieve.

[RubinCompServ]

My jobs aren't subject to this logic today (more specifically, this logic isn't relevant today) because all of my jobs use Restore Points for retention, not Days. As for "imagining corner cases", the cases in my original posts are actual cases that exist in my production environment; no imagination required.

Other cases that exist in my environment today:
I have a customer who has an backup job that runs once a year and they keep 7 points. In the new and "improved" methodology, they'll have to set retention to ~2560 days.
I have a customer who has a job that runs once a month and keeps 12 points. In the new system, they'll have to set it to 365 days. Which isn't a big deal except when their monthly job doesn't run for some reason (because, let's face it, sometimes things break) but the earliest restore point will drop off anyway (because it's been over 365 days) and now they only have 11 restore points.

[Gostev]

Ah, now I see the issue. Your comment indicates general lack of understanding of time based retention and GFS backups. I suggest you book a session with one of our SE/SA through your Veeam sales rep so they could guide you through these basics, as it's too much to unveil in forum posts. Because specifying "2560 days / 365 days" is absolutely NOT how your should set up desired retention policies.

[RubinCompServ]

I understand GFS. But GFS has issues when using quotas because, as I've already stated, Veeam can't tell the difference between "actually used" space and "claimed used" space, so a GFS backup that holds 12 Full backups may only consume 5 TB on disk but will consume 60TB in their quota. Allow me to demonstrate:

Customer A requires 14 dailies, 4 weeklies, and 12 monthlies. Just to keep the math easy, we'll say that every Full backup consumes 5TB and every Incremental consumes 500GB
They currently have 3 different jobs:
Job A1 runs every day and keeps 14 restore points (11.5TB)
Job A2 runs every Sunday and keeps 4 restore points (6.5 TB)
Job A3 runs on the first day of the month and keeps 12 points (10.5 TB)
After 1 year, BEM reports that they are using 28.5 TB of space. They pay us for 30TB of space and everybody is happy.

Now let's change that to a GFS model:
Daily still keeps 14 restore points (11.5TB)
GFS keeps 4 weekly Fulls (15 TB)
GFS keeps 12 monthly Fulls (55 TB)
After 1 year, BEM reports that they are using 81.5TB

Now, we all know that both cases are consuming around the same amount of space on disk (probably around 12-15TB due to dedupe). But in the seconds case (GFS), they would need to be allocated ~82TB of space instead of the 30TB in the multi-job case, because Veeam can't see actual use, just OS-reported use. Needless to say, customers would rather pay for 30TB of space than 80TB of space.

If it wasn't for this quota issue, I'd agree with you - GFS makes much more sense (in most cases) than multiple jobs for different retention types.

[RubinCompServ]

Once again, the above case is a real customer, not an imagined scenario. "Customer A" is an actual customer of ours with backup jobs built out as I described (I lowballed the storage just to make the math easy; BEM actually reports that they are consuming over 180TB of space today). We went through this exercise when they asked us for assistance improving their backup footprint. We immediately said, "Why don't they get rid of the multiple jobs and just use GFS?", and then we did the math. Seems like just another case where Veeam adds a feature and then later says, "We don't want you to actually USE that feature".

[Gostev]

BEM quotas discussion is off-topic. If you wish, please create a dedicated topic about GFS and BEM quotas interaction, as it's not specific to restore point based retention removal, but is rather how BEM works with GFS backups even in the current version. The responsible PM will need to review and comment whether there are any plans to change the current BEM quotas behaviour.

Reiterating the answer to the original question for future readers before closing the topic, so it's not lost.

Q: How can I keep a specific number of restore points on a backup job that isn't run regularly?

A: This happens automatically. The last 3 backups are never removed, and this value can be changed with a registry value.