Snapshot et restore Elasticsearch (repository fs / S3, SLM)

Met en place les snapshots (sauvegardes) d'un cluster Elasticsearch 8.x / 9.x installé et décrit la restauration : repository sur système de fichiers partagé (NFS + path.repo) ou S3 (keystore), activation par rolling restart et vérification, snapshot manuel (indices, include_global_state, feature_states), snapshots planifiés et rétention avec SLM (expire_after/min_count/max_count), restore sous un nouveau nom ou sur un index fermé, restore de feature state, supervision, et migration vers un autre cluster en enregistrant le même repository en lecture seule. Vous obtenez des snapshots pris automatiquement chaque jour, dont la restauration a été testée. Le snapshot est la seule méthode de sauvegarde valable dans Elasticsearch ; pour changer de mapping/de shards dans un même cluster, utilisez reindex, et pour récupérer rapidement un index isolé, les scénarios du guide d'exploitation.

Topologie: Cluster Elasticsearch 8.x / 9.x (1 à N nœuds) + répertoire partagé (NFS) ou stockage objet compatible S3

Avant de commencer

• Le cluster est sain (green) et vous disposez du mot de passe d'elastic (ou d'un utilisateur ayant les privilèges manage + snapshot). Comme le paramétrage du repository impose de redémarrer les nœuds, vérifiez que le cluster supporte la perte d'un nœud (replicas assignés).
• Le fichier CA HTTP (…) existe sur chaque nœud ; les appels d'API sont vérifiés avec ce CA.
• … est monté depuis le même partage (NFS) sur tous les nœuds master et data et est persistant dans fstab. L'UID/GID de l'utilisateur elasticsearch doit être identique sur tous les nœuds, ou le partage doit tout mapper sur un seul utilisateur avec all_squash,anonuid=…,anongid=… ; sinon les nœuds ne peuvent pas lire les fichiers écrits par les autres. Un répertoire local (non partagé) fait échouer la vérification du repository sur un cluster multi-nœuds.
• Le bucket … a été créé ; la clé d'accès (access key / secret key) dispose sur ce bucket des droits s3:ListBucket, s3:GetObject, s3:PutObject, s3:DeleteObject, s3:AbortMultipartUpload, s3:ListMultipartUploadParts et s3:ListBucketMultipartUploads. Les nœuds peuvent joindre … en HTTPS.
• Le partage dispose d'un espace libre suffisant : le premier snapshot occupe autant que la taille des index sur disque, les suivants n'ajoutent que les segments modifiés (incrémental).
• Vous connaissez les règles de version : un snapshot se restaure sur un cluster de même version ou plus récent ; jamais sur une version plus ancienne. Un index peut être restauré au plus dans la version majeure qui suit celle où il a été créé (un index créé en 8.x passe en 9.x ; un index créé en 7.x ne peut pas être restauré en 9.x comme index ordinaire).
• Vous disposez de l'accès root sur tous les nœuds et d'une fenêtre de maintenance pour le rolling restart.

Phases du guide

• Accès à l'API (tous les nœuds) — Fichier d'identifiants temporaire pour l'API · Vérifier le cluster et les repositories existants
• Préparation du système de fichiers partagé (tous les nœuds) — Monter le partage NFS · Régler les droits du répertoire et tester une écriture · Ajouter le paramètre path.repo
• Identifiants S3 et paramètres du client (tous les nœuds) — Ajouter les clés d'accès S3 au keystore · Ajouter les paramètres du client S3
• Enregistrer et vérifier le repository — Enregistrer le repository · Vérifier le repository
• Snapshot manuel — Créer l'index de test · Prendre un snapshot · Suivre l'état du snapshot
• Snapshots automatiques avec SLM — Créer la politique SLM · Exécuter la politique immédiatement · Vérifier l'état et les statistiques de SLM · Exécuter la rétention manuellement
• Restore — Restaurer l'index sous un nouveau nom · Suivre le restore et comparer le nombre de documents · Supprimer la copie restaurée · Fermer l'index et le restaurer en place · Restaurer le feature state
• Migration vers un autre cluster — Préparer le cluster cible · Enregistrer le repository en lecture seule · Restaurer les index sur le cluster cible · Supprimer le fichier d'identifiants sur la cible
• Supervision et maintenance — Superviser la santé des snapshots · Nettoyage du repository · Supprimer les fichiers d'identifiants · Exercices de restauration réguliers