[V13] Deprecated and Discontinued features for our 2025 release

[yizhar]

Another note:

Regarding ReFS repository with forward incremental and synthetic full, this is difficult to manage disk space consumption (difficult to calculate and view "used disk space").
Veeam team - Please consider adding an option to show actual disk used and logical disk used for each job or repository.

Handling disk free space issue in such configuration is more challenging then traditional reverse chain without synthetic full, or estimating the possible gain of changing retention of specific job/server.

Yizhar

[Gostev]

Or is this set in stone and we ultimately need to change how we utilize the software (for better or worse)?

The deprecation is set in stone, however we will be looking at addressing impacted scenarios in other functionality to ensure that same or similar results can be achieved with remaining functionality. This is why V13 is deprecation only: existing jobs will continue to work, but users will be forced to create any new jobs differently and we will work with them through any real issues they run into.

At least for reversed incremental backups, we've actually been on this road for over a year. You will find a number of existing discussions here where customers responded with different concerns to my pre-announcement of our intention to remove reverse incremental backup mode in future, and we've been working through those concerns around functionality or processes they thought would be impacted. This showed us that most of the time, the concerns were due to simply not knowing all the existing product capabilities (with tape export of virtual synthetic being a prime example) and other times they were purely ideological, as Maurice has just correctly stated. But we cannot keep maintaining features used by a very small percent of customers based on ideological grounds as feature bloat and having to support multiple completely separate "tunnels" holds the entire product and its overall quality back.

[Seve CH]

Hello,

* 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.

Regarding the copy of the full to USB, it may happen this:
- You manage to backup the full backup to USB before the next backup runs -> Ok. You were lucky and your backups are very small and/or your storage is very quick.
- You don't manage to backup the full backup to USB before the next backup schedule runs. In this case, I don't know exactly what will happen, but it may be one of these two things:
-- The backup job fails because the full backup is blocked and cannot be merged -> You won't respect your SLA for backups. This could be a minor issue or not based on your company needs.
-- The full backup file you are copying to USB is being modified on the background, so now your USB disks have corrupted backups. This is a problem.

Why can't you copy a synthetic full "as is" to external disk? It is a standard file that you can copy at your leisure. We generate one on the 1st of the Month and we have all the time we want to move it to offline storage without needing to worry if it is a bank holiday or not (how do you do your quarterly backups if the 1st of the month is a Sunday?). The only disadvantage is that if you aren't using block cloning (ReFS/XFS), you will need extra storage.

Regarding the "I want to keep X versions" from other posts. I am a hacker. You have 14 versions configured. I hack your systems and then go to your Veeam server and do 14 incrementals of the hacked servers in quick succession. You have now no clean backups anymore and you didn't realize I did it (depending on your system, it may take less than 1 hour). Now I am free to activate my ransomware. Please send me Bitcoin.

Best regards
Seve

[Spex]

I want to remember to the removal of tags from backup jobs or know as "From infrastructure function missing in new backup copy job" in V12. This made a lot of trouble for us (and others). I still had hope with the following post:

It was not a desired removal to start with but R&D just did not have enough time to port all existing functionality back to the newly designed universal Backup Copy engine in time for V12 release.

So you can add this to discontinued features as well. More and more I get disappointed by veeam.

[Seve CH]

Maybe we are lucky and "From Infrastructure" on Backup Copy jobs will be back in v13 (one can dream...). Well... we didn't convert our jobs yet, including rearchitecting the thing... but yeah. It's gonna be fun trying to avoid starting a new 1.3PB backup chain.

[b.vanhaastrecht]

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?

When a VAW job has settings which are not supported by VSPC, you can't deploy/edit/manage the job thru VSPC.

[Dima P.]

I want to remember to the removal of tags from backup jobs or know as "From infrastructure function missing in new backup copy job" in V12. This made a lot of trouble for us (and others).

This feature request for a new backup copy job engine is still in our books. Are you interested only in the tag usage? Would it work for your environment if we provide ability to select tags from backed up objects instead of selecting those directly from infrastructure? Thank you!

[b.vanhaastrecht]

When a VAW job has settings which are not supported by VSPC, you can't deploy/edit/manage the job thru VSPC.

As an example, this xml import export is my only way to deploy configs to VAW's to configure a backup job to a third party Cloud Connect repository.
veeam-service-provider-console-f42/poli ... 96587.html

[Dima P.]

Thank you for the details Bastiaan! We will discuss it with @Vitaliy S.!

[Vitaliy S.]

When a VAW job has settings which are not supported by VSPC, you can't deploy/edit/manage the job thru VSPC.

Hey Bastiaan,

That's not entirely true. You can definitely manage and edit jobs in VSPC but cannot change the unsupported parameter. If you have an example of when we lock down the job, let me know in PM, and I will investigate it.

The example you've referred to is not about having a supported/unsupported parameter but rather about having a non-common configuration for managing a backup agent.

Thanks!

[tgillispie]

ExaGrid continues to work closely with Veeam Product Management, Alliances team, RnD and QA to ensure seamless interoperability between the Veeam Data Platform and ExaGrid's Tiered Backup Storage solution.

An upcoming ExaGrid software release will fully support interop with both Veeam V12's and V13's Data Mover. ExaGrid customers should continue to work with their assigned ExaGrid support engineer to develop plans for upgrades of both Veeam and ExaGrid as relevant software versions become available.

Tom

[dpeach01]

So, I guess my post, which was apparently deleted, doesn't warrant a reply? That doesn't exactly foster a sense of trust or customer awareness. I guess I'll just have to deal with it, huh? Those features aren't really necessary anyway.

[Gostev]

I can still see your post on the previous page of this topic so it's definitely not deleted.

In your post you were asking for the reasons, however they were already explained in my original post, and it's hard to add anything more to them that I didn't already add in my follow up posts in this topic. So unfortunately yes, "just have to deal with it" is the right summary in this case... these are not the first and not the last features to go in VBR history. I'm sorry you're one of a few users affected by this change and I do realize that it can be painful when stuff that you're used to is taken away.

[mark99]

Hello, thank you for sharing your plans.

Veeam Backup & Replication
Backup job retention based on the number of restore points (only time-based retention will be available).

We use this feature and it works better for us than on time:
First, we can know exactly how many copies we have and inform other departments about it.
We have weekends disabled in the backup schedule. In the case of time intervals, we will need to count how many days the same scenario will be.

Secondly, backups in days once led to a merge that lasted for several days: one of the old installations did not use fast clone for merges and defragmentation was disabled.
At some point, the time spent on merging began to exceed the copy interval, which resulted in 1 copy being skipped, and the next time the merge took even longer since the deadline for one more copy expired.
If the task had continued to run, then apparently we would have come to 3-5 copies, instead of the 14 initially expected.
Approximately the same behavior can be obtained if the power is turned off (rarely, but it was) during the merge. The next time you run, there will be 2 merge operations, which may go beyond the copy interval.
We reconfigured everything with the new storage, using fast clone and the task of copying by copies count. Even if the task takes too long, it will only cause 1 skip and that's it.

It's just more convenient and clearer. We don't use s3, and you can block time-dependent functions for tasks that run on the number of copies.

[DFLiddle]

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.

Hi, Dima, I'm also among those who need to adjust to not doing reverse incremental jobs for the purpose of copying a full backup to tape. Does your first suggestion necessitate creating one GFS tape job (to a common weekly media set) for each day required? So far as I can see, only one day can be specified for the weekly interval of any given GFS job. I would gladly add a daily component to an existing GFS job, except that GFS follows a daily regimen strictly and doesn't permit the exclusion of days when staff are not present to swap and secure the tapes. (I won't ask for flexibility on that point, because "daily" should mean daily.)

[Dima P.] GFS currently allows you to configure weekly fulls. We are investigating how to improve the excising functionality and support daily full tape outs with reversed incremental mode being deprecated in v13. Thank you for your feedback and stay tuned for updates and product announcements!

[Gostev]

Guys please post tape-specific questions and feature requests in the dedicated subforum for tape. It costs nothing to create a dedicated topic with your questions there let's not try to cram multiple unrelated discussion threads into this topic as it's completely unmanageable.

[BackupBytesTim]

I don't expect everyone who posted previously will see this, but anyone saying they can't do "time-based retention" because things are complicated missing days like weekends or when backups take a long time to complete or if the device is offline for a while. Then anyone at Veeam can clarify for me too, does this remove the already existing behavior of only counting a "day" in "time-based retention" if that day has a backup?

So, if I previously had configured a retention policy of 30 backup versions, one backup version per day, and the computer was offline on weekends, this would result in 6 weeks worth of backups being kept. 5 backups per week. With time-based retention, now keeping backups for 30 days, would result in the same thing, no? Since it doesn't count a "day" if there's no backup on that day. Or is that strictly "delete backups older than 30 days", which I believe is actually an entirely new functionality that hasn't been a thing as of yet.

It seems there's a lot of people opposed to the change, but from what I understand the change only affects things for anyone with multiple backups in a single day, which I understood was a very non-standard thing in the industry, despite my thinking everything should be backing up hourly for most people. Just trying to determine what I'm not understanding, is it that I misunderstood the "time-based retention" behavior, or that most people saying it will make their job complicated is misunderstanding how that actually works?

[BackupBytesTim]

For everyone else commenting on it, I'll add in, the removal of reverse-incremental jobs has (as Gostev mentioned) been in discussion for a long time now, I've been an avid opponent of the decision for some time. But ultimately it is Veeam's decision to make, if it doesn't work out well then users of the software can find different software. There's a lot of people mentioning how it will affect tape-backup jobs. My understanding, though I've not used it, is that Veeam had some sort of functionality added to enable the forward-incremental jobs to work as expected with tape backup. That does seem like "we took out reverse incremental to save R&D expenses" somewhat goes against "we added a feature to make forward-incremental jobs work with tape" but perhaps I'm misunderstanding the complexity of the corresponding features in the software.

My main issue stems from the format of storing backups as a collection of files, I do still find this format highly unusual and don't understand who came up with the idea, but Veeam isn't the only software that does things that way, so I imagine for some reason the industry as a whole isn't that opposed to it. It presents an issue in my mind because it necessitates multiple files be available to actually restore a backup. This is assuming of course the latest backup version is what is desired, which in my experience is 99% of restoration scenarios. Also this is more of an issue in the real world use of Veeam, where at least for us, Veeam's backup files become corrupted all the time, nearly every week we have to do new full backups for some customer or another, though I can understand in Veeam's internal testing environments, which are very controlled, identical, and generally "clean" that sort of thing might not happen, but in reality we have lots of customers with unreliable connections, varying types of computers, assorted random events on customer devices and occassionally on our infrastructure, things break a lot, so file corruption (or just "Veeam disconnected the middle of writing a file and now refuses to do anything") happens regularly.

There are a lot of "workaround" features like synthetic full backups, file verification checks (to detect corruption), and backup file "merges" to allow for not storing every version ever created. In my mind all these features just serve to fill gaps in functionality that were lost by the switch to forward incremental backups. So it seems like a lot of extra work on Veeam's part, but this where again, maybe I'm missing something, and ultimately it's Veeam's decision. Every other good backup software I've ever used (that is still around), and admittedly I haven't used a ton of different ones, has had a single file storage format. Which allows for performing backups with the efficiency of "forward incremental" where we can just write new data to the disk and never touch the old data (until old data expires and needs to be deleted), but also the benefit of "reverse incremental" in that, we don't rely on a big collection of files in order to perform a data restoration. Also everything I've used has better compression ratios than Veeam, which I assume is related also to storing all data in a compressed single file format, rather than spread out as a collection of numerous files. Again though, I do fully recognize it's Veeam's decision to make, and so users who are strongly opposed to it can just use different software. There are plenty of alternatives out there.

[Wilhelm]

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

Hi Dima,
We have several drives and need to keep each Tenant to tape job to a single drive. As long as the GUI in version 13 will allow the number of drives to be set to 1 (one) this should work. In version 12.2 the lowest number is 2.
/Wilhelm

[Dima P.] Wilhelm, we will add option to set it to 1 for scenarios like you've described. Thank you for your feedback!

[premeau]

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?

I won't try to speak for the OP, but in my (now former) distributed higher education environment, there were a number of cases where trust issues get in the way of centralized management.

While it would still likely be possible to provide configuration instructions, the ability to provide a "out of the box" configuration, even where there is not enough trust for centralized management remains a valuable feature.

[JGM2023]

You mention removal of XML configured protection groups. How are you planning on Solaris backups In future? My understanding Is if we want to manage these through VBR this needs to be completed through XML protection groups.

https://helpcenter.veeam.com/docs/agent ... tml?ver=40

[Moebius]

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?

I do. I have a customer that needs to backup only specific folders of a large data disk (22 TB).
A Windows scheduled task runs daily and launches a Python script that scans the disk and collects the paths of all the folders that are to be backed up, and builds the 'config.xml' file that is subsequently imported by Veeam Agent.
The folders to be backed up are several hundreds, and there are frequent additions and deletions of the same. Also the paths are always different (only the folder name is always the same), so it would be impossible to select them manually in the Agent or VBR server interface. It would equally not be possible to back up the whole disk due to repository space limitations.
It is also not possible to rearrange the folder structure, as they are written by an application (the most important application for that customer).

This will then prevent that customer from upgrading to V13 (or maybe to V14, since I read that feature is deprecated in V13 but still available for upgraded jobs).

[Gostev]

Guys please post tape-specific questions and feature requests in the dedicated subforum for tape. It costs nothing to create a dedicated topic with your questions there let's not try to cram multiple unrelated discussion threads into this topic as it's completely unmanageable.

All, please pay attention to this. It's not just about tape of course.

This topic was never meant to be a place to discuss details around every single upcoming change, but rather to provide heads up on everything that is being deprecated and discontinued in one place for convenience of planning. If you have a question "how do I do this or that without deprecated feature X", please post your question in the corresponding subforum (general, tape, agents, etc.) where the responsible PM can actually see and respond to you on that, plan future changes to the product to accommodate your use cases etc. Which is in fact a very important part of a feature deprecation process!

Not only this topic is missing PMs who only monitor subforums for the functionality they are responsible for, but it is also completely unmanageable anyway with every other post talking about something different. Normally this topic should be just locked given such a chaos, however I'd really like to keep it open for more generic questions around the upcoming changes.

[tthomas1@ebsco.com]

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.

Yes, it affects backup copy jobs too.

Thank you Dima P! I'll review the link and figure out how to reconfigure our jobs. I should note we want 14 snapshot total, not 14 monthlies.

[RubinCompServ]

My main issue stems from the format of storing backups as a collection of files, I do still find this format highly unusual and don't understand who came up with the idea, but Veeam isn't the only software that does things that way, so I imagine for some reason the industry as a whole isn't that opposed to it. It presents an issue in my mind because it necessitates multiple files be available to actually restore a backup.

What software do you use that creates backups that are NOT written to files? Literally every piece of backup software I've used for the past 25 years (Windows, BackupExec, Acronis, Veeam, Cove, Crashplan, (and probably some others that I've forgotten) not to mention applications like SQL and Exchange) has written backups to files.

[JeroenL]

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.

Every backup is always an active full.
The thing is that the OT operators only have to press RUN NOW and everything in the backup is handled by Veeam.
The operators don't have to worry about disk usage or exports or even how many VMs are in a specific job.
They simple turn off the VMs belonging with a specific OT system. Run the backup job. Start up the VMs en perform their maintenance.
The IT department "monitors" the status of the jobs by checking the job status. VeeamOne runs reports about the number of restorepoints and their locations to verify they are conform company policy.

With VeeamZIP it is no longer possible to backup multiple pre-selected VMs in a simple run and and it is also not possible to "monitor" the results in a central place.
We have to come up with workarounds with scripting to have backups exported to different locations to come to the same end results.

@Veeam: Please reconsider dropping the restore points based retention option to help non-IT customers with different demands.

[cpfleger]

There are a lot of "workaround" features like synthetic full backups, file verification checks (to detect corruption), and backup file "merges" to allow for not storing every version ever created. In my mind all these features just serve to fill gaps in functionality that were lost by the switch to forward incremental backups. ...

Those features are already here for a long time if not from the beginning, definitely longer than RevI backup method doomed to be removed.
And the fact that RevI is going to be removed was no secret at all.

So for all who want to habe a daily full backup to tape (which is a rather rare wish outside of small business) you can switch to forever forward incremental w periodic fulls and do synthetic full backups to tape every day.
That should work for the most up to now RevI users, I believe it was even mentioned in v12 until some release in the console.

Regards!

[pwinterbourne]

This is not good news at all. Reverse incrementals have always been one of Veeam’s standout features. I’ve gone through this thread, but I’m struggling to understand what the viable alternatives are. Could someone explain how we’re supposed to migrate away from reverse incrementals and adapt our strategy? What’s the practical alternative here?

Here’s our current scenario:

We have 7 backup jobs, and each full backup is 2–4TB.
We run reverse incrementals nightly to our backup server and then copy the full backup file to USB drives (we have 7 USB drives in rotation).
USB drives are rotated offsite daily, so we always have a full backup offsite.
Incrementals are retained on the server for up to 60 days, giving us historical data if needed.
Our USB drives are 4–6TB each, and our backup server has ~100TB capacity.
This method works well for us because it’s straightforward: we always have a full backup offsite daily without complex chains or dependencies.

If we’re being forced to move to forward incrementals, does this mean:

I now need to do full backups every weekend for the entire infrastructure? (This seems unlikely given the size of our jobs, meaning I’d need to split them across weekends, which complicates scheduling.)
I’d need to buy larger USB drives to store not only the full backup file but also the entire incremental chain for offsite rotation?
Or am I missing something? Are there features or workflows I’ve overlooked that could simplify this? I admit I haven’t kept up with all the new features lately, so if there’s a better way, I’d love to hear it!

Any advice or insights would be much appreciated—this change feels like it’s going to throw a wrench in our strategy.

[cpfleger]

Why not use export backups function that would, if needed, create U a full backup synthetically out of an increment?
Then forward or forever forward incremental is no problem.

Description see here: https://helpcenter.veeam.com/docs/backu ... ml?ver=120

To automate that use powershell and post job scripting (see here for the commandlet: https://helpcenter.veeam.com/docs/backu ... up&ver=120)

edited: content

Regards!

[pwinterbourne]

Thanks cpfleger. I will check that out

its so frustrating. It took years to get our backups running like a well oiled machine. We have powershell scripts that mount every backup every day and do a test restore then send us an email to let us know the restore worked too.

I have done some research and there may be some ways of accomplishing what we need. It looks like potentially a combination of synthetic fulls/forever incrementals and backup copy jobs may get us close to where we need to be. I can easily enough move over to forever incrementals as its basically the opposite of what we do now. The issue is just those off site copy jobs which need to be done every day AND making sure we copy a full backup off site every day so that we have all of the most recent data. I need to look more into the backup copy jobs and see if these may work for us. My limited understanding is that they work alongside the normal backups and will create a full backup out of the most recent set of files (incrementals and full) and then copy this to USB. I think the rotation though may cause issues here....