The four solutions use two different Azure primitives to perform backups. Veeam, Rubrik, and Cohesity create per-disk incremental managed-disk snapshots; Afi creates VM Restore Points (a newer Azure primitive that captures all of a VM's disks atomically and integrates with VSS for application consistency without the vendor needing an in-guest agent).
In both cases Azure stores only the delta versus the previous restore point/snapshot of the same disk. Each vendor then either calls BeginGrantAccess/BeginGetAccess to obtain a SAS URI on the disk-level artifact and reads only the changed byte ranges via the page-blob Get Page Ranges Diff REST operation (afi.ai, Veeam) or creates a temporary managed disk from the snapshot and attaches it as a block device to a worker (Cohesity DPaaS, Rubrik). Compression and encryption happen at the data mover (or, for afi.ai, at the afi.ai backend) before data is written to the backup repository.
Multi-disk consistency.
As a result of relying on per-disk snapshots (one snapshot per attached disk), multi-disk consistency is best-effort in case of Cohesity, Rubrik, and Veeam. The snapshots are issued in quick succession but are not atomic across disks. Veeam reconciles the per-disk snapshots into a logical group by tagging them with shared metadata.
Application consistency.
afi.ai gets application consistency directly from the Restore Point's applicationConsistent mode, with no separate vendor agent. Cohesity, Rubrik, and Veeam either rely on crash consistency (the snapshot taken on a running VM is recoverable like a power-cut state) or require an in-guest agent to coordinate VSS on Windows or pre/post scripts on Linux.
The vendor-specific data flow
The afi.ai backend calls ARM to create an Azure VM Restore Point in a Restore Point Collection in the source subscription (first one is full, subsequent ones are incremental). It then enumerates the per-disk Disk Restore Points inside the VM Restore Point, generates SAS URIs, and reads changed page ranges directly from Azure Storage to the afi.ai backend over HTTPS, with no in-Azure data mover. The Restore Point Collection is retained in the customer subscription for 7 days; older recovery points exist only in afi.ai's object store.
The Cohesity DPaaS cloud management service calls ARM to create per-disk incremental snapshots. The storage-proxy VM in the customer VNet attaches each snapshot via a SAS URI (private-endpoint paths supported, with a 32 TB per-disk cap when used), reads the changed page ranges, deduplicates and compresses the stream, encrypts it, and pushes it over an outbound TLS-encrypted gRPC tunnel (port 443) to the Cohesity data-plane endpoint in the customer-selected Cohesity region. The per-disk snapshot is removed at job end.
The Cohesity Cloud Edition cluster running in customer Azure VMs is both orchestrator and data mover. It calls ARM for per-disk incremental snapshots and pulls changed page ranges via SAS URI into its own clustered storage on the cluster's locally attached managed disks, with opt-in tiering to Azure Blob.
The Rubrik SaaS console invokes ARM to snapshot the disks. The AKS data-mover cluster scales up; for the changed-block read to the customer's archive Blob storage account, a pod streams blocks from the snapshot via a SAS URI over HTTPS (routed through Azure private endpoints if the snapshot's network policy is private-only), with no temporary disk created in this path. For file indexing and file-level recovery, a separate pod creates a temporary managed disk from the snapshot, attaches it, and walks the filesystem. Only the index (not file contents) is sent to the SaaS console. For application-consistent in-guest backups, an AKS pod coordinates with an in-guest Rubrik agent installed on the VM. AKS nodes scale back down when idle.
The Veeam orchestrator VM calls ARM to create per-disk incremental snapshots, tagging each with metadata so the orchestrator can treat the per-disk snapshots of one VM as one logical unit. It launches one Linux data-mover VM per protected VM in the same region/subnet. The data mover reads changed page ranges from snapshot SAS URIs, compresses and encrypts the stream into Veeam-native backup files, and writes to the target Blob container. The data-mover VM is destroyed at job end. To enable the page-range diff against the next backup, VBAz permanently retains the two most recent per-disk snapshots in the source resource group; older snapshots are purged per policy. Orchestrator-to-mover control messaging uses Azure Queue Storage which avoids the need for VNet peering or public IPs between the orchestrator VM and movers.