Restore Elasticsearch Snapshots

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.
  • The
    include_aliases
    parameter prevents a conflict in the event that you restore to a cluster that already has an alias.
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 any Elasticsearch cluster.
  1. Send the API request to restore the snapshot:
    POST _snapshot/xsoar_repository/snapshotname/_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:
    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 Best Practices guide.

Recommended For You