Elasticsearch Snapshot und Restore (fs-/S3-Repository, SLM)

Richtet für einen installierten Elasticsearch-8.x-/9.x-Cluster Snapshots (Backups) ein und beschreibt die Wiederherstellung: Repository auf einem gemeinsamen Dateisystem (NFS + path.repo) oder in S3 (Keystore), Aktivierung per Rolling Restart und Verifizierung, manueller Snapshot (indices, include_global_state, feature_states), zeitgesteuerte Snapshots und Aufbewahrung mit SLM (expire_after/min_count/max_count), Restore unter neuem Namen oder über einen geschlossenen Index, Restore von Feature States, Überwachung und Migration in einen anderen Cluster, indem dasselbe Repository schreibgeschützt registriert wird. Am Ende stehen täglich automatisch erstellte Snapshots, deren Wiederherstellbarkeit geprüft ist. Snapshots sind in Elasticsearch die einzige gültige Backup-Methode; für Mapping-/Shard-Änderungen im selben Cluster nutzt du Reindex, um einen einzelnen Index schnell zurückzuholen, die Szenarien im Betriebsleitfaden.

Topologie: Elasticsearch-8.x-/9.x-Cluster (1–N Nodes) + gemeinsames Verzeichnis (NFS) oder S3-kompatibler Object Storage

Vor dem Start

• Der Cluster ist gesund (green) und du hast das Passwort von elastic (oder eines Benutzers mit den Rechten manage + snapshot). Da die Repository-Einstellungen einen Neustart der Nodes erfordern, stelle sicher, dass der Cluster den Ausfall eines Nodes verkraftet (Replicas sind zugewiesen).
• Auf jedem Node liegt die HTTP-CA-Datei (…); die API-Aufrufe werden gegen diese CA geprüft.
• … ist auf allen Master- und Data-Nodes von derselben Freigabe (NFS) eingehängt und in der fstab dauerhaft eingetragen. UID/GID des Benutzers elasticsearch müssen auf allen Nodes gleich sein, oder die Freigabe muss mit all_squash,anonuid=…,anongid=… auf einen einzigen Benutzer abgebildet werden; sonst können die Nodes die Dateien der jeweils anderen nicht lesen. Ein lokales (nicht gemeinsames) Verzeichnis führt in einem Cluster mit mehreren Nodes zu einem Fehler bei der Repository-Verifizierung.
• Der Bucket … ist angelegt; der Zugriffsschlüssel (Access Key / Secret Key) hat auf diesem Bucket die Rechte s3:ListBucket, s3:GetObject, s3:PutObject, s3:DeleteObject, s3:AbortMultipartUpload, s3:ListMultipartUploadParts und s3:ListBucketMultipartUploads. Die Nodes erreichen … per HTTPS.
• Auf der Freigabe ist genug Platz frei: Der erste Snapshot belegt so viel wie die Indizes auf der Platte, spätere fügen nur die geänderten Segmente hinzu (inkrementell).
• Die Versionsregeln sind bekannt: Ein Snapshot lässt sich in einen Cluster mit derselben oder einer neueren Version wiederherstellen, nicht in eine ältere. Ein Index lässt sich höchstens in die nächste Hauptversion nach der, in der er erstellt wurde, wiederherstellen (ein in 8.x erstellter Index geht nach 9.x; ein in 7.x erstellter Index kommt nicht als normaler Index nach 9.x).
• Du hast root-Rechte auf allen Nodes und ein Wartungsfenster für den Rolling Restart.

Phasen der Anleitung

• API-Zugriff (alle Nodes) — Temporäre Zugangsdatei für die API · Cluster und vorhandene Repositorys prüfen
• Gemeinsames Dateisystem vorbereiten (alle Nodes) — NFS-Freigabe einhängen · Verzeichnisrechte setzen und Schreibtest ausführen · Einstellung path.repo hinzufügen
• S3-Zugangsdaten und Client-Einstellungen (alle Nodes) — S3-Zugriffsschlüssel in den Keystore eintragen · S3-Client-Einstellungen hinzufügen
• Repository registrieren und verifizieren — Repository registrieren · Repository verifizieren
• Manueller Snapshot — Testindex anlegen · Snapshot erstellen · Snapshot-Status überwachen
• Automatische Snapshots mit SLM — SLM-Richtlinie anlegen · Richtlinie sofort ausführen · SLM-Status und -Statistiken prüfen · Retention manuell ausführen
• Restore — Index unter neuem Namen wiederherstellen · Restore überwachen und Dokumentanzahl vergleichen · Wiederhergestellte Kopie löschen · Index schließen und in place wiederherstellen · Feature State wiederherstellen
• Migration in einen anderen Cluster — Vorbereitung des Ziel-Clusters · Repository schreibgeschützt registrieren · Indizes im Ziel-Cluster wiederherstellen · Zugangsdatei im Ziel löschen
• Monitoring und Wartung — Snapshot-Zustand überwachen · Repository bereinigen · Zugangsdateien löschen · Regelmäßige Wiederherstellungsübung