The module lifecycle stage: Preview

Disk Snapshot-Based Backup

Disk snapshot creation depends on a separate module snapshot-controller.
The snapshot-controller module must be enabled, and one of the CSI drivers from the list must also be configured.
For example, sds-local-volume in LVM Thin mode.

Creating a Postgres Snapshot

Ensure that the selected spec.instance.persistentVolumeClaim.storageClassName supports snapshotting. If storageClassName was not explicitly specified, ensure that the default storageClassName in the DKP cluster supports this feature.

To create a disk snapshot, simply apply the following resource:

apiVersion: managed-services.deckhouse.io/v1alpha1
kind: PostgresSnapshot
metadata:
  name: my-first-snapshot
spec:
  postgresName: my-postgres

The disk snapshot result can be seen in the resource status:

kubectl get postgressnapshot -n postgres-ek my-first-snapshot -oyaml | yq .status

completedAt: "2025-12-04T19:00:31Z"
phase: completed
postgres:
  cluster:
    replication: Availability
    topology: Ignored
  configuration:
    maxConnections: 300
  databases:
    - name: test
  instance:
    cpu:
      coreFraction: 50
      cores: 1
    memory:
      size: 1Gi
    persistentVolumeClaim:
      size: 1Gi
      storageClassName: thin-local-storage-class
  postgresClassName: default
  type: Cluster
startedAt: "2025-12-04T19:00:16Z"
volumeSnapshotName: d8ms-pg-my-first-snapshot

Restoring from a Snapshot

To restore Postgres from a disk snapshot, apply a new Postgres resource with the spec.dataSource parameter.

Note that this operation is almost identical to creating a new Postgres cluster. That is, when creating such a resource, all validations for the corresponding PostgresClass will be performed.
This provides the advantage that the configuration for the restored cluster can be modified at this stage.
An important condition concerns the databases field: since we use a declarative description of logical databases, the absence of a database name in the list means that after restoration, that logical database will not exist in the resulting cluster, even if it exists in the snapshot. The same applies to users.

kubectl apply -f managed-services_v1alpha1_postgres.yaml -n postgres

apiVersion: managed-services.deckhouse.io/v1alpha1
kind: Postgres
metadata:
  name: my-restored-postgres
spec:
  dataSource:
    objectRef:
      kind: PostgresSnapshot
      name: my-first-snapshot
  users:
    - name: test-rw
      hashedPassword: >-
        SCRAM-SHA-256$4096:8LTjDsWOlQ7fnvr0DqRQx0TXMTh6LIyQJow2UnNlsJE=$ZjQi5diDTvn0g7is1ez9qPSGm6SoGezF0FVCZXssDKw=:IEzN8Dz5KcGd1r47thky5XFRhXlIMeoNLNfZtIlGv/8=
      role: rw
    - name: test-ro
      password: '123'
      storeCredsToSecret: test-ro-creds
      role: ro
  databases:
    - name: "test"
  postgresClassName: default
  instance:
    memory:
      size: 1Gi
    cpu:
      cores: 1
      coreFraction: 50
    persistentVolumeClaim:
      size: 1Gi
      storageClassName: thin-local-storage-class
  configuration:
    maxConnections: 300
  type: Cluster
  cluster:
    topology: Ignored
    replication: Availability

The restoration success will be reflected in the status of the created Postgres resource:

kubectl get postgres my-restored-postgres -n postgres -o wide -w