A snapshot repository is the durable, off-cluster storage location Elasticsearch uses for backup snapshots and later restores. It can be a shared filesystem, HDFS, or cloud storage such as Amazon S3, Microsoft Azure, or Google Cloud Platform. Register the repository before creating snapshots; after the first backup, later snapshots are incremental rather than full copies. section 14.4 section 14.4.1
For a filesystem repository, mount the same shared path on all master and data nodes. Add that path to `path.repo` in `elasticsearch.yml`, restart the affected nodes, then register a repository name, type, and location through the `_snapshot` API. A local temporary directory can serve as the location for local development. section 14.4.2
Listing 14.4 Registering a filesystem-based snapshot repository
PUT _snapshot/es_cluster_snapshot_repository #1
{
"type": "fs", #2
"settings": {
"location": "/volumes/es_snapshots" #3
}
}
This request registers `es_cluster_snapshot_repository`: `fs` selects a filesystem-backed repository, and `settings.location` identifies the mounted storage path. section 14.4.2
Back up selected production indexes
After registration, create a named snapshot beneath the repository. A request can back up everything by default, or target index patterns such as `*movies*` and `*reviews*`. Exclude obsolete indexes with patterns such as `-*.old`, and attach metadata—such as a reason or incident ID—to make an operational backup easier to identify. section 14.4.3
A restore operation reads a named snapshot from the repository and copies its data into the cluster. Restore all eligible contents or provide an index or data-stream selection when only part of a snapshot is needed. section 14.4.4
For regular protection, connect the repository to Snapshot Lifecycle Management (SLM):
- Create an `_slm` policy with a unique snapshot name, a cron schedule, and the registered repository. section 14.4.6
- Set the indexes to include, choose whether to include global state, and define retention such as seven days. section 14.4.6
- Use automated snapshots for recurring backups; reserve ad hoc snapshots for events such as migrations or production hotfix releases. section 14.4.6
Treat repository-backed snapshots as a routine production safeguard: store them off-cluster, automate them where possible, and retain enough snapshots for the recovery window you need. Kibana also provides snapshot, restore, and policy controls through Stack Management. section 14.4 section 14.7
