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 tofalse
so Elastiscsearch does not skip any unavailable indices. Note that withignore_unavailable
set tofalse
, if an index is not available, the entire request will fail. If set totrue
, 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.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 thePOST /[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 period of time to complete. If you do decide to restore to an existing cluster, stop the server before sending the API request (perform Step 2 before Step 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.
After the restore is complete, stop the Cortex XSOAR service. For high availability deployments, all servers must be stopped.
sudo systemctl demisto stop
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
.Restart the Cortex XSOAR service:
sudo systemctl demisto start
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.