[V13] Deprecated and Discontinued features for our 2025 release

[Gostev]

Dear all,

I wanted to share all changes to the existing feature set in our next major release (V13 in H2 2025) well in advance for your long-term planning purposes. For example, you may want to avoid implementing Deprecated features, and accelerate vacating Discontinued features.

Dropping unpopular, least used features is important so we don't spread our QA resources too thin as new features are added, ultimately helping with the overall product quality and enabling QA to spend more time on features that matter to the majority of users. While we strive to drop support only for unpopular features (according to our Support big data), we also consider high QA and Support costs of maintaining certain features, especially if those remain the source of continuous stability issues; as well as their compatibility with newly added capabilities.

Thanks!

Deprecated features
The following features will not be available in new V13 installation and/or for newly create jobs in the upgraded installations, however will continue to work for upgraded installations and/or in the existing jobs using these features. They will then be removed completely in V14. The main idea behind this approach is that we can potentially delay discontinuation of some feature in case we missed a critical use case (until we address this use case).

Veeam Backup & Replication
1. Reversed incremental backup mode.
2. Backup job retention based on the number of restore points (only time-based retention will be available).
3. Non per-machine backup chains (only per-machine backup chains will be available)
4. Active Directory based authentication for Veeam Cloud Connect tenants.
5. Restore options when double-clicking on VBK/VBM in Windows Explorer.
6. Sequential tape processing option (parallel processing will be a default behavior with automated failover to sequential tape processing when single drive is available).

Veeam Agents
1. Import/Export configuration to/from XML
2. Retention based on the number of restore points (only time-based retention will be available).
3. The ability to burn Recovery Media to CD / DVD.

Discontinued Features
Upgrade to V13 will be blocked in presence of the following:
1. Jobs with backup metadata still not upgraded to V12 format.
2. Backup Copy jobs still in legacy mode.
3. Full Veeam Agent for Windows installs prior to V6 (with LocalDB configuration database).
4. Veeam Cloud Connect Portal > https://helpcenter.veeam.com/docs/backu ... ml?ver=120
5. Universal Application-Item Recovery (U-AIR)

System Requirements
You may also want to review changes to the system requirements for the upcoming release.

[coolsport00]

Hi Anton -
This, and the Sys Req's forums post are great. Really appreciate the head's up!
Can you elaborate on the Retention item listed above. Are you saying for Jobs, Retention will only be only to be configured for "Days" and not "Restore Points"? Or, are you referring to some other feature I'm not thinking of?
Thank you.

[Gostev]

Hi, Shane. Happy you found this useful, I hope this helps many avoid unpleasant surprises!

Your understanding is correct. When you create a new backup job today, the default retention is time-based (Days) however you can also pick "restore point count" based option. The latter is going away in V13 with only time-based retention remaining. Many features already require/support time-based retention only (GFS backups, automatic immutability for the entire duration of retention policy, background retention of abandoned backup etc.) and V13 will have further enhancements that will require time-based retention. For example, we aim to significantly reduce the overhead of using immutability with object storage and this requires time-based retention.

[coolsport00]

Hi Anton -
Thanks for confirming. For a couple of my Backup Jobs, this is problematic. I back them up every 30mins by 'Restore Points' and, when the retention for those hit, I need them removed immediately for storage reclamation purposes...at least during certain times of the year. Most times, I'm fine, but certain times of the year (beginning of school yr at school district I work at), a significant amt of data gets added to a few systems causing change rates to egregiously skew causing Repo storage to near its limit. I've already done some things to limit this behavior, but still find the RP option better for at least these 2 Jobs. Once retention hits (i.e. a time during a given day, not wait for a whole next day), I need those RPs deleted to help maintain Repo storage. I guess I'm not fully "seeing" why the need to remove this other retention option...
Thoughts?

[Gostev]

Yes, this specific case of short retention for frequent backups is practically the only reason why I refused to remove this option for so many years (lots of people pushed to drop it sooner to reduce QA overhead), however realistically at this time too few customers are using backup schedule that is so frequent that daily retention is a problem + almost no other competitors ever provided such retention option either, while it is heavily incompatible with many new features as I explained.

[coolsport00]

Thanks for the info Anton. Appreciate it.

[edh]

Nice info shared aprecciate you share the roadmap for v13.

Regards

[chris.childerhose]

This is definitely some great information, Gostev. I like the fact that reverse incremental is going away, and the retention will be only "Day" based, not restore points. We have seen issues where restore point cleanup does not function well under the "Restore Points" option, and the "Days" option works very well. I'm looking forward to v13.

[dabrigo]

Thanks Anton for the anticipated roadmap, this will definitely help many of us to plan for the migration.

[MarkBoothmaa]

Does the change to time based retention apply to Replica's as well are is that a separate logic?

[Gostev]

It shouldn't, @Dima P. can you confirm please?

[Thonell]

Hey there,

Thank you for your amazing work!

I wonder about the following change "Sequential tape processing (only parallel will be available)". As we run multiple tenants on separate sets of tapes with a well planned schedule, will we still be able to allocate only one tape drive per job, allowing for running parallell tape jobs?

For the Enterprise Manager section "Veeam Cloud Connect Portal > https://helpcenter.veeam.com/docs/backu ... ml?ver=120, could you please verify this link as I fail to see the connection or maybe elaborate on the deprecated feature?

[Gostev]

The link looks correct to me. It opens a page with a screenshot of Veeam Cloud Connect Portal, which is exactly what is being deprecated, and the page itself is in the Veeam Cloud Connect Portal section of the User Guide.

[coolsport00]

Does the change to time based retention apply to Replica's as well are is that a separate logic?

Interesting...I don't really use anything special with my Rep Jobs...just my critical Backups.

[Thonell]

The link looks correct to me. It opens a page with a screenshot of Veeam Cloud Connect Portal, which is exactly what is being deprecated, and the page itself is in the Veeam Cloud Connect Portal section of the User Guide.

Ah I see, I got to the "Failover Plan" section so I got confused by the scope of the deprecation. But it's the the whole portal then, gotcha!
Page navigation: Veeam Cloud Connect Guide > Guide for Tenants > Using Veeam Cloud Connect Portal > Running Cloud Failover Plan

Thanks

[MarkBoothmaa]

Interesting...I don't really use anything special with my Rep Jobs...just my critical Backups.

I was thinking if they change to x number of days retention then hourly jobs will be impacted.

e.g. 12 x hourly restore points become 24 x restore points if you have 1 day etc.

[dabrigo]

Don't know if i got this right: the EM Cloud Connect Portal is being discontinued because the same functionality is available in the VSPC?

[Gostev]

The primary reason is rather that no one is leveraging it some providers use VSPC and other integrate failover management directly into their existing customer portal.

[Dima P.]

Does the change to time based retention apply to Replica's as well are is that a separate logic?

This change affects only backup jobs across all the workloads. Replication jobs will continue to have restore point based retention option.

I wonder about the following change "Sequential tape processing (only parallel will be available)". As we run multiple tenants on separate sets of tapes with a well planned schedule, will we still be able to allocate only one tape drive per job, allowing for running parallell tape jobs?

Whenever you have a single drive we automatically failover to sequential tape processing, as there is no other way to process tapes anyway.

[b.vanhaastrecht]

Whats the reason for dropping Veeam Agents / Import/Export configuration to/from XML? Will there be an alternative? We use this to deploy config options who are not yet or will never be available when the Agents are managed thru VSPC.

[mkretzer]

3. Non per-machine backup chains (only per-machine backup chains will be available)

Thank you for this post! Up until today we were evaluating non per-VM for backing up clustered systems. Deprecation would mean effectively there would be no way to get dedup between machines.
In our test the benefit was not very high - is this the reason for deprecation?

[JeroenL]

Yes, this specific case of short retention for frequent backups is practically the only reason why I refused to remove this option for so many years (lots of people pushed to drop it sooner to reduce QA overhead), however realistically at this time too few customers are using backup schedule that is so frequent that daily retention is a problem + almost no other competitors ever provided such retention option either, while it is heavily incompatible with many new features as I explained.

We backup OT environments using manual backups simply because changes to the OT systems are not very frequent or require cold backups with human interference. Backups are not created using a schedule. Only before and after a change are new backups created. Sometimes there are 3 months or even a complete year between backups. We want to make sure we have at lease one previous situation on disk, so with 6 restore points we are always safe.

With the restore points option gone, we can no longer easily manage the amount of restore points. Please do not depricate this feature.

[bhlgr015]

Couple of comments from our usage of certain features mentioned in this update.

1. Reversed incremental backup mode.
This is something we have always used for the last 10 years, I found it easier to have a single last good file. We currently have reverse incremental on most if not all our main backup jobs, then we have copy jobs to clone this to a external repository but I think the key reason for reverse incremental for us was we then have a daily tape archive which takes that full backup (no incrementals needed) and puts it on a single tape. This means should we have a complete disaster we know we have the lastest full backup on tape without having to worry about incrementals, chain of tapes etc..

Is there an easier way since we set this up all that time ago?


2. Backup job retention based on the number of restore points (only time-based retention will be available).
While not a huge issue, its going to potentially be a little annoying. Currently we have all backup jobs based on number of restore points. This is because our data is pretty consistent with gradual increases in data. This means we know roughly how many full backups and increments our backup storage can handle. If we do a few occasional ad-hoc backups outside of the normal schedule we know that we wont struggle with space because the oldest increment will be replaced. Now if we move to time based, this wont happen and we could potentially run out of storage due to oldest increment wont be removed. The reason for this is because if I have a backup storage pool I am going to maximize the amount of restore points I can fit in that pool. Why waste storage space not being used when i can get more restore points should I ever need it?

5. Restore options when double-clicking on VBK/VBM in Windows Explorer.
Was nice to have sometimes rather than going into the gui and finding the restore point within this. Not a big deal just convinient.

2. Retention based on the number of restore points (only time-based retention will be available).
Same as above I guess, we dont use many agents as we are not using VUL

3. Remove the ability to burn Recovery Media to CD / DVD.
Was always something we had done as part of our DR solution, Pressume this is replaced with USB/ISO options? I guess we need to consider bit rot if using flash media as cold storage.

2. Backup Copy jobs still in legacy mode.
Might be a dumb question, how do we know if our copy jobs are in legacy mode?

Appreciate the comments.

[X-ian]

Hi Anton,

thanks for prioviding such information upfront. As bhlgr015 stated, we also use reverse incrementals to copy the most recent state to a single tape. The whole chain will likely not fit onto a single tape. Is there any software-side alternative instead of purchasing a second tape drive, changing the tape during backup or reducing data so that the whole chain fits into one tape?

[Dima P.]

Hello folks,

Whats the reason for dropping Veeam Agents / Import/Export configuration to/from XML? Will there be an alternative? We use this to deploy config options who are not yet or will never be available when the Agents are managed thru VSPC

The alternative is to use either Veeam B&R Agent Management or VSPC. Can you share why it's not possibly to manage those agents centrally?

Thank you for this post! Up until today we were evaluating non per-VM for backing up clustered systems. Deprecation would mean effectively there would be no way to get dedup between machines. In our test the benefit was not very high - is this the reason for deprecation?

Retention logic does not affect deduplication, possibly you are referring to pre-vm storage? If yes - single storage will be still used by agent failover cluster backup job as that's the only way to effectively store cluster disk without duplicating it across multiple independent backups.

Thank you!

[Dima P.]

Jeroen,

Sometimes there are 3 months or even a complete year between backups. We want to make sure we have at lease one previous situation on disk, so with 6 restore points we are always safe.

If you take the backups for such system occasionally I'd recommend switching to VeeamZip, GFS or at least take an active full when such restore point is needed.

[mikaeln]

Yes, this specific case of short retention for frequent backups is practically the only reason why I refused to remove this option for so many years (lots of people pushed to drop it sooner to reduce QA overhead), however realistically at this time too few customers are using backup schedule that is so frequent that daily retention is a problem + almost no other competitors ever provided such retention option either, while it is heavily incompatible with many new features as I explained.

Hi Gostev,

the "significantly reduce the overhead of using immutability with object storage" is removing the added retention days for " immutability period" in the "Actual retention = job retention policy + immutability period + Block Generation period" ?
We moved to Object Storage and are see a about 50% increase in storage usage compared to Hardened Repositories.

In connection with Object Storage, any improvements regarding Block Generation?
Right now it is performed before backup starts ( Storage initialized ) which delays the start of the backups. For large backup with lots of objects this can be hours which breaks approved backup schedules which can be tight to work around customer needs.

Best regards,
Mikael

[Dima P.]

1. Reversed incremental backup mode.

key reason for reverse incremental for us was we then have a daily tape archive which takes that full backup (no incrementals needed) and puts it on a single tape.

You can point such jobs to a GFS media pool with weekly media set enabled. Such configuration will create a full backup on tape for the set day even though there is an incremental backup on disk. Alternatively for a simple media pool with incremental backups as a source you can leverage virtual full backup to tape please take a look - Virtual Full Backup.

2. Backup job retention based on the number of restore points (only time-based retention will be available).
Why waste storage space not being used when i can get more restore points should I ever need it?

With daily retention you archive the same by stretching the needed retention to a longer period.

3. Remove the ability to burn Recovery Media to CD / DVD.
Pressume this is replaced with USB/ISO options?

Yup, USB/ISO are already available.

2. Backup Copy jobs still in legacy mode.
Might be a dumb question, how do we know if our copy jobs are in legacy mode?

Search for 'legacy backup copy job' at the job type column at the Home > Jobs > Backup copy. These are interval-based periodic backup copy jobs.

[nathano]

Hey there,

Thank you for your amazing work!

I wonder about the following change "Sequential tape processing (only parallel will be available)". As we run multiple tenants on separate sets of tapes with a well planned schedule, will we still be able to allocate only one tape drive per job, allowing for running parallell tape jobs?

I was thinking about this as well.. we do tenant to tape on our cloud connect so it could be a bit different on non cc VBR. Anton, will there still be the option on the media pool to select the number of tape drives to be used simultaneously? If there is then that can effectivly force sequential. but if that goes away and the only behaviour is for the media pool to use all drives in the library then I think we will have some problems.

[Dima P.]

Hi Nathan,

will there still be the option on the media pool to select the number of tape drives to be used simultaneously?

Sure. Simply put, v13 will have the first checkbox checked and removed from UI while the rest of the functionality remains.