Concept
CloudStack Replication Checkpoints
Why Sendense creates short-lived CloudStack Volume Snapshots before updating controller-backed replica disks, and how to interpret their placement and latency.
A Destination Rollback Safety Boundary
A CloudStack replication checkpoint is a short-lived destination rollback boundary that Sendense creates before it updates the replica disks for a controller-backed target.
The checkpoint contains one CloudStack Volume Snapshot for each replica data volume attached to the Sendense Controller. Sendense prepares the complete set before destination writes begin, then records each snapshot with the matching pre-sync replication baseline.
This is not a retained backup
The checkpoint protects the last successful replica while Sendense modifies that replica in place. It is not an EBA recovery point, a CloudStack snapshot schedule, or a customer retention copy.
Why The Checkpoint Exists
Before a sync, the replica volumes and their per-disk replication baselines describe the same known state. If a transfer stops after writes begin, partially updated volumes must not be paired with the old change-tracking baseline.
The checkpoint lets Sendense restore the destination volume contents and the matching replication baselines together. This makes an in-place, cross-platform replication update recoverable without turning every sync into a retained backup.
Checkpoint Lifecycle
Destination update safety cycle
Known state
Last Successful Replica
Replica volumes and per-disk replication baselines describe the same completed sync.
Before writes
Create Volume Snapshots
Sendense creates and records one Volume Snapshot for every replica data volume. CloudStack processes the volume operations individually.
Checkpoint armed
Apply Replication Changes
Once the source-side SNA accepts the sync job, the checkpoint is armed because replica data may then change.
Success
Commit And Delete
Sendense commits the new per-disk baselines and deletes the temporary Volume Snapshots.
Checkpoint armed
Apply Replication Changes
Once the source-side SNA accepts the sync job, the checkpoint is armed because replica data may then change.
Failure
Stop, Revert, Restore
Sendense stops the Controller, reverts each replica volume, restores its previous baseline, restarts the Controller, and cleans up.
Known state
Last Successful Replica
Replica volumes and per-disk replication baselines describe the same completed sync.
Grouped by Sendense, not one atomic CloudStack call
Sendense does not permit replication writes until every required volume snapshot is ready. The checkpoint is a Sendense-orchestrated group of per-volume operations, not a single atomic multi-volume CloudStack snapshot API operation.
Why Volume Snapshots, Not An Instance Snapshot
A Sendense Controller has its own appliance root volume. Every protected source disk is represented by a separate attached replica volume, and those replica volumes are the state changed by a sync.
During CloudStack failover, Sendense detaches the Controller appliance root and attaches replica disk 0 as the recovered workload's root. The appliance root is not promoted, so coupling it to the replica rollback set would protect the wrong scope.
Primary Placement Can Still Be Slow On NFS
Sendense calls the standard CloudStack volume-snapshot operation. CloudStack decides where and how the snapshot data is materialized.
On CloudStack 4.22 KVM file-based storage, snapshot.backup.to.secondary=false keeps the final snapshot on primary storage. On NFS, primary-only can still require a size-dependent copy into another directory on the same primary storage, so it need not be metadata-only or instantaneous.
Storage-native backends such as LINSTOR can create point-in-time snapshots with little data movement. That explains why LINSTOR checkpoints can complete much faster than NFS checkpoints, but elapsed time alone does not establish whether CloudStack used primary or secondary storage.
Sendense waits for every required Volume Snapshot before it permits destination writes. On the current CloudStack path, those per-volume operations are submitted and awaited in sequence, so multi-disk checkpoint time can accumulate across the replica volumes.
BackedUp Does Not Prove Secondary Placement
The CloudStack snapshot state BackedUp means the snapshot is ready to use. It does not, by itself, mean that the snapshot resides on secondary storage.
- Confirm the effective snapshot.backup.to.secondary value.
- On CloudStack 4.22.0.1, restart every management-server process after changing this non-dynamic setting.
- As a CloudStack administrator, call listSnapshots with showunique=false. Correlate one snapshot by ID and inspect locationtype plus the datastore fields for each returned store entry.
- Check the management-server log for that same snapshot ID and timestamp.
- Treat BackedUp without placement fields as incomplete evidence rather than proof of secondary storage use.
Operational Boundaries
- Do not replace Sendense checkpoints with CloudStack scheduled snapshots; their purpose and lifecycle are different.
- Do not manually delete an active checkpoint snapshot; Sendense may need it to recover an armed sync.
- Allow temporary capacity for a checkpoint of every replica volume, particularly on file-based NFS.
- Complete unresolved checkpoint recovery or cleanup before attempting another sync.
- Retry and timeout settings affect waiting and retries, not primary-versus-secondary placement.
Related Docs