Skip to content

Snapshot Operations

Snapshots are the point-in-time primitive behind most AKS stateful recovery workflows. On AKS, you should treat snapshots as fast recovery building blocks, not as a complete recovery plan by themselves.

Prerequisites

  • The workload uses a CSI-backed storage path that supports snapshots.
  • Snapshot controller support is enabled where required.
  • You know whether the workload needs application quiescing before the snapshot.
  • The team has decided whether the snapshot is for local rollback, clone, or a backup workflow.

When to Use

  • Point-in-time rollback before risky changes.
  • Fast clone or test-environment copy from current state.
  • Backup workflows that depend on CSI snapshots as the PV data source.
  • Operator recovery for accidental file or block-level corruption.

Procedure

flowchart TD
    A[Decide snapshot goal] --> B[Quiesce app if consistency requires it]
    B --> C[Create VolumeSnapshot or backup recovery point]
    C --> D[Restore to new PVC or alternate cluster path]
    D --> E[Validate data and application behavior]

1) Pick the right snapshot scope

Goal Recommended path
Quick rollback of a single PVC CSI VolumeSnapshot
Recovery point that also includes Kubernetes objects Azure Backup for AKS
Clone for test or investigation Snapshot restore to a new PVC

2) Know the storage-specific behavior

Azure Disk

  • Best fit for block-level point-in-time recovery.
  • Snapshot classes can drive full or incremental behavior.
  • Restores usually land as a new PVC that you validate before cutover.

Azure Files

  • Snapshot support exists at the CSI layer and in the underlying file share.
  • Restore planning should include share-level access behavior and any secrets or storage-account roles required for the workload.

3) Treat snapshots as crash-consistent unless you prove otherwise

If the workload needs flush, freeze, or coordinated write pause, add that logic before the snapshot. A technically successful snapshot is not automatically an application-consistent restore point.

4) Point-in-time recovery workflow

Typical AKS operator flow:

  1. create snapshot or backup recovery point
  2. restore into a new PVC
  3. mount into a validation pod or alternate workload
  4. confirm data quality
  5. cut over only after validation succeeds

5) Use snapshots inside broader backup design

Azure Backup for AKS composes cluster-state metadata plus CSI-backed volume snapshots into a recovery point. That is the safer choice when you need workload objects and PV data to move together.

Verification

  • Snapshot object or recovery point reaches ready state.
  • Restored PVC binds successfully.
  • Mounted data matches the expected point in time.
  • Application-level validation confirms the data is usable, not just mountable.

Rollback / Troubleshooting

  • If the restored PVC is healthy but the application is not, suspect application consistency first.
  • If the snapshot exists but restore is blocked, check target StorageClass compatibility and restore permissions.
  • If Azure Backup recovery points are present but incomplete, inspect warning details for skipped resources.

See Also

Sources