StackGres supports manual and automated backups, based on Postgres continuous archiving, that is base backups plus WAL (write ahead log) archiving, as well as backup lifecycle management. To achieve maximum durability, backups are stored on cloud/object storage and volume snapshots. S3, GCP, Azure Blob, and S3-compatible object storages are supported as on cloud/object storage.
All the configuration for this matter can be found at the SGCluster backups section. When backups are configured, Postgres WAL files will start being archived in the specified storage at the specified path. Also, automatic backups can be scheduled and (in such case) a retention policy of backups is created. You will have to find out a time window and retention policy that fit your needs. When configuring cluster backups, you may also specify the compression algorithm and performance-related options, such as the maximum disk and network throughput, or the parallelism for uploading files.
apiVersion: stackgres.io/v1
kind: SGCluster
# [...]
spec:
# [...]
configurations:
backups:
- sgObjectStorage: # name of the referenced SGObjectStorage
path: # may be customized by the user or left with
# a default value based on cluster namespace,
# name and postgres version
cronSchedule: '0 5 0 0 0'
retention: 5
compression: # <lz4|lzma|brotli>
performance:
maxDiskBandwidth: # unlimited if left unset
maxNetworkBandwidth: # unlimited if left unset
uploadDiskConcurrency: # 1 by default
For more information, have a look at the SGCluster backups section.
StackGres support backups with the following storage options:
The examples are using the MinIO service as a S3 compatible service for a quick setup on local Kubernetes clusters. Although StackGres definitely recommends to choose a Storage-as-a-Service for production setups.
All the storage-related configuration is defined in the SGObjectStorage CRD.
apiVersion: stackgres.io/v1beta1
kind: SGObjectStorage
# [...]
spec:
# fill the preferred storage method with
# specific credentials and configurations
type: # <s3|s3Compatible|gcs|azureBlob>
storage:
s3: {}
s3Compatible: {}
gcs: {}
azureBlob: {}
StackGres supports also backup based on Volume Snapshot that, in general, are faster that object storage for big volumes of data. This feature requires the VolumeSnapshot CRDs and controller to be installed in the Kubernetes cluster. A backup based on VolumeSnapshot still requires WAL files that will be stored in the object storage defined by SGObjectStorage.
Backups are materialized using SGBackup. An SGBackup can be created automatically by the scheduled backup process, manually, or by copying an existing SGBackup in order to make it accessible in another namespace. Removing an SGBackup also triggers the removal of the actual backup associated with it, that is the files on the object storage that represent the backup (if they are accessible by the backup configuration used by the SGCluster).
A manual backup has to reference the cluster and to specify whether it will have a managed lifecycle (i.e. it will be removed on rotation by the specified retention):
apiVersion: stackgres.io/v1
kind: SGBackup
# [...]
spec:
sgCluster: # name of the referenced SGCluster
managedLifecycle: # <true|false>
A backup is only accessible from the namespace in which it is located.
In order to use it in another namespace, you need to copy it by modifying the resource content.
In particular, apart from the obvious part of having to change the namespace, you will have to prepend the referenced cluster name with the source namespace and a dot (.).
The following is shows how to copy an SGBackup from the source namespace to the target namespace using kubectl and jq:
kubectl get sgbackup -n source source -o json \
| jq '.spec.sgCluster = .metadata.namespace + "." + .spec.sgCluster | .metadata.namespace = "target"' \
| kubectl create -f -
The backup associated to the SGBackup created in this way will not be deleted until all the copies and the original SGBackup have been removed.
StackGres can restore a database from a StackGres backup by specifying the SGBackup resource name of the desired backup in the restore section of the SGCluster. Like this:
apiVersion: stackgres.io/v1
kind: SGCluster
spec:
initialData:
restore:
fromBackup:
name: # the backup name to restore
An SGBackup can be restored only on SGCluster creation and such section can not be modified. Check the complete explanation about restoring a backup in the Restore a Backup Runbook.