Snapshots provide a way to restore your Elasticsearch indices. They can be used to copy indices for testing, to recover from failures or accidental deletions, or to migrate data to other deployments.

By default, Elasticsearch Service takes a snapshot of all the indices in your Elasticsearch cluster every 30 minutes. You can set a different snapshot interval, if needed for your environment. You can also take snapshots on demand, without having to wait for the next interval. Taking a snapshot on demand does not affect the retention schedule for existing snapshots, it just adds an additional snapshot to the repository. This might be helpful if you are about to make a deployment change and you don’t have a current snapshot.

Beginning with Elastic Stack version 7.6, use Kibana to manage your snapshots. In Kibana, you can set up additional repositories where the snapshots are stored, other than the one currently managed by Elasticsearch Service. You can view and delete snapshots, and configure a snapshot lifecycle management (SLM) policy to automate when snapshots are created and deleted. To learn more, check the Snapshot and Restore documentation.

From within Elasticsearch Service, you can restore a snapshot from a different deployment in the same region.

For deployments with Elastic Stack versions 7.5 and earlier, anywhere between a minimum of 12 and up to a maximum of the 100 most recent, successful snapshots may be stored. These tasks are available from the Elasticsearch Service UI:

List available snapshotsedit

To list all available snapshots:

The list shows when the snapshot was completed, whether the snapshot succeeded or was only partially successful, along with the number of shards and indices in the snapshot.

Configure the snapshot retention periodedit

For Elastic Stack versions 7.6 and above, refer to the Snapshot and Restore documentation to learn about the snapshot management features.

For Elastic Stack versions 7.5 and below, from within Elasticsearch Service you can set the snapshot interval and count to have control over the retention period for your clusters. The calculation displayed is based on a projected estimate of the snapshot interval, expected snapshot count, and current cluster size. Changing any of these factors results in a different retention period.

Change the snapshot intervaledit

If you find the the default snapshot interval isn’t working for your environment, you can change it. It might make sense to use a 4 or 24 hour interval if the data in your index doesn’t change that often but you need more snapshot history.

When you change the interval, the interval timer begins after the next scheduled snapshot.

Change the snapshot countedit

You can get more control over your repository space by adjusting the number of snapshots that are stored for your cluster. The minimum number of snapshots must be at least 12, the maximum limit is 100.