Home > Data Protection > PowerProtect Data Manager > Dell PowerProtect Data Manager: Protecting Kubernetes Workloads > Application-consistent database backups in Kubernetes
PowerProtect Data Manager supports agentless, application-consistent backups of database applications that reside in Kubernetes pods. Application-consistent backups occur when the database application is informed of a pending backup. The database completes all pending transactions and operations, while typically queuing new requests. This process places the database in a quiescent state of relative inactivity where the backup represents a true snapshot of the application. This backup now captures items that would have otherwise been stored only in memory. After the snapshot, the application resumes normal functionality. In most environments, the snapshot operation is instantaneous, so downtime is minimal.
These backups are agentless, in that the PowerProtect Data Manager can take a snapshot of containers without the need for software installation in the database application environment. Then, that snapshot is backed up using the normal procedures for the Kubernetes environment.
The PowerProtect Data Manager provides a standardized way to quiesce a supported database, back up the data from that database, and then return the database to operation. Application templates serve as a bridge between a specific database environment and the Kubernetes backup architecture for the PowerProtect Data Manager. Depending on the differences between database environments, each deployment may require a different configuration file.
Application templates are typically deployed from customizable YAML files that come with the CLI package. The CLI package exists on the PowerProtect Data Manager host at
/usr/local/brs/lib/cndm/misc/ppdmctl.tar.gz
and is part of the PowerProtect Data Manager deployment. Starting from PowerProtect Data Manager 19.12, the CLI package can be downloaded from the PowerProtect Data Manager UI.
Supported applications include:
Standalone deployment in one pod.
Cluster (primary/secondary) deployment with multiple StatefulSets or ReplicaSets. For example, through Helm.
Standalone deployment in one pod.
Cluster (primary/secondary) deployment with multiple StatefulSets. For example, through Helm.
Because data syncs from the primary pods to secondary pods, the PowerProtect Data Manager backs up secondary pods first.
Data Manager has Application Consistent protection feature for MySQL and MongoDB databases. To use this feature, user creates a MySQL Application consistent backup using templates. PowerProtect Data Manager has in-built ‘ppdmctl.tar.gz’ file available which contains the templates for MySQL and MongoDB in YAML format. This file is pushed from PowerProtect Data Manager to Kubernetes cluster root directory to enable the application-consistent protection. The protection is provided only to the namespace which has asset defined in the protection policy. When the protection policy is applied with an enabled MySQL template, the consistency of the backed-up data is application consistent; when the MySQL template is disabled, the consistency is crash consistent.
Kubernetes namespaces are already discovered as assets with PowerProtect Data Manager. There are the available namespaces for protection except powerprotect and velero-ppdm namespaces. To configure the application-consistent protection, particular namespace is specified. In this case, test-namespace is used to demonstrate.
cd /usr/local/brs/lib/cndm/misc
ls -ltrh
scp ppdmctl.tar.gz tme@k8s-cluster01
tar -xvf ppdmctl.tar.gz
cd ppdmctl
ls
cd examples
ls
mysqlapptemplatehelm.yaml
file to create a template copy from the example for MySQL with command
(tmedemomysqlapptemplatestadalone.yaml
is the existing template associated to test-namespace).
cp mysqlapptemplatehelm.yaml tmedemomysqlapptemplatestadalone.yaml
kubectl describe sts mysql -n test-namespace
To change the name of primary pod as per the pod description, edit:
selectorExpression: “mysql” (mysql is new name)
If there are no worker pods being used for MySQL, remove the selectorTerms section under selectors for worker.
To edit the MySQL password environment variable, preHook and postHook are edited. (Pod-based hooks run hook code in a new pod derived from template in a deployment configuration, preHook is to quiesce and postHook is to be unquiesce.)
cd..
to exit the examples directory to the ppdmctl directory.
./ppdmctl template create tmemysqltemplate –type=mysql –namespace=test-namespace –inputfile=examples/tmedemomysqlapptemplatestadalone.yaml
The application-consistent protection is configured for specific namespace (test-namespace in this demonstration). When the backup is run manually or using protection policy, the backup copy is saved as application consistent at the target storage.
./ppdmctl template disable tmemysqltemplate –namespace=test-namespace
PowerProtect Data Manager supports both PostgreSQL and PostgreSQL HA (high availability). Both PostgreSQL and PostgreSQL HA configure a cluster with a primary-standby topology. The primary node has writing permission while replication is on the standby nodes which have read-only permissions. PowerProtect Data Manager has the integrated ppdmctl.tar.gz file which contains the templates for PostgreSQL in YAML format. This file is pushed to the primary node. Pgpool-II acts as proxy for PostgreSQL backend. It reduces connection overhead and used as a load balancer for PostgreSQL. Pgpool-II is responsible to spread the queries among nodes.
Application template of PostgreSQL
AppLabel: “app=postgresql”
Type: “Postgresql”
AppActions:
Pod:
PreHook: "[\"/bin/bash\", \"-c\", \"PGPASSWORD=$POSTGRES_PASSWORD psql - U
$POSTGRES_USER -c \\\"select pg_start_backup('ppdm-backup', true);\\\"\"]" PostHook: "[\"/bin/bash\", \"-c\", \"PGPASSWORD=$POSTGRES_PASSWORD psql - U
$POSTGRES_USER -c \\\"select pg_stop_backup();\\\"\"]"
AppLabel:“app.kubernetes.io/name=postgresql- ha,app.kubernetes.io/component=postgresql”
# applabel to select pod Type: “Postgresql” AppActions:
Pod:
PreHook: "[\"/bin/bash\", \"-c\", \"REPMGR_PRIMARY_HOST=`echo
$REPMGR_PRIMARY_HOST | cut -f1 -d '.'`; if [ $HOSTNAME =
$REPMGR_PRIMARY_HOST ]; then PGPASSWORD=$POSTGRES_PASSWORD psql -U
$POSTGRES_USER -c \\\"select pg_start_backup('ppdm-backup', true);\\\"; fi\"]“
PostHook: "[\"/bin/bash\", \"-c\", \"REPMGR_PRIMARY_HOST=`echo
$REPMGR_PRIMARY_HOST | cut -f1 -d '.'`; if [ $HOSTNAME =
$REPMGR_PRIMARY_HOST ]; then PGPASSWORD=$POSTGRES_PASSWORD psql -U
$POSTGRES_USER -c \\\"select pg_stop_backup();\\\"; fi\"]"
Application:
Kind: StatefulSet
Selectors:
SelectorTerms: {“field” : “Name”, "selectorExpression": ".*-[1-9][0- 9]*$“ }
# Standby pods with index > 0
SelectorTerms: {“field” : “Name”, "selectorExpression": ".*-0$"} # Primary pods with index = 0
Apache Cassandra is highly scalable, high-performance distributed database designed to handle large amounts of data with no single point of failure. It is a type of NoSQL database. Cassandra partitions data over storage nodes using consistent hashing algorithm. Each node stores multiple ranges of tokens and each range of token replicates to multiple nodes for fault-tolerance and high availability. PowerProtect Data Manager has Application Consistent protection feature for Cassandra database. PowerProtect Data Manager has the integrated ppdmctl.tar.gz file which contains the templates for Cassandra in YAML format.
Application template of Cassandra:
AppLabel: “app=cassandra”
Type: “Cassandra”
Enable: true
AppActions:
Pod:
PreHook: "[\"/bin/bash\", \"-c\", \"nodetool flush\"]"
For more details, see the PowerProtect Data Manager Kubernetes User Guide on Dell Support at PowerProtect Data Manager Info Hub: Product Documents and Information.