K10 defaults to volume snapshot operations when capturing data, but there are situations where customization is required. For example, the best way to protect your application's data may be to take a logical dump of the database. This requires using tools specific to that database.
Kanister uses Blueprints to define these database-specific workflows and open-source Blueprints are available for several popular applications. It's also simple to customize existing Blueprints or add new ones.
When configured to do so, K10 will automatically use Kanister Blueprints and manage the resulting application-level Kanister artifacts.
Configuring a Profile
The Kanister Blueprints provided use object storage or NFS file storage to manage data artifacts. To make this storage accessible to Kanister Blueprints, configure a Location Profile from the Settings section of the dashboard or via the CRD-based Profiles API. Specifying a Location Profile is required when executing actions or defining policies for applications protected with Kanister.
Make sure that the credentials specified in the Location Profile have sufficient permissions to perform LIST, PUT, GET, and DELETE for the object storage location.
To learn more about configuring an NFS file storage location profile, refer to this section.
Installing Applications and Blueprints
Blueprints typically require no modifications to the application and most Blueprints are written to work with respective standard Helm charts. The Kanister GitHub repository contains several Blueprints that work with respective Helm Charts.
If backups are required where data is captured completely at the data service layer without requiring volume snapshots, the following examples are available today:
Managed Services Backups
If backups need to be performed on Managed Services like Amazon RDS or Google Cloud Databases, to achieve this by using the snapshot APIs of the service provider or by extracting data directly from the service through logical dumps. Following examples are available today:
Application-consistent backups can be enabled if the data service needs to be quiesced before a volume snapshot is initiated.
To obtain an application-consistent backup, a
as defined in the application blueprint, is first invoked and is
followed by a volume snapshot. To shorten the time spent while
the application is quiesced, it is
unquiesced based on the blueprint
definition as soon as the storage system has indicated that a
point-in-time copy of the underlying volume has been started. The
backup will complete asynchronously in the background when the volume
snapshot is complete, or in other words after
application, K10 waits for the snapshot to complete.
An advantage of this approach is that the database is not locked for
the entire duration of the volume snapshot process.
The following examples for application-consistent backups are available today:
etcd Backup and Restore
If a backup of all cluster state stored in etcd is required, the etcd cluster can be backed up and restored in case of catastrophic failure.
Kafka Backup and Restore
For some types of data services, the best approach to data protection may be for the service to stream data directly to object storage. Kanister Blueprints are still used to initiate the stream and to recover data, even though Kanister may not be in the data path.
Kafka, a data streaming platform, is an example of a data server where using a Blueprint to initiate a backup stream may be the preferred data protection strategy.
K8ssandra Backup and Restore
K8ssandra is a cloud native distribution of Apache Cassandra® (Cassandra) designed to run on Kubernetes. K8ssandra follows the K8s operator pattern to automate operational tasks. This includes metric, data anti-entropy services, and backup/restore tooling. More details can be found here.
K8ssandra operator uses Medusa to backup and restore Cassandra data. K10 platform integrates with Medusa operator to perform backup and restore of Cassandra data.
Crunchy Data Postgres Operator Backup and Restore
The Postgres Operator (PGO) developed by Crunchy Data automates and simplifies deploying and managing open source PostgreSQL clusters on Kubernetes.
PGO provides some out of the box features like high availability, disaster recovery, and monitoring, all over secure TLS communications. More details can be found here.
PGO uses open source pgBackRest to backup and restore Postgres data. K10 platform integrates with PGO to perform backup and restore Postgres data using the operator APIs.
Logical Backups to NFS File Storage Location
Kanister Blueprints that use
kando to write and read data can
use NFS file storage locations. The following are some examples:
Specifying a Kanister Blueprint for Your Application
To request K10 to use a custom Kanister Blueprint to manage a workload
(e.g., Deployment or StatefulSet), please (a) create the Blueprint in
the K10 namespace (default
kasten-io) and (b) annotate the
workload with the name of the created blueprint as follows:
$ kubectl --namespace=<app-namespace> annotate <workload>/<workload-name> \ kanister.kasten.io/blueprint=<blueprint-name>
Finally, note that the Blueprint used must have a
restore action defined and ideally a
delete action for
Use Case Testing
Once you have installed your application, you will be able to use the K10 Dashboard to bring the application in compliance and protect it by creating one or more policies. You can also subsequently restore the application and its data to a previous version. You can find more detailed instructions in the Protecting Applications and Restoring Applications sections of this documentation.