Veeam v13: Direct Backup to Azure

Veeam v13 Series | Component: VBR v13, Azure Blob Storage | Audience: Enterprise Architects, Hands-on Sysadmins

Azure Blob is the Microsoft native choice for VBR's capacity and archive tiers, and it's the right call for organizations already running Azure workloads, paying for an Azure enterprise agreement, or building a hybrid retention architecture between on-premises and Azure IaaS. It's straightforward once you understand the access model: VBR connects through an Azure Storage Account, and the authentication uses either a storage account access key or a service principal with RBAC. Both work. Service principals are better for security and auditability.

This article covers the Azure storage account setup and access configuration, object storage repository configuration in VBR, immutability with Azure Blob immutable storage policies, Azure VM restore workflows, and the hybrid retention architecture for environments splitting operational backup between on-premises repositories and Azure for long term retention.

1. Azure Storage Account Setup

Storage Account Configuration Requirements

• Account kind: StorageV2 (general purpose v2). Legacy account types (BlobStorage, StorageV1) are not supported for VBR object storage repositories.
• Redundancy: LRS (Locally Redundant Storage) is sufficient for backup data since VBR maintains its own redundancy through primary and copy jobs. GRS or ZRS add cost without adding backup specific value. Use GRS or ZRS only if regulatory requirements mandate it.
• Access tier: Hot or Cool at the storage account level. VBR controls tier selection at the individual blob level (Hot, Cool, Cold, Archive) independently of the account level default.
• Hierarchical namespace: Disabled. Azure Data Lake Storage Gen2 hierarchical namespace is not supported for VBR object storage repositories.
• Blob versioning: Required if you intend to enable immutability. Enable versioning before creating the container you'll use for VBR.

Service Principal Setup (Recommended over Access Keys)

# Login and set the target subscription
az login
az account set --subscription "your-subscription-id"

# Create the storage account (if not already created)
az storage account create \
  --name veeambackupstorage \
  --resource-group veeam-backup-rg \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --allow-blob-public-access false \
  --min-tls-version TLS1_2

# Create a service principal for VBR
az ad sp create-for-rbac \
  --name "veeam-vbr-backup" \
  --role "Storage Blob Data Contributor" \
  --scopes "/subscriptions/your-subscription-id/resourceGroups/veeam-backup-rg/providers/Microsoft.Storage/storageAccounts/veeambackupstorage"

# Output includes appId (client ID), password (client secret), tenant ID
# Store these securely - they're the VBR service principal credentials

# Enable blob versioning (required for immutability)
az storage account blob-service-properties update \
  --account-name veeambackupstorage \
  --resource-group veeam-backup-rg \
  --enable-versioning true

2. Configuring the Azure Blob Repository in VBR

1. In VBR, go to Backup Infrastructure, then Object Storage Repositories, and click Add New. Select Microsoft Azure Blob Storage.
2. On the Account step, choose Service Account (for service principal) or Shared Key (for storage account access key). Enter the tenant ID, application ID, and application secret for service principal authentication. For access key, enter the storage account name and key directly.
3. Select the subscription, storage account, and container. Create a dedicated container for VBR. Don't share a container with other Azure workloads.
4. Select the blob storage tier. Hot, Cool, Cold, and Archive are available. Hot is appropriate for operational restore windows (data accessed within 30 days). Cool reduces storage cost for data accessed less than monthly but adds retrieval cost. Cold is between the two. Archive is for long term retention data you access rarely, with retrieval latency measured in hours.
5. Enable immutability if required. See Section 3 for the full immutability setup.

3. Immutability with Azure Blob Immutable Storage

Azure Blob supports two types of immutability policies: time based retention policies and legal hold policies. VBR uses time based retention policies when you enable immutability on the object storage repository. The policy is set at the container level and applies to all blobs in that container.

Container level vs Version level Immutability

Azure offers two immutability scopes:

• Container-level immutable storage: The older model. The retention policy applies to all blobs in the container and can't be changed to reduce the retention period once set. Extending the period is allowed. VBR supports this model.
• Version-level immutability: The newer model requiring blob versioning. Retention policies apply per blob version rather than per container. VBR also supports this model and it's preferred for new deployments because it allows more granular control.

# Blob versioning must be enabled on the storage account first (done in Section 1)

# Create the container if it doesn't exist
az storage container create \
  --name veeam-backups \
  --account-name veeambackupstorage \
  --auth-mode login

# Enable version-level WORM immutability on the container
az storage container immutability-policy create \
  --account-name veeambackupstorage \
  --container-name veeam-backups \
  --period 30 \
  --allow-protected-append-writes true

# Lock the policy (makes it permanent - cannot be shortened, only extended)
# Only lock if you're certain of the retention period
# Unlocked policies can be deleted if needed - locked policies cannot
# az storage container immutability-policy lock \
#   --account-name veeambackupstorage \
#   --container-name veeam-backups \
#   --if-match "[etag-from-create-command]"

4. Azure Blob Access Tiers and Cost Modeling

Archive tier rehydration takes up to 15 hours in standard priority and 1 hour in high priority. High priority rehydration costs more per GB. For any data with an RTO shorter than 15 hours, Archive tier is the wrong choice. Cold or Cool tier maintains near instant access while still reducing costs significantly versus Hot.

5. Azure VM Restore Workflows

Restoring from an Azure Blob backed repository to Azure VMs uses the same VBR restore workflows as on-premises restores, with the Azure compute target specified during the restore wizard. VBR reads the backup data from Blob storage and creates the Azure VM with managed disks.

Instant Recovery to Azure

Instant Recovery to Azure uses vPower NFS to mount the backup directly in an Azure hosted helper appliance (the Veeam Worker) and registers the VM in Azure. The VM starts quickly from the mounted backup, giving you the fastest RTO. After the immediate availability window, VBR migrates the VM storage to permanent Azure Managed Disks in the background. This is the right restore path when time to availability is the priority.

Full Restore to Azure

Full restore creates the Azure VM directly from the backup data without the staging step. The process takes longer to start (VBR has to read and convert the backup data) but the resulting VM runs on permanent Managed Disks from the start with no background migration needed. Use full restore when you want a clean production VM state immediately, not a staging state that transitions to production.

6. Hybrid Retention Architecture

The most common VBR-to-Azure architecture for environments with both on-premises and Azure workloads separates the operational restore window from the long term retention window using Azure Blob as the capacity and archive tier in a SOBR.

The design: a SOBR with local disk (SSD backed NAS or DAS) as the performance tier for 14 to 30 days of operational restore points, and Azure Blob Cool or Cold tier as the capacity tier for 90 to 365 days of retention. The performance tier handles restores that need fast access. The capacity tier handles compliance and long term retention. The SOBR offload job moves data from the performance tier to Azure as it ages out of the operational window.

For environments with 7+ year retention requirements, add Azure Blob Archive tier as the archive tier below the capacity tier in the SOBR. Data ages from local disk to Cool/Cold, then from Cool/Cold to Archive as it passes the defined age thresholds. Restores from the archive tier require the rehydration window. Document this in your recovery procedures so operations teams aren't surprised by the wait time.