If you’re managing backups stored in the cloud, you’ve probably wrestled with infrastructure headaches, cost control, and security. Enter Veeam Data Cloud Vault (VDC Vault)—Veeam’s fully-managed, secure cloud storage solution built on Azure Blob Storage. VDC Vault isn’t just another bucket in the cloud; it’s a hands-off, immutable, designed to keep your data out of harm’s way and out of your own infrastructure.
So why choose VDC Vault? You get Azure’s scale and security, but with Veeam’s management, automation, and immutability baked in. It’s separated from your own environment, making it ideal for ransomware recovery, long-term retention, and compliance. You don’t need to DIY your own BLOB storage or worry about setting it up correctly—Veeam handles all that for you. It’s a simple subscription service: add Vault as a repository in Veeam Backup & Replication (VBR), set up your jobs, and you’re off.
Many organisations are moving to VDC Vault but, as with all migrations, there are caveats and best practices. Here’s what we’ve learned.
Key Migration Points & Findings
Encryption – Double Encryption
For backups to land directly in VDC Vault, job-level encryption is required. If you’re using SOBR (Scale-Out Backup Repository), you can choose to only encrypt at the capacity tier (not the job level) which avoids double encryption if desired. Avoiding double encryption is not necessarily a best practice; however, it’s an important consideration given performance extents such as ExaGrid, DataDomain and StoreOnce deduplication appliances will perform better if backups stored on them are not encrypted
Egress Cost Minimisation
Data transfer costs in Azure can add up if not carefully managed. As of 2024, Microsoft has updated its pricing so that data transfer between availability zones within the same Azure region is no longer charged (see Azure update). This means that whether your AzureVM (configured as the Veeam Gateway) and your VDC Vault (Blob Storage) are in the same or different availability zones, as long as they are within the same region, you should not be charged for data transfer between them—even if a public endpoint is used.
Of course, to be safe, and because it’s not possible to confirm which availability zone the VDC Vault resides in, it’s always best to configure a service endpoint for VDC Vault.
- Keep both your gateway VM and VDC Vault in the same Azure region; intra-region traffic (even between availability zones) is free.
- Egress charges should only apply if data leaves the Azure region, such as to the internet or on-premises.
- To optimise routing and maintain security, it’s still recommended to configure a service endpoint for VDC Vault (Microsoft.Storage.Global).
- Use AzureVMs as gateway servers to ensure data flow remains within Azure and not to on-premises, which would incur egress costs.
- Be mindful if you
Gateway Server & Data Flow
- In “Direct Mode,” your mount server acts as the gateway. If it’s on-prem, expect egress when traffic is read from your source BLOB back to on-premises then pushed back out to VDC vault.
- Best practice: deploy a temporary Azure VM as your gateway server to keep transfers internal within Azure and fast.
Networking – Service Endpoints are Key
- Private endpoints: Not supported for VDC Vault yet.
- Service endpoints: Recommended. Configure at the vNet layer; all VMs in the vNet will use it. (Use Microsoft.Storage.Global for VDC Vault)
- ExpressRoute: Use Microsoft Peering for public Azure services. For Private Peering, the gateway must be in Azure. Read Veeam KB4745 for details.
Availability Zones
Confirm which availability zone(s) your backups reside in. This helps optimise gateway placement and performance.
Migration Steps
- Register and add VDC Vault to VBR.
- Add Vault to SOBR.
- Put old Blob capacity tier in maintenance, evacuate backups.
- Remove old capacity tier after migration.
While the old (source) capacity tier extent is in maintenance mode, Veeam will not run any offload jobs to any capacity tier in the SOBR. This means new backups will not be offloaded or copied to any capacity tier while the migration is running, this may impact your ability to copy backups offsite (achieve 3-2-1). For this reason, it is important to size the gateway server appropriately to ensure the migration can be completed within an acceptable timeframe.
Performance Tuning
Decryption and re-encryption hit CPU hard. Recommend the following sizing.
- 4 GB RAM per concurrent migration task
- 1 vCPU per 2 concurrent tasks
- Example: 58 concurrent tasks (to move 500 TB in 48 hours) = 232 GB RAM, 29 vCPU
- Most start with 4–16 tasks, perform basic migration test first and tune as needed
Immutability
- Orphaned backups keep the longest of their original immutability or job retention period.
- Manual cleanup needed for orphaned backups after retention ends.
- New repository settings take over post-migration—immutability defaults to 30 days on VDC Vault.
Gateway Server Placement
Keep the gateway server in Azure, in the right region, to avoid egress and maximize speed.
Miscellaneous Tips
- Public endpoints can be enabled at the same time as private endpoints.
- Private endpoint DNS: Remove DNS server from Azure VM if you want to avoid resolving private endpoints.
- Host table entries may be needed for VBR resolution.
- For public access, restrict to the vNet/subnet used by your Azure VM.
- BCJ Vault-to-Vault avoids egress if all components are in the same region.
- Routing through on-prem firewalls? Expect extra egress/network charges.
AVS (Azure VMware Solution) Nuances
- You’ll likely need a gateway in Azure IaaS, not AVS, with a service endpoint.
- AVS connects via ExpressRoute, acting like on-prem.
- For restores/reads from Vault: Data uses Microsoft’s backbone if the gateway is in your Azure tenant, connected via ExpressRoute/private peering.
Final Thoughts
VDC Vault is a leap forward for cloud backup security and simplicity, but migrating isn’t a “click and forget” affair. Get your encryption, networking, endpoints and gateway placement right, and you’ll dodge surprises on cost and performance.