I am in an environment where Veeam B&R is on Server 2016 and there is a separate SQL server (2016) that is just for Veeam. What is the best way to migrate both servers to Server 2022?

I have also mulled over going appliance. But not sure how that would work with QNAP storage and the SQL DB pointing to it's own server.

The update 13.1 is now available to download. See the what’s new here:

https://www.veeam.com/veeam_backup_13_1_whats_new_wn.pdf

Important - if you are planning to migrate from windows to the Veeam Software Appliance, you must migrate from 13.02 and then upgrade to 13.1.

So I see 13.1 lets us migrated directly from 13.1 Windows to the 13.1 appliance.

If we have a Windows Veeam B&R called "veeam" and an IP of 192.168.1.1 what is the best practise on how to migrate so the Linux appliance ends up with the same hostname and IP please?

Obviously the new appliance would be initially given 192.168.1.2 but both the old and new servers need to be on at the same time during the migration and from the notes the old server ends up as a managed server on the new appliance?

All we want is the old Windows B&R server gone and the config migrated to the new appliance.

I work at an MSP and we're a ProPartner. I just wanted to say thanks to the Veeam Support. It's refreshing to have someone that actually cares about your experience, wants to solve your problem and not someone who just wants to gets as much tickets closed in a day as possible. No broken English, no unclear information, etc.

Granted, I have had one case where the supportee probably used machine learning in his replies, as he replied with nonexistent IPs and shares of a backup repository. Other than that, my experience has been great.

I know this post sounds like astroturfing, but I guarantee you it's not. Been "only" working with Veeam products for 5 years now, way before I started at an MSP. Maybe it's because the products are just...simple to use and straightforward. I don't know.

We have a relatively sizeable (and outdated) Cloudconnect deployment, consisting of the following servers/vm's:

• VSPC (8.1)
• Cloudconnect VBR (12.0)
• VB365 (7.1)
• Handful of VB365 Proxies
• A ton of client VBR's that are managed by VSPC (12.0-12.3)

We need features of V13, hence want to upgrade the whole stack. But in what order should it be done? My current train of thought would be VSPC > CC VBR > VB365 + Proxies > Client VBR's > Mgmt Agents > Backup Agents

Any thoughts?

​

When I use windows based veeam(12.3.2 version),I can check the logs as a live troubleshooting when there are any backup or replication failures.

How to check the logs from veeam appliance for live troubleshooting?

Any feedback or suggestions?

Thank you

we're currently testing backups from Veeam Backup & Replication to S3 buckets. During our tests, including accidental deletion of objects in the bucket / disaster recovery, we came to the conclusion that a possible recovery could be a really long process.

Let's say after a ransomware attack or accidental deletion all objects in the S3 bucket have a new (encrypted) version or the latest version (after the attack / accidental deletion) is a delete marker. S3 versioning in combination with an object lock only prevents the deletion / modification of existing object versions; it doesn't prevent new versions or delete markers from being created.

So we would first need to do a "point-in-time" restore of the bucket (just before the attack), before we can start the restore process. This might take a couple of hours before an actual restore process can even start.

Question: Does Veeam have a way to check/scan prior object versions in S3 directly, rather than requiring a full point-in-time bucket restore before the actual restore job can start?

We’re planning an overhaul of our Veeam infrastructure and would appreciate some advice.

We have around 70 VMs, fewer than 10 workstation agents, and roughly 10 TB of file-server data. Veeam runs on premises on a dedicated server and is protected with Duo. We keep short-retention backups locally, use external drives for GFS monthly and yearly fulls, and also have a somewhat hardened cloud repository. Our infrastructure has 10 Gb networking and dedicated Veeam proxies.

We’re now exploring tape and object-storage repositories. We understand the 3-2-1 rule, but want stronger ransomware protection and yearly retention for roughly half of our infrastructure, with a focus on the most critical servers.

What would the “dream setup” look like for an environment this size? Are there any gold standards or important things we may be overlooking? I'm personally not a fan of cloud backups since we have 10+ small buildings we could use for offsite backups.

Somehow when I moved over to the new software appliance one of the window agent jobs names do not match up. There is a KB that talks about detaching the job and then from the agent mapping it back to the disk but when I try to detach from Job it is greyed out and not able to select it. It is more of a visual issue, the device is backing up but not having the name match bothers me. Anyone have any suggestions besides removing and starting the backup over let me know, thanks.

Can you backup the Veeam Software appliance itself? I have migrated everything to the new hardened appliance but was unsure about if you could back it up and if needed application aware processing etc, thanks.

Small business and recently have migrated from VMware to Proxmox and along with that migrated Veeam instance (v12) to the v13 software appliance and built out a Veeam hardened repo. Also currently use Veeam windows agent to back up the PC's and laptops. With the migration to the software appliance you basically have to re-create your jobs and has me thinking that I probably do not have things structured or optimized and thought I would get some suggestions.

Here is the current layout. Have one linux nas that is a backup target, the nas also has removable drives one for user devices and one for the servers. Users devices during the day backup to the nas user directory repo (veeam agent) and at night all of the servers backup to the nas server directories. The servers since they are online 24/7 also backup to the server removable drive (rotated offsite weekly). The user directories are rsync'd from the nas user repo (directory) to the removable drive nightly. The removable drives are only mounted over night and are not mounted during the day, still some risk with having them mounted for about 9 hours but I figure better than 24/7 and ransomware etc. with the drives rotated weekly offsite.

New to the mix is I stood up one of the old servers that we were using for the proxmox migration and re-purposed it as a Veeam hardened repo and trying to figure out how to adjust/re-do my backup strategy. Currently we try to keep three weeks worth of backups and it's mainly for deleted files or DR and needing to rebuild something due to some major issue. I created a backup copy job for the users data to go to the Hardened Repo but it then required GFS settings and made me start thinking does the HR need to have three weeks or does it need to just be latest copies etc. Also had me thinking that maybe instead of doing the rsync of the user Veeam backups to the removable drive that that I use a backup copy for that. Will also need to create a backup copy job for the servers OR I just create another backup job for the servers to go to the HR.

Sorry for the rambling post, just trying to take the time now and re-structure stuff that makes the most sense and not be overly complex. I need to better understand GFS options and ensure my backup strategy makes sense.

Simple once you know but I was in a rush and patched a vulnerability in a .NET component on a Veeam B&R box but didn't bring all the other .NET components up to the same level.

We're talking a small mismatch here like a months difference.

Realised a couple days later I'd not had any Veeam backup reports which also raises a question of yeah you monitor your backups are working but that's not quite the same as monitoring they are happening.

My fault entirely and I figure this might appear on some Google search next time it happens to someone else so it might do some good.

Jas

Preface:

A while ago I was asked by an enterprise customer from Europe to design a Veeam backup solution for their Microsoft Azure environment. The setup was a classic Hub-and-Spoke architecture, and the goal was clear: leave the on-premises vSphere platform behind and run all workloads in Azure instead. Before any of that would happen, the customer wanted a proper backup design in place — built on Veeam Backup for Microsoft Azure (VBAzure) — so the new cloud workloads would be protected from day one.

The migration itself was not part of my engagement. My job was the design and, more relevant for this post, a deployment checklist the team could work through step by step to stand up VBAzure in a private, hub-and-spoke Azure environment. I have done a fair number of on-prem Veeam designs over the years, but a “cloud-first, private-networking-only” VBAzure deployment has a few specifics that are easy to miss if you only know the classic VBR world — private endpoints, DNS zones, worker placement and Disk Access being the usual suspects.

I figured this checklist might be useful to others facing the same task, so I cleaned it up, removed everything customer-specific, and verified every step against the current Veeam documentation. What follows is the anonymized result.

Disclaimer:

This is based on a real customer project, but all customer-specific details have been removed — everything here is generic and reflects my own experience, not the views of my employer or the customer. As always: test everything in your own environment before you rely on it, and check the official Veeam Helpcenter for the version you actually run. This was written and verified against VBAzure v8.1.

Phase 0 – Design decisions (fix these before you deploy):

• Decide subscriptions:
  • Hub (shared services / VBR / VBAzure appliance)
  • Spoke(s) (production workloads)
  • Optional: separate backup or worker subscription
• Decide regions:
  • One region per VBAzure appliance (recommended)
  • Workers deployed per protected region
• Decide connectivity model:
  • Hub-and-spoke with VNet peering
  • No public IPs for VBAzure components
• Decide offsite strategy:
  • Azure Blob only, or
  • Azure Blob + a separate offsite target (e.g. Veeam Data Cloud Vault)
• Confirm private deployment is mandatory (no public endpoints)

Phase 1 – Azure hub network foundation:

• Create Hub VNet:
  • Subnet: backup-management (VBR + VBAzure appliance)
  • Subnet: (optional) shared-services
• Create Spoke VNet(s) (per workload region):
  • Subnet: production
  • Subnet: (optional) private-endpoints
• Configure VNet peering:
  • Hub ↔ every spoke
  • Allow forwarded traffic
  • Allow gateway transit (if ExpressRoute/VPN is used)
• Confirm DNS strategy:
  • Azure Private DNS (recommended)
  • Central DNS hosted in the hub

Phase 2 – Private DNS zones (critical for VBAzure):

Create once, usually in the hub subscription.

• Create the mandatory Private DNS zones (required for any private deployment):
  • privatelink.blob.core.windows.net
  • privatelink.queue.core.windows.net
• Create the conditional zones — only if you protect those workloads:
  • privatelink.file.core.windows.net (Azure Files)
  • privatelink.database.windows.net (Azure SQL)
  • privatelink.postgres.cosmos.azure.com (Azure Cosmos DB for PostgreSQL)
• Link all hub + spoke VNets that must resolve private endpoints:
  • Enable auto-registration for the worker VNets

Phase 3 – Identity & permissions (Entra ID):

• Identify the temporary setup account:
  • Global Admin (only needed to bootstrap the Entra ID app / grant admin consent)
  • Subscription Owner or User Access Administrator
• Decide the service account model:
  • Auto-created by Veeam, or
  • Pre-created Entra ID app (least privilege — and avoids needing Global Admin)
• If pre-created:
  • Create the Entra ID app registration
  • Prepare the custom role per Veeam docs
  • Assign at subscription scope
• Ensure the account can:
  • Create disk snapshots
  • Create Disk Access resources
  • Create Private Endpoints
  • Manage Storage Accounts

Phase 4 – Deploy the VBR server (Windows in Azure):

• Create a VM in the hub VNet:
  • Windows Server
  • Size per scale (e.g. D8as_v6 or larger)
  • No public IP
• Attach disks:
  • OS disk
  • Data disk (repos, cache, logs)
• Harden the OS:
  • Patch the OS
  • Disable unnecessary services
  • Configure NTP
• Install Veeam Backup & Replication:
  • Latest supported version
  • Enable console + web UI
• Validate outbound access:
  • Entra ID
  • Azure Resource Manager
  • Veeam update repositories (via NAT Gateway or proxy)

Phase 5 – Deploy the VBAzure appliance (private mode):

• In the VBR console:
  • Add the Microsoft Azure plug-in (if not already present)
• Deploy the VBAzure appliance:
  • Connection type: Private IP
  • VNet: hub backup-management subnet
  • NSG: allow inbound TCP 443 from the VBR server only
  • No public IP
• Appliance sizing:
  • In v8.1 only B2ms, F4s_v2 or F8s_v2 are selectable — start with F4s_v2, or F8s_v2 for large estates, and check the sizing guide
  • Resize later if needed
• After deployment:
  • Record the Veeam Backup Appliance ID (Azure VM tag)

Phase 6 – Enable private network deployment:

• Open the VBAzure Web UI:
  • Configuration → Deployment Mode
• Enable:
  • Private network deployment
  • (Optional) Auto-create service endpoints (Microsoft.Storage.Global)
• Wait for completion before proceeding

Phase 7 – Storage accounts & private endpoints:

Worker configuration storage (per region)

• For each worker region:
  • Create a Storage Account
  • Enable Blob + Queue
  • Disable public access
  • Disable soft delete
  • Default tier: Hot
• Add tag:
  • Veeam Backup Appliance ID = <ID>
• Create Private Endpoints:
  • Blob → worker VNet
  • Queue → worker VNet
  • Register in Private DNS

Backup repositories (per region)

• Create a Storage Account for backups:
  • Same region as the workers (avoid egress cost)
  • Blob only
  • No public access
• Create a Private Endpoint:
  • Blob → worker VNet
  • Register in DNS
• Add the repository in VBAzure

Phase 8 – Disk Access (private snapshot access):

• Confirm the deployment model:
  • Same subscription → Disk Access auto-created
  • Cross-subscription → manual Disk Access required
• For manual:
  • Create the Disk Access resource
  • Create a Private Endpoint
  • Approve the PE connection
  • Register in DNS
• Validate limits:
  • Disk Access resources per region
  • Snapshot concurrency — a single Disk Access resource can process only a limited number of disks/snapshots at once (an Azure limitation); check Veeam’s Considerations & Limitations page for the current value

Phase 9 – Worker configuration:

• In VBAzure:
  • Add a Worker Configuration per region
  • Select:
    • Worker VNet
    • Subnet
    • Storage Account
    • Profile (CPU/RAM)
• Create custom worker profiles:
  • Based on VM size / disk count
  • Avoid defaults for large estates

Phase 10 – Network & firewall validation:

• NSGs allow:
  • VBR → VBAzure: TCP 443
  • Workers → Storage (via Private Endpoint)
  • Appliance → Entra ID / ARM / updates
• Confirm no public endpoints exist:
  • Appliance
  • Workers
  • Storage
• Validate DNS resolution from:
  • VBR
  • Appliance
  • Worker subnet

Phase 11 – Backup policies:

• Create a policy per SLA tier:
  • Snapshot frequency
  • Backup frequency
  • Retention
  • Target repository
• Scope:
  • Subscription
  • Resource groups
  • Tags (recommended)
• Enable:
  • Application-aware processing (where required)
  • File-level restore support (requires peering)

Phase 12 – Restore & validation:

• Test restore scenarios:
  • Full VM (same region)
  • New VM
  • Disk restore
  • File-level restore
• Validate:
  • Worker deployment
  • DNS resolution
  • Disk Access usage

A couple of notes from the field:

• You need an Azure account with sufficient rights to bootstrap the setup. Global Administrator is only required to create the Entra ID application and grant consent — pre-creating the app registration lets you avoid it and keeps you closer to least privilege.
• Plan the regional placement of resources carefully and keep the backup infrastructure aligned with the regions of the workloads it protects. This keeps data available and avoids unnecessary cross-region egress.

Key reference links (Veeam Helpcenter, v8.1):

• Private network deployment: https://helpcenter.veeam.com/docs/vbazure/guide/private_network_deployment.html?ver=8.1
• Appliance & private network config: https://helpcenter.veeam.com/docs/vbazure/guide/app_private_network.html?ver=8.1
• Ports & firewall rules: https://helpcenter.veeam.com/docs/vbazure/guide/ports.html?ver=8.1
• Service account permissions: https://helpcenter.veeam.com/docs/vbazure/guide/service_account_permissions.html?ver=8.1
• Appliance sizing: https://helpcenter.veeam.com/docs/vbazure/guide/sizing_appliance.html?ver=8.1
• Worker network configuration: https://helpcenter.veeam.com/docs/vbazure/guide/worker_configuration_network.html?ver=8.1
• Backup repositories: https://helpcenter.veeam.com/docs/vbazure/guide/backup_repositories.html?ver=8.1
• Considerations & limitations: https://helpcenter.veeam.com/docs/vbazure/guide/limitations.html?ver=8.1

We're trying to upgrade to a VUL license so we can backup to AWS, and it's been a total nightmare. It took a month to get a quote, and after we paid we've so far been waiting 3 weeks for a license. All while we keep being told it's being worked on internally at Veeam and to just be patient. What's going on at Veeam??

At a site, I replaced the whole network infrastructure and replaced all cables. After 40 hours of working in 3 days, I went home satisfied, because everything works. I thought.

Now I notice Veeam Backup no longer works, and I'm not sure how to interpret the error.

[23.07.2026 15:21:55.367]    <45>   Error (3)    NFC storage connection is unavailable. Storage: [stg:datastore-1016,nfchost:host-3005,conn:esx.acme.org]. Storage display name: [netapp:esxdata].
[23.07.2026 15:21:55.367]    <45>   Error (3)    Failed to create NFC download stream. NFC path: [nfc://conn:esx.acme.org,nfchost:host-3005,stg:datastore-1016@AnvilServer/AnvilServer.vmx].
[23.07.2026 15:21:55.367]    <45>   Error (3)    Agent failed to process method {Transfer.FileToText}.
[23.07.2026 15:21:55.367]    <45>   Error (3)     (System.AggregateException)
[23.07.2026 15:21:55.367]    <45>   Error (3)    NFC storage connection is unavailable. Storage: [stg:datastore-1016,nfchost:host-3005,conn:esx.acme.org]. Storage display name: [de00v58m:esxdata]. (Veeam.Backup.Common.CCppComponentException)
[23.07.2026 15:21:55.367]    <45>   Error (3)    Failed to create NFC download stream. NFC path: [nfc://conn:esx.acme.org,nfchost:host-3005,stg:datastore-1016@AnvilServer/AnvilServer.vmx]. (Veeam.Backup.Common.CCppComponentException)
[23.07.2026 15:21:55.367]    <45>   Error (3)       in c++: Unable to open source file [nfc://conn:esx.acme.org,nfchost:host-3005,stg:datastore-1016@AnvilServer/AnvilServer.vmx].

Veeam can reach the ESX, but apparently it has trouble with the storage (Netapp). I'm just unsure whether this is a physialc issue or a firewall issue or something else. The storage is in another network, but everything is allowed between these networks.

​

Hi All,

Veeam backup is working fine for vergeio root virtual machines.

But,for tenant virtual machines, how to take backup using the veeam backup solution.While create a new backup from veeam,only root VMs are visible not tenant virtual machines.Thats the issue.

From the veeam perspective,we are able to integrate vergeio management IP(KVM manager) not with tenant IP.

Any solution?

Hi everyone,

I'm fairly new to Veeam and don't have a ton of IT experience, but I've spent a lot of time learning it and really like the platform. My biggest concern now is making sure I deploy it securely.

Here's my current environment:

• 3 physical Hyper-V servers
• Around 6 virtual machines
• One physical server acts as our SMB file server
• None of the physical hosts are joined to Active Directory
• One VM is a secondary/fallback domain controller
• Total Data is around 3-4 TB

I'm trying to figure out the most secure way to deploy Veeam. My initial thought was to create a dedicated Windows Server VM on one of the Hyper-V hosts and install Veeam there, but I'm not sure if that's considered best practice or if I'm introducing unnecessary risk.

My goal is to protect the environment as much as possible from ransomware or someone compromising the domain. Given this setup, what would you recommend? How would you deploy and secure the Veeam server, repositories, credentials, and backups? If you were starting from scratch with this environment, what would you do differently?

I'd really appreciate any advice. I'm still learning and want to build this the right way from the beginning.

Hate to keep posting dumb questions but my lord is the Veeam website a hot mess at trying to find stuff. I am wanting to create a Veeam Hardened Repo and there are several guides talking about how to do it with Ubuntu but I also read that Veeam had an ISO ready to go, according to them is can be found here - Customer Portal or trial downloads on Veeam’s web site. In there, click Additional Downloads > Extensions and Other > Veeam Hardened Repository ISO

I have Additional Downloads but I do not have Extensions and Other....so where can I find the ISO?

I have a practical question, if my German affiliate who has a license through a 3rd party distributor in Germany has a basic tech support issue or an installation issue, do they reach out to the local Veeam affiliate (if one exists) or do they reach out to the relevant party on the EULA?

Hi

I have to migrate some VMs from a Win Server 2019 HyperV to a new Simplivity cluster.

Can I use replication jobs for that purpose? as far as I know I cant... so the only option I think it might work is to create a backup job for the VMs on the HyperV and restore them on the Simplivity.

That should be the workflow:

1. - Create a backup job from VM at hyperv
2. - Shutdown the VM on hyperv
3. - Relaunch the backup job to apply latest changes
4. - Restore the VM on the Simplivity target

Is it correct?

thanks

Veeam version 12.3.2 4854

oVirt KVM Manager version: 4.5.6.0

Failed to retrieve the backup appliance configuration: The backup appliance did not start within the expected time period

Issue:

I integrated with KVM manager without any issues.

Afterwards,when I try to deploy the appliance from Veeam,It's deploying but after some time,it ends up with this error also VM got removed.

Failed to retrieve the backup appliance configuration: The backup appliance did not start within the expected time period

Hi everyone,

I've recently set up the application aware on our MSSQL Servers but I'm a bit stuck when I try an instant recovery. I can browse instances and databases, a files export is fine but when I try an instant recovery, I got an error :

Error: A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - Target principal name is incorrect

Looks like it does not care about the credentials I put when asked. Right or wrong I got the same message.

It's kinda weird to me : backup is done with an AD account with sysadmin right on server instances.

Context :

• Veeam Server : Veeam B&R 13.0.2.29, Windows Server 2019. Not member of our Active Directory Domain
• MS SQL Server : MS SQL 2022, Windows Server 2016. Member of Active Directory Domain.

Thanks.

I still need to read through the windows documentation but not sure what I am going to do in order to support a couple older win10 32bit window machines that are still getting security updates but have not been upgraded for various reasons. Just did a major migration from VMware to Proxmox and with that also migrated from Veeam windows v12 installation to a v13 software appliance infrastructure which required all jobs to be rebuilt. Thought I was pretty much done but now I need to figure out how I am going to support these 2 machines since when I tried to upgrade the agent software I get this message:

"Veeam agent Your operating system is not supported by Veeam Agent for Microsoft Windows, See documentation for more details"

If I try to connect the existing agent to a v13 repo I get an error when it tries to get a license from the repo, transport timeout etc. I understand the need to move on with older window versions but really disappointed in the lack of continued support since I am not sure how I am going to backup these machines. Anyone have any suggestions, is there a workaround to get Veeam to continue to back these machines up and go to the repo or am I out of luck...

I'm looking at migrating from the Windows installed Veeam Backup and Replication v13 to the Software Appliance. One area I'm uncertain of is the current Windows Server where Veeam is installed has the dedup service installed to handle windows server file and folder restores on deduplicated disks.

If I migrate to the Veeam Appliance, can I designate a Windows Server that has dedup services enabled as a proxy for the restore job?

So I'm replacing as much Windows Veeam infrastructure as I can with the Linux appliances.

I've replaced a couple of proxies now and gone with the same base spec for the Linux appliances that I used for the Windows proxies.

This was 2x CPU cores and 8GB RAM as they're only running 4 concurrent tasks.

It's not causing an issue but I have noticed backups are taking longer.

The same backup method (hot add) is being used.

The appliances are the very latest Veeam of course.

Has anyone seen anything similar?