Overview 

This article details the steps that an Application Admin will need to perform to backup stateful applications.

Prerequisites

1. Using terminal console ensure all prerequisites are met on the kubernetes cluster to be backed up.
2. Verify that the following prerequisites are installed:
   • kubectl ((v 1.19 and later), Kubernetes CLI tool
   • Helm (v 3.6.0), the package manager 
   • AWS Command Line Interface (CLI) v2, a unified tool to manage your AWS services
   • The IAM keys from your AWS Management Console and configure them, IAM users will need the requisite permissions. 
   • CSI External-Snapshotter (v 4.1.0)
   • The latest CSI driver for Amazon EBS
     Note: The CSI driver must be installed post-installation of the External Snapshotter
   • Cert Manager (v 1.1.0 and later)
   • Service Catalog

For more information, see Prerequisites.
 

The following parameters must be defined to trigger a backup:

• Kubernetes Object Name: BackupTrigger
• BackupMethod: Snapshot
• Application Group ID and Recipe, as applicable, based on which backup is to be performed
   

Procedure 

 The Kubernetes Admin will need to assign the requisite role and permissions to the  Application Admin to enable backup and restore of stateful applications. The    Application Admin can then log into the cluster and administer only a namespace belonging to their applications.

1. To trigger a backup, run the following command:

$kubectl druva create backup <applicationgroup> -n <namespace>

A sample backup command is shown below:

$kubectl druva create backup mysqlappgroup -n mysqlapp

2. To trigger application-consistent snapshots of a MySQL workload, refer to the sample ApplicationGroup YAML below:

apiVersion: backup.druva.com/v1alpha1
    kind: ApplicationGroup
    metadata:
      name: restore-appgroup
      namespace: wordpress-prod
    spec:
      applicationGroupDetail:
        helmReleases:
        - helmDriver: Secret
          releaseNames:
          - mysql-release
          - wordpress-release
      applicationGroupRecipes:
        standalone:
          applicationRecipes:
            mysql:
              applicationName: druva-standalone-mysql-application
              env:
              - name: DRUVA_MYSQL_HOST
                value: mysql-release-headless
              - name: DRUVA_MYSQL_SECRET_NAME
                value: mysql-release

The above Application Group configuration includes a Recipe, which is application-specific. 

Note: There are some mutable and Immutable configuration settings within the ApplicationGroup. The Application Admin may modify the following values based on business requirements:

• name:  and namespace: under metadata
• release name under releaseNames
• applicationGroupRecipes can either be standalone or replicated
• applicationName: change as per MySQL architecture model, that is standalone or replicated

 

3. You can trigger backups with or without an Application Group Recipe configured. To trigger a backup without an Application Group Recipe, run the following command:

apiVersion: backup.druva.com/v1alpha1
kind: BackupTrigger
metadata:
  name: standalone-mysql
spec:
  backupMethod: Snapshot
  applicationGroupID:

where,
name indicates the Application Group Name.
backupMethod indicates the type of backup to be triggered, for example, Snapshot, Full or Incremental. Snapshots are the only backup method, currently supported.
applicationGroupID indicates the ID of the ApplicationGroup for which to trigger a backup. If the applicationGroupID specified does not match the ID of the ApplicationGroup, the backup will fail.

 

4. Display Backup Status: To display the status of all backups within that Namespace, use the get backup command for the latest successful backups of all application group(s) within that namespace:

kubectl get backup -- namespace <namespace> 

This will generate the list of backups available for restore, serving either as a precursor to the restore workflow or as part of monitoring.
A sample of the output displayed:

NAME                                          APPLICATIONGROUPNAME       STARTEDAT              STAGE      STATE       UPDATEDAT              COMPLETEDAT
dbo-f52e1295-515d-4515-a806-691a001bd575      mysqlappgroup              2021-10-21T13:44:45Z   Finalize   Completed   2021-10-21T13:47:40Z   2021-10-21T13:47:40

Note: If the last initiated backup has failed, then only the last successful backup of application groups within that namespace will be displayed.

Next Steps

Upon creating an Application Group, Druva Backup Operator registers the Application Group with the backup catalog and installs a secret containing the Application Group credentials, which are required to initiate the backup and create a Restore Point. Once the backup generates successfully, the Restore Point is created in the same namespace as the Application Group. For more information, see Restore Workflow Using Command Line Interface.

 

Related articles

• Backup Job Management
• Restore Workflow Using Command Line Interface