Backup and recovery without Google Cloud Stay organized with collections Save and categorize content based on your preferences.
This section discusses how to configure backup and recovery of your Cassandra database usingssh and your file system instead of using Google Cloud. See also:
What is Cassandra backup and recovery without Cloud Services
Backup without Cloud Services stores backups of your Cassandra database to compressed files in the file system of a server you specify. Backups occur on a schedule you specify in your overrides file. The connection to the server is by secure SSH.
Note: You must ensure there is enough space on the file system for the backups, and adjust the frequency of the backups to avoid unnecessarily filling the alloted storage space. Apigee does not dictate a retention policy for the backup files. You may want to create a retention policy for files appropriate to your installation.Setting up backups without Cloud Services
The following steps include common examples for completing specific tasks, like creating an SSH key pair. Use the methods that are appropriate to your installation.
The procedure has the following parts:
Set up the server and SSH
- Designate a Linux or Unix server for your backups. This server must be reachable using SSH from your Apigee hybrid runtime plane. It must have enough storage for your backups.
- Set up an SSH server on the server, or ensure that it has a secure SSH server configured.Caution: For security purposes, make sure your SSH server is up to date.
- Create an SSH key pair and store the private key file in a path that is accessible from your hybrid runtime plane.You must use a blank password for your key pair or the backup will fail. For example:
ssh-keygen -t rsa -b 4096 -Cexampleuser@example.comEnter file in which to save the key (/Users/exampleuser/.ssh/id_rsa):$APIGEE_HOME/hybrid-files/certs/ssh_key Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in ssh_key Your public key has been saved in ssh_key.pub The key fingerprint is: SHA256:DWKo334XMZcZYLOLrd/8HNpjTERPJJ0mc11UYmrPvSA exampleuser@example.com The key's randomart image is: +---[RSA 4096]----+ | +. ++X| | . . o.=.*+| | . o . . o==o | | . . . =oo+o...| | . S +E oo .| | . . .. . o .| | . . . . o.. | | . ...o ++. | | .. .. +o+. | +----[SHA256]-----+ - Create a user account on the backup server with the name
apigee. Make sure the newapigeeuser has a home directory under/home. - On the backup server, create an
sshdirectory in the new/home/apigeedirectory. - Copy the public key (
ssh_key.pubin the previous example) into a file namedauthorized_keysin the new/home/apigee/sshdirectory. For example:cd /home/apigee
mkdir .sshcd .sshvi authorized_keys - On your backup server, create a backup directory within the
/home/apigee/directory. The backup directory can be any directory as long as theapigeeuser has access to it. For example:cd /home/apigee
mkdir cassandra-backup - Test the connection. You need to make sure that your Cassandra pods can connect to your backup server using SSH:
- Log into the shell of your Cassandra pod. For example:
kubectl exec -it -n apigeeAPIGEE_CASSANDRA_DEFAULT_0 -- /bin/bash
WhereAPIGEE_CASSANDRA_DEFAULT_0 is the name of a Cassandra pod. Change this to the name of the pod you want to connect from.
- Connect by SSH to your backup server, using the server IP address:
Note: You may see a warning at this point saying your server's fingerprint is unrecognized and asks if you would like to continue. For purposes of this test, this means you can successfully reach your backup server from your Cassandra pod. You do not need to continue.ssh apigee@BACKUP_SERVER_IP
- Log into the shell of your Cassandra pod. For example:
Set the schedule and destination for backup
You set the schedule and destination for backups in youroverrides.yaml file.
- Add the following parameters to your
overrides.yamlfile:Parameters
cassandra:backup:enabled:truekeyFile:"PATH_TO_PRIVATE_KEY_FILE"server:"BACKUP_SERVER_IP"storageDirectory:"/home/apigee/BACKUP_DIRECTORY"cloudProvider:"HYBRID"#requiredverbatim"HYBRID"(allcaps)schedule:"SCHEDULE"
Example
cassandra:backup:enabled:truekeyFile:"/Users/exampleuser/apigee-hybrid/hybrid-files/service-accounts/private.key"server:"34.56.78.90"storageDirectory:"/home/apigee/cassbackup"cloudProvider:"HYBRID"schedule:"0 2 * * *"
Where:
Property Description backup:enabledBackup is disabled by default. You must set this property to true.backup:keyFilePATH_TO_PRIVATE_KEY_FILE
The path on your local file system to the SSH private key file (named
ssh_keyinthe step where you created the SSH key pair).backup:serverBACKUP_SERVER_IP
The IP address of your backup server.
backup:storageDirectoryBACKUP_DIRECTORY
The name of the backup directory on your backup server. This must be a directory within
home/apigee(the backup directory is namedcassandra_backupinthe step where you created the backup directory).backup:cloudProviderHYBRIDThe
cloudProvider: "HYBRID"property is required.backup:scheduleSCHEDULE
The time when the backup starts, specified instandard crontab syntax. Default:
Note: Avoid scheduling a backup that starts a short time after you apply the backup configuration to your cluster. When you apply the backup configuration, Kubernetes recreates the Cassandra nodes. If the backup starts before the nodes restart (possibly several minutes) the backup will fail.0 2 * * * - Use
apigeectlto apply the backup configuration to the storage scope of your cluster:$APIGEECTL_HOME/apigeectl --datastore -fYOUR_OVERRIDES_FILE
WhereYOUR_OVERRIDES_FILE is the path to the overrides file you just edited.
Configure restore
Restoration takes your data from the backup location and restores the data into a new Cassandra cluster with the same number of nodes. No data is taken from the old Cassandra cluster.
The restoration instructions below are for single region deployments that do not use Google Cloud Storage for backups. For other deployments, see the following:
- For single region deployments that do use Google Cloud Storage for backups, see Cassandra backup and recovery.
- For multi-region deployments, see Multi-region deployment on GKE and GKE on-prem.
To restore Cassandra backups:
- Create a new namespace within the existing Kubernetes cluster that will be used to restore the hybrid huntime deployment. Do not use the original namespace name for the new namespace. Do not use the old namespace for restoration.
- In the root hybrid installation directory, create a new
overrides-restore.yamlfile. - Copy the complete Cassandra configuration from your original
overrides.yamlfile into the newoverrides-restore.yamlfile. For example:cp ./overrides.yaml ./overrides-restore.yaml
- Add a namespace element to the new
overrides-restore.yamlfile.Parameters
namespace:YOUR_RESTORE_NAMESPACEcassandra:...restore:enabled:truekeyFile:"PATH_TO_PRIVATE_KEY_FILE"server:"BACKUP_SERVER_IP"storageDirectory:"/home/apigee/BACKUP_DIRECTORY"cloudProvider:"HYBRID"#requiredverbatim"HYBRID"(allcaps)snapshotTimestamp:"TIMESTAMP"...
Example
namespace:cassandra-restorecassandra:restore:enabled:truekeyFile:"/Users/exampleuser/apigee-hybrid/hybrid-files/service-accounts/private.key"server:"34.56.78.90"storageDirectory:"/home/apigee/cassbackup"cloudProvider:"HYBRID"snapshotTimestamp:"20201001183903"
- Change the
applabel on any Cassandra nodes in the old namespace by executing the following command:kubectl label pods --overwrite --namespace=OLD_NAMESPACE -l app=apigee-cassandra app=apigee-cassandra-old
- Create a new hybrid runtime deployment. This will create a new Cassandra cluster and begin restoring the backup data into the cluster:
./apigeectl init -f ../overrides-restore.yaml
./apigeectl apply -f ../overrides-restore.yaml
Once the restoration is complete, the traffic must be switched to use the Cassandra cluster in the new namespace. Run the following commands to switch the traffic:
kubectl get rs -nOLD_NAMESPACE # look for the 'apigee-connect' replicaset
kubectl patch rs -nOLD_NAMESPACEAPIGEE_CONNECT_RS_NAME -p '{"spec":{"replicas" : 0}}'- Once the traffic switch is complete, you can reconfigure backups on the restored cluster by removing the
restoreconfiguration and adding thebackupconfiguration to theoverrides-restore.yamlfile. ReplaceYOUR_RESTORE_NAMESPACE with the new namespace name created instep 1.namespace:YOUR_RESTORE_NAMESPACEcassandra:...backup:enabled:trueserviceAccountPath:SA_JSON_FILE_PATHdbStorageBucket:CLOUD_STORAGE_BUCKET_PATHschedule:BACKUP_SCHEDULE_CODE...
Then apply the
backupconfiguration with the following command:./apigeectl apply -f ../overrides-restore.yaml
Where:
| Property | Description |
|---|---|
namespace | YOUR_RESTORE_NAMESPACE The name of the new namespace you created instep 1 for the new Cassandra cluster. Do not use the same namespace you used for your original cluster. |
restore:enabled | Restore is disabled by default. You must set this property totrue. |
restore:keyFile | PATH_TO_PRIVATE_KEY_FILE The path on your local file system to the SSH private key file (named |
restore:server | BACKUP_SERVER_IP The IP address of your backup server. |
restore:storageDirectory | BACKUP_DIRECTORY The name of the backup directory on your backup server. This must be a directory within |
restore:cloudProvider |
The |
restore:snapshotTimestamp | TIMESTAMP The timestamp of the backup snapshot to restore. To check what timestamps can be used, go to the
Where20210203213003 is the |
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-12-17 UTC.