Ein Wazuh-Indexer-Cluster kann nach einer scheinbar unkomplizierten Änderung des Speicherpfads plötzlich den Status RED anzeigen. Obwohl alle Nodes erreichbar sind und ein Cluster Manager gewählt wurde, bleiben unter Umständen zahlreiche Primary Shards nicht zugewiesen. Besonders kritisch wird die Situation, wenn Inventory-, Vulnerability- und Monitoring-Indizes betroffen sind.

Die Ursache liegt häufig nicht in einem beschädigten Cluster, sondern darin, dass OpenSearch nach einer Änderung von path.data auf ein leeres Datenverzeichnis zugreift. Die ursprünglichen Shard-Daten existieren weiterhin, sind für den betroffenen Indexer jedoch nicht mehr erreichbar.

Dieser Artikel zeigt anhand eines Praxisfalls mit Wazuh 4.14.8 und OpenSearch 2.19.6, wie sich ein solcher Cluster ohne unnötigen Datenverlust wiederherstellen lässt. Außerdem wird beschrieben, wie eine Storage-Migration über mehrere Indexer-Nodes kontrolliert durchgeführt werden kann.

1. Ausgangslage / Problemstellung

In einer neu aufgebauten Wazuh-Umgebung sollte der Indexer-Speicher schrittweise auf ein neues Storage-Volume verschoben werden.

Die Umgebung bestand aus folgenden Komponenten:

Komponente	Konfiguration
Wazuh	4.14.8
OpenSearch	2.19.6
Indexer-Cluster	4 Nodes
Betriebssystem	Linux mit SELinux
Ursprünglicher Datenpfad	/var/lib/wazuh-indexer
Neuer Datenpfad	/data/wazuh-indexer/data
Ursprünglicher Logpfad	/var/log/wazuh-indexer
Neuer Logpfad	/data/wazuh-indexer/logs

Auf dem ersten Node wurden in der Datei /etc/wazuh-indexer/opensearch.yml die folgenden Einstellungen geändert:

Ursprüngliche Konfiguration:

path.data: /var/lib/wazuh-indexer
path.logs: /var/log/wazuh-indexer

Neue Konfiguration:

path.data: /data/wazuh-indexer/data
path.logs: /data/wazuh-indexer/logs

Die Berechtigungen und SELinux-Kontexte der neuen Verzeichnisse wurden angepasst. Anschließend wurde der Indexer-Dienst neu gestartet.

Dabei wurde jedoch ein entscheidender Schritt ausgelassen: Die vorhandenen Daten aus dem ursprünglichen Datenverzeichnis wurden nicht auf das neue Volume kopiert.

Symptome nach dem Neustart

Der betroffene Node konnte sich wieder erfolgreich mit dem Cluster verbinden. Alle vier Nodes waren sichtbar und ein Cluster Manager war gewählt.

Trotzdem meldete OpenSearch:

Cluster Health

RED

Indexer-Nodes

4 / 4

Nicht zugewiesene Primary Shards

26

Gemeldete Fehlerursachen

NODE_LEFT · no_valid_shard_copy

Insgesamt waren 26 Indizes betroffen:

Indextyp	Anzahl
wazuh-states-inventory-*	23
wazuh-states-vulnerabilities-*	2
wazuh-monitoring-*	1
Gesamt	26

Zu den betroffenen Inventory-Daten gehörten unter anderem Informationen über installierte Software, Benutzer, Prozesse, Dienste, Netzwerkinterfaces, Ports, Hardware und Hotfixes.

Auffällig war, dass weder Alert-Indizes noch System- oder Security-Indizes betroffen waren.

Der zunächst geplante Lösungsansatz

Da es sich um eine neue Installation ohne geschäftskritische historische Daten handelte, wurde zunächst erwogen, die 26 betroffenen Indizes über die OpenSearch-API zu löschen und anschließend durch Wazuh neu erstellen zu lassen.

Dieser Ansatz hätte zwar die nicht zugewiesenen Shards aus der Cluster-Metadatenstruktur entfernt, wäre jedoch mit vermeidbarem Datenverlust verbunden gewesen.

Die bessere Lösung bestand darin, zunächst die noch vorhandenen Originaldaten wieder verfügbar zu machen.

2. Technische Analyse

2.1 Warum ein neuer Datenpfad zu fehlenden Primary Shards führt

OpenSearch speichert im konfigurierten Datenverzeichnis nicht nur die eigentlichen Indexdaten, sondern auch lokale Node-Metadaten, Shard-Daten und weitere Informationen, die für den Betrieb benötigt werden.

Bei einer Änderung von path.data ohne Übernahme der vorhandenen Dateien startet der Prozess mit einem neuen beziehungsweise leeren lokalen Datenbestand.

Der Indexer kann sich unter geeigneten Voraussetzungen weiterhin mit dem bestehenden Cluster verbinden. Das bedeutet jedoch nicht, dass die zuvor lokal gespeicherten Shards verfügbar sind.

Die Cluster-Metadaten kennen die vorhandenen Indizes weiterhin. Die zugehörigen lokalen Shard-Kopien können auf dem betroffenen Node aber nicht mehr gefunden werden.

Ursache und Auswirkung

Alter Datenpfad

Enthält gültige Shard-Daten

Pfadänderung ohne Datenkopie

Neuer Datenpfad

Keine bisherigen Shard-Kopien vorhanden

26 Primary Shards nicht zugewiesen

Clusterstatus RED

Wichtig ist die Unterscheidung zwischen einem erreichbaren Node und einem Node, der tatsächlich die erwarteten Shard-Daten bereitstellt.

2.2 Warum ausschließlich bestimmte Wazuh-Indizes betroffen waren

Die Erklärung liegt insbesondere in den Replikationseinstellungen der betroffenen Indizes.

In der beschriebenen Wazuh-Version verwenden die Templates für wazuh-states-inventory-* und wazuh-states-vulnerabilities-* standardmäßig:

{
  "number_of_replicas": 0
}

Auch für die Monitoring-Indizes ist standardmäßig keine zusätzliche Replik vorgesehen:

wazuh.monitoring.replicas: 0

Diese Einstellung wird über die Wazuh-Dashboard-Konfiguration verwaltet.

Ein Index mit number_of_replicas: 0 besitzt für jeden Shard nur eine Primary-Kopie und keine Replica-Kopie.

Wenn diese einzige Kopie auf einem Node liegt, dessen lokaler Datenbestand nicht mehr erreichbar ist, kann OpenSearch den Shard nicht automatisch von einem anderen Node wiederherstellen.

Die 26 fehlenden Primaries sind daher mit einer Situation vereinbar, in der sich deren einzige gültige Kopien auf dem zuerst migrierten Node befanden.

Im Gegensatz dazu verwenden Wazuh-Alert-Indizes standardmäßig eine automatische Replikationskonfiguration:

{
  "auto_expand_replicas": "0-1"
}

In einem Cluster mit mehreren geeigneten Nodes kann dadurch eine zusätzliche Kopie vorhanden sein.

Das erklärt, warum Alert-Indizes in diesem Fall nicht betroffen waren. Voraussetzung ist allerdings, dass die entsprechenden Indexeinstellungen nicht nachträglich verändert wurden.

2.3 Bedeutung von NODE_LEFT und no_valid_shard_copy

Zwei Diagnoseinformationen sind für diesen Fehler besonders relevant.

NODE_LEFT

Diese Information beschreibt, dass ein Shard nicht mehr zugewiesen ist, nachdem der Node, auf dem er zuvor lag, den Cluster verlassen hat.

Das ist bei einem geplanten Dienstneustart zunächst nicht ungewöhnlich.

no_valid_shard_copy

Diese Information ist deutlich aussagekräftiger. Sie weist darauf hin, dass OpenSearch unter den aktuell verfügbaren Shard-Kopien keine gültige Kopie findet, die für die automatische Zuweisung verwendet werden kann.

In diesem Fall war die ursprüngliche Datenablage noch vorhanden. Damit bestand eine realistische Möglichkeit, die fehlenden Shards ohne Löschung der Indizes wiederherzustellen.

2.4 Warum das Löschen der Indizes nicht die erste Wahl ist

Ein API-Aufruf wie

curl -k -u admin \
  -X DELETE \
  "https://localhost:9200/INDEX_NAME"

löscht den betreffenden Index aus dem Cluster.

Das ist keine Reparatur eines Shards, sondern eine destruktive Operation.

Bei den betroffenen Wazuh-Indizes wären dadurch unter anderem Inventory-, Vulnerability- und Monitoring-Daten verloren gegangen.

Zwar können bestimmte Wazuh-State-Indizes durch erneute Synchronisation wieder aufgebaut werden. Zeitpunkt und Vollständigkeit hängen jedoch von den beteiligten Wazuh-Komponenten und deren Zustand ab. Historische Monitoring-Daten lassen sich nicht einfach durch eine neue Indexer-Verbindung rekonstruieren.

Darüber hinaus garantiert das Löschen einzelner Indizes nicht, dass der Cluster anschließend GREEN wird. Weitere Allocation-Probleme könnten weiterhin bestehen.

Solange eine gültige ursprüngliche Shard-Kopie existiert, sollte deren Wiederherstellung Vorrang vor dem Löschen des Index haben.

3. Lösung / Best Practices

3.1 Wiederherstellung des ursprünglichen Datenpfads

Da die ursprünglichen Datenverzeichnisse unverändert vorhanden waren, konnte der betroffene Node auf seinen vorherigen Datenbestand zurückgesetzt werden.

Schritt 1: Indexer-Dienst stoppen

Auf dem betroffenen Node:

sudo systemctl stop wazuh-indexer

Schritt 2: Daten des ersten Migrationsversuchs sichern

Das während des ersten Starts neu angelegte Datenverzeichnis wird umbenannt, statt es zu löschen:

sudo mv -T \
  /data/wazuh-indexer/data \
  /data/wazuh-indexer/data.first-attempt

Vorher muss sichergestellt werden, dass das Zielverzeichnis noch nicht existiert. Die Option -T verhindert, dass das Quellverzeichnis versehentlich in ein bereits vorhandenes Zielverzeichnis verschoben wird.

Schritt 3: Ursprüngliche Konfiguration wiederherstellen

In /etc/wazuh-indexer/opensearch.yml:

path.data: /var/lib/wazuh-indexer
path.logs: /var/log/wazuh-indexer

Dabei müssen die ursprünglichen Verzeichnisse einschließlich ihrer Berechtigungen und SELinux-Kontexte weiterhin gültig sein.

Schritt 4: Indexer erneut starten

sudo systemctl start wazuh-indexer

Damit greift der Indexer wieder auf die ursprünglich gespeicherten Node- und Shard-Daten zu.

3.2 Clusterzustand überprüfen

Nach dem Neustart sollten zunächst alle Nodes geprüft werden.

curl -k -u 'USERNAME' \
  'https://INDEXER_IP:9200/_cat/nodes?v'

Anschließend wird der Clusterzustand abgefragt:

curl -k -u 'USERNAME' \
  'https://INDEXER_IP:9200/_cluster/health?pretty'

Eine detaillierte Shard-Übersicht liefert:

curl -k -u 'USERNAME' \
  'https://INDEXER_IP:9200/_cat/shards?v&h=index,shard,prirep,state,node,unassigned.reason'

Die Platzhalter USERNAME und INDEXER_IP müssen an die eigene Umgebung angepasst werden. Bei Verwendung von -u 'USERNAME' fragt curl interaktiv nach dem Passwort.

Die Option -k deaktiviert die TLS-Zertifikatsprüfung. Sie sollte nur verwendet werden, wenn dies in der jeweiligen Umgebung bewusst erforderlich ist. Für den regulären Betrieb empfiehlt sich die Prüfung über die vertrauenswürdige CA.

Wenn OpenSearch die ursprünglichen Shard-Kopien als gültig akzeptiert, können die fehlenden Primaries wieder zugewiesen werden.

Ergebnis des Praxisfalls: Die Wiederherstellung des ursprünglichen Datenpfads löste das Problem erfolgreich. Eine Löschung der 26 Indizes war nicht notwendig.

3.3 Diagnose bei weiterhin nicht zugewiesenen Shards

Sollten nach der Wiederherstellung noch Primary Shards fehlen, kann die Allocation Explain API zur Analyse eingesetzt werden.

Beispiel:

curl -k -u 'USERNAME' \
  -X POST \
  'https://INDEXER_IP:9200/_cluster/allocation/explain?pretty' \
  -H 'Content-Type: application/json' \
  -d '{
    "index": "INDEX_NAME",
    "shard": 0,
    "primary": true
  }'

Die Werte für index und shard müssen aus der tatsächlichen Shard-Übersicht übernommen werden.

Die API liefert Informationen darüber, warum ein Shard nicht zugewiesen werden kann. Dazu gehören unter anderem Allocation-Entscheidungen und Hinweise auf vorhandene oder fehlende gültige Shard-Kopien.

Erst wenn sichergestellt ist, dass keine nutzbare Kopie mehr existiert und keine Wiederherstellung aus einem Snapshot möglich ist, sollten destruktive Maßnahmen erwogen werden.

Die OpenSearch-Dokumentation beschreibt die zugrunde liegende Diagnose-API ausführlich. Wazuh dashboard · Wazuh documentation

3.4 Sichere Storage-Migration der verbleibenden Nodes

Nach der erfolgreichen Wiederherstellung kann die eigentliche Storage-Migration durchgeführt werden.

Die wichtigste Regel lautet:

Jeder Node wird einzeln migriert, und seine bestehenden Daten werden bei gestopptem Indexer-Dienst vollständig auf das neue Volume kopiert.

Vor der Migration sollten ein aktueller, überprüfter Snapshot sowie ein dokumentierter Rückfallplan vorhanden sein.

Schritt 1: Replica Allocation vorübergehend einschränken

Um unnötige Replica-Recovery während eines geplanten Node-Neustarts zu vermeiden, kann die Allocation-Einstellung vorübergehend angepasst werden:

curl -k -u 'USERNAME' \
  -X PUT \
  'https://INDEXER_IP:9200/_cluster/settings' \
  -H 'Content-Type: application/json' \
  -d '{
    "persistent": {
      "cluster.routing.allocation.enable": "primaries"
    }
  }'

Diese Einstellung erlaubt die Zuweisung von Primary Shards, schränkt jedoch die reguläre Replica Allocation ein.

Sie schützt nicht vor der temporären Nichtverfügbarkeit eines Primary Shards ohne Replica.

Für zeitlich begrenzte Wartungsarbeiten ist eine transient-Einstellung häufig zweckmäßiger. Entscheidend ist, die vorherige Konfiguration zu dokumentieren und nach der Migration wiederherzustellen.

Schritt 2: Flush ausführen

curl -k -u 'USERNAME' \
  -X POST \
  'https://INDEXER_IP:9200/_flush'

Ein Flush unterstützt einen geordneten Zustand der Indexdaten vor dem Neustart, ersetzt jedoch weder einen Snapshot noch die vollständige Datenübernahme.

Schritt 3: Indexer auf dem betreffenden Node stoppen

sudo systemctl stop wazuh-indexer

Vor der Datenübertragung ist sicherzustellen, dass der Dienst vollständig beendet ist und keine weiteren Prozesse das Datenverzeichnis verändern.

Schritt 4: Daten und Logs kopieren

Zunächst wird geprüft, ob auf dem Zielvolume ausreichend Speicherplatz verfügbar ist:

df -h /data

Die Zielverzeichnisse müssen vorbereitet sein. Insbesondere darf das neue Datenverzeichnis keine fremden oder bereits initialisierten Node-Daten enthalten.

Anschließend werden die bestehenden Daten kopiert:

sudo rsync -aHAX \
  /var/lib/wazuh-indexer/ \
  /data/wazuh-indexer/data/

Die vorhandenen Logs können ebenfalls übernommen werden:

sudo rsync -aHAX \
  /var/log/wazuh-indexer/ \
  /data/wazuh-indexer/logs/

Die Optionen von rsync erfüllen dabei unterschiedliche Aufgaben:

Option	Funktion
-a	Archivmodus, erhält wesentliche Dateiattribute
-H	Erhält Hardlinks
-A	Erhält ACLs
-X	Erhält Extended Attributes

Beide Kopiervorgänge müssen erfolgreich abgeschlossen sein. Der Exit-Code sollte jeweils 0 betragen.

Da der Dienst währenddessen gestoppt ist, wird vermieden, dass sich die Daten während des Kopierens verändern.

Schritt 5: Berechtigungen und SELinux prüfen

Nach dem Kopieren müssen Eigentümer, Dateiberechtigungen und SELinux-Kontexte kontrolliert werden.

Beispiel zur Überprüfung:

ls -ldZ /data/wazuh-indexer/data
ls -ldZ /data/wazuh-indexer/logs

Die Verzeichnisse müssen für den Indexer-Dienst lesbar beziehungsweise beschreibbar sein.

Bei aktiviertem SELinux müssen die neuen Pfade mit passenden Dateikontextregeln versehen werden. Die tatsächlich erforderlichen SELinux-Typen sollten anhand der bestehenden Installation und der geltenden Sicherheitsrichtlinien bestimmt werden.

Ein pauschales Abschalten von SELinux ist keine geeignete Lösung.

Schritt 6: Neue Pfade konfigurieren

In /etc/wazuh-indexer/opensearch.yml:

path.data: /data/wazuh-indexer/data
path.logs: /data/wazuh-indexer/logs

Die ursprünglichen Verzeichnisse bleiben unverändert erhalten.

Dadurch kann bei Problemen mit dem neuen Storage-Pfad vergleichsweise einfach auf die vorherige Konfiguration zurückgewechselt werden.

Schritt 7: Dienst starten

sudo systemctl start wazuh-indexer

Danach wird kontrolliert, ob der Node dem Cluster wieder beigetreten ist und die erwarteten Shards verfügbar sind.

Schritt 8: Normale Allocation wiederherstellen

Wenn die Einstellung zuvor auf primaries gesetzt wurde:

curl -k -u 'USERNAME' \
  -X PUT \
  'https://INDEXER_IP:9200/_cluster/settings' \
  -H 'Content-Type: application/json' \
  -d '{
    "persistent": {
      "cluster.routing.allocation.enable": "all"
    }
  }'

Wurde stattdessen eine temporäre Einstellung verwendet, muss diese entsprechend zurückgesetzt werden.

Anschließend ist der Cluster erneut zu überprüfen:

curl -k -u 'USERNAME' \
  'https://INDEXER_IP:9200/_cluster/health?pretty'

Die Migration des nächsten Nodes sollte erst beginnen, wenn die Shard-Zuweisung wieder vollständig stabil ist und der Cluster den erwarteten Zustand erreicht hat.

3.5 Besonderheit: Zero-Replica-Indizes und Verfügbarkeit

Die bisher beschriebene Methode erhält die bestehenden Daten und Node-Identitäten, garantiert aber keine unterbrechungsfreie Verfügbarkeit aller Indizes.

Bei Indizes ohne Replicas kann der Cluster während des Neustarts eines Nodes vorübergehend RED werden.

Wenn kontinuierliche Verfügbarkeit erforderlich ist, sollte der Node vor der Migration kontrolliert geleert werden.

Dafür kann OpenSearch angewiesen werden, Shards nicht mehr auf einem bestimmten Node zu platzieren:

curl -k -u 'USERNAME' \
  -X PUT \
  'https://INDEXER_IP:9200/_cluster/settings' \
  -H 'Content-Type: application/json' \
  -d '{
    "persistent": {
      "cluster.routing.allocation.exclude._name":
        "NODE_NAME"
    }
  }'

NODE_NAME steht für den tatsächlichen Namen des betreffenden Indexer-Nodes.

Dabei muss cluster.routing.allocation.enable auf all stehen, damit die erforderlichen Relocations stattfinden können.

Vor dem Stoppen ist zu prüfen, ob tatsächlich sämtliche Shards vom Node weg verschoben wurden:

curl -k -u 'USERNAME' \
  'https://INDEXER_IP:9200/_cat/shards?v'

Die übrigen Nodes benötigen ausreichend freien Speicherplatz und müssen die Allocation-Anforderungen erfüllen.

Nach erfolgreicher Migration wird die Exclusion entfernt:

curl -k -u 'USERNAME' \
  -X PUT \
  'https://INDEXER_IP:9200/_cluster/settings' \
  -H 'Content-Type: application/json' \
  -d '{
    "persistent": {
      "cluster.routing.allocation.exclude._name": null
    }
  }'

Anschließend muss erneut geprüft werden, ob die Shards korrekt zugewiesen sind.

Das Drain-Verfahren reduziert das Risiko temporär nicht verfügbarer Indizes, verursacht jedoch zusätzliche Datenbewegungen im Cluster und benötigt entsprechend Kapazität und Zeit.

3.6 Cluster Manager zuletzt migrieren

Bei einem Cluster mit vier Nodes sollte der aktuell gewählte Cluster Manager nach Möglichkeit zuletzt migriert werden.

Der aktuelle Cluster Manager kann über folgenden API-Aufruf ermittelt werden:

curl -k -u 'USERNAME' \
  'https://INDEXER_IP:9200/_cat/cluster_manager?v'

Das reduziert unnötige Wechsel während der Migration. Dennoch muss vorab geprüft werden, ob die verbleibenden cluster-manager-berechtigten Nodes weiterhin ein ausreichendes Quorum bilden können.

Die Reihenfolge allein garantiert keine Cluster-Verfügbarkeit.

4. Lessons Learned / Best Practices

Aus dem beschriebenen Vorfall lassen sich mehrere wichtige Empfehlungen für den Betrieb von Wazuh-Indexer-Clustern ableiten.

Storage-Migration ist keine reine Konfigurationsänderung

Das Ändern von path.data verschiebt keine bestehenden Dateien. OpenSearch erwartet am neuen Pfad einen konsistenten Datenbestand.

Ein neuer, leerer Pfad ist daher nicht mit einem erfolgreich migrierten Datenverzeichnis gleichzusetzen.

Zero-Replica-Indizes erhöhen das Ausfallrisiko

Bei Indizes ohne Replicas existiert keine zusätzliche Shard-Kopie auf einem anderen Node.

Dies spart Speicherplatz, reduziert jedoch die Fehlertoleranz. Für sicherheitsrelevante Umgebungen sollte geprüft werden, welche Indizes eine zusätzliche Replica benötigen und ob die jeweilige Wazuh-Konfiguration dies unterstützt.

Eine höhere Replica-Anzahl erhöht allerdings den Speicherbedarf und ersetzt kein Backup.

Ein erreichbarer Node bedeutet nicht automatisch gesunde Shards

Ein Cluster kann alle erwarteten Nodes anzeigen und dennoch RED sein.

Deshalb sollten bei Wartungsarbeiten immer Cluster Health, Shard Allocation und Indexzustände gemeinsam betrachtet werden.

Bestehende Daten vor destruktiven API-Operationen prüfen

Das Löschen von Indizes sollte nicht als Standardreaktion auf no_valid_shard_copy verwendet werden.

Vorher müssen vorhandene Datenverzeichnisse, Snapshots und mögliche Allocation-Ursachen untersucht werden.

Auch scheinbar reproduzierbare Inventory-Daten können für die Sicherheitsanalyse relevant sein. Ihr Verlust kann vorübergehend zu unvollständiger Transparenz über Endpoints und Schwachstellen führen.

Migrationen in klar getrennten Wartungsschritten durchführen

Für produktive Cluster empfiehlt sich eine feste Reihenfolge:

1. Snapshot und Rückfallplan prüfen.
2. Clusterzustand und Shard-Verteilung dokumentieren.
3. Genau einen Node für die Migration auswählen.
4. Daten konsistent auf das neue Volume übertragen.
5. Node starten und Shard-Zuweisung überprüfen.
6. Cluster vollständig stabilisieren, bevor der nächste Node folgt.

Alte Datenverzeichnisse erst nach Abschluss entfernen

Die ursprünglichen Datenverzeichnisse sollten erhalten bleiben, bis alle Nodes erfolgreich migriert wurden und die Funktion des Clusters validiert ist.

Dabei sollten insbesondere die Indexer-Logs, die Shard-Verteilung, die Wazuh-Dashboard-Funktionen sowie Inventory- und Vulnerability-Daten überprüft werden.

Erst danach ist eine kontrollierte Bereinigung der alten Speicherpfade sinnvoll.

5. Fazit

Ein RED-Status nach einer Änderung von path.data bedeutet nicht zwangsläufig, dass ein Wazuh-Indexer-Cluster beschädigt ist oder neu aufgebaut werden muss.

Im beschriebenen Fall waren 26 Primary Shards nicht mehr verfügbar, weil ein Indexer nach der Storage-Umstellung auf ein leeres Datenverzeichnis zugriff. Die ursprünglichen Daten waren weiterhin vorhanden, sodass eine Wiederherstellung ohne Indexlöschung möglich war.

Die Rückkehr zur ursprünglichen Datenpfadkonfiguration löste das Problem erfolgreich.

Für die anschließende Migration der verbleibenden Nodes ist entscheidend, die vollständigen Datenverzeichnisse bei gestopptem Indexer zu übernehmen, die Node-Identität zu erhalten und jeden Migrationsschritt anhand des Clusterzustands zu validieren.

Besonders in Wazuh-Umgebungen mit Inventory-, Vulnerability- und Monitoring-Indizes ohne Replicas sollten Storage-Migrationen sorgfältig geplant werden. Eine kontrollierte Datenübernahme verhindert vermeidbare Ausfälle und schützt sicherheitsrelevante Informationen.

Die wichtigste Erkenntnis: Vor dem Löschen nicht zugewiesener Indizes immer prüfen, ob die ursprünglichen Shard-Kopien noch vorhanden und wiederherstellbar sind.

Quellen und weiterführende Dokumentation

Die folgenden Dokumentationen bieten ergänzende Informationen zu Indexer-Betrieb, Wazuh-Konfiguration und Shard Allocation.

1. Wazuh – Upgrading central components
   Hinweise zu Wartungsarbeiten, Neustarts und dem kontrollierten Betrieb zentraler Wazuh-Komponenten.
   https://documentation.wazuh.com/current/upgrade-guide/upgrading-central-components.html
2. Wazuh – Dashboard settings
   Konfigurationsmöglichkeiten des Wazuh Dashboards einschließlich der Monitoring-Einstellungen.
   https://documentation.wazuh.com/current/user-manual/wazuh-dashboard/settings.html
3. OpenSearch – Cluster Allocation Explain API
   Technische Referenz zur Diagnose nicht zugewiesener Shards und zur Analyse von Allocation-Entscheidungen.
   https://docs.opensearch.org/latest/api-reference/cluster-api/cluster-allocation/

Mehr zu Wazuh …

Mehr zum Wazuh Ambassador Program …

https://wazuh.slack.com/archives/C0A933R8E/p1793747862526169