Windows.edb im Dirty Shutdown: mit esentutl reparieren
Warum eine gesicherte Windows.edb im Dirty Shutdown steht, wie man das mit esentutl /mh prüft und die MSS-Protokolle mit esentutl /r auf einer Kopie nachspielt.
Kurz gesagt. Eine aus einem laufenden System kopierte Windows.edb steht fast immer im Zustand Dirty Shutdown: Einige bestätigte Änderungen stehen nur in den Transaktionsprotokollen MSS*.log. Mit esentutl /mh Windows.edb prüfen. Für eine konsistente Datenbank den ganzen Ordner (Datenbank, MSS*.log, MSS.chk) in ein Arbeitsverzeichnis kopieren, per cd hineinwechseln und esentutl /r MSS /d ausführen. Das /d ist entscheidend: Ohne es sucht esentutl die Datenbank in dem Verzeichnis, das in den Protokollen steht, also am Originalort. Wenn der Unterschied zählen kann, sowohl die Rohkopie als auch die wiederhergestellte Kopie auswerten. Die Wiederherstellung nie am Original-Beweismittel ausführen.
Was „Dirty Shutdown“ bedeutet
ESE schreibt jede Änderung in sein Transaktionsprotokoll, bevor es die Datenbankdatei aktualisiert. Beim ordentlichen Herunterfahren schreibt die Engine alles in die Datenbank und markiert den Header als Clean Shutdown. Wird die Datei bei laufender Engine kopiert oder verliert der Rechner den Strom, steht im Header weiterhin Dirty Shutdown. Den Datenbankseiten können dann Änderungen fehlen, die nur in den Protokollen existieren. Microsoft beschreibt dieses Wiederherstellungskonzept in seiner ESE-Übersicht; das allgemeine Konzept steht im Glossar.
Bei Windows Search sind das die Dateien:
| Datei | Rolle |
|---|---|
Windows.edb | Die Datenbank |
MSS.log | Aktuelles Transaktionsprotokoll |
MSSxxxxx.log (hexadezimale Generationsnummer) | Ältere, noch benötigte Protokollgenerationen |
MSS.chk | Checkpoint: bis zu welcher Position die Protokolle bereits angewendet sind |
*.jrs | Reserveprotokolle (Schutz bei voller Platte) |
MSStmp.log | Temporäres Protokoll |
Der Basisname MSS ist das, was man esentutl übergibt.
Schritt 1: den Zustand prüfen
Auf einer Kopie, mit dem in Windows enthaltenen esentutl.exe:
esentutl /mh Windows.edb
Nach dieser Zeile suchen:
State: Dirty Shutdown
oder Clean Shutdown. Die Ausgabe zeigt außerdem die Seitengröße (cbDbPage) und den Protokollbereich, den die Datenbank noch benötigt. Microsofts archivierter Beitrag zu esentutl und VSS zeigt einen echten Header-Dump in beiden Zuständen. Der Windows Search Index Parser liest dasselbe Zustandsfeld und warnt bei „dirty“.
Verweigert esentutl das Öffnen einer Datei, die ein anderer Prozess hält, arbeitet man an der aktiven Datei. Anhalten und zuerst eine Kopie anlegen: siehe Sicherungsoptionen.
Schritt 2: eine Arbeitskopie vorbereiten
- Den gesicherten Ordner hashen.
- Den ganzen Ordner in ein Arbeitsverzeichnis kopieren, etwa
D:\work\search. Die Wiederherstellung braucht Datenbank, alleMSS*.log-Generationen undMSS.chkzusammen. - Einen Windows-Analyserechner verwenden, dessen ESE-Version mindestens so neu ist wie die des Quellsystems. Eine ältere Engine kann eine Datenbank ablehnen, die eine neuere geschrieben hat.
Schritt 3: Soft Recovery mit esentutl /r
cd /d D:\work\search
esentutl /r MSS /d
Was die Optionen bewirken, laut archivierter Referenz zum esentutl-Wiederherstellungsmodus:
| Option | Bedeutung | Verwenden? |
|---|---|---|
/r MSS | Wiederherstellung mit Protokollen des Basisnamens MSS | Ja |
/l | Speicherort der Protokolldateien (Standard: aktuelles Verzeichnis) | Nur wenn die Protokolle woanders liegen |
/s | Speicherort der Systemdateien wie des Checkpoints (Standard: aktuelles Verzeichnis) | Nur wenn MSS.chk woanders liegt |
/d [Pfad] | Speicherort der Datenbankdateien; ohne Pfad das aktuelle Verzeichnis. Ohne /d: das ursprünglich in den Protokollen vermerkte Verzeichnis. | Immer, damit die Wiederherstellung in der Arbeitskopie bleibt |
/i | Fehlende oder nicht passende Datenbankanhänge ignorieren | Nur wenn die Wiederherstellung an den Anhängen scheitert; dokumentieren |
/a | Wiederherstellung darf bestätigte Daten verlieren, wenn die Integrität erhalten bleibt | Letzter Ausweg; dokumentieren |
/t | Protokolldateien nach Erfolg kürzen | Nein: Protokolle als Beweismittel behalten |
Anschließend erneut esentutl /mh Windows.edb ausführen. Der Zustand sollte nun Clean Shutdown sein.
Scheitert die Wiederherstellung, weil eine Protokollgeneration fehlt, ist die Sicherung unvollständig. Wenn möglich neu sichern. Sonst die „dirty“ Datenbank so auswerten, wie sie ist, und die Lücke dokumentieren.
Alternative: /vssrec im laufenden System
Auf einem laufenden System ab Windows 10 kann esentutl die Datenbank aus einer Schattenkopie kopieren und die Protokolle innerhalb der Schattenkopie in einem Schritt nachspielen:
cd /d C:\ProgramData\Microsoft\Search\Data\Applications\Windows
esentutl /y Windows.edb /d D:\case\Windows.edb /vssrec MSS .
Das entspricht dem Beispiel aus Microsofts archiviertem Beitrag (/y <Quelle> /d <Ziel> /vssrec <Protokoll-Basisname> <Protokollpfad>), ausgeführt aus dem Datenbankordner, damit . der Protokollpfad ist. So entsteht eine saubere Kopie, ohne den Dienst zu stoppen. Zwei Vorbehalte aus demselben Beitrag: Beim Anlegen der Schattenkopie nicht bestätigte Transaktionen werden zurückgerollt, und die Schattenkopie erzeugt zusätzliche I/O-Last. Ich sichere zusätzlich den Rohordner, damit der nicht wiederhergestellte Zustand erhalten bleibt.
Warum nicht /p (Reparatur)?
esentutl /p ist eine Reparatur: Sie macht die Datenbank konsistent, indem sie verwirft, was sie nicht beheben kann. Ein verlustbehafteter Vorgang für Administratoren, die eine funktionierende Datenbank zurückwollen. Für Beweismittel ist die Soft Recovery mit den Protokollen das richtige Werkzeug. Falls /p doch nötig wird, auf einer separaten Kopie ausführen und die unreparierte Datenbank daneben aufbewahren.
Wiederhergestellt oder roh: was auswerten?
Beides, wenn es darauf ankommt.
| Rohe „dirty“ Kopie | Kopie nach Soft Recovery | |
|---|---|---|
| Jüngste Änderungen, die noch in Protokollen stehen | Fehlen | Enthalten |
| Datensätze, die diese protokollierten Transaktionen löschen | Eventuell noch sichtbar | Weg (die Löschung wurde angewendet) |
| Konsistenz | Seiten eventuell mitten in der Aktualisierung | Konsistent |
| Von einem selbst verändert | Nein | Ja, dokumentierte Arbeitskopie |
Die ersten beiden Zeilen erklären, warum ich beide behalte: Die Rohkopie kann noch ein Element zeigen, das die protokollierten Transaktionen löschen, die wiederhergestellte Kopie zeigt die neuesten Zugänge. Ein Diff beider Exporte zeigt genau, was in den Protokollen stand.
Braucht der Parser eine saubere Datenbank?
Nein. Der Windows Search Index Parser liest „dirty“ Datenbanken und meldet den Zustand. Gefundene MSS*.log-, .jrs- und MSS.chk-Dateien listet er als erkannt, aber nicht ausgewertet: Transaktionsprotokolle spielt er selbst nicht nach. Für die vollständigste Sicht eine Kopie mit esentutl /r wiederherstellen und beide Kopien nacheinander laden. Nicht vergessen: Sein ESE-Leser wurde nur an synthetischen Datenbanken validiert; zentrale Ergebnisse mit einem anderen Tool gegenprüfen (siehe den Vergleich).
FAQ
Sollte man esentutl /p auf eine Windows.edb im Dirty Shutdown anwenden?
Nicht als ersten Schritt. /p ist eine Reparatur, die beschädigte Seiten und Daten verwerfen kann. Zuerst die Soft Recovery (/r) mit den Protokollen nutzen. Nur eine Kopie reparieren, nur wenn die Wiederherstellung scheitert, und es dokumentieren.
Kann man eine Windows.edb im Dirty Shutdown ohne Wiederherstellung parsen?
Ja. Die Datenbankdatei ist lesbar; ihr fehlen nur die Änderungen, die noch in den Protokollen stehen. Der Windows Search Index Parser liest sie und warnt, dass jüngste Änderungen fehlen können.