Kubernetes backup
StackState Self-hosted v5.1.x
Last updated
StackState v5.1
StackState Self-hosted v5.1.x
Last updated
The Kubernetes setup for StackState has a built-in backup and restore mechanism that can be configured to store backups to the local clusters, to AWS S3 or to Azure Blob Storage.
The following data can be automatically backed up:
Configuration and topology data stored in StackGraph is backed up when the Helm value backup.stackGraph.enabled is set to true.
Telemetry data stored in StackState's Elasticsearch instance is backed up when the Helm value backup.elasticsearch.enabled is set to true.
The following data will NOT be backed up:
In transit topology and telemetry updates stored in Kafka - these only have temporary value and would be of no use when a backup is restored
Master node negotiations state stored in ZooKeeper - this runtime state would be incorrect when restored and will be automatically determined at runtime
Kubernetes configuration state and raw persistent volume state - this state can be rebuilt by re-installing StackState and restoring the backups.
Kubernetes logs - these are ephemeral.
StackGraph and Elasticsearch backups are sent to an instance of , which is automatically started by the stackstate Helm chart when automatic backups are enabled. MinIO is an object storage system with the same API as AWS S3. It can store its data locally or act as a gateway to , and other systems.
The built-in MinIO instance can be configured to store the backups in three locations:
Encryption
Amazon S3-managed keys (SSE-S3) should be used when encrypting S3 buckets that store the backups.
⚠️ Encryption with AWS KMS keys stored in AWS Key Management Service (SSE-KMS) isn't supported. This will result in errors such as this one in the Elasticsearch logs:
Caused by: org.elasticsearch.common.io.stream.NotSerializableExceptionWrapper: sdk_client_exception: Unable to verify integrity of data upload. Client calculated content hash (contentMD5: ZX4D/ZDUzZWRhNDUyZTI1MTc= in base 64) didn't match hash (etag: c75faa31280154027542f6530c9e543e in hex) calculated by Amazon S3. You may need to delete the data stored in Amazon S3. (metadata.contentMD5: null, md5DigestStream: com.amazonaws.services.s3.internal.MD5DigestCalculatingInputStream@5481a656, bucketName: stackstate-elasticsearch-backup, key: tests-UG34QIV9s32tTzQWdPsZL/master.dat)",
To enable scheduled backups to AWS S3 buckets, add the following YAML fragment to the Helm values.yaml file used to install StackState:
Replace the following values:
YOUR_ACCESS_KEY and YOUR_SECRET_KEY are the credentials that will be used to secure the MinIO system. These credentials are set on the MinIO system and used by the automatic backup jobs and the restore jobs. They're also required if you want to manually access the MinIO system.
YOUR_ACCESS_KEY should contain 5 to 20 alphanumerical characters.
YOUR_SECRET_KEY should contain 8 to 40 alphanumerical characters.
AWS_ACCESS_KEY and AWS_SECRET_KEY are the AWS credentials for the IAM user that has access to the S3 buckets where the backups will be stored. See below for the permission policy that needs to be attached to that user.
AWS_STACKGRAPH_BUCKET and AWS_ELASTICSEARCH_BUCKET are the names of the S3 buckets where the backups should be stored. Note: The names of AWS S3 buckets are global across the whole of AWS, therefore the S3 buckets with the default name (sts-elasticsearch-backup and sts-stackgraph-backup) will probably not be available.
The IAM user identified by AWS_ACCESS_KEY and AWS_SECRET_KEY must be configured with the following permission policy to access the S3 buckets:
To enable backups to an Azure Blob Storage account, add the following YAML fragment to the Helm values.yaml file used to install StackState:
Replace the following values:
The StackGraph and Elasticsearch backups are stored in BLOB containers called sts-stackgraph-backup and sts-elasticsearch-backup respectively. These names can be changed by setting the Helm values backup.stackGraph.bucketName and backup.elasticsearch.bucketName respectively.
If MinIO is configured to store its data in Kubernetes storage, a PersistentVolumeClaim (PVC) is used to request storage from the Kubernetes cluster. The kind of storage allocated depends on the configuration of the cluster.
It's advised to use AWS S3 for clusters running on Amazon AWS and Azure Blob Storage for clusters running on Azure for the following reasons:
Kubernetes clusters running in a cloud provider usually map PVCs to block storage, such as Elastic Block Storage for AWS or Azure Block Storage. Block storage is expensive, especially for large data volumes.
Persistent Volumes are destroyed when the cluster that created them is destroyed. That means an (accidental) deletion of your cluster will also destroy all backups stored in Persistent Volumes.
Persistent Volumes can't be accessed from another cluster. That means that it isn't possible to restore StackState from a backup taken on another cluster.
To enable backups to cluster-local storage, enable MinIO by adding the following YAML fragment to the Helm values.yaml file used to install StackState:
Replace the following values:
YOUR_ACCESS_KEY and YOUR_SECRET_KEY - the credentials that will be used to secure the MinIO system. The automatic backup jobs and the restore jobs will use them. They're also required to manually access the MinIO storage. YOUR_ACCESS_KEY should contain 5 to 20 alphanumerical characters and YOUR_SECRET_KEY should contain 8 to 40 alphanumerical characters.
Configuration and topology data (StackGraph) backups are full backups, stored in a single file with the extension .graph. Each file contains a full backup and can be moved, copied or deleted as required.
When backup.enabled is set to true, scheduled StackGraph backups are enabled by default. To disable scheduled StackGraph backups only, set the Helm value backup.stackGraph.scheduled.enabled to false.
When backup.enabled is set to true, StackGraph restores are enabled by default. To disable StackGraph restore functionality only, set the Helm value backup.stackGraph.restore.enabled to false.
By default, the StackGraph backups are created daily at 03:00 AM server time.
By default, the StackGraph backups are kept for 30 days. As StackGraph backups are full backups, this can require a lot of storage.
The telemetry data (Elasticsearch) snapshots are incremental and stored in files with the extension .dat. The files in the Elasticsearch backup storage location should be treated as a single whole and can only be moved, copied or deleted as a whole.
When backup.enabled is set to true, scheduled Elasticsearch snapshots are enabled by default. To disable scheduled Elasticsearch snapshots only, set the Helm value backup.elasticsearch.scheduled.enabled to false.
When backup.enabled is set to true, Elasticsearch restores are enabled by default. To disable Elasticsearch restore functionality only, set the Helm value backup.elasticsearch.restore.enabled to false.
By default, Elasticsearch snapshots are created daily at 03:00 AM server time.
By default, Elasticsearch snapshots are kept for 30 days, with a minimum of 5 snapshots and a maximum of 30 snapshots.
The retention time and number of snapshots kept can be configured using the following Helm values:
backup.elasticsearch.scheduled.snapshotRetentionMinCount
backup.elasticsearch.scheduled.snapshotRetentionMaxCount
By default, a snapshot is created for Elasticsearch indices with names that start with sts.
To list the StackGraph backups, execute the following command:
The output should look like this:
The timestamp when the backup was taken is part of the backup name.
To avoid the unexpected loss of existing data, a backup can only be restored on a clean environment by default. If you are completely sure that any existing data can be overwritten, you can override this safety feature by using the command -force. Only execute the restore command when you are sure that you want to restore the backup.
To restore a StackGraph backup on a clean environment, select a backup name and pass it as the first parameter in the following command:
To restore a StackGraph backup on an environment with existing data, select a backup name and pass it as the first parameter in the following command next to a second parameter -force:
The output should look like this:
In case you are running a restore command missing the -force flag on a non-empty database the output will contain an error like this:
To list the Elasticsearch snapshots, execute the following command:
The output should look like this:
The timestamp when the backup was taken is part of the backup name.
To delete existing Elasticsearch indices so that a snapshot can be restored, follow these steps.
Stop indexing - scale down all *2es deployments to 0:
Open a port-forward to the Elasticsearch master:
Get a list of all indices:
The output should look like this:
Delete an index with a following command:
Replace INDEX_NAME with the name of the index to delete, for example:
The output should be:
To restore an Elasticsearch snapshot, select a snapshot name and pass it as the first parameter in the following command line. You can optionally specify a second parameter with a comma-separated list of the indices that should be restored. If not specified, all indices that match the Helm value backup.elasticsearch.scheduled.indices will be restored (default "sts*"):
The output should look like this:
The indices restored are listed in the output, as well as the number of failed and successful restore actions.
After the indices have been restored, scale up all *2es deployments:
AZURE_STORAGE_ACCOUNT_NAME - the
AZURE_STORAGE_ACCOUNT_KEY - the where the backups should be stored.
The backup schedule can be configured using the Helm value backup.stackGraph.scheduled.schedule, specified in .
The backup retention delta can be configured using the Helm value backup.stackGraph.scheduled.backupRetentionTimeDelta, specified in .
The configuration snippets provided in the section will enable daily Elasticsearch snapshots.
The backup schedule can be configured using the Helm value backup.elasticsearch.scheduled.schedule, specified in .
backup.elasticsearch.scheduled.snapshotRetentionExpireAfter, specified in .
By default, the retention task itself . If you set snapshots to expire faster than within a day, for example for testing purposes, you will need to change the schedule for the retention task.
The indices for which a snapshot is created can be configured using the Helm value backup.elasticsearch.scheduled.indices, specified in .
Scripts to list and restore backups and snapshots can be found in the . To use the scripts, download them from GitHub or checkout the repository.
When a snapshot is restored, existing indices will NOT be overwritten. Use the Elasticsearch to remove them first.
See .