r/Veeam

My bad for not knowing this before moving my server, but I’ve discovered the hardened v13 appliance (Rocky OS install) blocks, via USBGuard, keyboards at the console not used for the initial install. Anybody know of a work around besides booting into single user mode and modding grub? Otherwise I’m going to have to dig out my old KVM rack unit I thankfully hadn’t thrown away yet and hook it back up for this one server.

I asked Veeam support and they said that’s the way it is.

Good evening my fellow sysadmins,

I've got a question for you : what is the best file server solution that works best with Veeam backup & Replication ?

Context : in my company (a Consulting engineering company) we currently store our data on-prem, we have two production servers and two other replicas. The solution that is deployed is a Ubuntu Server with two ZFS Pools in RaidZ2 (each pool is around 150TB big but with only 40 to 60% used).

Last month, before my tutor retirement, the choice was made to use Veeam to backup our physical infrastructure as well as our file servers. I just found out that Veeam doesn't support ZFS and with the size of our pools, the jobs fail immediately. The limit of VBK files are 218TiB and I don't know how Veeam calculate the size but it fails.

I am thinking of deploying new file servers, since most of our production is on Windows Server I tend to go in that direction with DFS Namespaces or use Azure file for a Hot / Cold data tiering but if you have any others remarks, I will gladly read them.

Thanks ;)

We're running a decent number of jobs and Veeam fires off one status email per job. On a normal day that's 30-50 separate emails, and figuring out if everything actually succeeded means scrolling through all of them by hand.

I looked at VSPC and Veeam ONE, but for our size the setup overhead (dedicated server, Cloud Connect config, certs) feels disproportionate to what we'd get out of it.

How are you all handling this?

• Running VSPC/ONE anyway — was it worth the setup?
• Built your own script/report to consolidate?
• Or also just scrolling through the individual emails every morning?

Curious what setups people actually landed on, especially for smaller in-house teams (not MSPs).

Veeam Agent for Windows version: 13.0.3.1220

Issue:

Full backup job completes reading the entire source (both partitions, ~2.3TB total) successfully at 100%, but fails during the "Finalizing" stage with the following error:

Error: Failed to save backup meta to '\\10.0.0.1\backup-share\Job MYPC\Job MYPC.vbm'. The system cannot find the file specified. Failed to open file [\\10.0.0.1\backup-share\Job MYPC\Job MYPC.vbm_tmp]

Log excerpt attached below.

What I've already ruled out:

- Reproduced identically on TWO different NAS targets (different IPs, different NAS devices)

- Reproduced identically after a COMPLETE reinstall of Veeam Agent

- Reproduced identically regardless of job duration - tested both a ~46 hour full backup (slow network) and, after fixing an unrelated network bottleneck, a ~5 hour full backup with the same source data. Same exact error both times, at the same finalization step.

- NAS-side disk health confirmed clean (SMART check passed on all relevant disks)

- Antivirus (Trend Micro) exclusions added per Veeam KB2034, no change

- Target-side SMB share permissions and connectivity confirmed working (a repair/retry session immediately after the failure connects and authenticates without any issue)

From the detailed backup job log, the failure happens because Veeam attempts to open '.vbm_tmp' with CreationDisposition=OPEN_EXISTING (3), but that file was already consumed/renamed to '.vbm' at the very start of the job and is never recreated before the final write attempt:

[BackupMeta] Saving backup meta to '...vbm'

[FC] Saving file content [...]

Error: Failed to call DoRpc. CmdName: [FcWriteFileEx] inParam: [<InputArguments><FilePath value="...vbm_tmp" /><DesiredAccess value="1073741824" /><ShareMode value="1" /><CreationDisposition value="3" /> ...

Error code: 0x00000002 (ERROR_FILE_NOT_FOUND)

Stack trace points to:

Veeam.Backup.Core.CBackupMetaFile.Save(String serializedMeta)

Veeam.Backup.ProxyProvider.CProxyFileCommander.SaveFileContent(String link, String fileContent)

This looks like the finalization step assumes the temp file placeholder from job initialization is still present, but nothing recreates it before the final metadata write - regardless of how long the job took to run.

Has anyone else encountered this specific error, or is there a known fix/patch for it? Full backup + network share target seems to be the common factor.

--

log

--

18/08/2026 13:18:59 :: Creating VSS snapshot

18/08/2026 13:19:58 :: Calculating digests

18/08/2026 13:20:45 :: EFI system partition (disk 0) (100.0 MB) 100.0 MB read at average. 66.7 MB/s

18/08/2026 13:20:56 :: (C:) (465.2 GB) 302.7 GB read at average. 61.7 MB/s

18/08/2026 14:08:08 :: Recovery partition (disk 0) (499.0 MB) 415.0 MB read at average. 131.8 MB/s

18/08/2026 14:08:11 :: New Volume (D:) (1.8 TB) 1.7 TB read at average. 50.5 MB/s

18/08/2026 18:34:19 :: Finalizing

18/08/2026 18:34:21 :: Error: Failed to save backup meta to '\\10.0.0.1\backup-share\Job MYPC\Job MYPC.vbm'. The system cannot find the file specified. Failed to open file [\\10.0.0.1\backup-share\Job MYPC\Job MYPC.vbm_tmp]

18/08/2026 18:34:21 :: Error: Failed to save backup meta to '\\10.0.0.1\backup-share\Job MYPC\Job MYPC.vbm'. The system cannot find the file specified. Failed to open file [\\10.0.0.1\backup-share\Job MYPC\Job MYPC.vbm_tmp]

18/08/2026 18:34:24 :: Email notification was sent

18/08/2026 18:34:23 :: Processing finished with errors at 18/08/2026 18:34:23

We migrated Veeam VBR 12 server to a new datacenter, new VM (still 2022) but moved from MSSQL to PostgreSQL.
When we have a lot of tasks running, usually > 100, VBR service crashes and a reboot is needed.
This is happening 2-3 times per week.
NEVER happened in the old datacentre with same quantity of jobs configured.
Never.
Opened a ticket in Veeam support page on 29 July, not a single idea or fix from support was resolutive, they point fingers on:

-

1. antivirus exclusions (all configured correctly from our side)

-

1. corruption in logs (found old .arc files in log fo

lder)
-

1. now they are pointing on virtual server vcpu configuration (that is the same of the old vm)

Also it seems they ignored what I put in the ticket or did mistake with commands to run or logs to check (they checked an old log when I uploaded a fresh one).

It seems they have NO IDEA about the issue and are in try and error mode.

Already asked an escalation, the ticket was assigned to a different guy that seems ignoring the whole ticket, asking again info that I have already wrote.

Plus, the ticket page is a nightmare to read with blank lines added randomly.

I was wondering if I am missing a setting, I updated to 13.1 and tested all the workers and put in the new vlan option because I always did that manually after an update.

But now when all the backup start I get a couple of warning that the worker was not available and it used a different worker from an other node. I was searching for an option to let the job wait before the worker was done. Maybe it is just a setting somewhere now that I am missing.

We start a lot of backups around the same time but I would rather have the jobs wait for the worker to complete the task before than moving to another worker.
I increased the concurrent tasks for now.

I'm moving a large old backup from one backup job to another for VMs that are retired or not being backed up so they don't get tested with my nightly SureBackup tests that run against those backups. (Can't exclude it because it's no longer on my vCenter, and there's no way to pick VMs to exclude from the backup job which seems odd.)

I have a server running as a linux hardened repo on SUSE with one volume housing all my backups. I'm moving the backup data on the same same repo just one job to another, and it appears that Veeam server has to receive all the data and then stream it back to the repo, rather than just utilizing a file move in Linux which would be basically instantanious. I'm guessing this is expected behavior for validating metadata or such? It's so far reported it's moved 2.4TB at 140 MB/s in a little under 5 hours.

LHR is on a 25Gbps fiber and my Veeam VM is on vCenter that's on the same switch also with 25Gbps, I would believe this should transfer faster.

First thing I'll start investigating is if my infrastructure is configured correctly, but also wondering about how Veeam moves its data. I get moving from one storage location to another it has to go over the wire, maybe that's just the default and it doesn't understand it's on the same repo and just needs to update pointers.

I did try to move all the files to the new location and rescan my repo, but then it couldn't find it in either backup job. I then moved them back, rescan still didn't find them, but I did an import of the backup and it then found it all and updated in the GUI.

The Windows 2022 Veeam VM has 8 cores and 32GB of ram, 18 of which is in use, 8 of that for the Veeam.Archiver.Proxy.exe. The backups are encrypted.

I am starting the process of doing network speed tests along each link in the chain.

VM - VMXNET 3 adapter - ESXI host -25Gbps - DHCI Switch -25Gbps - Linux Hardened Repo

Please don't ask me why my auditors want this, but here goes. My SureBackups run on the same day as my backups, right after the last backup is complete. It never crosses into the next day.

I have a daily scheduled task on each VM to write to a text file with today's date in YYYYMMDD format in the content. I'm trying to get my SureBackup script testing to check the file contents and validate that the contents match, but I'm not sure my output is what it's looking for and also if the Write-Host may be mucking it up?

$FilePath = 'C:\Temp\SureBackupValidation.txt'

$Return = 1

# Fail if the file doesn't exist
if (-not (Test-Path $FilePath)) {
Write-Host "Validation file not found."
$Return = 1 #Somewhat redundant
exit $Return
}

# Read the file contents
$FileDate = (Get-Content $FilePath -ErrorAction SilentlyContinue | Select-Object -First 1).Trim()

# Get today's date in the expected format
$Today = Get-Date -Format 'yyyyMMdd'

if ($FileDate -eq $Today) {
Write-Host "Validation successful. File contains today's date: $Today"
$Return = 0
exit $Return
}

else {
Write-Host "Validation failed. Expected: $Today, Found: $FileDate"
exit $Return
}

&#x200B;

Pessoal, estou com um problema no Veeam Agent for Microsoft Windows e gostaria de saber se alguém já passou por algo parecido.

Tenho um backup em **File Level Backup** e o backup é concluído normalmente, porém, quando tento fazer o **mount para File-Level Recovery (FLR)**, a operação falha com o erro:

&gt; Unsupported disk type

O problema acontece somente na tentativa de montar o backup para acessar/restaurar os arquivos. O job de backup em si termina normalmente.

Já tentei algumas alternativas, inclusive testar o backup em Volume Level, mas preciso manter o File Level Backup, pois não quero fazer backup do volume inteiro.

Alguém já encontrou esse erro especificamente durante o mount/FLR de um backup feito pelo Veeam Agent?

Existe alguma configuração, limitação ou característica do disco/partição que possa causar esse Unsupported disk type”?

Se precisarem, posso enviar os logs do mount/FLR e as informações do disco.

Obrigado!

I loved that vSphere replication could just use them so the one job was all I needed. Now my pure snaps are running and then it's copying the same data with veeam replication jobs.

Veeam already sees my SAN and the snaps in the storage infrastructure section... Any chance they will add the ability to just use that similar to the way VMware does?

Hey zusammen, ich administriere seit einiger Zeit Windows-Umgebungen mit NinjaOne und habe im Laufe der Zeit einige eigene Skripte gesammelt/geschrieben – u. a. für Veeam-Backup-Trigger, Logging und ein paar Wartungsaufgaben. Hab die mal in ein GitHub-Repo gepackt, falls jemand ähnliche Anwendungsfälle hat: . Bin auch offen für Verbesserungsvorschläge oder wenn jemand Bugs findet – ich pflege das aktiv weiter.
Soll keine Eigenwerbung sein, nur ich hatte damals gesucht im Dojo und auf Git und keine Automatisierung direkt gefunden.
Viel Spaß damit.
Mit freundlichen Grüßen

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

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

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'

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

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?

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?