Trigger Backups Using Command Line Interface
This article details the steps that an Application Admin will need to perform to backup stateful applications.
- Using terminal console ensure all prerequisites are met on the kubernetes cluster to be backed up.
- 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
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.
- 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
Do Not Modify the following settings
- name: DRUVA_MYSQL_HOST
- name: DRUVA_MYSQL_SECRET_NAME
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:
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.
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.