Restore Elasticsearch Snapshots - Administrator Guide - 6.9 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Administrator Guide

Product
Cortex XSOAR
Version
6.9
Creation date
2022-09-29
Last date published
2024-06-20
End_of_Life
EoL
Category
Administrator Guide
Abstract

Restore one or more indices or the entire Cortex XSOAR database, using Elasticsearch snapshots.

Using Elasticsearch snapshots, you can restore a single index, multiple indices, or the entire Cortex XSOAR database.

Restore one or more indices

You can restore one or more indices to an already active node or to a new node, using a PUT API request.

  • We recommend setting the ignore_unavailable parameter to false so Elastiscsearch does not skip any unavailable indices. Note that with ignore_unavailable set to false, if an index is not available, the entire request will fail. If set to true, if one index was available and the second index was not available, the first index would be restored. If you do decide to restore to an existing cluster, stop the server before sending the API request (perform Step 2 before Step 1).

  • The include_aliases parameter prevents a conflict in the event that you restore to a cluster that already has an alias.

  • If restoring to an existing Elasticsearch cluster, stop Cortex XSOAR (for high availability deployments, all servers must be stopped), close the original indexes with the POST /[index name]/_close command, and then send the API request to restore. After restoring, open the indices with the POST /[index name]/_open command and restart Cortex XSOAR. For high availability multi-tenant deployments, you can stop only the main servers and the host servers for the high availability group where that tenant resides.

For more information on restoring an Elasticsearch snapshot, see the Elasticsearch Restore a Snapshot guide.

In the following example, two indices are restored. The first is all incidents from October 2021 and the second is all indicators system wide.

POST _snapshot/DemistoBackupRepository/test-dbmain/_restore
{
  "indices": "my-dmst-common-incident_202110,my-dmst-common-indicator",
  "ignore_unavailable": false,
  "include_aliases": false
}
Restore the entire database

You can restore a snapshot of the entire database to a new Elasticsearch cluster. We do not recommend restoring an entire database to an existing Elasticsearch cluster, as it can take an extended amount of time to complete.

  1. Send the API request to restore the snapshot:

    POST _snapshot/xsoar_repository/snapshotnames/_restore

    You have the option, when restoring the snapshot, to modify the indices settings, such as replicas count and refresh interval, to improve cluster rebalancing upon restoration. See the Elasticsearch documentation for changing index settings during restore.

    In some cases, snapshot restoration might take hours to complete, depending on the size of the data, the cluster size, and network latency.

  2. After the restore is complete, stop the Cortex XSOAR service. For high availability deployments, all servers must be stopped.

    sudo systemctl demisto stop

  3. Update the Elasticsearch configuration settings for each Cortex XSOAR application server, if cluster connection information has changed. Cluster connection information includes master/coordinate notes, passwords, and other credentials. If you are restoring to the original Elasticsearch cluster, verify that the original cluster is active and revert each Cortex XSOAR application server to its original configuration, if changes have been made.

    If a load balancer or a coordinate node address is set in the configurations, you can reroute to the new data nodes and keep your current Cortex XSOAR Elasticsearch settings in demisto.conf.

  4. Restart the Cortex XSOAR service:

    sudo systemctl demisto start

  5. Validate that all data is available.

After Disaster Recovery

In some cases, after restoring a partial snapshot, nodes might be unbalanced, which might lead to performance degradation. Nodes can also be unbalanced if you restore an entire database to a new Elasticsearch cluster which is a different size than the original cluster.

After completing partial or full disaster recovery, confirm that your Elasticsearch deployment still matches the Elasticsearch Best Practices guide.