Warum ein einzelner VM-Restore keinen Verzeichnisdienst beweist
Der Domain Controller ist in fast jeder Windows-Landschaft das System, von dem die anderen abhängen. Genau deshalb sagt seine Wiederherstellung als einzelne virtuelle Maschine wenig darüber aus, ob Anmeldungen und abhängige Dienste danach funktionieren.
Ein Verzeichnisdienst ist kein einzelner Server
In der Sicherung sieht ein Domain Controller aus wie jede andere virtuelle Maschine. Er lässt sich zurückschreiben, er bootet, das Betriebssystem meldet sich. Aus dieser Beobachtung wird oft geschlossen, das Active Directory sei wiederhergestellt. Der Schluss ist verständlich und trotzdem zu kurz.
Ein funktionierender Verzeichnisdienst ist ein Zusammenspiel mehrerer Bedingungen. Die Namensauflösung muss stimmen, weil Clients und Dienste den Controller über DNS finden. Die Zeit muss stimmen, weil die Authentifizierung zeitabhängig ist. Sind mehrere Controller im Spiel, spielt ihr Verhältnis zueinander eine Rolle. Und die Dienste, die sich anmelden wollen — Datenbanken, Applikationsserver, Dateidienste — müssen den Controller zum richtigen Zeitpunkt erreichen.
Keine dieser Bedingungen prüft man mit einem Restore. Man prüft sie, indem man die Umgebung startet und sich anmeldet.
Was neben dem Controller gebraucht wird
Diese Punkte entscheiden darüber, ob aus einer gestarteten Maschine ein nutzbarer Dienst wird.
Namensauflösung
Ohne funktionierendes DNS finden Clients und Dienste den Verzeichnisdienst nicht — unabhängig davon, ob er läuft.
Zeit
Die Authentifizierung ist zeitabhängig. Weicht die Zeit in der wiederhergestellten Umgebung ab, scheitern Anmeldungen ohne erkennbaren Grund.
Startreihenfolge
Dienste, die vor dem Verzeichnisdienst starten, laufen in Fehler. Die richtige Reihenfolge ist Betriebswissen, das im Ernstfall fehlt.
Mehrere Controller
Wo mehrere Controller im Einsatz sind, ist ihr Verhältnis zueinander Teil des Dienstes — nicht nur die einzelne Maschine.
Dienstkonten
Anwendungen melden sich mit Konten an, die an Systeme gebunden sein können. Fehlt eine Bindung, startet die Anwendung nicht.
Namen und Zertifikate
Fest eingetragene Namen, Adressen und Zertifikate sind unproblematisch — bis die Umgebung neu aufgebaut wird.
Als Teil der Landschaft, nicht als Einzelstück
Deshalb wird ein Domain Controller im Recovery Lab nicht isoliert wiederhergestellt, sondern als Teil der vereinbarten Systemlandschaft: gemeinsam mit den Systemen, die von ihm abhängen, in der Startreihenfolge, die Sie vorgeben, in einem nachgebildeten Netz.
Die Wiederherstellung und den Start übernehmen wir. Die Prüfung, ob Anmeldung, Gruppenzugehörigkeiten und abhängige Dienste wie erwartet arbeiten, führen Ihre Administratoren in der isolierten Umgebung selbst durch — sie kennen den Sollzustand.
Ob sich Ihre Verzeichnisstruktur sinnvoll in einer isolierten Umgebung abbilden lässt, hängt vom Aufbau ab und wird vor dem Test geklärt. Wir sagen Ihnen vorher, was in Ihrer Konstellation aussagekräftig testbar ist — und was nicht.
Der Controller kommt zusammen mit den Systemen zurück, die ihn brauchen.
Verzeichnisdienst und Namensauflösung zuerst, dann die abhängigen Dienste.
Ihre Administratoren melden sich in der isolierten Umgebung an und bewerten das Ergebnis.
Was im Test klemmt, ist genau die Information, die im Ernstfall fehlen würde.
Häufige Fragen zu Active Directory Recovery
Reicht es, einen Domain Controller aus dem Backup wiederherzustellen?
Für die Aussage „die VM ist zurück“ reicht es. Für die Aussage „die Anmeldung funktioniert“ nicht. Ein Verzeichnisdienst ist kein einzelner Server, sondern ein Zusammenspiel: Namensauflösung, Zeitsynchronisation, Replikation zwischen mehreren Controllern und die Dienste, die sich darauf verlassen. Erst wenn diese Bestandteile zusammen laufen, ist der Dienst wieder da.
Wird Active Directory im Recovery Lab wiederhergestellt und gestartet?
Domain Controller können als Teil der vereinbarten Systemlandschaft wiederhergestellt und gestartet werden — wie andere Server auch. Ob sich Ihre Verzeichnisstruktur in der isolierten Umgebung sinnvoll abbilden lässt, klären wir vor dem Test anhand Ihrer konkreten Konstellation.
Wer prüft, ob die Benutzeranmeldung funktioniert?
Das prüfen Sie selbst in der isolierten Umgebung. Wir stellen wieder her und starten die Systeme; ob Anmeldungen und abhängige Dienste wie erwartet arbeiten, beurteilen Ihre Administratoren. Sie kennen die Erwartung — wir kennen nur das Startverhalten.
Warum ist die Reihenfolge beim Start so wichtig?
Weil viele Dienste ohne erreichbaren Verzeichnisdienst und ohne funktionierende Namensauflösung nicht starten oder in einen Fehlerzustand laufen. Wer Datenbank und Applikationsserver vor dem Domain Controller startet, sieht Fehler, die nichts mit dem Backup zu tun haben. Diese Reihenfolge ist im Ernstfall genau das Wissen, das fehlt — der Test macht sie explizit.
Was lernt man typischerweise aus so einem Test?
Meistens etwas über Abhängigkeiten, die niemand dokumentiert hatte: ein Dienstkonto, das an einen bestimmten Server gebunden ist, eine Anwendung mit fest eingetragener IP-Adresse, ein Zertifikat, das an einen Namen hängt. Solche Punkte sind harmlos, solange die Umgebung steht — und aufwendig, wenn sie neu aufgebaut werden muss.
Weiter im Thema: Proxmox Recovery für die Wiederherstellung der Maschinen und Disaster-Recovery-Test für Testplan und Reihenfolge. Übersicht im Recovery Lab.