Unanswered questions

Salve a tutti,avrei bisogno del vostro aiuto per validare una soluzione "non convenzionale" che non posso fare da solo non avendo un lab sufficientemente grande per contenere tutto.Obiettivo: creare un sistema di DR da un tenant di VCD in region 1 verso il suo omologo su VCD in region 2.Come da documentazione, VCC non permette la replica avente sorgente un tenant di VCD e target un altro tenant su VCD.Io pensavo di fare così: creare job di backup sulla region 1, magari tramite EM in modo da renderli visibili al tenant creare job di copia verso la region 2 di questi backup abilitare il tenant sull'EM del VCD della region 2 affinché possa fare restore con instant recovery abilitare il corrispondente tab Veeam nell'ambiente VCD del tenant creare in anticipo le reti con gli stessi nomi e le regole di NAT e FW identiche a quelle del tenant su sorgenteA questo punto il tenant sarebbe autonomo nel ripristinare l'ambiente sulla region 2. In questo modo risolverei il problema dell'RTO. Non quel

Hello everyone,For several days now, I have been receiving the following error message during our backup copy job:“Failed to perform backup verification Error: Unable to get block digest: block is not initialized. Skipped arguments: [0]; Agent failed to process method {Signature.FullRecheckBackup}.”I performed a full backup, but unfortunately the same error message appeared again. The copy job does not conflict with the backup job.How can I fix this error?Thanks in advance!Version: Backup & Replication 12, Build: 12.3.2.4165

Hi All,  Has anyone seen hotadd Linux (Rocky 9.7) VM proxies go sideways and not mount after upgrading to v13? I also added a new v13 appliance proxy and the result were the same. Changing transports to net work fine. On this client side logging it shows: Error: Access to [/dev/sdb] is denied.Failed to check whether access to path is grantedFailed to open disk for write.Failed to download disk 'snapshot-909174XXXX'. CC tenant job logging has: <842>    Info (3)    Skipping VcdDatastore (VcdRef=[urn:vcloud:datastore:GUIDXXXXXX], Name=[*CLIENT_DS*]) because it does not have valid underlying vCenter resources VCSA 8.3VCD 10.4xVBR 13Rocky 9.7 latest Kernel.  We have a Sev1 open but its currently pending logging reviews.  

We all have beautifully designed DR plans.Redundant storage. Replication. Immutable backups. Offsite copies.And then the phone rings at 4:07 AM.Adrenaline kicks in. Your brain is half online. Someone is asking for ETAs. Something slightly unexpected is already happening.This post isn’t about the standard “3-2-1-1-0” advice. This is about the obscure, easy-to-ignore details that make or break a real-world recovery. 1. Label. Your. Cables.I know. It sounds basic.But in a real DR scenario: You’re stressed. You’re tired. Things are never exactly as documented. Someone is standing behind you asking, “Is it up yet?” That is not the time to guess which FC cable goes to which SAN port.Label both ends of: SAN connections Uplinks iSCSI paths Replication links Management ports At 4AM your brain power is a limited resource. Use it for decision-making, not tracing cables with a flashlight.Bonus tip: color coding helps. Future-you will be grateful. 2. Name Things Like Your Job Depends

Hello All I am reconfiguring my Backups, and trying to achieve disaster recovery, i want to backup local VMs,Microsoft 365 and Entra ID, for that i am using Veeam Backup and replication V13 (VM) Veeam Microsoft 365 for Email, OneDrive and SharePoint. look to add Entra ID but not sure which Veeam product will be best.for repositories i am thinking one local (immutable backup), Azure Blob (immutable backup) now my question is which product i should use for Entra ID backup, what i should use for local immutable backup, is “Object First” devices good? my backup will be under 8 TB, and what i should use for remote backup Azure or i think Veeam have product cloud vault? what will be best.  

Hello everyone,I would like to get some advice regarding the optimal Veeam architecture for a two-site environment.Infrastructure Hyper-V environment Two locations: Vienna Novi Sad Sites connected with 1 Gbps IPSec tunnel Repository available in both locations Current components: Backup Server Hyper-V hosts acting as on-host proxies Repository Vienna Repository Novi Sad Current designRight now the backup jobs run like this:VMs from both locations → backup to Vienna repositoryThen we run Backup Copy jobs from:Vienna Repository → Novi Sad RepositoryThis means that VMs located in Novi Sad follow this path:Novi Sad VM → Vienna Repo → Backup Copy → Novi Sad RepoSo effectively the data crosses the WAN twice.ExampleVM located in Novi Sad: Backup goes NS → Vienna Backup Copy goes Vienna → NS ObservationDuring the first full backup we see relatively low throughput (~7 MB/s) and Veeam reports Network bottleneck.This is expected since the traffic goes through an IPSec tunne

Hi since upgrading my PVe to version 9.1 and the VBR to 13, the backup performance have degraded a lot. We have 1 worker per pve host, storage is Ceph. Did someone encounter this issue?

Trying to get Veeam Agent for Windows to run, installs without error using:VeeamAgentWindows_13.0.1.1009.exeI get the following error when trying to run anything…Could not load file or assembly 'System.Diagnostics.EventLog, Version=8.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.I installed .net 8.0.24, here’s the list of runtimes…C:\>dotnet --list-runtimesMicrosoft.AspNetCore.App 8.0.24 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]Microsoft.NETCore.App 8.0.24 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]Microsoft.WindowsDesktop.App 8.0.24 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]After installing the runtimes, I’ve removed the agent software, rebooted, reinstalled but the same issue continues.Anybody have any ideas?

Sorry to rant, but I have nowhere else to turn, and it's beginning to impact our clients. Veeam 13 has been absolutely horrible to install on all our backup servers. The upgrades are breaking the installs on current backup servers. It is straight up failing to install and start the Veeam service on a brand new server, and Veeam support has been unable to figure it out for two weeks. I've put escalation requests in and I'm getting nowhere. has anybody seen behaviour like this? The people on the Veeam subreddit agree that Veeam 13 has been horrible to roll out.

Running Veeam agent for Linux, v. 6.3.2.1207_x86_64. OS is Mint MATE 22.  Been making weekly backups for a year or more, just now trying a test recovery on spare computer- loaded some files, ran b/u to ext. drive, deleted files.  Have Recovery Media on stick, using steps in user guide.  All good thru several menus until “Mount Local Disc” which brings up a menu “Select Local Disc” but there are no items from which to select.  Backup drive lights up, so recognized by system.  What am I missing?  

Hi teamCan someone shed some light on this and how best to go about it.We have Nutanix cluster A and Nutanix cluster B.VM have been moved from cluster A with Nutanix Move, which creates a new VM on cluster B and syncs data. My guess is that it creates a new UUIDThere is an existing backup to a Wasabi Repo from cluster A.How can I re-create/re-point the backups that are on the repo so that the copied VM on cluster B can continue to use the backups already there?I am not so sure if there is a remap function for this. I also cannot add vm from the new cluster to the existing job as it only allows me to select existing one. It appears that you select cluster first when creating the job.My guess is I may have to create a new job and let old one age out?

What is this type of issue ? Anyone, please explain.   

I have company policy to not use port 80 and i can see Veeam GatewayAPI was listen on port 80.Can we change this port?  

Hello,i would like to ask, if somebody is not experiencing that issue, that big environments have issue with SSL connection? we have all in one boxes - VBR, VEM and postgresql is on the same machine at the end of postgresql.conf #------------------------------------------------------------------------------# CUSTOMIZED OPTIONS#------------------------------------------------------------------------------# Add settings for extensions heressl = onssl_cert_file = 'backup_server.crt'ssl_key_file = 'backup_server.key'ssl_ca_file = 'backup_root.crt' in svc_veeambackup.log we see[02.03.2026 11:40:10.307]    <35>   Error (3)    0: Breaking connector[02.03.2026 11:40:10.307]    <35> Warning (3)    Failed to obtain connection: [Failed to connect to [::1]:5432]. Attempt 1 of 20. in pg_hba.conf is preferred connextion via ssl# IPv4 local connections:hostssl    all             all             127.0.0.1/32            scram-sha-256host    all             all             127.0.0.1/32      

I need to back up my Windows without using the cloud. I mean that the backup should be stored on my own laptop, not in the cloud. When I downloaded Veeam One, its size was about 3.5 GB, which is quite large.

We have replaced are our physical servers and are decommissioning the old servers.  I have two servers that were setup and functioning as proxies in Veeam.  When i go to remove the server, i get a message saying the server can’t be removed because it is still associated with backups.  The backups it indicates are blocking are no longer jobs and the only references to those names i can find are in the Orphaned and Exported Disks section, but there is no option in there showing an association to a server or a way to change anything.I have opened a case with support (02943295) and so far they are suggesting that we will need to manually edit the database records to remove this association.I am curious if any one else has had to manually modify database records just to remove old servers from Veeam Backup and Replication?  This does not seem to make sense and is likely just masking the real issue.

we have initiated veeam replication job from pr site to dr site and failover to dr site,at dr site after failover we imported vm to VCD and renamed vm to new one and makes changes to replica on VCD,after this we failback to production and commit failback,but changes done on dr site vm are not showing up on pr site vm, what could be the possible issues.  

I have been validating MongoDB full instance restore using Veeam Explorer for MongoDB (VBR v13) and would like to raise a discussion related to file ownership and permissions after restoring.Observed BehaviorWhen restoring a full MongoDB instance to a Linux server, the restored MongoDB data files are owned by the OS user used during the restore process (restore authentication user).As a result:MongoDB service fails to start under the original mongod service account, or The node cannot be cleanly added back to an existing MongoDB replica set Manual post‑restore steps are required (chown / chmod) to revert ownership to the original MongoDB service userThis aligns with current permission requirements documented for MongoDB restore operations, where the restore user must have root privileges on the target system. [helpcenter.veeam.com]Challenge / RiskFrom an operational and security perspective, this introduces several challenges:Requires manual intervention after every full instance resto

We are using an IBM tape drive (standalone) instead of a tape library. We perform tape backups daily at 5:00 PM and 11:00 PM, manually inserting the tapes into the drive.We follow a weekly rotation, where each tape is reused on the same day of the following week (e.g., Monday tape reused next Monday). However, during reuse, we are facing an issue where the backup job does not start.To proceed with the backup, we are manually marking the tape as “Free”, after which the backup runs successfully. However, this causes the previous week’s backup data to be backup again form the disk.

I have two file shares: one for backing up my jobs and one for immutable backups. They are both backing up the same virtual machines. However, my immutable backups keep failing. The immutable repository also shows as Unavailable under Managed Servers.The error I’m getting is: ‘Failed to make the backup file immutable after applying the retention policy: Read-only file system. Unable to open file [.veeam.635.lock] in directory [/BACKUPS/"job_name"] — Error: Read-only file system (POSIX).’

Has anyone encountered any data sovereignty considerations or concerns when working with Native American tribes, particularly regarding offsite backup locations?I proposed adding Veeam Vault or Wasabi as a backup solution for a tribal clinic, and they raised questions about whether their data can be stored in an environment that is not owned or directly controlled by the tribe.

Hello,We’ve recently had to move away from Direct SAN backups as we currently have an open ticket with HPE Nimble regarding an issue affecting that transport mode.In the meantime, we’ve configured Veeam to use HotAdd transport, which is working well for the majority of our environment.However, one specific VM refuses to back up via HotAdd.Environment Summary vSphere environment Backup proxy is a VM within the same cluster HotAdd transport mode (Automatic selection) Fallback to network mode disabled (initially) Veeam account used: adminaccount@vsphere.local (member of vsphere.local\Administrators, inherited from Global Permissions) No snapshot or consolidation warnings on the VM All hosts in cluster have access to the same datastores Problem VM Details VM has 11 virtual disks A couple of disks reside on a different datastore Veeam successfully creates the VMware snapshot Failure occurs during HotAdd disk attach Behaviour ObservedWhen the job runs: Snapshot creation suc

.

Hi everyone,I have a SureBackup issue and I’m trying to understand the IP selection behavior.SetupRepository server has two NICs:Management NIC 192.168.10.191 Has gateway Domain profile iSCSI NIC 172.16.100.11 No gateway No DNS Used only for iSCSI to Synology ProblemSureBackup fails with: Failed to connect to the endpoint [172.16.100.11:2500]Veeam is trying to connect to the iSCSI IP instead of the management IP.What I verified VBR can connect to 192.168.10.191:2500 → OK VBR cannot reach 172.16.100.11 → expected VeeamTransportSvc is running Port 2500 is listening Firewall rule for 2500 exists iSCSI NIC has no gateway Management NIC has lower metric Windows DNS API returns192.168.10.191172.16.100.11So management IP is first.  

Orchestrator Embedded VBR Repair Required.Have a ticket opened with Support for a week now but so far we haven’t figured out the cause of the issue. We have tried to refresh the Registry entry below and reset the state in the VAO DB and restarted the Backup Orchestrator Agent but to no avail.  Connection to an external VBR is working as shown above as Healthy. Thanks again for the community’s input/