A Complete Guide to Veeam Cloud Backup
Extending your Veeam infrastructure with immutable offsite cloud repositories, a practical reference for Veeam administrators.
On this page...
You already run Veeam Backup & Replication. You understand jobs, repositories, retention chains, and the value of application-consistent snapshots. What this guide addresses is the next logical step in a robust 3-2-1-1-0 strategy: getting a copy of your Veeam backups into an immutable, offsite cloud repository, and doing it in a way that doesn’t compromise your existing architecture.
This is not a primer on backup concepts. It’s a practical reference for Veeam administrators evaluating or implementing cloud-based backup offload, covering repository configuration, transport modes, immutability mechanics, and recovery scenarios.
Why Your On-Premises Veeam Deployment Needs a Cloud Tier
The 3-2-1-1-0 rule in practice
Most mature Veeam environments already satisfy the first three elements: three copies of data, on two different media types, with one copy offsite. The second “1” — one immutable or air-gapped copy — is where many deployments still have a gap.
A hardened Linux repository on-site satisfies immutability technically, but it does not satisfy the geographic separation requirement. A ransomware event that propagates laterally, a fire, or a flood affecting your primary data centre will impact both your production workloads and your local hardened repo simultaneously.
What cloud-tiered storage solves
- Geographic isolation: Your cloud copy lives in a physically separate location, managed by a separate credential set, unreachable from your production network during an attack.
- Object lock immutability: S3-compatible object storage with WORM locking means even a compromised Veeam backup server cannot delete or overwrite cloud copies within the lock period.
- Retention extension without capital expenditure: Long-term retention (LTR) to cloud is significantly cheaper than expanding on-premises disk or tape infrastructure.
- Recovery flexibility: Direct restores from cloud, including Instant VM Recovery® from object storage, without needing to recall data to an intermediate repository first.
Key consideration: Cloud backup is not a replacement for your local Veeam repository, it is a complementary tier. Your fast local repository still handles your short-term recovery SLAs; the cloud tier handles your resilience and long-term retention requirements.
Veeam's Cloud Integration Architecture
Scale-Out Backup Repository (SOBR) and Cloud Tier
The primary mechanism for integrating cloud storage into a Veeam deployment is the Scale-Out Backup Repository with a configured Capacity Tier. This is distinct from simply pointing a backup job at an object storage repository, SOBR gives you policy-driven offload and copy behaviour.
SOBR components relevant to cloud offload
- Performance Tier: Your existing on-premises extents (local disk, NAS, dedup appliance). This is where backups land initially.
- Capacity Tier: S3-compatible object storage (AWS S3, Azure Blob, or compatible providers). Backups are moved or copied here based on your offload policy.
- Archive Tier (v12+): Deep cold storage for multi-year retention (AWS Glacier, Azure Archive). Significantly lower cost per GB, with longer recall times.
Offload vs. Copy policy
When configuring the Capacity Tier, you choose between Move (offload after X days, freeing local space) and Copy (retain local copy, also write to cloud). For maximum resilience, Copy mode is strongly recommended, it satisfies the 3-2-1-1-0 requirement for an independent immutable copy without removing your fast local restore capability.
Direct-to-Object Storage Jobs (VBR v12+)
From Veeam Backup & Replication v12, you can also configure backup jobs to write directly to object storage as the primary repository, bypassing the SOBR construct. This is most useful for cloud-native workloads or edge deployments where no local storage is available, but for most enterprise deployments, the SOBR + Capacity Tier approach provides better performance and flexibility.
Veeam Cloud Connect (VCC) vs. Self-Managed Object Storage
It is worth distinguishing between two fundamentally different cloud backup models:
| Veeam Cloud Connect (VCC) | Self-Managed Object Storage (SOBR Capacity Tier) | |
|---|---|---|
| Immutability | Managed by service provider via hardened repo or object lock | Configured directly in your Veeam console via S3 Object Lock |
| Encryption in transit | TLS tunnel to VCC gateway server | TLS to object storage endpoint; Veeam-side encryption recommended |
| Encryption at rest | Provider-managed or Veeam-encrypted | Veeam-side encryption (AES-256) before data leaves your environment |
| WAN acceleration | Built-in Veeam WAN acceleration through VCC gateway | Veeam’s built-in compression/dedup; no dedicated WAN accel |
| Restore options | Full VBR-orchestrated restore via provider’s gateway | Direct restore from object storage, Instant Recovery from cloud |
| Credential management | Single set of VCC credentials | IAM policy-scoped access keys; supports separate delete-restricted keys |
| Cost model | Capacity + egress via service provider pricing | Direct cloud storage costs; egress charges apply on restore |
Configuring Immutable Cloud Repositories
Object Lock: How Immutability Actually Works
S3 Object Lock operates in two modes, both of which Veeam supports when you enable the “Make recent backups immutable for X days” option in your Capacity Tier configuration:
- Governance mode: Objects cannot be overwritten or deleted by standard IAM users. Users with the
s3:BypassGovernanceRetentionpermission (typically a separate break-glass admin account) can override the lock. - Compliance mode: No user, including the root account, can delete or overwrite objects before the lock period expires. This is the stronger option for ransomware protection and is required by some cyber insurance policies.
Veeam’s implementation detail
When Veeam writes a backup file to an immutability-enabled bucket, it sets the object lock retention timestamp at the point of upload, calculated as upload date + immutability period. Crucially, Veeam also sets a lock on the .vbm metadata file. This means that even if an attacker can reach your object storage credentials, they cannot delete the metadata index that Veeam uses to enumerate and restore backups.
IAM Policy Configuration for Least Privilege
Veeam only requires a scoped set of S3 permissions for normal operation. The principle of least privilege is especially important here, the credentials your Veeam server uses should not have s3:DeleteObject or s3:DeleteBucket permissions. A recommended policy split:
- Veeam operational role:
s3:GetObject, s3:PutObject, s3:ListBucket, s3:GetBucketLocation, s3:GetObjectRetention, s3:GetObjectLegalHold - Lifecycle management role (separate, offline credentials):
s3:DeleteObject, s3:PutBucketLifecycle
Encryption: What to Configure and Where
Veeam supports two layers of encryption relevant to cloud backup:
- Job-level encryption: Enabled on the backup job itself. Data is encrypted before it is written to any repository, including your local SOBR extent. This means encrypted data is what gets offloaded to the cloud, the cloud provider never holds plaintext data. Recommended for all cloud-destined jobs.
- Repository-level encryption: Applied at the SOBR or object storage repository level. Encrypts data at rest on the target. Can be combined with job-level encryption for defence-in-depth.
Key management note: Veeam’s encryption keys are tied to your Veeam configuration database. Ensure your Veeam config backup (and its associated encryption password) is stored securely and separately from your main environment, you will need it to recover if your Veeam server itself is destroyed.
Recovery Scenarios from Cloud Respositories
Instant VM Recovery® from Object Storage
From VBR v11 onwards, Instant VM Recovery is supported directly from object storage without staging to an intermediate repository. Veeam mounts the backup from the object storage endpoint directly to the vSphere/Hyper-V host using the backup server as an NFS mount point.
Performance considerations:
- Initial mount latency depends on your WAN link speed and object storage endpoint proximity. Plan for 2–5 minutes for the VM to boot from cloud storage on a typical 100Mbps link.
- Veeam’s Quick Migration then runs in the background to restore the VM to local storage. The production impact window is the time until Quick Migration completes, not the duration of the entire restore.
- CDP policies cannot be used for cloud-tier restores — Instant Recovery from cloud is SOBR Capacity Tier or Archive Tier only.
Full and Partial Restores
- Full VM restore: Veeam retrieves the backup chain from object storage and rebuilds the VM on your target datastore. For large VMs over WAN, consider using a local Veeam Proxy positioned closer to the cloud endpoint.
- Guest file-level recovery (FLR): Veeam can mount the object storage backup and present the guest filesystem via the Enterprise Manager browser or vSphere console. No need to fully restore the VM to extract individual files or application items.
- Application-item recovery: Exchange, SQL, SharePoint, and Active Directory item-level restores are all supported from cloud-tier backups. The Veeam Explorer tools function identically against cloud-stored backups as they do against local ones.
Disaster Recovery: Full Site Failover
If your primary site is unavailable, you can rebuild from cloud backups on any Veeam-managed infrastructure:
- Deploy a new Veeam Backup & Replication server (or use an existing secondary site VBR instance).
- Add the immutable object storage bucket as a repository — Veeam will scan and import the backup metadata.
- Restore workloads in priority order using Instant Recovery to get critical systems online fast, then migrate to permanent storage.
Sizing, Performance, and Cost Considerations
Initial Seeding
For large datasets (10TB+), the initial offload to cloud over WAN can take days or weeks. Options to accelerate:
- Veeam Data Mover throttling: Schedule offload tasks to run during off-peak hours to avoid saturating production WAN links. Configured in the SOBR Capacity Tier “Schedule” settings.
- Offline seeding: Send an initial dataset via physical media to the cloud provider, who imports it directly into your object storage bucket. Veeam can then switch to incremental offload going forward. Contact Nexstor for offline seeding options.
Ongoing Data Transfer and Egress
After the initial seed, ongoing transfer consists of incremental backup data only. Key factors:
- Source-side deduplication and compression in Veeam significantly reduces the data volume transferred. Typical ratios are 2:1 to 5:1 depending on workload type.
- Egress costs (charges for reading data back from cloud) apply on restore. For DR planning, factor egress costs into your RTO costings — particularly for large VM restores.
- Immutable copies incur storage charges for the full lock duration even if local copies are deleted. Right-size your immutability window (30–90 days is common) to balance protection with cost.
Monitoring Capacity Tier Health
Within VBR, the SOBR dashboard shows Capacity Tier usage, offload job status, and any upload errors. Additionally:
- Veeam ONE: Provides alerting on Capacity Tier offload failures, object storage connectivity issues, and backup chain integrity. Set alerts for any S3 upload errors to catch credential rotation issues before they break your cloud copy.
- Bucket versioning: Enable versioning on your object storage bucket in addition to Object Lock. This provides an additional recovery mechanism if backup metadata is inadvertently overwritten.
Nexstor's Immutable Cloud: What's Different
Nexstor provides S3-compatible immutable object storage built specifically for Veeam workloads, hosted in UK data centres. Key differentiators from commodity cloud storage:
| Capability | Nexstor Detail |
|---|---|
| UK Data Residency | All data stored in UK-based data centres. No data transits outside UK jurisdiction — relevant for UK GDPR and data sovereignty requirements. |
| Veeam-Validated Configuration | Bucket policies, object lock settings, and IAM configurations are pre-validated against Veeam’s compatibility matrix. No trial-and-error configuration. |
| Compliance Mode Object Lock | Nexstor’s immutable storage uses S3 Compliance mode locking by default, providing the strongest available protection against deletion. |
| Dedicated Ingress Bandwidth | No shared bandwidth contention on ingest. Your initial seed and ongoing offload jobs run at line rate to your WAN link. |
| No Egress Charges on Recovery | Restores to your on-premises environment do not incur egress fees — a significant cost differentiator versus hyperscaler object storage for DR scenarios. |
| Veeam Cloud Connect Gateway (Optional) | If you prefer VCC over direct S3, Nexstor operates a VCC gateway infrastructure. Both connection models are available from the same underlying storage platform. |
Implementation Checklist
Before configuring your SOBR Capacity Tier to point at Nexstor’s immutable cloud:
Pre-configuration
- Confirm VBR version is v11 or later (v12 recommended for direct-to-object and enhanced immutability features)
- Identify which SOBR (or create a new one) will use the cloud Capacity Tier
- Decide on offload policy: Copy mode (retains local copy) vs. Move mode (frees local space after offload period)
- Define your immutability window (typically 30–90 days — long enough to survive a delayed ransomware discovery)
- Confirm job-level encryption is enabled for all jobs feeding the SOBR
- Document your Veeam configuration backup location and encryption password — store this separately from your main environment
Nexstor Provisioning
- Nexstor provisions your S3-compatible bucket with Object Lock enabled in Compliance mode
- IAM access keys are issued with least-privilege policy (no DeleteObject permission)
- Endpoint URL, bucket name, access key, and secret key provided for Veeam configuration
- UK data centre location confirmed for data residency documentation
Veeam Configuration
- Add object storage as a new repository: Backup Infrastructure > Add Repository > Object Storage > S3 Compatible
- Enter endpoint, bucket, and credentials. Enable “Make recent backups immutable” and set lock period
- Edit your SOBR > Capacity Tier tab > set offload policy and schedule
- Run a manual offload trigger and verify data appears in the bucket
- Confirm
.vbmmetadata files are present and locked in the bucket - Test a file-level restore from the cloud copy to validate end-to-end recoverability
Talk to Nexstor
If you’re running Veeam and want to close the gap in your 3-2-1-1-0 strategy with a UK-hosted, immutable cloud tier, the Nexstor team can review your current SOBR architecture and recommend a configuration that meets your RPO, RTO, and data residency requirements.
We work at the infrastructure layer; storage, networking, and Veeam configuration, so the conversation starts where your existing deployment is, not with a product pitch.
