Backup from Storage Snapshots: How it works and when to use it

Key takeaways

• Backup from Storage Snapshots uses an array-based snapshot as the backup source, so backup reads do not run through the production datastore for the length of the job.
• The VMware snapshot can be removed shortly after the storage snapshot is created, rather than staying open for the whole transfer. That limits delta growth, which is what reduces consolidation time and stun.
• Three things have to line up: a supported storage system and firmware, storage credentials, and a backup proxy that can reach the snapshot over a supported transport mode. The specifics vary by integration.
• A primary storage snapshot is not a substitute for an independent backup copy, because it stays inside the production storage system and its failure domain.
• Snapshot orchestration, Backup from Storage Snapshots, and standard image-level backup do three different jobs. Orchestration gives you very tight recovery points, Backup from Storage Snapshots gives you daily protection without the long snapshot, and standard backup covers everything outside the integration.
• The integration supports VMware vSphere only. Hyper-V VMs cannot be backed up with it.

If you have ever watched a production workload struggle while a VMware snapshot was being removed, you already understand the problem this feature is designed to reduce.

Backup from Storage Snapshots lets Veeam Backup & Replication use a storage snapshot as the source for a VMware backup. Instead of reading VM data through the production datastore for the duration of the job, Veeam reads what it needs from the storage snapshot and transfers it to a separate backup repository.

The VMware snapshot still gets created, because that is what establishes the consistent point in time. It just does not have to stay open while the data moves. A shorter snapshot window means less delta growth and less consolidation work when the snapshot is removed.

One scope note before going further: this integration applies to VMware vSphere only. If you are running Hyper-V, the mechanism described here is not available to you.

Why the backup window exists in the first place

When VMware creates a VM snapshot, subsequent writes are redirected to delta disks while the base virtual disks hold the point-in-time state the backup reads from.

The longer the snapshot stays open, the more those delta disks grow. When the snapshot is removed, VMware consolidates the accumulated changes back in. A VM can experience brief stun during snapshot creation or removal, and large delta disks or high write rates increase both the time and the operational impact of that consolidation.

Small delta, quick consolidation, nobody notices. Large delta, long consolidation, and you hear about it. On a busy database with a job that runs for hours, that is the entire reason backups got pushed to the middle of the night.

What is Backup from Storage Snapshots?

The method changes the source of the backup read and shortens the time the VMware snapshot stays open. The order matters:

1. Veeam creates a VMware snapshot. Where application-aware processing or guest quiescence is enabled and supported, Veeam coordinates the guest operating system and supported applications before the recovery point is created.
2. Veeam triggers a snapshot on the storage volume holding those virtual disks.
3. The VMware snapshot is removed. Because it was open for a short time rather than the length of the job, there is far less delta to consolidate.
4. A backup proxy accesses the storage snapshot using a transport mode supported by the storage system and the Veeam integration.
5. Veeam transfers the required backup data from the storage snapshot to a separate backup repository.
6. Veeam removes temporary storage snapshots according to the integration and job workflow. Monitor job sessions and array capacity to confirm cleanup is happening as expected.

Changed block tracking keeps the read short. For incremental backups, VMware Changed Block Tracking identifies the blocks that changed since the previous run, so less data has to be processed when CBT is available and valid.

What that gives you:

• Backup reads run against the storage snapshot through a proxy rather than through the production datastore. Snapshot and production workloads can still share underlying array resources, so this reduces the backup path rather than eliminating all impact.
• Long-running jobs stop being a problem for I/O-sensitive applications, because the read load sits on the storage snapshot instead of the production path.
• More frequent protection becomes practical, within whatever your application, storage, and recovery requirements allow.
• Restores and test labs can start directly from a storage snapshot when you need something back in a hurry.

What you need before you design around it

Backup from Storage Snapshots depends on several components working together. If a prerequisite is not met, Veeam may use another permitted processing mode, or the job may fail. Verify the following before you design around it:

• A supported storage array on supported firmware. Compatibility depends on the Veeam version, storage vendor and product, model, protocol, firmware, and the applicable integration or plug-in. Validate the complete configuration against current Veeam documentation.
• A backup proxy configured to access storage snapshots through a transport mode supported by the relevant Veeam storage integration. If the preferred storage access method is unavailable, behavior depends on the integration and job settings: Veeam may use another permitted transport mode, or report a job failure.
• Storage credentials with permission to create and remove snapshots, plus enough free capacity on the array to hold them.
• Headroom for the change rate. A snapshot costs almost nothing when it is created, but it grows as production data diverges from it.
• The right licensing and edition for the targeted Veeam release and storage integration. Check the current edition comparison rather than assuming, since packaging has changed over time.

After configuration, review the job session to confirm that Backup from Storage Snapshots was actually used. Proxy placement is the one that catches people out, and incorrect placement or transport configuration can stop an environment from seeing any of the expected benefit.

Three protection approaches with different purposes

Storage snapshots show up in more than one place, and the distinction trips people up. One approach uses the array as a source for backup. Another uses the array as the destination for a very fast, very short-term recovery point. They are not interchangeable.

Many organizations combine all three, based on workload criticality, storage compatibility, recovery objectives, and retention requirements. Orchestration covers the gap between backups on tier-one systems. Backup from Storage Snapshots handles daily protection of what sits on a supported array. Standard backup picks up everything outside the integration, Hyper-V workloads included.

A snapshot is not a backup

This is the part worth being blunt about. A primary storage snapshot is not a substitute for an independent backup copy, because it usually remains within the production storage system and its failure domain. If the array is lost, corrupted, or encrypted, the snapshots go with it. It is a recovery mechanism, not a copy.

So this only works as part of a layered design. The array gives you speed. A separate repository gives you survivability. A Scale-out Backup Repository federates whatever storage you already own into one logical target, across three tiers:

• Performance tier for fast access, built from block-based backup repositories or object storage repositories.
• Capacity tier for longer-term retention on object storage, on premises or in the cloud.
• Archive tier for cold copies that satisfy compliance retention at the lowest cost per terabyte.

Immutability belongs in the design too, as long as you are precise about what it does. When correctly configured on a supported repository, immutability helps prevent backup data from being deleted or modified until the immutability period expires. It should be combined with credential separation, least-privilege access, monitoring, and additional backup copies in separate failure domains. It is one layer, not a force field.

Limitations to plan for

None of these is a reason to avoid the feature. They are the things that surface during a design review, and they are cheaper to know now.

• VMware vSphere is the only supported virtualization platform. Hyper-V VMs cannot be backed up through this integration.
• Compatibility moves across both Veeam versions and array firmware. Check your specific vendor, model, protocol, and firmware against the current compatibility list before you commit to a design.
• Certain disk configurations are excluded. Raw device mapping disks in virtual compatibility mode, for example, are skipped during Backup from Storage Snapshots. Review the exclusions for your specific integration.
• Some vendor-specific replication, high-availability, or storage-policy configurations are not supported. Again, this is per integration, so check rather than assume.
• Storage infrastructure is rescanned on a schedule. After you change the array configuration, trigger a rescan manually rather than waiting for the next one.
• Array snapshots consume array capacity. On a volume with a high change rate that cost is not trivial, and it is worth sizing rather than discovering.

How Veeam helps

Veeam Backup & Replication orchestrates the whole sequence, from quiescing the guest to triggering the storage snapshot to cleaning up afterward. The integration covers primary storage arrays from the major vendors, and the Veeam Ready program tells you what has actually been tested rather than what is theoretically compatible. At design time, that is the difference that matters.

The platform then handles what the array cannot. Backups land in a Scale-out Backup Repository that unites your existing block storage, Linux and Windows repositories, and deduplicating appliances as logical extents, and tiers older copies to object storage automatically. Recent releases have extended malware detection to unstructured data and added finer control over archive tier copies and minimum immutability periods.

FAQ