Snapshot Lifecycle Management: automatisierte Backups einrichten

1. Warum manuelle Snapshots als Backup-Strategie nicht ausreichen

Ein manuell ausgeführter Snapshot ist im Grunde ein einmaliger Akt guten Willens, kein verlässlicher Prozess. Sobald die Verantwortung für regelmäßige Sicherungen an eine Person oder ein Cron-Skript ohne zentrale Überwachung delegiert wird, entstehen typische Lücken: ein vergessener Snapshot vor einem größeren Deployment, ein fehlgeschlagener Snapshot, dessen Fehlermeldung niemand gesehen hat, oder ein Repository, das über Monate keine Bereinigung erfährt und irgendwann den verfügbaren Speicherplatz sprengt.

Snapshot Lifecycle Management verlagert diese Verantwortung vom einzelnen Menschen in eine deklarative, vom Cluster selbst ausgeführte Richtlinie. Damit wird aus einer fehleranfälligen, manuellen Routine ein reproduzierbarer, überwachbarer Prozess, der nach einem festen Zeitplan läuft, unabhängig davon, ob gerade jemand daran denkt oder nicht, und der zusätzlich alte Snapshots nach klar definierten Regeln automatisch entfernt.

2. Snapshot-Repository einrichten: Objekt-Speicher versus gemeinsames Dateisystem

Bevor eine SLM-Richtlinie überhaupt greifen kann, braucht der Cluster ein registriertes Repository als Ziel für die Snapshots. In der Praxis dominieren zwei Varianten: ein S3-kompatibles Objekt-Speicher-Repository für Cloud-Umgebungen und ein gemeinsames Dateisystem-Repository, das von allen Cluster-Knoten unter demselben Pfad eingehängt sein muss, für On-Premises-Setups. Beide Varianten erfordern das jeweils passende Repository-Plugin sowie korrekt gesetzte Zugriffsrechte, ohne die jeder Snapshot-Versuch mit einer Berechtigungsfehlermeldung scheitert.

Ein S3-Repository bringt zusätzlich Vorteile bei Skalierung und Ausfallsicherheit mit, da Objekt-Speicher unabhängig von der Cluster-Infrastruktur existiert und meist bereits über eine eigene Redundanz verfügt. Ein Dateisystem-Repository ist dagegen einfacher einzurichten, verlangt aber eine sorgfältige, eigene Absicherung gegen Datenverlust, etwa durch RAID oder eine zusätzliche externe Spiegelung, da ein Ausfall des zugrunde liegenden Speichers sonst sowohl den Cluster als auch dessen Sicherungen gleichzeitig betreffen kann.

PUT _snapshot/s3-backup-repo
{
  "type": "s3",
  "settings": {
    "bucket": "meinshop-es-snapshots",
    "region": "eu-central-1",
    "base_path": "produktion/backups",
    "server_side_encryption": true
  }
}

3. SLM-Policy-Grundstruktur: Zeitplan, Name-Muster und Konfiguration

Eine SLM-Richtlinie definiert vier zentrale Bausteine: einen Cron-basierten Zeitplan, ein Namensmuster für die erzeugten Snapshots, das Ziel-Repository und optional eine Konfiguration, welche Indizes eingeschlossen werden sollen. Das Namensmuster kann Datumsvariablen enthalten, sodass jeder Snapshot automatisch einen eindeutigen, chronologisch sortierbaren Namen erhält, etwa daily-snap-2026.08.08, ohne dass dafür zusätzliche Logik außerhalb der Richtlinie nötig wäre.

Die Indexauswahl lässt sich über Muster oder explizite Listen steuern, wobei es sich in der Praxis meist lohnt, systemkritische Indizes wie den Kibana-Konfigurationsindex bewusst mit einzuschließen, da ein Wiederherstellungsszenario ohne diese Indizes zwar die Daten, aber nicht die zugehörigen Visualisierungen und Dashboards zurückbringen würde. Eine bewusste, dokumentierte Auswahl ist hier wichtiger als eine pauschale Regel für alle Indizes.

PUT _slm/policy/daily-snapshots
{
  "schedule": "0 30 1 * * ?",
  "name": "<daily-snap-{now/d}>",
  "repository": "s3-backup-repo",
  "config": {
    "indices": ["*", "-.monitoring*"],
    "include_global_state": true
  },
  "retention": {
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 50
  }
}

4. Retention-Regeln im Detail: expire_after, min_count und max_count

Die Retention-Konfiguration einer SLM-Richtlinie steuert, wie viele alte Snapshots aufbewahrt werden, bevor sie automatisch gelöscht werden. Das Feld expire_after legt eine reine Zeitgrenze fest, nach deren Ablauf ein Snapshot grundsätzlich zum Löschen vorgesehen ist. Die Felder min_count und max_count greifen ergänzend ein: min_count verhindert, dass zu wenige Snapshots übrig bleiben, selbst wenn die Zeitgrenze längst überschritten ist, während max_count eine harte Obergrenze setzt, unabhängig vom Alter.

Diese drei Regeln zusammen verhindern zwei entgegengesetzte Probleme: einerseits ein unkontrolliertes Anwachsen des Repositories durch nie gelöschte Snapshots, andererseits ein versehentliches Löschen aller Sicherungen, falls die Snapshot-Erstellung für längere Zeit ausfällt und dadurch kein neuer Snapshot nachrückt. Ein typisches Muster für produktive Cluster hält Snapshots dreißig Tage vor, garantiert aber mindestens fünf, selbst wenn diese älter als dreißig Tage sind.

5. Snapshot-Ausführung überwachen mit der SLM Stats API

Da SLM-Richtlinien im Hintergrund laufen, ist eine regelmäßige Prüfung des Ausführungsstatus unverzichtbar. Die SLM Stats API sowie die Get-Policy-API liefern Informationen über den letzten erfolgreichen Lauf, den letzten fehlgeschlagenen Lauf inklusive Fehlermeldung sowie kumulierte Zähler für erfolgreiche und fehlgeschlagene Ausführungen seit dem letzten Neustart des Clusters. Diese Werte sollten fester Bestandteil eines Monitoring-Dashboards sein, nicht etwas, das nur bei Verdacht manuell nachgeschaut wird.

Ein besonders tückisches Fehlerbild ist ein Snapshot, der zwar startet, aber wegen eines konkurrierenden, bereits laufenden Snapshots übersprungen wird. Da SLM standardmäßig immer nur einen Snapshot gleichzeitig pro Repository zulässt, kann ein ungewöhnlich lange laufender Snapshot dazu führen, dass mehrere geplante Läufe in Folge ausfallen, ohne dass dies ohne aktives Monitoring auffällt, bis am Ende schlicht kein aktueller Snapshot mehr existiert.

6. Der Restore-Test als Pflichtübung statt Backup-Illusion

Ein Snapshot, der erfolgreich erstellt wurde, beweist nur, dass der Schreibvorgang funktioniert hat, nicht, dass eine Wiederherstellung tatsächlich gelingt. Beschädigte Repository-Metadaten, fehlende Berechtigungen für den Lesezugriff oder ein inkompatibles Cluster-Ziel fallen bei der Erstellung oft gar nicht auf, sondern erst im Ernstfall, wenn es bereits zu spät ist. Ein regelmäßiger, dokumentierter Restore-Test in eine separate Testumgebung ist deshalb kein optionaler Bonus, sondern der einzige Beweis dafür, dass eine Backup-Strategie tatsächlich funktioniert.

In der Praxis bewährt sich ein monatlicher Restore-Test, bei dem ein zufällig gewählter, aktueller Snapshot in einen isolierten Testcluster eingespielt und stichprobenartig auf Vollständigkeit und Konsistenz der Daten geprüft wird. Wer diesen Test überspringt, verlässt sich auf eine reine Vermutung, dass die Backups im Ernstfall funktionieren würden, und genau diese Vermutung erweist sich in der Praxis regelmäßig als der teuerste Fehler im gesamten Sicherungskonzept.

# Snapshot in einen separaten Test-Cluster einspielen
curl -X POST "test-cluster:9200/_snapshot/s3-backup-repo/daily-snap-2026.08.08/_restore" \
  -H 'Content-Type: application/json' -d '{
    "indices": "produktkatalog-*",
    "rename_pattern": "(.+)",
    "rename_replacement": "restored_$1",
    "include_global_state": false
  }'

7. Cross-Cluster-Replikation als Ergänzung, nicht als Ersatz für Snapshots

Manche Teams verwechseln Cross-Cluster-Replikation mit einer Backup-Lösung, weil beide Mechanismen Daten redundant vorhalten. Der entscheidende Unterschied liegt in der Fehlerausbreitung: Eine versehentliche Löschung oder eine korrupte Indexierung wird über die Replikation nahezu in Echtzeit auf den Zielcluster übertragen, sodass beide Cluster denselben fehlerhaften Zustand zeigen. Ein Snapshot dagegen ist ein Zeitpunkt-Abbild, das von genau diesem Problem unberührt bleibt, solange der Fehler nach der Snapshot-Erstellung passiert ist.

Für ein vollständiges Sicherungskonzept ergänzen sich beide Mechanismen: Cross-Cluster-Replikation reduziert die Wiederherstellungszeit bei einem kompletten Rechenzentrumsausfall, während SLM-gesteuerte Snapshots vor logischen Fehlern wie versehentlichen Löschungen, fehlerhaften Bulk-Updates oder Ransomware-Szenarien schützen. Wer nur auf Replikation setzt, verzichtet bewusst oder unbewusst auf genau diesen zweiten Schutzmechanismus.

8. Fehlerbehandlung bei fehlgeschlagenen Snapshots

Ein fehlgeschlagener Snapshot ist meist ein Symptom eines tieferliegenden Problems: volles Repository, fehlende Netzwerkverbindung zum Objekt-Speicher, abgelaufene Zugriffsschlüssel oder Shards, die sich gerade in Relokation befinden und deshalb nicht konsistent gesichert werden können. Die Snapshot-Status-API liefert für jeden fehlgeschlagenen Versuch eine detaillierte Fehlermeldung pro betroffenem Shard, was die Ursachensuche deutlich beschleunigt, sofern diese Meldungen tatsächlich ausgewertet werden.

Ein bewährtes Muster ist eine Alarmierung, die bei zwei aufeinanderfolgenden fehlgeschlagenen SLM-Läufen automatisch eskaliert, statt erst bei einem völligen Ausbleiben von Snapshots über mehrere Wochen zu reagieren. Da SLM standardmäßig weiterläuft und den nächsten Lauf einfach zum vorgesehenen Zeitpunkt erneut versucht, bleibt ein wiederholt scheiternder Snapshot ohne aktive Alarmierung leicht über längere Zeit unbemerkt.

9. Repository-Integrität prüfen und verwaiste Daten aufräumen

Ein Snapshot-Repository sollte regelmäßig auf strukturelle Konsistenz geprüft werden, statt sich blind auf erfolgreiche Snapshot-Meldungen zu verlassen. Die Verify-Repository-API lässt jeden Cluster-Knoten prüfen, ob er tatsächlich lesend und schreibend auf das Repository zugreifen kann, und deckt damit frühzeitig Konfigurationsfehler auf, etwa einen Knoten mit fehlenden Zugriffsrechten, der sonst erst bei einem konkreten Snapshot- oder Restore-Versuch auffallen würde.

Zusätzlich können durch abgebrochene Snapshot-Löschungen oder unterbrochene Uploads verwaiste Datenfragmente im Repository zurückbleiben, die weder von einem aktuellen noch von einem historischen Snapshot referenziert werden, aber weiterhin Speicherplatz und damit Kosten verursachen. Die Cleanup-API räumt genau diese verwaisten Fragmente auf, ohne dabei referenzierte, gültige Snapshots zu gefährden, und sollte deshalb in regelmäßigen Abständen als eigener, von der eigentlichen SLM-Richtlinie unabhängiger Wartungsschritt eingeplant werden.

curl -X POST "localhost:9200/_snapshot/s3-backup-repo/_verify"
curl -X POST "localhost:9200/_snapshot/s3-backup-repo/_cleanup"

10. Zusammenfassung

11. FAQ: SLM in Elasticsearch: Das Wichtigste auf einen Blick