Snapshots statt „Backup“-Action: Wazuh Indexer mit Snapshot Management und ISM korrekt absichern

von

Einleitung

Wer Wazuh-Daten langfristig sichern und gleichzeitig alte Indizes automatisiert aus dem Cluster entfernen will, landet schnell bei zwei eng verwandten, aber funktional getrennten Mechanismen: Snapshot Management für Backups und Index State Management (ISM) für Aufbewahrung und Löschung. Genau an dieser Stelle entsteht in der Praxis häufig Verwirrung, weil in der Wazuh-Oberfläche unter der State-Definition keine Aktion mit dem Namen „Backup“ existiert. Das ist kein Bedienfehler, sondern entspricht der Architektur von Wazuh Indexer beziehungsweise OpenSearch: Snapshots und Index-Lifecycle-Aktionen sind unterschiedliche Workflows. Wazuh dokumentiert ISM für Retention und Löschlogik, während Snapshot-Operationen über die Snapshot-Verwaltung von OpenSearch Dashboards laufen.

Ausgangslage / Problemstellung

Die Anforderung ist klar: Alle relevanten Wazuh-Indizes sollen zunächst in ein bereits eingerichtetes Repository gesichert und anschließend aus dem Cluster gelöscht werden, um Speicherplatz freizugeben. Im konkreten Fall existiert bereits ein Snapshot-Repository, etwa backup2025, und es wird versucht, innerhalb einer State-Management-Policy eine Aktion zu finden, die den Backup-Schritt übernimmt.

Der zentrale Punkt: Eine ISM-Policy kann Indizes verwalten, verschieben, sperren, rollen oder löschen, aber nicht selbst als „Backup“-Mechanismus dienen. Für Sicherungen muss eine separate Snapshot Policy erstellt werden. Erst danach sollte eine ISM-Policy die alten Indizes löschen. OpenSearch beschreibt Snapshot Management ausdrücklich als eigenen Mechanismus für automatisierte Snapshots, während ISM für Index-Zustände und Aktionen wie Delete zuständig ist.

Technische Analyse

Wazuh Indexer basiert auf OpenSearch und trennt operative Speicherverwaltung von Datensicherung. Diese Trennung ist für einen stabilen Betrieb sinnvoll:

  • Snapshot Management (SM) erstellt und verwaltet Snapshots in einem Repository.
  • Index State Management (ISM) steuert den Lebenszyklus der Indizes, etwa Übergänge nach Alter, Größe oder Dokumentenzahl und Aktionen wie Löschung.

Deshalb gibt es in der State-Definition auch keinen Action-Typ „backup“. Wer in einer ISM-Policy nach einer Backup-Option sucht, sucht an der falschen Stelle. Die richtige Reihenfolge lautet:

  1. Snapshot-Repository registrieren
  2. Snapshot-Policy anlegen und erfolgreich ausführen lassen
  3. ISM-Policy definieren, die alte Indizes nach gewünschter Frist löscht

Ein weiterer wichtiger Aspekt betrifft die Frage nach bestimmten Zeiträumen wie „1. Januar 2025 bis 31. März 2025“. Snapshot Policies arbeiten primär mit Index-Auswahlmustern, nicht mit einem frei definierbaren Dokument-Zeitfenster innerhalb eines Indexes. Ein Snapshot sichert also ganze Indizes, nicht beliebige Teilmengen von Dokumenten nach Datum. Wenn Wazuh-Indizes periodisch benannt sind, etwa tage- oder monatsweise, lässt sich der gewünschte Zeitraum indirekt durch passende Indexmuster oder die Auswahl konkreter Indizes abbilden. Für ein beliebiges Dokument-Zeitfenster innerhalb eines einzelnen großen Indexes ist Snapshot Management hingegen nicht das passende Werkzeug. Dafür wären Reindexing oder Export-/Restore-Workflows nötig. OpenSearch dokumentiert Snapshots als Sicherung von Indizes und Cluster-State, nicht als inhaltlich gefilterten Teil-Export.

Auch die Frage nach den Index-Typen ist betrieblich relevant. Wazuh dokumentiert unter anderem folgende Muster:

  • wazuh-alerts-* für Alerts, die vom Wazuh-Server erzeugt werden
  • wazuh-monitoring-* für Monitoring-Daten
  • weitere Muster für Archives, States, Statistics und andere interne Datentypen

Dadurch wird verständlich, warum eine Sicherungsstrategie nicht pauschal nur auf einen einzigen Index-Typ reduziert werden sollte. Wer ein vollständiges Betriebs-Backup will, muss bewusst entscheiden, welche Indexfamilien gesichert werden sollen.

Lösung / Best Practices

Die saubere Lösung besteht aus zwei Policies: einer Snapshot Policy für die Sicherung und einer ISM Policy für die Löschung.

1. Snapshot-Repository verwenden

Da das Repository bereits existiert, entfällt die Neuanlage. Snapshot Management setzt lediglich voraus, dass das Repository korrekt registriert und vom Indexer erreichbar ist. OpenSearch weist zudem darauf hin, dass Snapshots inkrementell arbeiten. Der erste Snapshot ist typischerweise größer, spätere sichern nur die Änderungen.

2. Snapshot Policy erstellen

Die Policy wird im Dashboard unter Indexer Management → Snapshot management → Snapshot policies angelegt. Dort werden Name, Zeitplan, Repository und zu sichernde Indizes definiert. Für eine vollständige Sicherung aller Wazuh-Indizes kann als Indexmuster beispielsweise ein breites Pattern wie wazuh-* oder bei Bedarf * verwendet werden, sofern keine anderen fachfremden Indizes im Cluster liegen. OpenSearch dokumentiert, dass in der Snapshot-Konfiguration die Ziel-Indizes und das Repository direkt angegeben werden.

Ein API-Beispiel für eine Snapshot-Policy mit dem Repository backup2025 sieht konzeptionell so aus:

POST _plugins/_sm/policies/wazuh-backup-policy
{
  "description": "Automated snapshots for Wazuh indices",
  "creation": {
    "schedule": {
      "cron": {
        "expression": "0 2 * * *",
        "timezone": "Europe/Berlin"
      }
    },
    "time_limit": "1h"
  },
  "deletion": {
    "schedule": {
      "cron": {
        "expression": "0 3 * * 0",
        "timezone": "Europe/Berlin"
      }
    },
    "condition": {
      "max_age": "90d",
      "min_count": 7
    },
    "time_limit": "1h",
    "snapshot_pattern": "wazuh-snapshot-*"
  },
  "snapshot_config": {
    "indices": "wazuh-*",
    "repository": "backup2025",
    "ignore_unavailable": true,
    "include_global_state": false,
    "partial": false,
    "date_format": "yyyy-MM-dd-HH:mm",
    "timezone": "Europe/Berlin"
  }
}

Wichtig daran sind drei Punkte:

Erstens: Die Sicherung erfolgt über snapshot_config, nicht über eine ISM-State-Action.
Zweitens: Die Löschung im Block deletion betrifft Snapshots im Repository, nicht produktive Indizes im Cluster.
Drittens: Die Snapshot Policy sollte zunächst erfolgreich laufen, bevor produktive Index-Löschungen automatisiert werden. Das OpenSearch-SM-API beschreibt genau diese Struktur mit creation, optionaler deletion für Snapshots und snapshot_config.

3. ISM-Policy für alte Indizes anlegen

Die eigentliche Löschung alter Indizes gehört in eine ISM-Policy. Ein einfaches Beispiel für wazuh-alerts-* wäre:

PUT _plugins/_ism/policies/wazuh-alerts-retention
{
  "policy": {
    "description": "Delete old wazuh-alerts indices after snapshot window",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [],
        "transitions": [
          {
            "state_name": "delete",
            "conditions": {
              "min_index_age": "90d"
            }
          }
        ]
      },
      {
        "name": "delete",
        "actions": [
          {
            "delete": {}
          }
        ],
        "transitions": []
      }
    ],
    "ism_template": [
      {
        "index_patterns": ["wazuh-alerts-*"],
        "priority": 100
      }
    ]
  }
}

Diese Policy sorgt dafür, dass Alert-Indizes nach 90 Tagen gelöscht werden. Der Delete-Schritt ist ein nativer ISM-Action-Typ. Wazuh beschreibt ISM explizit als Mechanismus, um Index-Operationen automatisiert anhand von Alter, Größe oder Dokumentenzahl auszuführen.

Für andere Indexfamilien wie wazuh-monitoring-* oder wazuh-statistics-* sollten bei Bedarf eigene Policies angelegt werden, weil diese Datenarten oft unterschiedliche Aufbewahrungsfristen haben.

4. Unterschied zwischen wazuh-monitoring und wazuh-alerts sauber berücksichtigen

wazuh-alerts-* enthält sicherheitsrelevante Alerts aus der Event-Analyse.
wazuh-monitoring-* enthält Monitoring- und Statusinformationen rund um Agents und Plattformbetrieb. Wazuh dokumentiert die verschiedenen Indexmuster und deren Zweck in der Übersicht der Wazuh-Indexer-Indizes.

Betrieblich bedeutet das: Alert-Indizes sind meist stärker audit- und forensikrelevant, Monitoring-Indizes dagegen eher operativ. Daraus ergibt sich oft eine längere Retention für Alerts und eine kürzere für Monitoring.

5. Zeitfenster wie Januar bis März 2025 richtig einordnen

Die Frage „Warum kann ich keinen Zeitraum wie 1 January 2025 bis 31 March 2025 auswählen?“ ist technisch wichtig. Snapshot Management arbeitet nicht wie eine Suchabfrage mit frei definierbarer Event-Zeitspanne. Ein Snapshot sichert komplette Indizes, die über Namen oder Patterns adressiert werden.

Das heißt konkret:

  • Gibt es periodische Indizes, etwa monatlich oder täglich, kann man genau diese Indizes auswählen.
  • Gibt es nur einen großen Sammelindex, lässt sich daraus per Snapshot kein inhaltlich gefilterter Teilbereich nach Dokumentdatum sichern.
  • Für fachliche Zeitfenster innerhalb eines Indexes braucht man eher Reindexing oder Export auf Basis einer Range Query auf das Datumsfeld. OpenSearch-Datumsfelder unterstützen Range Queries und Date Math, aber das ist eine Query-Logik und keine Snapshot-Policy-Logik.

Lessons Learned / Best Practices

Die wichtigste Erkenntnis lautet: ISM ersetzt kein Backup. Wer nur eine State-Management-Policy baut und dort auf eine Backup-Aktion hofft, wird keine vollständige Sicherung erhalten. Snapshots und Retention müssen als zwei getrennte Prozesse geplant werden.

Für einen sauberen Betrieb haben sich folgende Grundsätze bewährt:

Zuerst immer das Snapshot-Repository und eine funktionierende Snapshot-Policy validieren, bevor Index-Löschung aktiviert wird. Ein fehlgeschlagener Snapshot plus aggressive Delete-Policy ist einer der riskantesten Konfigurationsfehler im Indexer-Betrieb. OpenSearch weist außerdem darauf hin, Snapshots nie direkt im Dateisystem zu löschen, sondern ausschließlich über API oder Snapshot Management, weil Snapshots inkrementell aufgebaut sind und Datenblöcke gemeinsam nutzen können.

Retention nicht global über alle Wazuh-Indizes gleichsetzen. wazuh-alerts-*, wazuh-monitoring-*, wazuh-statistics-* und State-Indizes haben unterschiedliche betriebliche Bedeutung. Die passende Retention ergibt sich aus Compliance, Forensikbedarf und Storage-Kapazität.

Zeitfenster fachlich von Indexstruktur trennen. Wer Snapshots für „Q1 2025“ erwartet, braucht dafür eine Indexstruktur, die diesen Zeitraum sauber segmentiert, oder einen separaten Reindex-/Migrationsprozess. Wazuh empfiehlt beim Migrieren von Indizes ebenfalls den Snapshot-/Restore-Weg und beschreibt dabei, wie Indizes als Ganzes behandelt werden.

Fazit

Für das gewünschte Ziel gibt es in Wazuh Indexer keine einzelne „Backup“-Action innerhalb einer State-Management-Policy. Die korrekte Architektur besteht aus einer Snapshot Policy, die die Indizes in das Repository backup2025 sichert, und einer ISM Policy, die alte Indizes nach definierter Frist löscht. Wer zusätzlich einen fachlichen Zeitraum wie Januar bis März 2025 sichern will, muss verstehen, dass Snapshots ganze Indizes sichern und nicht beliebige Dokumentzeiträume innerhalb eines Indexes. Mit dieser Trennung lassen sich Wazuh-Indexer-Daten sauber sichern, kontrolliert aufräumen und langfristig betriebssicher verwalten.

Quellenverweis

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C07BZJY86G3/p1770232948452049