[V13] Deprecated and Discontinued features for our 2025 release

[TDog]

To better prepare for these changes, can we pull any of this the depreciated/discontinued features through VSPC, or would we have to use a powershell script to pull it per client? I think we should be pretty good, but it would be a good way to double check.

[JustinIzzard]

Veeam Agents
1. Import/Export configuration to/from XML

How does this affect using protection groups with pre-installed agents (https://helpcenter.veeam.com/docs/backu ... ml?ver=120)? We manage the majority of our Veeam Agent installations with our config management platform rather than within the Veeam Console. Since the protection group configuration file is XML, will we still be able to use the commands below to configure the pre-installed agents with the <protection_group_name>.xml configuration file?

• "C:\Program Files\Veeam\Endpoint Backup\Veeam.Agent.Configurator.exe" -setVBRsettings /p:"<protection_group_name>.xml" (Windows)
• veeamconfig mode setVBRsettings --cfg <protection_group_name>.xml (Linux & Unix)

[dpeach01]

I can't wait to hear the reasons why you would nerf your flagship product so drastically.

Reversed incremental backup mode. I won't waste time explaining the benefits of Reverse incremental backup strategy. I have to believe that Veeam decision makers know this already. My specific need is the fact that there are not enough hours in a day to conduct full backups on at least one of my filesystems. It is over 14 TB and growing. It takes several days to get the initial full backup. If I ditch Veeam and just do a protection domain replication synch, I can get a full copy over a weekend, but that kind of defeats the purpose of using Veeam doesn't it? Maybe there are good arguments for not using forward, but it should be my decision at the end of the day, not yours.

Reversed incremental backup mode. Really? What If I have a requirement to keep a defined number of RP's? Same comment as above. Why would you do this????

Sequential tape processing option - I'm starting to see a trend here. With the size of the aforementioned backup, I need a dedicated tape job to keep it up without aborting my primary backup jobs. I bought a separate drive specifically for this purpose.

Hopefully support for v12 won't go away for a long time.

V13 looks like a non-starter.

[Dima P.]

can we pull any of this the depreciated/discontinued features through VSPC, or would we have to use a powershell script to pull it per client?

Not aware of such functionality but possibly @Vitaliy S. can help.

How does this affect using protection groups with pre-installed agents

It does not affect Agent Management functionality or agents managed by VSPC, only standalone agent deployments.

[Vitaliy S.]

To better prepare for these changes, can we pull any of this the depreciated/discontinued features through VSPC, or would we have to use a powershell script to pull it per client? I think we should be pretty good, but it would be a good way to double check.

Unfortunately, it wouldn't be possible to run it through VSPC as not all deprecated features can be detected by the Console at the moment. Given that it is a one-time operation, then I would start checking remotely managed clients one by one via PS script (without waiting for the Console option to appear).

[coolsport00]

@Dima , @Gostev -
So in moving forward, how does one go about configuring Jobs to backup more than once a day? I not only have 30min Jobs, but 4hr Jobs as well. I guess in the Schedule?...using the "periodically" setting, as I currently do? But, I'll just have more backup files on disk than with the Restore Point setting?
Thanks.

[chris.childerhose]

I think the schedule and periodic setting would be the way to go, Shane, for each of the jobs that need to run more often. That is how I would do it.

[coolsport00]

Thought so..thanks Chris.

[Gostev]

Correct, the only change is that now you have to keep a minimum of 1 day worth of backups. Arguably you NEVER want to have less than a few days of backups anyway, otherwise you will lose all backups to a smart attacker who initiates the attack on Friday night specifically so that no one mentions it until Monday (which is extremely common approach).

[daniel.rajczewski]

Hi,
all sounds nice
I using VBEM for Password loss protection for encrypted backups.
This function will be enable in different product?

[Gostev]

Hi, Daniel. Not sure what deprecated or discontinued feature are you referring to with your question, could you clarify?

[tthomas1@ebsco.com]

Gostev,

Thank you for this extremely useful post. Regarding retention, we use restore point-based retention on all our jobs for a simple reason: our monthly full backup, which runs on Friday night, frequently spills over through the weekend and even through Tuesday or Wednesday of the following week. By using restore point-based retention, we ensure that we always have at least 14 snapshots to restore from regardless of how long the monthly job takes. If it's time-based on 14 days rather than restore point, we might end up with 10 or 11 a couple of weeks into this month.

When we upgrade, will the existing restore-point-based retention setting remain [with the ability to configure new jobs that way removed] or will we need to change it to time-based ahead of time?

[nd39475]

no mention of any PostgreSQL migration requirements. Will v13 still support existing MS-SQL databases?

[Maurice]

You can find this in the "[V13] System Requirements..." Post:
"SQL Server: dropping support for SQL Server 2012 and 2014; minimum supported version is SQL Server 2016."

[gtelnet]

Thanks for all the great info, Anton!

Re: "only time-based retention will be available", does this only affect Backup jobs or will it affect Copy jobs as well? Thank you!

[daniel.rajczewski]

Hi, Daniel. Not sure what deprecated or discontinued feature are you referring to with your question, could you clarify?

Is Veeam Backup Enterprise Manager will be further developed in version 13?

[Vitaliy S.]

Is Veeam Backup Enterprise Manager will be further developed in version 13?

You will be able to continue using it as you're doing it now (if I understood your previous post correctly). The deprecated feature is a Cloud Connect portal. A specific part of the EM functionality that is used to fail over VM replicas to a DR site.

[Dima P.]

we use restore point-based retention on all our jobs for a simple reason: our monthly full backup, which runs on Friday night, frequently spills over through the weekend and even through Tuesday or Wednesday of the following week. By using restore point-based retention, we ensure that we always have at least 14 snapshots to restore from regardless of how long the monthly job takes. If it's time-based on 14 days rather than restore point, we might end up with 10 or 11 a couple of weeks into this month.

Thomas, it's achievable via daily retention and Weekly + Monthly GFS: Step 7. Configure Long-Term Retention. You need to define how many monthly backups to keep which could be set to 14.

Re: "only time-based retention will be available", does this only affect Backup jobs or will it affect Copy jobs as well? Thank you!

Yes, it affects backup copy jobs too.

[nd39475]

all, here is a simple PowerShell script to partially list some of the aforementioned deprecations (B&R #1,#2,#3).
Briefly tested in my environment, please comment in github, any corrections or additions for other users.
https://gist.github.com/meoso/9a6ac5eb1 ... 5ffd7fa9b0

[RubinCompServ]

Will VCC in v13 support VBR tenants running v12?

[Vitaliy S.]

Hey @RubinCompServ ,

This post from the VCSP forums should be able to answer your question (to some extent), please take a look. Let's continue the discussion over there as it is unrelated to the deprecated/discontinued features topic.

[RubinCompServ]

@Vitaliy,

I don't see mention of v12 there at all. To clarify my question, we're currently running v12.0 in VCC, and we were supposed to upgrade to v12.3 on 1/1. We had to postpone the upgrade when the installer told us that some of our tenants are using v10 & v11, and they would stop working when we upgraded to v12.3 (we are in the process of getting them to, at least, 12.2 now). So I want to make sure that, when we take VCC to v13, all of our v12 tenants will continue to be supported.

[Vitaliy S.]

Yes, that's why I said "to some extent" and moved your post from the 2025 sys req topic to the service provider area (not to derail the original topic idea).

[cputnam]

I'm going to add my voice to the "I really like restore point-based retention" camp. I have fairly tight space constraints on my rotated drive backups. Using a pair of (almost) the largest available hard drives, I can fit 1 full + 1 incremental of my server environment. It's not at all clear how I would enforce that constraint with time-based backups. Even if I could do so with clever abuse of GFS, that would just reinforce my point - I should be able to directly express my intent to the software rather than work around its limitations.

I'm sure that VBR is an absolute labyrinth of legacy code at this point, so I understand the need to deprecate rarely-used features. It just seems like retention based on restore point count should not be one of those features.

[jpennin1]

Certainly disappointed with two features I use going away and the implications for our usage. This is the first time I've been "bummed" about changes to Veeam since we started using it 15 years ago.

1. Reverse Incremental Backup - This was a primary feature of why I moved to Veeam many years ago and we continue to use this feature. Isn't reverse incremental faster for restoring to the most recent backup and better for being able to always have a current full backup file not dependent on a chain of files? Supposedly, reverse incremental is slower to backup, but I've never been impacted with performance of the backup.
2. Backup retention based on number of restore points - Honestly, I've always wanted an additional method of retention, disk space based, rather than less options. I'm not a storage guru working for a big enterprise. Our business is limited by storage repository capacity, and retention is important for us less for compliance, and more for maximizing what we can retain based on storage. I wish I could allocate, say 15TB for a particular job and when the next increment would exceed that, that's when the backup chain would be trimmed. Using the "number of restore points" retention policy was somewhat of a workaround. I would calculate our average daily backups and then figure out how many backups we could "afford" to store.

[JeroenL]

Jeroen,


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.

The reason we don't use VeeamZIP is because it is impossible to pre-configure the job. The OT operators aren't IT specialists. They are thought to start a specific backup job linked to a specific OT system before and after they perform maintenance. Some OT systems use 8 servers. Now we simply configure a job without a schedule to create a full backup of the proper servers at each run. 6 or 8 restore points are kept. It doesn't matter if we create 1, 2 or 10 backup a year, the software keeps the number of restore points to the set limit.
GFS isn't an option. There is a time based retention and exactly that is what we don't need. If we configure 1 year it might cause 20 restore points kept on disk. If we configure 1 month it might cause we loose previous restore points, because the interval between backups was too large. Backups are created at random moments. Often the pre-maintenance and post-maintenance backups are created on the same day. How to make sure both are kept for one year?

The only option is to keep backups for one week and export backups with a set retention. Maybe we can script this, but better is to NOT depricate the restore points based retention option.

[MOBO]

i got a disabled legacy backupcopy job than contains 2½ years of monthly backups , will this also prevent me from upgradering to v13 ?
the reason i am keeping the job is that its automatedly release space each month as the GFS retention expires and i believe that if i delete the job i have to manuelt delete the oldest monthly for each of my 255 servers in the job , do i understand that correctly ?

[bhlgr015]

VeeamTeam...

Do we have any hope that the discussions here and the favourable feedback given for their usage (on the points below) could sway Veeam to reconsider the deprecation of them? Or is this set in stone and we ultimately need to change how we utilize the software (for better or worse)?

Areas to reconsider their demise
1. Reversed incremental backup mode.
2. Backup job retention based on the number of restore points (only time-based retention will be available).

Thanks.

[yizhar]

Hello.

We are heavily using reverse incremental mode, due to its benefits, such as:

* VBK full is always the latest.

* Easier management in case i need to change retention, and dropping older VRB files without affecting the chain (example running out of free space in repository)

* Easier copy to quarterly external disks for long term retention:
For example - i have a repository + jobs to hold weekly backups for around 180 days with reverse incremenal, for mid term recovery (like 3 month ago).
then every 3 month i copy (file copy) this repository to external usb disk and keep it aside as quarterly/yearly backup.
this method allows me very good recovery point selection for long term recovery (i can go back and restore data from several years ago and have weekly recovery points to choose from when needed).
Doing this with forward incremental is problematic, i will need a very long vib chain, or use synthetic full which i cannot copy "as is" to external disk.

i know and understand that there are benefits to forward incremental but still prefer using reverse incremental method for most of the backups.

Please keep both methods and let us choose what to use.

Yizhar

[Maurice]

In the past years, we have moved several customers from reverse incremental to forward incremental, whether they used it to have a full backup for a tape out or because of some misconceptions regarding restore performance (and other reasons). We still have a few customers who want a full backup as the most recent restore point because of "reasons" (Some are ideological and some are technical ones).

What we did is that we use a ReFS Repo and on Daily Running Backup Jobs we create a Synthetic Full Backup every day. Through this we achieve an available full backup at any time, we don't need any extra space because of ReFS Block Cloning and we don't have any chains anymore because every backup is a full backup. We have even shorter Snapshot times because of this, because we first create an incremental backup and then we create the synthetic full backup. Reverse incremental reads the data from the source, looks in the full backup what needs to be changed to accompany the changed data, reads that data and writes it out to a new incremental file and then writes the new data into the full backup.

It should always be looked into it why there are some configurations in place. Maybe with an expert of your choice.