Snapshot- und Restore-Strategien fuer produktive Elasticsearch-Cluster

1. Warum ein Snapshot allein noch keine Strategie ist

Ein Snapshot in Elasticsearch ist ein point-in-time Abbild eines oder mehrerer Indizes, das in ein externes Repository geschrieben wird. Technisch betrachtet ist ein einzelner Snapshot schnell erstellt, doch die eigentliche Herausforderung beginnt erst danach: Wie oft wird ein Snapshot ausgeloest, wie lange bleibt er aufbewahrt, wo liegt das Repository physisch, und funktioniert ein Restore tatsaechlich, wenn er gebraucht wird. Ein einzelner manuell erstellter Snapshot ist ein Zufallstreffer, keine Strategie.

In der Praxis sehen viele Teams Snapshots als Nebensache, weil der Cluster im Regelbetrieb replizierte Shards hat und dadurch bereits gegen einen einzelnen Node-Ausfall abgesichert wirkt. Replikation schuetzt aber nicht vor gelöschten Indizes, fehlerhaften Bulk-Updates, korrupten Segmenten oder einem kompletten Rechenzentrumsausfall. Genau fuer diese Faelle braucht es eine durchdachte Snapshot-Strategie mit externem Repository, regelmaessigem Zeitplan und einem dokumentierten Restore-Weg, der nicht erst im Ernstfall zum ersten Mal ausprobiert wird.

Dieser Artikel deckt die vollstaendige Kette ab: von der Einrichtung eines Repositories ueber die Automatisierung mit Snapshot Lifecycle Management bis zum tatsaechlichen Restore und dessen regelmaessiger Verifikation. Jeder Abschnitt zeigt konkrete API-Aufrufe, die sich direkt gegen einen produktiven oder Test-Cluster ausfuehren lassen.

2. Snapshot-Repositories: Filesystem und S3 im Vergleich

Bevor ein Snapshot ueberhaupt erstellt werden kann, muss ein Repository registriert werden, das als Ziel dient. Elasticsearch unterstuetzt mehrere Repository-Typen als Plugins, die gebraeuchlichsten sind das gemeinsame Filesystem (fs) und Amazon S3 (s3). Ein Filesystem-Repository erfordert, dass alle Nodes im Cluster denselben Pfad unter derselben Mount-Adresse sehen, typischerweise ueber NFS gemountet, und dass dieser Pfad explizit in elasticsearch.yml unter path.repo freigegeben wird. Ohne diesen Eintrag verweigert Elasticsearch aus Sicherheitsgruenden die Registrierung eines beliebigen Pfads als Repository-Ziel.

Ein S3-Repository ist fuer Cloud-Deployments meist die praktischere Wahl, weil kein gemeinsam gemounteter Speicher noetig ist und die Kapazitaet praktisch unbegrenzt skaliert. Das repository-s3-Plugin muss auf jedem Node installiert sein, die Zugangsdaten werden ueber den Elasticsearch Keystore verschluesselt hinterlegt statt im Klartext in der Konfigurationsdatei. Wichtig ist, dass der verwendete IAM-User oder die IAM-Rolle nur die minimal noetigen Rechte auf den Ziel-Bucket erhaelt, insbesondere s3:PutObject, s3:GetObject, s3:ListBucket und s3:DeleteObject fuer die Bereinigung alter Snapshots.

Unabhaengig vom Repository-Typ gilt: Ein Repository sollte niemals auf demselben physischen Storage liegen wie die Datenknoten selbst. Ein Repository auf demselben Server, der auch die Indexdaten haelt, schuetzt nicht gegen Hardware-Ausfaelle dieses Servers und untergraebt den ganzen Sinn eines externen Snapshot-Ziels. Die Trennung von Compute und Backup-Storage ist eine der ersten Entscheidungen jeder soliden Snapshot-Architektur.

PUT /_snapshot/s3_backup_repo
{
  "type": "s3",
  "settings": {
    "bucket": "mironsoft-es-snapshots",
    "region": "eu-central-1",
    "base_path": "cluster-prod/snapshots",
    "compress": true,
    "server_side_encryption": true,
    "chunk_size": "1gb"
  }
}

// Filesystem alternative, requires shared mount and path.repo entry
PUT /_snapshot/fs_backup_repo
{
  "type": "fs",
  "settings": {
    "location": "/mnt/es-backups/cluster-prod",
    "compress": true
  }
}

// Verify the repository is reachable from every node
POST /_snapshot/s3_backup_repo/_verify

3. Wie inkrementelle Snapshots Speicher und Zeit sparen

Ein haeufiges Missverstaendnis ist, dass jeder Snapshot eine vollstaendige Kopie aller Indexdaten anlegt. Tatsaechlich sind Snapshots in Elasticsearch inkrementell auf Segment-Ebene: Beim ersten Snapshot eines Index werden alle Lucene-Segmente in das Repository kopiert. Bei jedem weiteren Snapshot desselben Index vergleicht Elasticsearch die vorhandenen Segmente mit denen des vorherigen Snapshot und ueberfuehrt nur die neuen oder geaenderten Segmente in das Repository. Unveraenderte Segmente werden per Referenz aus dem vorherigen Snapshot wiederverwendet, nicht erneut kopiert.

Dieser Mechanismus funktioniert, weil Lucene-Segmente selbst unveraenderlich sind: Ein bestehendes Segment wird nie modifiziert, sondern bei Aenderungen entstehen neue Segmente, waehrend alte irgendwann durch Merges zusammengefasst und geloescht werden. Ein Snapshot muss also nur den Delta zwischen zwei Zeitpunkten uebertragen, was sowohl die benoetigte Netzwerkbandbreite als auch den Speicherplatz im Repository drastisch reduziert im Vergleich zu einer naiven vollstaendigen Kopie bei jedem Lauf.

Die praktische Konsequenz: Ein taeglicher Snapshot eines mehrere Terabyte grossen Index kostet nach dem ersten vollstaendigen Lauf oft nur wenige Prozent an zusaetzlichem Speicher und Laufzeit, solange die Aenderungsrate moderat bleibt. Bei sehr schreibintensiven Indizes mit hoher Merge-Aktivitaet faellt der Delta pro Snapshot entsprechend groesser aus, weil mehr Segmente neu geschrieben werden. Das ist ein wichtiger Faktor bei der Wahl der Snapshot-Frequenz fuer stark schreibende Workloads wie Log-Indizes.

4. Snapshot Lifecycle Management: Policies statt Cronjobs

Vor der Einfuehrung von Snapshot Lifecycle Management, kurz SLM, mussten Teams externe Cronjobs oder Orchestrierungs-Tools bauen, um Snapshots regelmaessig auszuloesen und alte Snapshots wieder zu loeschen. SLM verlagert diese Logik direkt in den Cluster: Eine SLM-Policy definiert einen Zeitplan im Cron-Format, ein Namensschema fuer die erzeugten Snapshots, das Ziel-Repository und eine Retention-Regel, die festlegt, wie viele Snapshots minimal und maximal aufbewahrt werden, bevor aeltere automatisch geloescht werden.

Der grosse Vorteil von SLM gegenueber externen Skripten ist, dass die Policy Teil der Cluster-Konfiguration ist und ueber die normale Elasticsearch-API inspiziert, angepasst und ueberwacht werden kann. Der Status jedes SLM-Laufs, inklusive Erfolgs- und Fehlerzeitpunkt, wird direkt am Repository gespeichert und ist ueber GET _slm/policy abrufbar. Das reduziert die Anzahl externer Abhaengigkeiten, die im Fehlerfall separat ueberwacht werden muessten, und macht Snapshot-Ausfaelle direkt im Cluster-Monitoring sichtbar.

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

// Trigger the policy manually for testing purposes
POST /_slm/policy/nightly-snapshots/_execute

// Inspect run history and last error, if any
GET /_slm/policy/nightly-snapshots?human

5. Snapshots erstellen und den Fortschritt ueberwachen

Neben der automatisierten SLM-Policy bleibt die manuelle Erstellung eines Snapshot per API sinnvoll, etwa vor einem grossen Migrations-Schritt oder direkt vor einem Rolling Upgrade. Ein manuell ausgeloester Snapshot folgt derselben API wie SLM intern verwendet, nur ohne automatischen Zeitplan. Standardmaessig laeuft ein Snapshot-Request asynchron im Hintergrund, der aufrufende Client erhaelt sofort eine Antwort, waehrend der Cluster im Hintergrund weiterschreibt.

Der Fortschritt eines laufenden Snapshot laesst sich ueber den Status-Endpunkt abfragen, der pro Shard anzeigt, ob er bereits abgeschlossen, noch in Bearbeitung oder fehlgeschlagen ist. Bei sehr grossen Clustern mit tausenden Shards empfiehlt es sich, den Status nicht per Polling in kurzen Intervallen abzufragen, weil die Statusermittlung selbst Cluster-Ressourcen bindet, sondern in groesseren Abstaenden von mehreren Minuten. Ein Snapshot kann jederzeit ueber die Delete-API abgebrochen werden, wenn er nicht mehr benoetigt wird oder faelschlich gestartet wurde.

# Trigger a manual snapshot before a risky operation
curl -s -X PUT "https://localhost:9200/_snapshot/s3_backup_repo/pre-migration-2026-07-24?wait_for_completion=false" \
  -H "Content-Type: application/json" \
  -u elastic:changeme \
  -d '{"indices": "products,orders", "include_global_state": false}'

# Poll snapshot status without blocking on wait_for_completion
curl -s "https://localhost:9200/_snapshot/s3_backup_repo/pre-migration-2026-07-24/_status" \
  -u elastic:changeme | jq '.snapshots[0].state'

# List all snapshots in a repository, sorted by start time
curl -s "https://localhost:9200/_snapshot/s3_backup_repo/_all?sort=start_time&order=desc" \
  -u elastic:changeme

6. Der Restore-Prozess: von der Auswahl bis zur Shard-Zuweisung

Ein Restore stellt einen oder mehrere Indizes aus einem Snapshot wieder her, entweder unter ihrem urspruenglichen Namen oder, was in der Praxis oft sinnvoller ist, unter einem umbenannten Namen parallel zum bestehenden Index. Der Parameter rename_pattern und rename_replacement im Restore-Request erlaubt, einen Index als products_restored statt products wiederherzustellen, sodass der Original-Index unangetastet bleibt und die wiederhergestellten Daten erst validiert werden koennen, bevor sie live geschaltet werden.

Waehrend des Restores werden die Shards des wiederhergestellten Index ueber den Cluster verteilt, genau wie bei der Neuerstellung eines Index. Bei grossen Indizes mit vielen Shards ist es sinnvoll, die Shard-Allokation waehrend eines besonders sensiblen Zeitfensters gezielt zu steuern, etwa ueber index.routing.allocation-Einstellungen, um die Netzwerklast auf bestimmte Nodes zu begrenzen. Ein Restore blockiert dabei nicht den gesamten Cluster, sondern laeuft, wie ein Snapshot selbst, als Hintergrundprozess, dessen Fortschritt ebenfalls ueber die Recovery-API beobachtet werden kann.

Ein oft uebersehenes Detail: Ein Restore aus einem Snapshot kann nur in einen Index geschrieben werden, der zum Zeitpunkt des Restores noch nicht existiert, es sei denn, der bestehende Index wird vorher explizit geschlossen. Wer versucht, direkt in einen offenen, bereits existierenden Index gleichen Namens zu restaurieren, erhaelt einen klaren Fehler. Dieses Verhalten ist beabsichtigt und verhindert, dass ein Restore versehentlich produktive Daten unbemerkt ueberschreibt.

POST /_snapshot/s3_backup_repo/pre-migration-2026-07-24/_restore
{
  "indices": "products",
  "rename_pattern": "(.+)",
  "rename_replacement": "$1_restored",
  "index_settings": {
    "index.number_of_replicas": 1
  },
  "ignore_index_settings": ["index.refresh_interval"]
}

// Watch recovery progress per shard until it reaches DONE
GET /_cat/recovery/products_restored?v&h=index,shard,stage,bytes_percent

7. Restore-Tests: warum ungetestete Snapshots kein Backup sind

Der zentrale Satz jeder Backup-Disziplin gilt fuer Elasticsearch genauso wie fuer jede andere Datenbank: Ein Snapshot, dessen Restore nie getestet wurde, ist kein verifiziertes Backup, sondern eine Vermutung. Ein defektes Repository, fehlende IAM-Rechte, ein abgelaufenes Zertifikat oder ein inkonsistenter Snapshot faellt in der Regel erst beim tatsaechlichen Restore-Versuch auf, und genau dann steht das Team unter dem groessten Zeitdruck.

Ein sinnvoller Rhythmus ist, mindestens einmal pro Quartal einen vollstaendigen Restore-Test in einer isolierten Testumgebung durchzufuehren: einen zufaellig gewaehlten produktiven Snapshot in einen frischen Test-Cluster restaurieren, Dokumentanzahl und Stichproben-Queries gegen die urspruenglichen Werte pruefen, und die benoetigte Restore-Zeit dokumentieren. Diese Zeit ist eine wichtige Kennzahl fuer den Recovery Time Objective, kurz RTO, denn ein Restore eines mehrere Terabyte grossen Index kann je nach Netzwerkbandbreite mehrere Stunden dauern.

Automatisierte Restore-Tests lassen sich gut in eine CI-Pipeline integrieren: Ein wöchentlicher Job restauriert den juengsten Snapshot in einen ephemeren Cluster, fuehrt eine Reihe definierter Validierungs-Queries aus und meldet das Ergebnis an ein Monitoring-System. Scheitert dieser Job, ist das ein ebenso kritischer Alarm wie ein fehlgeschlagener Snapshot selbst, weil beide Faelle dieselbe Konsequenz haben: Im Ernstfall gibt es kein funktionierendes Backup.

# Force-delete a snapshot stuck in state IN_PROGRESS after a node crash
curl -s -X DELETE "https://localhost:9200/_snapshot/s3_backup_repo/stuck-snapshot-2026-07-20" \
  -u elastic:changeme

# Verify no snapshot is currently blocking the repository afterwards
curl -s "https://localhost:9200/_snapshot/s3_backup_repo/_status" -u elastic:changeme

8. Snapshots versus Cross-Cluster-Replikation

Snapshots werden gelegentlich mit Cross-Cluster-Replikation, kurz CCR, verwechselt, obwohl beide unterschiedliche Probleme loesen. CCR repliziert Aenderungen nahezu in Echtzeit von einem Leader- in einen Follower-Cluster und dient primaer der Ausfallsicherheit ueber mehrere Rechenzentren oder Regionen hinweg sowie der Lesenaehe fuer geografisch verteilte Anwender. Ein CCR-Follower-Cluster schuetzt aber nicht vor logischen Fehlern: Wird ein Index versehentlich geloescht oder mit fehlerhaften Daten ueberschrieben, repliziert CCR diesen Fehler in nahezu Echtzeit in den Follower-Cluster mit.

Ein Snapshot hingegen ist ein Zeitpunkt-Abbild, das unabhaengig von laufenden Aenderungen im Repository verbleibt, bis es explizit geloescht wird. Genau das macht Snapshots zum richtigen Werkzeug gegen logische Fehler und versehentliches Loeschen, waehrend CCR das richtige Werkzeug fuer Hochverfuegbarkeit und geografische Verteilung ist. Eine belastbare Gesamtarchitektur kombiniert typischerweise beide Mechanismen: CCR fuer schnelle Failover-Faehigkeit, Snapshots als zusaetzliches, zeitversetztes Sicherheitsnetz gegen Fehler, die sonst ungebremst repliziert wuerden.

9. Troubleshooting: haengende und fehlgeschlagene Snapshots

Der haeufigste Fehlerfall ist ein Snapshot, der im Status IN_PROGRESS haengen bleibt, obwohl offensichtlich keine Fortschritte mehr gemacht werden. Ursache ist meist ein Node, der waehrend des Snapshot-Vorgangs abgestuerzt oder neu gestartet wurde, ohne dass der Cluster den Vorgang sauber beenden konnte. In diesem Fall hilft der Aufruf der Delete-API auf den haengenden Snapshot, was den internen Zustand bereinigt, auch wenn der Snapshot selbst nie erfolgreich abgeschlossen wurde.

Ein zweiter haeufiger Fehler ist SnapshotInProgressException, die auftritt, wenn versucht wird, einen zweiten Snapshot im selben Repository zu starten, waehrend bereits einer laeuft. Elasticsearch erlaubt standardmaessig nur einen laufenden Snapshot pro Repository gleichzeitig. Wer mehrere parallele Snapshots benoetigt, muss entweder mehrere Repositories anlegen oder die Snapshot-Ausfuehrung sauber sequenzieren, statt sie parallel aus mehreren Quellen auszuloesen.

Repository-Sperren durch read_only-Flags, abgelaufene Cloud-Credentials oder Netzwerk-Timeouts bei sehr langsamen Storage-Backends sind weitere klassische Ursachen. Die Logs des Master-Nodes enthalten in der Regel die konkrete Fehlermeldung des Repository-Plugins, waehrend die reine Snapshot-Status-API oft nur einen generischen Fehlerstatus zeigt. Ein systematischer Blick in die Master-Node-Logs ist deshalb immer der erste Schritt bei jedem fehlgeschlagenen Snapshot.

10. Zusammenfassung

Eine belastbare Snapshot-Strategie fuer Elasticsearch und OpenSearch besteht aus mehreren zusammenspielenden Bausteinen: ein sauber getrenntes Repository auf S3 oder gemeinsamem Filesystem, inkrementelle Snapshots, die dank unveraenderlicher Lucene-Segmente nur echte Deltas uebertragen, eine SLM-Policy, die Zeitplan und Retention ohne externe Cronjobs steuert, und ein dokumentierter Restore-Prozess mit Umbenennung, um produktive Daten nicht zu gefaehrden.

Der wichtigste Punkt bleibt der Restore-Test: Ein Snapshot, der nie restauriert wurde, ist eine unbewiesene Annahme. Wer regelmaessig, im Idealfall automatisiert, gegen einen Test-Cluster restauriert, kennt sowohl die tatsaechliche Restore-Dauer als auch die Integritaet der Daten, bevor ein echter Vorfall diese Fragen unter Zeitdruck beantwortet. In Kombination mit CCR fuer Hochverfuegbarkeit entsteht so ein zweistufiges Sicherheitsnetz, das sowohl Hardware-Ausfaelle als auch logische Fehler abdeckt.

11. FAQ: Snapshot- und Restore-Strategien