Zehn Gründe für das Scheitern einer Wiederherstellung virtueller Maschinen

Scheitert die Wiederherstellung einer virtuellen Maschine, kann das viele Gründe haben. Bei der Fehlersuche starten Sie am besten bei den Log-Dateien.

Schlägt die Wiederherstellung einer virtuellen Maschinem (VM) fehl, müssen Sie das Problem schnell identifizieren und beheben. Die Ereignis-Protokolle sind hierfür ein guter Anfang. Manchmal sind die dort hinterlegten Informationen allerdings kryptisch und geben keine brauchbare Auskunft über das eigentliche Problem. In diesem Beitrag finden Sie zehn häufige Gründe, warum die Wiederherstellung virtueller Maschinen nicht funktioniert.

1. Das Backup war beschädigt

Mehr zum Thema Backup

Erfahren Sie, welche verschiedenen Möglichkeiten Sie für ein modernes Backup haben.

Lesen Sie hier, wie Sie virtuelle Maschinen in Windows-Failover-Clustern sichern und wiederherstellen.

Auf diese Weise realisieren Sie redundante Backup-Lösungen.

Einer der häufigsten Gründe für das Fehlschlagen einer Wiederherstellung ist ein kaputtes Backup. Zu Beschädigungen an Sicherungen kommt es etwa, wenn Datenträger kaputt sind oder die Verbindung unterbrochen wurde. Sie können Ihr Unternehmen gegen beschädigte Backups schützen, aber nur, wenn Sie die Datensicherungen regelmäßig testen und entsprechende Probleme korrigieren.

Beschädigte Backups lassen sich ziemlich schwer beheben. In einer solchen Situation sind die Log-Dateien der Backups die beste Informationsquelle. Sollten im Log Lesefehler verzeichnet sein, deutet das auf auf einen fehlerhaften Datenträger hin. Ebenso kann der Fehler bei einem ein kaputten Kabel oder einer defekten Netzwerkkarte liegen.

2. Der VSS läuft nicht

Backups von Windows Servern basieren in der Regeln auf dem Volume Shadow Copy Service (VSS). Die Backup-Applikation agiert dabei in der Regel als VSS-Requester und schickt entsprechend eine Anfrage an den VSS-Provider. Dessen Aufgabe ist es, die verschiedenen VSS-Writer zu koordinieren. Die Koordination des VSS-Providers und -Writers übernimmt ein Service des Betriebssystems, der Volume Shadow Copy Service heißt. Dieser Service muss gestartet sein, damit VSS ordnungsgemäß funktioniert. Die damit verbundenen Writer müssen ebenfalls laufen.

Sie können den Status des Volume Shadow Copy Service durch die Benutzung des Service Control Manager testen. Die Zustände individueller VSS-Writer können Sie mit Hilfe des Befehls VSSAdmin List Writers überprüfen.

3. Das Backup wurde auf Datei-Ebene gemacht

Die meisten modernen Backup-Anwendungen unterstützen das Sichern virtueller Maschinen. Dieselben Applikationen unterstützen aber auch Backups auf Datei-Ebene. Sollte die Backup-Anwendung so konfiguriert sein, dass Sie einen Server auf Datei-Ebene sichert, könnte das zu einem Fehler bei der Wiederherstellung führen.  Machen Sie kein spezielles Backup für VMs und sichern stattdessen auf Datei-Ebene, befinden sich die entsprechenden VMs mit hoher Wahrscheinlichkeit in einem inkonsistenten Zustand.

4. Entscheidende Komponenten der VM wurde nicht vom Backup adressiert

Virtuelle Maschinen bestehen aus mehr als virtuellen Festplatten. Es gibt zudem kritische Metadaten und Konfigurationsdateien, die mit den entsprechenden VMs assoziiert sind. Diese Daten bestimmen die virtuelle Maschine und die entsprechenden Bereitstellungen der Hardwareressourcen.

In einigen Unternehmen ist es üblich, die Konfigurations- und Snapshot-Daten getrennt von den virtuellen Maschinen zu speichern. In diesem Szenario muss die Backup-Anwendung die dezentrale Natur der verschiedenen Komponenten kennen. Andernfalls werden bestimmte Komponenten der VM nicht gesichert und die Wiederherstellung ist unmöglich. Die einfachste Lösung ist auch hier das Überprüfen der Log-Dateien. Am besten sollten Sie die Integrität der Backups durch ausführliche Tests verifizieren.

5. Die Speicherkontingente wurden überschritten

Eine weitere Ursache für die nicht funktionierende Wiederherstellung von VMs ist, wenn Storage-Kontingente überschritten wurden. Speziell in Private-Cloud-Umgebungen ist das ein Problem, da jedem Anwender nur eine begrenzte Menge Speicher zugewiesen ist. Ist der Speicher nicht ausreichend, könnte eine Wiederherstellung unmöglich sein. Hier hilft nur, das Kontingent des Speichers temporär zu erhöhen.

6. Dem Host geht der Arbeitsspeicher aus

Bei der Wiederherstellung einer VM werden auf dem Host-Server Ressourcen in Anspruch genommen. In der Regel werden Festplatten- und Netzwerkressourcen, CPU-Zyklen und Arbeitsspeicher benötigt. Das Problem ist, dass einige Unternehmen die maximale Dichte an virtuellen Maschinen auf einem Host-Server nutzen, um die Investitionen auszureizen (ROI). Sollten die Ressourcen auf dem Host-Server knapp sein, könnte eine Wiederherstellung aus diesem Grund scheitern. Das ist häufig der Fall, wenn der Server zu wenig RAM hat.

7. Eine Backup-Appliance führt Live-Migrationen aus

Einige Unternehmen konfigurieren ihre Server-Virtualisierungs-Infrastruktur so, dass diese Workloads je nach Anforderung dynamisch auf den verschiedenen Virtualisierungs-Hosts verteilen. Das kann ein Problem sein, wenn die Backup-Anwendung auf einer virtuellen Appliance läuft.

Eine virtuelle Appliance sollte theoretisch in der Lage sein, ohne Probleme live auf einen anderen Host zu migrieren. Das gilt auch, wenn ein Backup läuft. Unter bestimmten Umständen kann es aber vorkommen, dass es zu einer kurzfristigen Unterbrechung der Verbindung kommt. Die Folge ist, dass laufende Jobs scheitern.

8. Die Applikation ist gegen Wiederherstellung geschützt

Ein Grund für eine fehlgeschlagene Wiederherstellung kann auch sein, dass bestimmte Anwendungen gegen diese geschützt sind. Ein klassisches Beispiel einer solchen Applikation ist Exchange Server. Wollen Sie eine Mailbox-Datenbank wiederherstellen, würde dieser Vorgang scheitern. Sie müssen dem Exchange Server ausdrücklich die Erlaubnis erteilen, diese Datenbank überschreiben zu dürfen. Diese Art von Schutz sollte für eine Wiederherstellung auf Ebene einer VM nicht zutreffen. Allerdings könnte es hinderlich sein, wenn Sie individuelle Anwendungen oder Datenbanken innerhalb einer VM wiederherstellen wollen. Das kann in physikalischen, virtuellen oder gemischten Umgebungen zutreffen.

9. Die Wiederherstellung steht im Konflikt mit einer laufenden VM

Manchmal kommt es vor, dass die Wiederherstellung einer virtuellen Maschine mit einer laufenden VM kollidiert. Wie sich diese Konflikte lösen lassen, variiert je nach Backup-Anwendung. Ein doppelter Name einer virtuellen Maschine könnte ein Grund sein, warum eine Wiederherstellung nicht funktioniert. Das gilt auch für Duplikate virtueller MAC-Addressen oder Kennungen des Betriebssystems.

10. Die Ursache des Problems wurde nicht gelöst

Stellen Sie sich vor, dass eine VM beschädigt ist und Sie möchten die virtuelle Maschine aus dem Backup wiederherstellen. Sollte die Wiederherstellung fehlschlagen, kann dies daran liegen, dass das zugrunde liegende Problem nicht gelöst worde. Möglicherweise ist die virtuelle Maschine defekt, da es ein Problem mit dem Datenträger gibt und Sie hatten keine Zeit, das Problem zu beseitigen. Befindet sich der Datenträger in einem beschädigten Zustand, ist die Wiederherstellung einer virtuellen Maschine ebenfalls nicht möglich.

Wie Sie sehen, gibt es viele Faktoren, die ein Scheitern einer Wiederherstellung verursachen können. In diesen Fällen ist es ein guter Anfang, wenn Sie die Ereignis-Protokolle der Backup-Anwendung studieren. Dort finden Sie möglicherweise Hinweise auf das Problem.

Im Allgemeinen weisen Security-bezogene Log-Einträge auf ein Passwort-Problem der Service-Konten oder unzureichende Berechtigungen hin. Das gilt entweder für den Backup-Operator oder das Service-Konto. Ein Fehler beim Agent oder eine allgemeinere Fehlermeldung könnten auf Probleme mit dem Volume Shadow Copy Service deuten. Kommunikationsfehler sind in der Regel mit Hardwareproblemen verbunden. Ein Lesefehler ist ein Hinweis auf ein kaputtes oder verschmutztes Bandlaufwerk.

Über den Autor: Brien M. Posey, MCSE, hat bereits acht Mal Microsofts MVP-Auszeichnung für Exchange Server, Windows Server und Internet Information Server (IIS) erhalten. Brien hat als CIO für eine landesweite Krankenhauskette gearbeitet und war für das Department of Information Management in Fort Knox zuständig. Sie finden weitere Informationen zu seiner Person auf seiner Website unter brienposey.com.

Folgen Sie SearchStorage auf Twitter@sstoragede.

Artikel wurde zuletzt im April 2014 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Virtualisierungsstrategien

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close