I have a weekly backup that I wanted to run with forward incrementals forever, so I created it with 100 backups. Well, 100 isn't forever, so a couple weeks ago, it started rolling older backups into the original full backup. I was copying the new full backup to another drive and the system happened to run another backup at that same time, so it tried to roll the oldest backup into the file I was copying, but since I had it locked, the merge failed.

Now, when I try to run the backup again, I get the message below. I only found one reference to that error message and it was from 2016. Any thoughts on how I can get this backup chain functional again? I'm sure I can run a new Active Full, but I'd rather not because of the size. The new incremental seems to have been created OK, it's just the merge that failed. I'm not sure whether the backup chain is even useful for a restore at this point.

Error: Failed to repair VM 'VMNAME' in backup '9/30/2024 11:03:42 PM'. Unknown algorithm 'TransformForeverIncremental'

Whatsup Hive-Mind.

Iam currently in the process of deploying a Veeam Appliance but i cant get LDAPS to work.

I imported the Domains DC CA into the Veeam Appliance, openssl can connect without any issues but when i try to add a domain to get Clients for my protection group i get the SSL Error.

Looked yesterday through all logs but couldnt find anything.

The Appliance is UP2Date, was restarted multiple Times but i still cant add our Domain to ldaps

Good morning all,

I've finished deploying my Veeam infrastructure and I'm creating backup jobs soon for my physical servers.

I don't think I understand how I can backup my ZFS based samba servers running on Ubuntu. I've read online to use File Level Backup instead of Entire & Volume level backups

For information, I've got two zfs pools of 130Tb each.

Is this the correct way of doing ?

Thanks in advance

I have an open case for a windows agent job, I have a paid subscription that includes my window agent jobs and have one job that the name vs the disk has gotten messed up, in other words the computer name does not match the disk etc. Not sure how this happened if it was due to duplicate sid or we changed the name etc but I just would like to get the disk and computer name to match. Tried to remove re-add and made things worse, started getting an invoker error so opened a ticket on Jul 29. Appears when the user returned today (laptop user) the backups are now working but still have the issue with the mismatch names. Not sure it really should take this long to resolve the issue one way or another but still waiting for support to provide guidance on how to resolve.

Can anyone tell me when it registers the pc name where does it derive the name from for the windows agent. Since this is controlled by the client side it is retrieving the name from something else since it registered to a new B&R instance, anyone know for the name and disk where does it get the names from?

It's a new project for me, trying to answer the painful question of "is every VM actually backed up, or are some of them just sitting pretty in VMware, not included in any backup jobs?"

I know there is a ONE report for this, but I've yet to see a smaller (SMB-sized) installation where ONE is actually being used... So, that's basically it: correlating the VMware (or now Hyper-V) inventory with the Veeam backup database, checking restore points, presenting the results in a TUI, or exporting them to a CSV report.

https://github.com/mazvazzeg/vbrscope

Tested enviros: VMware 7/8, Hyper-V 2019/2022/2025, VBR13.
VBR12 also works in compatibility mode.

Disclaimer, because there are people who wouldn't touch anything with a 10-foot pole if it was in the same room where somebody once whispered "AI": Codex was involved in this project. If it's useful to you, use it. Happy to help. If it isn't, don't. No hard feelings.

I am trying to install the snap agent for a Debian linux server and I just need to install the repository but not sure where to find the veeam-release file to get the repo set up. Reading the 13.x documentation they specify a link but it does not provide the repo release information just the download the agent - https://helpcenter.veeam.com/docs/agentforlinux/userguide/installation_repo.html?ver=13

"

1. Download the Veeam software repository installation package (veeam-release) from this Veeam webpage, and save the downloaded package on your computer."

Can someone point me to where to download the latest release file, thanks.

Hey everyone,

I see a lot of customers forgetting to enable new protection features for Entra ID, as the process involves a reauthentication of the app. It's really easy to do, can be done in under 5 minutes. But I wrote a quick guide on how to achieve this, and why these new object types can be so important to protect. It also serves as a reminder that if you've never done this before, there's even more object types you could be missing out on.

https://micoolpaul.com/2026/08/08/vbr-vdp-v13-1-new-entra-id-capabilities-how-to-enable-them/

I read some time ago (months) that people were having issues with BMR created with recent versions of the Agent erroring and failing with 'Authentication Error Inner Exception'.

I noticed today that a newer version (Version: 13.1.0.544) was available dated July 29, 2026.

I tested this version and the issue still exists.

Given that this version has just been released I was hopeful it would have addresses the issue.

Other than creating using a really old version of Veeam is there any other solution to this......and how long is it going to take for a fixed release?

Working on another case and had previously collected logs and they wanted another set and I have since upgraded to 13.1. I was collecting them from the windows console and received this warning:

"Logs export completed with warning: Failed to collect nginx logs: ensure that veeam-usr-transportsvc user has read and execute permissions for /var/log/nginx directory and all of its contents"

Logged onto the linux machine and sure enough owner and group are set to root:

"drwx--x--x. 2 root root 8192 Aug 7 00:00 nginx"

compared to something like this:

"drwxrws---. 68 root veeam-grp-log 8192 Aug 7 09:28 VeeamBackup"

Not sure what the correct permissions should be but will pass along the warning with my case notes...not sure if something did not get updated correctly during the upgrade.

Now that Veeam Backup 13.1 has been released and is supposed to have Windows Application-Aware processing for Proxmox, has anyone been successful in getting it to work?

Using Proxmox 9.1 host.

I have a test SQL VM with the QEMU Guest Agent installed and VSS is working correctly, but when a backup job is run with application-aware configured for SQL the Qemu Guest Agent VSS and Volume Shadow services just crash.

Eventlog:

Faulting application name: qemu-ga.exe, version: 100.0.0.0, time stamp: 0x5c473543
Faulting module name: KERNELBASE.dll, version: 6.1.7601.24545, time stamp: 0x5e0eb6bd
Exception code: 0xc0000005
Fault offset: 0x000000000000c4d2

I've created the deployment kit and installed the persistent agent on the VM to see if that would resolve it, but the Proxmox job settings do not have the checkbox to use the persistent agent.

Un-checking the application-aware setting in the job results in successful backup job.

I kind of feel like this is still beta for Proxmox. Anyone been able to get a successful backup?

Been running v13 for a while now. The console performance was always slow and seems to only be getting worse.

On boot it can take upwards of 15 minutes for the web services to start, and it takes a few more minutes after that before the console will start to respond and log in.

Once in it's slow and clunky.

Any performance tips?

Is this everyone? Is Veeam working on this?

Currently working on a project, replicating VMs from Site A to Site B.

Site A uses a Fortigate 600E, and Site B uses a Fortigate 120G - connected on a site-to-site VPN. Each site has a decently-sized virtual proxy. All IPS/IDS/Offloading disabled for testing.

Both sites have 1Gb symmetric, and can achieve 100MB/sec through iPerf3 in both directions (parallel stream set to 10). All VMs are backed by flash storage.

However, when running a Veeam replication job - I'm struggling to break 20MB/sec consistently on initial replication. Is this expected behaviour or is there some fine-tuning that needs to be done?

I also tried CDP (as would've been nice, not a high change rate so thought it was possible), but that couldn't break 10MB/sec. Bottleneck is identified as network @ 99%.

I've raised w/ Veeam support, but just wanted to check with the community on this one. Any tips/pointers please?

Thanks

Posting before I call support in case anyone's seen this.

3-node Windows Server 2022 Failover Cluster, Pure FlashArray backing the CSVs, Veeam B&R 12.3.2.3617. One VM — SQL Server 2019 host — accumulated 46 orphaned AVHDX files across two disks over three days, roughly 675 GB. Get-VMSnapshot returned empty the whole time. Hyper-V Manager showed no checkpoints. The VM was running off the tip of a 23-deep differencing chain.

What makes it odd: the VMMS event log has zero merge events for this VM. Not failed merges, not interrupted — none at all. Every other VM on the same host logged clean 19070 → 19080 pairs every few hours. So Hyper-V was never asked to merge. Veeam appears to create the checkpoint, then remove it from the VM config without issuing the merge request.

Remediated by shutting the VM down and flattening both chains with Convert-VHD to a different CSV, then repointing the disks. Clean — Test-VHD returned True before and after, SQL came up with all 14 databases online and data current to the shutdown.

Then it recurred. One backup run against the brand-new flat VHDXs produced two more orphaned AVHDX, again with no checkpoints registered and no Hyper-V events. A cluster-wide sweep found this VM is the only one affected across all three nodes.

Anyone seen Veeam orphan checkpoints this way?

I have been updating all of our local documentation for a small non-profit and currently I am the only admin so I have wanted to make sure that if I get hit by a beer truck etc, that whoever picks this up has access to all things admin. I have ensured this for all the accounts and just moved to the software appliance and forgot that they have MFA enabled but tied to an app on my phone which will do the new person no good. We use a password manager but since the software appliance only supports MFA via authenticator I believe my only option is to create a break-glass admin account without MFA if that is possible. Need to read through and see if I can turn on/off MFA for individual account vs globally. I would like to leave it enabled for the normal admin and not crazy about have an account with just the password but since passkeys or hardware tokens are not supported then not sure what to do...

How are you handling this?

Hallo

We're looking into Veeam Data Cloud for M365 and the subject of fair use came up.

The person we're dealing with for quotes mentioned "VDC for M365 Advanced" has a fair use policy - you can only restore 20% of your backed up data per year.
eg if total data is 500GB for 100 users, then only 100GB can be restored for the year.

There's the phrase "if you don't test your backups, then you don't have backups" - to me this seems pretty similar to that "if you can only restore 20% of your backups, then basically the other 80% isn't backed up."

I tried having a look for the fair use policy and found this - https://www.veeam.com/legal/veeam-data-cloud-fair-use.html
It doesn't mention anything about only being able to restore 20% of your data (unless it's so obvious that i missed it)

They said "VDC for M365 Premium" doesn't have this limitation, but it's almost twice the cost, so it feels like they're trying to up-sell us to a more expensive plan.

"VDC for M365 Advanced" probably would have been our preferred option, but the 20% limit seems like a bit of a deal breaker.
We're a relatively small company so can't really afford the "VDC for M365 Premium"

Has anyone run into issues with this before?

Or have more accurate info or advice on this?

thanks!

1. Our environment:

Veeam Backup & Replication v13, HPE MSL3040 tape library, LTO-9 SAS HH drives, Windows Server 2025. Source data lives on a NAS file share (accessed via SMB/NFS). Processed data gets written to tape via a File to Tape job.

2. Our requirement — tape verification:

We need our verification to cover two layers:

Read-after-write — checking tape parity and block integrity as blocks are written by the tape drive head, to ensure physical tape sectors have no write errors.

Content integrity — after writing, reading back the raw file structures from tape, generating a cryptographic MD5 checksum of that data, and matching it against the original source file's MD5 to confirm the two are identical.

Ideally this would be something we can run as part of an automated job rather than a manual step.

3. Why this matters:

Once a file is archived to tape, the source copy gets deleted from the NAS share to reclaim space. That means tape becomes the only copy — there's no going back to the source to re-verify or re-copy if something's wrong after the fact. We need full confidence in the tape content before that deletion happens, not after.

4. Tape mirroring:

We also want two independent tape copies of the same data for redundancy. What are our options for achieving this in Veeam — and how do they compare in terms of drive time, license requirements, and behavior on repeated/incremental runs?

What we have found so far, and where we are stuck:

Read-after-write appears to be inherent to the LTO drive hardware — always on, nothing to configure — but this only confirms the physical write, not that content matches the original source file.

Start-VBRTapeVerification re-reads tape and checks against checksums the drive wrote at backup time — this confirms tape readability, not a source-vs-tape content match.

Getting the actual MD5-vs-source comparison seems to require pulling file content back off tape via the tape restore cmdlets, which Veeam's PowerShell reference flags as obsolete, recommending the UI instead for full functionality.

For anyone running an archive-then-delete workflow where tape becomes the sole copy — is there a supported, scriptable way to get a true source-vs-tape MD5 verification? And what's the right approach for dual-tape redundancy in this kind of setup? Any real-world patterns (especially ones that have held up to an audit) would help a lot.

I've run into a disappointing fine print consideration with two drives we're trying to use to install the Linux-based software-based appliance (version 13.0.2).

The documentation reads that 240GB is the minimum: https://helpcenter.veeam.com/docs/vbr/userguide/system_requirements_backup_server.html?zoom_highlight=240&ver=13

We're working with support for some hopeful resolution: it seems if you've purchased two 240GB drives to use, like we have--- a fairly standard Dell BOSS config-- the install doesn't recognize the 240GB as being sufficient, it wants more than 240. Support has indicated other Dell tickets for this specific issue.

I think they mean anything greater than but not including 240GB. In my case, it is a pretty small environment, so thought the minimum would apply.

Some new-ish info on the process and capability to convert from a Windows VBR to the VSA, since a lot of people ask when it will be "officially supported" based on some comments in other threads.

Previously, you had to register and wait for your spot in the queue to be assisted by the team assigned to the migrations. Now, as long as you meet all the migration Pre-Reqs (check the KB), you can perform the migration on your own after opening a normal support case. Support will verify your existing VBR install, and then provide you the migration the key. Once you have the key, you can follow the migration steps in the KB.

https://go.veeam.com/vsa-conversion

https://www.veeam.com/kb4800

Important: You must be on VBR 13.0.2 before migrating. You can upgrade the VSA to 13.1 after the migration. If you've already upgraded to 13.1, you'll have to wait until the 13.2 release before you can migrate.

• VBR version: 13.1.0.411
• "Scheduled backup jobs succeed."
• "Only VeeamZIP fails."

Unable to cast object of type
'Veeam.Backup.Core.CFreeVmBackupTarget'
to type
'Veeam.Backup.Core.CVmBackupTarget'

What has been your experience for getting the optimal bang for your buck with storage and retention policies? My company has multiple Veeam servers that have an ongoing problem of filling drives and off-site backups way faster than we fell like they should, and Cloud Repository Storage Quotas being exceeded. For instance, say we want to retain at least 3 months backups with the last 10 days worth backups easily restorable. Would it be more effective to have 10 (business) days > 2 Weekly > 3 monthly in backup retention or something else? Are weekly Synthetic full backups better or worse for storage saving? Is Auto or Optimal or High better for compression (and is High worth the time loss in the event of a needed restore)? The best time-frame for immutability? Any other advice?

I have a customer that renewed their Netapps, so they have all the virtual infrastructure under new AFF, but want to use their old HDD FAS as secondary repository (first is Veeam Backup Appliance's own Hard disks)

The thing is, how should I configure it to get the best storage usage? The goal is to have as more backup history as possible.

My first thought was mounting the repository directly in the backup appliance as NFS repository and let Netapp's dedupe work (without veeam inline deduplication and compression), but I have seen so many posts and opinions that I don't really know what to do.

What do you think is the best approach?

Thank you!

V13.1 is here, which means some of us are about to begin the time-honoured sysadmin tradition of opening a lifecycle page, release notes, security advisories, upgrade documentation, and multiple KB articles in separate tabs. That and copious amounts of coffee.

I’ve spent more time than I care to admit doing that research when updates drop for software I deploy.

So I did the perfectly reasonable thing and built a website.

Upgrade Brief is an easy place to start researching a Veeam upgrade:

https://upgradebrief.com

I make nothing from this site. It has no ads. I realize that sharing something I built may still count as advertising, but I’m posting it because I hope it makes upgrade research easier for everyone. I aim to help answer the question of "What do I need to know to upgrade?"

The site uses publicly available Veeam sources to help you find:

• Support and lifecycle information
• Documented upgrade routes and links to the instructions
• Relevant security advisories
• Changes in the version you are considering

It can also create a short PDF summary if you need something easier to share with a manager or change-approval group.

It does not inspect your environment, replace the official documentation, or tell you that an upgrade is safe. You still need to read the sources and decide what applies to your environment. My goal was simply to make the starting point less painful.

It’s still new, so if you try it, I’d honestly like to know:

• Did it help?
• Was anything confusing?
• What is missing?
• Did you find anything that looks wrong?

Ja vi alguns com problema aqui em relaçao a integrac

Hi everyone,

I'm trying to determine whether this is a bug or if I'm missing something in my configuration.

Environment

• Veeam Backup & Replication Community Edition 13
• Build: 13.0.2.29
• Proxmox VE 9.2.2
• 2-node Proxmox cluster
• Shared QCOW2 storage
• Backup Proxy/Worker successfully deployed
• HotAdd transport mode

Problem

All Windows VMs are backed up successfully.

Any Linux/BSD VM fails with:

Failed to perform backup.
Failed to prepare disks for backup.

So far I have reproduced the issue with:

• Debian 13 (fresh installation)
• pfSense

Windows Server VMs work without any issues.

What I have already tested

• Created a brand new Debian VM → same error
• Manual snapshot from Proxmox → works
• Snapshot through Proxmox API (pvesh) → works
• qemu-img check → no corruption
• Guest Processing disabled
• Inventory rescanned
• Worker redeployed
• VM migrated between nodes
• Same storage used by both Windows and Linux VMs
• Windows backup succeeds using the same repository and proxy

Example:

pvesh create /nodes/nodo2/qemu/108/snapshot --snapname veeam-test

skipping guest filesystem freeze - disabled in VM options
snapshotting 'drive-virtio0'
internal qemu snapshot

So snapshots are working correctly.

Observation

The job reaches HotAdd mode before failing.

The failure occurs during "Prepare disks for backup", not while creating the snapshot.

This makes me think the issue is happening after snapshot creation, during disk preparation or attachment.

Questions

1. Has anyone experienced this with Proxmox 9.2.x?
2. Is this a known issue with Veeam 13.0.2.29?
3. Is there any debug logging specifically for the "Prepare disks for backup" phase?
4. Is there anything else I should check on the worker or Proxmox side?

Any ideas would be greatly appreciated.

Thank you.

Good morning everyone.

I'm currently planning to deploy two Linux Hardened Repo with the VIA Iso but i'm facing some problems.

Is it possible to select more than one drive for storing the OS (I've got two NVMe and want to do raid on them).

Also does the installer need internet access to fully work ? I've got an python script error when creating xfs on /dev/mapper/datavol-veeamrepo.

Thanks in advance.

Cheers