Bewährte Verfahren für tägliche Elasticsearch-Sicherungs- und Wiederherstellungsvorgänge

Tägliche Sicherungen schützen Ihren Elasticsearch-Cluster vor Fehlern, die Replikate nicht beheben können: versehentliche Löschungen, fehlerhafte Mappings, beschädigte Daten, fehlgeschlagene Upgrades und vollständiger Clusterverlust. Replikate helfen bei der Verfügbarkeit, aber Snapshots ermöglichen es Ihnen, zu einer bekannten, guten Kopie zurückzukehren.

Diese bewährten Verfahren für tägliche Elasticsearch-Sicherungs- und Wiederherstellungsvorgänge decken die Einrichtung des Repositoriums, Snapshot Lifecycle Management (SLM), Wiederherstellungstests und die Stellen ab, an denen Index Lifecycle Management (ILM) passt.

Verständnis des Elasticsearch-Snapshot-Mechanismus

Elasticsearch-Snapshots sind nicht einfach Dateikopien; sie sind inkrementell und nutzen die interne Struktur von Lucene-Indizes. Das bedeutet, dass nach dem ersten vollständigen Snapshot nachfolgende Snapshots nur Datensegmente speichern, die sich seit dem letzten erfolgreichen Snapshot geändert haben, was sie hinsichtlich Zeit und Speicher sehr effizient macht.

Snapshots erfassen zwei Hauptkomponenten:

Indexdaten: Die tatsächlichen Lucene-Segmente für ausgewählte Indizes.
Clusterzustand: Metadaten, dauerhafte Einstellungen, Indexvorlagen, Pipelines und Rollen.

1. Einrichtung des Snapshot-Repositoriums

Bevor Sie einen Snapshot erstellen, müssen Sie ein Repositorium registrieren: den sicheren Ort, an dem Snapshot-Dateien gespeichert werden. Die Wahl des Repositoriums ist entscheidend für Haltbarkeit und Wiederherstellungsgeschwindigkeit.

Repositoriumstypen

Repositoriumstyp	Beschreibung	Am besten geeignet für	Anforderungen
`fs` (Gemeinsames Dateisystem)	Lokales oder netzwerkgebundenes Laufwerk, das von allen Master- und Datenknoten zugänglich ist.	Kleine Cluster, schnelle lokale Sicherungen.	Muss in `elasticsearch.yml` (`path.repo`) registriert sein.
`s3`, `azure`, `gcs`	Cloud-Speicherdienste. Einige Distributionen und Versionen bündeln diese Repositoriumstypen; andere erfordern die Installation des entsprechenden Repositorium-Plugins auf jedem Knoten.	Produktionsumgebungen, Notfallwiederherstellung.	Versionsgerechte Repositorium-Unterstützung und ordnungsgemäße IAM/Service-Principal-Anmeldeinformationen.

Beispiel: Registrieren eines S3-Repositoriums

Für Produktionsumgebungen ist Cloud-Speicher in der Regel die bessere Wahl für Haltbarkeit und externe Wiederherstellung. Bestätigen Sie die Repositorium-Unterstützung für Ihre Elasticsearch-Version, konfigurieren Sie Anmeldeinformationen sicher und registrieren Sie dann das Repositorium über die API.

PUT /_snapshot/my_s3_daily_repo
{
  "type": "s3",
  "settings": {
    "bucket": "es-backup-bucket-name",
    "region": "us-east-1",
    "base_path": "daily_snapshots/production",
    "compress": true
  }
}

Tipp: Stellen Sie sicher, dass der konfigurierte Bucket oder Dateisystempfad sicher, unveränderlich (falls von Ihrem Anbieter unterstützt) und ausschließlich für Sicherungen verwendet wird.

2. Implementierung der täglichen Automatisierung mit SLM

Manuelle Snapshots sind für einmalige Vorgänge akzeptabel, aber routinemäßige tägliche Sicherungen müssen mit Snapshot Lifecycle Management (SLM) automatisiert werden. SLM ist der native Mechanismus in Elasticsearch, der speziell für die Definition von Zeitplänen, Aufbewahrungsrichtlinien und die Verwaltung von Snapshots entwickelt wurde.

Definieren einer SLM-Richtlinie

Eine typische tägliche Richtlinie definiert einen Zeitplan, die einzuschließenden (oder auszuschließenden) Indizes und wie lange die Snapshots aufbewahrt werden sollen.

PUT /_slm/policy/daily_archive_policy
{
  "schedule": "0 30 1 * * ?", 
  "name": "<daily-{{now/d}}>",
  "repository": "my_s3_daily_repo",
  "config": {
    "indices": ["logstash-*", "application-metrics-*"],
    "ignore_unavailable": true,
    "include_global_state": false 
  },
  "retention": {
    "expire_after": "30d", 
    "min_count": 5, 
    "max_count": 30 
  }
}

Wichtige SLM-Konfigurationspunkte:

schedule: Verwendet die Quartz-Cron-Syntax (z. B. 0 30 1 * * ? läuft täglich um 01:30 Uhr). Planen Sie während Zeiten geringer Nutzung.
include_global_state: false: Für tägliche Datensicherungen ist es oft am besten, den Clusterzustand auszuschließen, um einen versehentlichen Zustands-Rollback während der Wiederherstellung zu verhindern.
retention: Definiert den Bereinigungszeitplan. Das obige Beispiel behält Snapshots für 30 Tage bei und stellt sicher, dass mindestens 5 und höchstens 30 aufbewahrt werden.

Überwachung von SLM

Überprüfen Sie regelmäßig den Status Ihrer Richtlinien, um sicherzustellen, dass sie erfolgreich ausgeführt werden.

GET /_slm/status
GET /_slm/policy/daily_archive_policy

3. Integration mit Index Lifecycle Management (ILM)

Für große Zeitreihendaten, wie Protokolle und Metriken, verwaltet Index Lifecycle Management (ILM) Indizes von der Erstellung bis zur Löschung. ILM ersetzt nicht die täglichen SLM-Snapshots, kann aber helfen, die Löschung mit einer abgeschlossenen Snapshot-Richtlinie zu koordinieren.

ILM und Data Tiering

Bevor ILM alte Indizes löscht, können Sie die Löschphase warten lassen, bis eine SLM-Richtlinie ausgeführt wurde. Das gibt Ihrer täglichen oder langfristigen Snapshot-Richtlinie die Möglichkeit, die Daten zu erfassen, bevor der Index aus dem Cluster entfernt wird.

Erstellen Sie eine SLM-Richtlinie, die das relevante Indexmuster snapshotiert.
Referenzieren Sie diese SLM-Richtlinie in der ILM-Löschphase mit wait_for_snapshot.

...
"delete": {
  "min_age": "90d",
  "actions": {
    "wait_for_snapshot": {
      "policy": "daily_archive_policy"
    },
    "delete": {}
  }
}
...

Dies wartet auf einen erfolgreichen Snapshot von der genannten SLM-Richtlinie, bevor ILM den Index löscht. Wenn Sie Datenströme verwenden, testen Sie den Lebenszyklusablauf in der Staging-Umgebung, damit Sie wissen, welche zugrunde liegenden Indizes von der Snapshot-Richtlinie abgedeckt werden.

Wenn Ihr Ziel darin besteht, ältere durchsuchbare Daten auf günstigerem Speicher zu behalten, anstatt sie zu löschen, sehen Sie sich die Aktion "searchable snapshot" in der kalten oder gefrorenen Phase an. Dies ist ein anderes Muster als ein einfacher Notfallwiederherstellungs-Snapshot:

...
"cold": {
  "min_age": "30d",
  "actions": {
    "searchable_snapshot": {
      "snapshot_repository": "my_s3_daily_repo"
    }
  }
}
...

Verwenden Sie ein Lebenszyklusmuster pro Ziel: SLM für wiederherstellbare Sicherungen, wait_for_snapshot vor dem Löschen und durchsuchbare Snapshots, wenn Sie kostengünstigeren Suchzugriff benötigen.

4. Bewährte Verfahren für Wiederherstellungstests

Eine Sicherungsroutine ist ohne eine bewährte Wiederherstellungsstrategie unvollständig. Sie müssen Ihren Wiederherstellungsprozess regelmäßig testen, um die Datenintegrität zu validieren und die Ziele der Wiederherstellungszeit (RTO) zu erreichen.

Umgebung für Wiederherstellungstests

Testen Sie Wiederherstellungen nicht direkt auf einem Live-Produktionscluster. Verwenden Sie eine dedizierte Staging- oder Testumgebung, die eine kompatible Elasticsearch-Version ausführt und genügend Speicherplatz für wiederhergestellte Shards hat.
Häufigkeit: Testen Sie die Wiederherstellung mindestens vierteljährlich oder nach größeren Upgrades/Konfigurationsänderungen.

Durchführung einer Wiederherstellung

Die Wiederherstellung kann auf bestimmte Indizes oder den gesamten Clusterzustand abzielen.

Schritt 1: Snapshot-Details abrufen

Identifizieren Sie den Snapshot-Namen, den Sie wiederherstellen müssen.

GET /_snapshot/my_s3_daily_repo/_all

Schritt 2: Wiederherstellungsvorgang ausführen

Um bestimmte Indizes wiederherzustellen, verwenden Sie den Parameter indices. Es ist oft notwendig, Indizes während der Wiederherstellung umzubenennen, um Konflikte mit aktiven Indizes zu vermeiden (insbesondere in einer Testumgebung).

POST /_snapshot/my_s3_daily_repo/snapshot_20240501/_restore
{
  "indices": ["logstash-2024-05-01"],
  "rename_pattern": "(.+)",
  "rename_replacement": "restored-$1",
  "include_aliases": false
}

Überprüfung des Wiederherstellungserfolgs

Überprüfen Sie nach der Wiederherstellung die Shard-Gesundheit und die Dokumentanzahlen. Ein Abgleich der Anzahl ist nützlich, aber führen Sie auch eine Beispielabfrage aus, von der Ihre Anwendung abhängt.

GET /_cluster/health/restored-logstash-2024-05-01?wait_for_status=green&timeout=60s
GET /restored-logstash-2024-05-01/_count

5. Sicherheits- und Leistungsaspekte

Sicherheit

Repositoriumszugriff: Stellen Sie sicher, dass die von Elasticsearch verwendeten Anmeldeinformationen für den Zugriff auf das Repositorium dem Prinzip der geringsten Privilegien für den Repositoriumspfad folgen. In der Praxis benötigt die Snapshot-Verwaltung Lese-, Schreib-, Auflistungs- und Löschberechtigungen für die Objekte, die sie besitzt, insbesondere wenn die Aufbewahrung alte Snapshots löscht.
Verschlüsselung: Nutzen Sie sichere Repositorien (wie S3) mit aktivierter serverseitiger Verschlüsselung (SSE-S3 oder SSE-KMS).

Leistungsdrosselung

Snapshots können I/O-intensiv sein. Wenn Sie während des Snapshot-Fensters eine Leistungsverschlechterung bemerken, drosseln Sie den Snapshot-Verkehr auf Repositoriumsebene. Für viele Repositoriumstypen sind die relevanten Einstellungen max_snapshot_bytes_per_sec und max_restore_bytes_per_sec, wenn Sie das Repositorium registrieren oder aktualisieren.

PUT /_snapshot/my_s3_daily_repo
{
  "type": "s3",
  "settings": {
    "bucket": "es-backup-bucket-name",
    "region": "us-east-1",
    "base_path": "daily_snapshots/production",
    "max_snapshot_bytes_per_sec": "100mb",
    "max_restore_bytes_per_sec": "100mb"
  }
}

indices.recovery.max_bytes_per_sec steuert den Peer- und Snapshot-Wiederherstellungsverkehr. Passen Sie es daher nur an, wenn Sie die Auswirkung auf die Shard-Wiederherstellung verstehen. Halten Sie Snapshot-Zeitpläne nach Möglichkeit außerhalb der Spitzenzeiten für Indizierung und Suche.

Täglicher Sicherungs-Workflow

Dauerhaftes Repositorium konfigurieren: Verwenden Sie Cloud-Speicher (S3/Azure/GCS) für Produktionsumgebungen.
SLM-Richtlinie definieren: Planen Sie Snapshots (z. B. täglich um 1:30 Uhr) mit SLM und stellen Sie sicher, dass angemessene Aufbewahrungsregeln festgelegt sind.
ILM koordinieren (falls zutreffend): Verwenden Sie wait_for_snapshot vor dem Löschen oder durchsuchbare Snapshots für kostengünstigere durchsuchbare Historie.
Status überwachen: Überprüfen Sie regelmäßig die Ausführung der SLM-Richtlinie über die APIs _slm/policy und _slm/status.
Wiederherstellung testen: Führen Sie vierteljährlich oder halbjährlich eine vollständige Wiederherstellung in einer separaten Umgebung durch, um die RTO-Bereitschaft zu validieren.

Die nützliche Sicherung ist die, die Sie wiederherstellen können. Halten Sie die tägliche SLM-Richtlinie einfach, überwachen Sie Fehler und planen Sie Wiederherstellungsübungen oft genug, damit Ihr Team die genauen Schritte vor einem Vorfall kennt.