Backing Up and Restoring Configuration Data for Deployed Capabilities

For more information on backing up and restoring Event Data, see Backing Up and Restoring the ArcSight Database

Certain components deployed on the ArcSight Platform use NFS (or EFS when deployed to AWS) to store some of their data, such as Fusion credentials, dashboard widgets, and search preferences. You can configure automatic backups of NFS or EFS as a protection in the event of data corruption or loss. You can restore the backed up data at any time to the same system or a separate one per your requirements. In the event of data corruption or loss, you can use the backed up data and roll back to an available and known good restore point. Backups are carried out at two levels: pod and NFS.

Because data stores are mounted to /<Server mount path>/arcsight-volume, do not use this same storage device for your NFS backups. Use a local folder on the system or a remote location.

The following table lists the impacted pods for each capability:

Capability Name Pod Name
Fusion

  • fusion-metadata-rethinkdb-*-*

  • fusion-user-management-*-*

  • fusion-single-sign-on-*-*

  • fusion-dashboard-web-app-*-*

  • fusion-metadata-web-app-*-*

  • fusion-arcmc-web-app-*-*

  • soar-web-app -*-*

  • soar-message-broker -*-*

Intelligence

  • h2-*-*

  • intelligence-arcsightconnector-api-*-*

  • intelligence-tenant-control-*-*

  • intelligence-tuning-api-*-*

  • interset-analytics-*-*

  • interset-api-*-*

  • interset-ui-*-*

  • searchmanager-api-*-*

  • searchmanager-engine-*-*
Transformation Hub

  • th-c2av-processor-*.*

  • th-c2av-processor-esm-*.*

  • th-enrichment-processor-group*-*

  • th-kafka-*.*

  • th-kafka-manager-*-*

  • th-routing-processor-group*-*

  • th-schemaregistry-*-*

  • th-web-service-*-*

  • th-zookeeper-*.*

Understanding How Pod-level Backup Occurs

Each pod backs up its own data on an hourly basis, placing the data in a backup staging directory related to the pod's mount location under /<Server mount path>/arcsight-volume. This automated backup process ensures that the pod stores a backup of its data in a complete state. The pod retains a maximum of 24 backups in the staging directory. At any given hour, the oldest backup is deleted and a fresh one created. Because the pod backup is stored in the same NFS volume as the pod content, this pod-level backup does not protect you against data loss or corruption of the volume. Thus, you should configure an NFS level backup to ensure data continuity.

Automated pod backups apply to Fusion and Intelligence capabilities only.

NFS Level Backup

You must configure an NFS level backup to store the pod-level backup in a reliable, external storage system. For the backup, you must configure a scheduled job to back up the backup staging directory updated by the pod-level backups. The schedule should be less frequent than the hourly interval for pod-level backups.

To set up the NFS level backup or to restore the data, see the following sections based on your environment: