Snapshot Lifecycle Management : sauvegardes automatisées, restauration et reprise après sinistre

1. Dépôt et politique #

Automatiser.

Configuration #

PUT _snapshot/backups
{ "type": "s3", "settings": { "bucket": "es-backups-prod", "base_path": "cluster-eu" } }

PUT _slm/policy/nightly
{
  "schedule": "0 30 1 * * ?",
  "name": "<nightly-{now/d}>",
  "repository": "backups",
  "config": { "indices": [ "*" ], "include_global_state": true },
  "retention": { "expire_after": "30d", "min_count": 5, "max_count": 50 }
}

POST _slm/policy/nightly/_execute          # tester tout de suite
GET _slm/stats

À savoir : Les snapshots sont incrémentaux au niveau des segments : seule la donnée nouvelle est copiée. Le dépôt fs exige un système de fichiers partagé déclaré dans path.repo sur tous les nœuds.

2. Restaurer #

Le seul test qui compte.

Restauration #

GET _snapshot/backups/_all?verbose=false

POST _snapshot/backups/nightly-2026.10.20/_restore
{ "indices": "logs-nginx-*", "rename_pattern": "(.+)", "rename_replacement": "restored-$1",
  "include_global_state": false }

Erreur Courante : Une sauvegarde jamais restaurée n'est pas une sauvegarde. Planifiez un test de restauration régulier sur un cluster séparé, et mesurez le temps qu'il prend : c'est votre RTO réel.

Bonne Pratique : Gardez les snapshots dans une autre région ou un autre compte cloud que le cluster, avec une protection contre la suppression (verrouillage d'objets du stockage).