Skip to main content

​
Overview

Genesis on AKS runs as a StatefulSet with a single Azure Disk–backed PVC (ReadWriteOnce, typically StorageClass managed-csi). Application state includes SQLite and files on that volume. Kubernetes Secrets and ConfigMaps (for example API keys and GENESIS_MASTER_KEY) are separate objects — plan restores so volume data and cluster configuration stay consistent. Microsoft’s operator guidance is to plan backup and test restore for workloads that use attached storage. See Best practices for storage and backup in AKS.
The master encryption key is not on the PVC. It lives in a Kubernetes Secret as GENESIS_MASTER_KEY, or is resolved at startup from an external vault when GENESIS_MASTER_KEY_REF is set. Restoring the volume without the matching master key renders encrypted fields unusable. Include Secrets and ConfigMaps in your recovery plan alongside the PVC.

​
What lives on the PVC

The Genesis StatefulSet mounts the PVC at four subpaths:

​
Option 1: CSI volume snapshots (Azure Disk)

What it is: Point-in-time snapshots of the managed disk behind your PVC, using the Kubernetes VolumeSnapshot API and the Azure Disk CSI driver. When it fits: You want a simple, disk-level backup on a regular cadence (for example daily), minimal platform surface area, and you are comfortable automating snapshot creation (CronJob, GitOps, or scripts). Azure documentation:
Snapshots are typically crash-consistent. For SQLite-heavy workloads, many teams snapshot during quiet periods or use brief maintenance windows; optionally combine with application-level exports (below) if your recovery objectives require it.

​
Option 2: Azure Backup for AKS

What it is: Microsoft-managed backup vault, policies, and an AKS backup extension in the cluster to coordinate backup and restore of cluster resources and supported persistent data. When it fits: You want Azure-native scheduling, retention, and compliance integration with less custom automation than hand-rolled snapshot jobs. Azure documentation:

​
Option 3: Third-party backup tools (for example Velero)

What it is: Open-source or commercial Kubernetes backup products (for example Velero) that can back up namespaces, resources, and — depending on configuration — persistent volumes using cloud provider snapshot plugins or object storage. When it fits: You already standardize on a tool across clusters or need portable backup/restore workflows beyond a single PVC. Follow your vendor or project documentation (Velero is widely used with Azure Blob and snapshots). This is not a Microsoft-owned path; evaluate support and SLAs with your team. For EKS-specific Velero and hook examples, see Backup and Recovery on AWS.

​
Option 4: Application-level backup (logical exports)

What it is: Periodic exports of SQLite (or other application data) to durable storage (for example Azure Blob Storage), independent of disk snapshots. When it fits: You want logical backups, easier selective restore, or extra assurance beyond block-level snapshots. Trade-off: You must align secrets, configuration, and file layout with restores so the application starts correctly. Example config export (complements PVC backups):

​
Summary comparison

​
Practices that apply to every option

  • Test restores to a non-production namespace or cluster on a recurring basis.
  • Define retention (how many snapshots or backup points, and for how long).
  • Include Secrets and ConfigMaps in your recovery plan alongside the PVC.