Backing up Events Service data helps you to recover from hardware or another type of failure of an Events Service machine. A snapshot represents the backed up data for the entire Events Service cluster. In addition to using it for failure recovery, you can use a snapshot to migrate Events Service to a new instance.

The Events Service tool—events-service.sh for Linux and events-service.exe for Windows—includes commands for preparing the system for backing up with snapshots, generating a snapshot, and restoring from a snapshot, as described below. 

The following instructions show sample commands for Linux. If using Windows, be sure to use the events-service.exe form of the executable rather than the .sh form, and adjust the sample directory paths as needed.

Prepare the File System

When planning your backup strategy, it is important to consider the storage location and frequency of backups. The system that will serve at the repository for snapshots must be able to handle high I/O demands in a performant manner. SSD-based storage is recommended. Also, ensure you have enough disk space on the repository system.

Only the first snapshot results in a full copy of the data. Each subsequent snapshot is incremental, applying only the changes since the last snapshot. Backing up frequently, therefore, does not result in substantially more storage overhead than backing up infrequently.

The Events Service includes tools for setting up the snapshot repository. It supports the following snapshot repository location types:

  • A file system location that is shared among the Events Service nodes. 
  • An Amazon S3 bucket

After choosing and preparing the system that will host the snapshot, set up each Events Service node as follows: 

  1. If using FS, mount the shared filesystem at the default location for the backup repository, <appd_home>/events-service/appdynamics-events-service-backup. To change this backup location, set the the ad.es.backupmanager.path.repo setting in conf/events-service-api-store.properties. Keep in mind, however, that changing the properties file requires a restart of the Events Service node to have the change take effect.
  2. Set up the repository on each node. Use the appropriate command for your repository type: 

    • For shared file system: 

      bin/events-service.sh snapshot-configure-fs -p conf/events-service-api-store.properties

    • For Amazon S3:

      bin/events-service.sh snapshot-configure-s3 -p conf/events-service-api-store.properties -bucket "s3-bucket-name"

      The snapshot-configure-s3 command accepts additional optional arguments, including arguments for passing the access key and secret key for S3. Run "bin/events-service.sh -h" to view all options. 

    Look for a message similar to the following to verify that the configuration succeeded: 

    [2015-12-17T15:43:04,092-08:00] Successfully configured snapshot repository!

Create a Snapshot

After setting up the repository, you can generate a snapshot of the Events Service data. If you are backing up a cluster, you only need to run the command from one of the primary nodes. If you have more than one cluster, generate a snapshot for each one. Snapshots are cluster-specific.

Generate a snapshot: 

bin/events-service.sh snapshot-run -p conf/events-service-api-store.properties

You can use this command to script regular backups based on your backup policy. The following output indicates that backup was successful:

Take snapshot request executed successfully. Snapshot itself may still be in progress.

To check the progress of the snapshot, use snapshot-status. 

bin/events-service.sh snapshot-status -p conf/events-service-api-store.properties

If you don't specify a snapshot ID, the command gets the status for the most recent snapshot. You can use snapshot-list command to see a list of available snapshots. 

Restore from a Snapshot

By restoring a snapshot, you replace the data store configured for the Events Service with one that was previously saved as a snapshot. When you restore from a snapshot, you restore from a snapshot for a specific cluster. Run the command for each cluster 

To restore a snapshot, use the snapshot-restore command, passing the properties file for the Events Service instance you are backing up. The following shows an example with sample output: 

bin/events-service.sh snapshot-restore -p conf/events-service-api-store.properties
[2015-12-17T17:02:52,264-08:00] HV000001: Hibernate Validator 5.0.2.Final
[2015-12-17T17:02:52,811-08:00] Restore snapshot request executed successfully. Restore is now in progress. Use the snapshot-status command to view the current restore status.

Check the status of the snapshot restore using the snapshot-restore-status command. For example:

bin/events-service.sh snapshot-restore-status -p conf/analytics-api-store.properties
[2017-01-03T14:37:46,647-08:00] HV000001: Hibernate Validator 5.2.2.Final
[2017-01-03T14:37:47,027-08:00] Restore is complete, your cluster should be fully functional!

You can restore a specific snapshot by passing the snapshot ID with the command. Otherwise, the most recent snapshot is restored.

bin/events-service.sh snapshot-restore -p conf/events-service-api-store.properties -id <snapshot_id>

You can use snapshot-list command to get a list of snapshot IDs.

Migrating Events Service Data

In addition to data backup and recovery, you can use the snapshot utility to migrate data from one Events Service instance to another.

The target Events Service needs to be a fresh installation; that is, data in two different Events Service instances cannot be merged. Be sure to avoid configuring the Events Service URL with the new instance location in the Controller configuration until you have completed these steps.

To migrate Events Service data, follow these general steps:

  1. Prepare the new Events Service nodes, as described above. 
  2. On each new Events Service node, mount the shared directory where the repository is located.
  3. From a primary node in the new cluster, restore the snapshot by ID, as described above, passing the property file that defines the new cluster as the -p argument. 
  4. When finished, change the connection from the Controller to the Events Service and any Events Service clients, as described in Connect to the Events Service, to use the new instance.