Scheduling backups in a remote server

You are currently viewing version 1.12 of the Apigee hybrid documentation.This version is end of life. You should upgrade to a newer version. For more information, seeSupported versions.
Warning: Apigee Hybrid versions before 1.12.4 havea known issue affecting backups that useHYBRID orGCP Cloud Providers. Please check theCleanup leftover snapshots to check whether your setup is affected and for steps needed for resolution.

This page describes how to schedule backups for Cassandra without the Cloud Storage.In this method, backups are stored on a remote server specified by you instead of a Cloud Storage bucket. Apigee uses SSH to communicate with the remote server.

You must schedule the backups ascron jobs. Once a backup schedule has been applied to your hybrid cluster, a Kubernetes backup job is periodically executed according to the schedule in the runtime plane. The job triggers a backup script on each Cassandra node in your hybrid cluster that collects all the data on the node, creates an archive (compressed) file of the data, and sends the archive to the server specified in youroverrides.yaml file.

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 allotted 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.
  • Applying backup configuration on the existing cluster will rolling restart Cassandra pods.

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

  1. Select a Backup Server: Choose a Linux or Unix server with adequate storage for your backups and ensure it can be accessed via SSH from your Apigee hybrid runtime plane.
  2. Configure the SSH Server: Either install an SSH server or confirm that an existing one is secure.
  3. Caution: For security purposes, make sure your SSH server is up to date.
  4. Create an SSH Key Pair: Generate an SSH key pair without a passphrase:For example:
    ssh-keygen-trsa-b4096-Cexampleuser@example.comEnterfileinwhichtosavethekey(/Users/exampleuser/.ssh/id_rsa):$APIGEE_HOME/hybrid-files/certs/ssh_keyEnterpassphrase(emptyfornopassphrase):Entersamepassphraseagain:Youridentificationhasbeensavedinssh_keyYourpublickeyhasbeensavedinssh_key.pubThekeyfingerprintis:SHA256:DWKo334XMZcZYLOLrd/8HNpjTERPJJ0mc11UYmrPvSAexampleuser@example.comThekey'srandomartimageis:+---[RSA 4096]----+|+.++X||..o.=.*+||.o..o==o||...=oo+o...||.S+Eoo.||.....o.||....o..||....o++.||....+o+.|+----[SHA256]-----+

    Where:exampleuser@example.com is a string. Any string that follows-C in thessh-keygen command becomes a comment included in the newly createdssh key. The input string can be any string. When you use an account name in the form ofexampleuser@example.com, you can quickly identify which account goes with the key.

    The command will generate two SSH key files, A private key file (for example `ssh_key.rsa`) and a public key file (for example, `ssh_key.pub`).

    Save the private key to a location that your runtime plane can access.

  5. Add a User Account: On the backup server, create a user named apigee with a home directory under/home/apigee. Make sure the newapigee user has a home directory under/home.
  6. Set Up the .ssh Directory: On the backup server, create a.ssh directory in/home/apigee/.ssh. For example:
    cd /home/apigeemkdir .sshcd .sshvi authorized_keys
  7. Install the Public Key: Place the public key into theauthorized_keys file within the/home/apigee/ directory. The backup directory can be any directory as long as theapigee user has access to it.Paste the contents of thessh public keyfile into the file.
  8. Verify SSH Access: Test the connection from your local machine or a cluster node:
  9. ssh -iPATH_TO_PRIVATE_KEY_FILE apigee@BACKUP_SERVER_IP
    Note: Make sure that you are able to access the remote server without being prompted for a password or a passphrase. If you get asked for a passphrase, please regenerate the ssh key pair without specifying a passphrase. In case you get prompted for a password, please double-check your ssh configuration on your remote server, since it is most likely not set up correctly.

Set the schedule and destination for backup

You set the schedule and destination for backups in youroverrides.yaml file.

  1. Add the following parameters to youroverrides.yaml file:

    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:"private.key"#pathrelativetoapigee-datastorepathserver:"34.56.78.90"storageDirectory:"/home/apigee/cassbackup"cloudProvider:"HYBRID"schedule:"0 2 * * *"

    Where:

    PropertyDescription
    backup:enabledBackup is disabled by default. You must set this property totrue.
    backup:keyFile

    PATH_TO_PRIVATE_KEY_FILE

    The path on your local file system to the SSH private key file (namedssh_key inthe step where you created the SSH key pair). This path must be relative to theapigee-datastore chart directory.

    backup:server

    BACKUP_SERVER_IP

    The IP address of your backup server.

    backup:storageDirectory

    BACKUP_DIRECTORY

    The name of the backup directory on your backup server. This must be a directory withinhome/apigee (the backup directory is namedcassandra_backup inthe step where you created the backup directory).

    backup:cloudProvider

    HYBRID

    For a remote server backup, set the property toHYBRID.

    backup:schedule

    SCHEDULE

    The time when the backup starts, specified instandard crontab syntax. Times are in the local time zone of the Kubernetes cluster. Default:0 2 * * *

    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, the first backup will fail and the subsequent backups will pass.

  2. Apply the backup configuration to the storage scope of your cluster:
    helm upgrade datastore apigee-datastore/ \  --install \  --namespaceAPIGEE_NAMESPACE \  --atomic \  -fOVERRIDES_FILE.yaml

    WhereOVERRIDES_FILE is the path to the overrides file you just edited.

  3. Verify the backup job. For example:
    kubectl get cronjob -nAPIGEE_NAMESPACE
    NAMESCHEDULESUSPENDACTIVELASTSCHEDULEAGEapigee-cassandra-backup33****False0        <none>94s

Launch a manual backup

Backup jobs are triggered automatically according to the cron schedule set incassandra.backup.schedule in youroverrides.yaml file. However, you can also initiate a backup job manually if needed using the following command:

kubectl create job -nAPIGEE_NAMESPACE --from=cronjob/apigee-cassandra-backupMANUAL_BACKUP_JOB_NAME

WhereMANUAL_BACKUP_JOB_NAME is the name of a manual backup job to be be created.

Troubleshooting

  1. Test the connection from a Cassandra pod. You need to make sure that your Cassandra pods can connect to your backup server using SSH:
    1. Log into the shell of your Cassandra pod. For example:
      kubectl exec -it -nAPIGEE_NAMESPACEAPIGEE_CASSANDRA_POD -- /bin/bash

      WhereAPIGEE_CASSANDRA_POD is the name of a Cassandra pod. Change this to the name of the pod you want to connect from.

    2. Connect by SSH to your backup server, using the private SSH key mounted the Cassandra pod and server IP address:
      ssh -i /var/secrets/keys/key apigee@BACKUP_SERVER_IP
      Note: You may see a warning at this point saying your server's fingerprint is unrecognized and asks if you would like to continue. You can continue at that prompt and verify the SSH configuration.
  2. If you have problems accessing your remote server from the Cassandra pod, please check your ssh configuration on the remote server again and also make sure thatupgrading the datastore was successful.
  3. You can check if Cassandra uses the correct private key by running the following command while you are logged in to your Cassandra pod, and compare the output with the private key you created:
    cat /var/secrets/keys/key

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.