none
Frage zur manuellen Sicherung von Hyper-V VM´s mit wbadmin RRS feed

  • Frage

  • Hallo,

    ich habe da mal eine Frage zur Sicherung mit wbadmin.
    Wbadmin bietet ja die Möglichkeit VM´s über den Host direkt zu sichern. 

    wbadmin start backup -backuptarget:\\BackupServer\HyperV -hyperv:XXX -allowDeleteOldBackups -quiet

    Wenn man aber eine große VHDX ausschließen möchte, funktioniert es so nicht. 
    Das geht wohl nur, wenn man statt mit dem Parameter "-hyperv" nur die benötigten Disks und die zur VM gehörenden Konfig-Dateien manuell sichert. 

    Jetzt die Frage: Gibt es irgendeinen Vorteil der Sicherung mit "-hyperv" gegenüber der manuellen Sicherung?

    vG Markus

    Dienstag, 30. April 2019 08:22

Antworten

  • Beispiel: Die VHDX selber ist 100GB groß, das OS des Gastes meldet eine Belegung von 25GB.
    Somit sichert der Host 100GB und der Gast würde nur 25GB sichern.

    Moin,

    das ist natürlich grober Unfug. Ich habe hier eine VM, wo auf einer 60GB VHDX, welche auf 58GB aufgeblasen ist, 23GB belegt sind. Sowohl eine Hyper-V-Sicherung als auch eine Volume-Sicherung mit lediglich dieser VHDX ergeben ein Backup von 23 GB Größe. So intelligent ist der Hyper-V VSS Writer dann schon. Übrigens: in beiden Fällen wird ein VSS-Vorgang in der VM ausgelöst, wenn sie eingeschaltet ist und die ICs laufen.

    Der Unterschied zwischen dem Sichern der Applikation "Hyper-V" zum Sichern der einzelnen Dateien von VMs liegt darin, dass alle Bezüge zwischen den einzelnen Komponenten aufgezeichnet werden und beim Restore erhalten bleiben. Beispiel: eine VM mit einer differenziellen Platte und Snapshots. Basisplatte, Konfiguration, VHDX und Snapshots liegen auf vier unterschiedlichen Volumes. Mit einer Hyper-V-Sicherung kann ich die komplette VM auf einen Host wiederherstellen, der eine völlig andere Festplattenkonfiguration hat. Eine File-Sicherung hingegen wird mir keine funktionierende Konfiguration erzeugen, wenn ich z.B. nur ein großes Festplatten-Volume für alles habe. Ich werde alles mühsam händisch zusammen puzzeln müssen.

    Bedenken sollte man bei der Planung und Einrichtung, dass Backup im richtigen Leben völlig unwichtig ist - es zählt nur Restore. Beispiel: Ich habe in der VM eine Datenbank, die zufälligerweise keinen VSS-Writer hat. Von der mache ich mit Datenbank-Mitteln jede Stunde ein Backup auf eine zweite Platte der VM, und das reicht mir als RPO. Dann ist es mir vollkommen egal, ob die Datenbank nach dem Restore der VM konsistent oder nur crash-konsistent ist, denn ich werde ja sowieso das letzte native Backup einspielen und nicht das "rohe" Ergebnis des Restore benutzen!

    Und machen wir uns nichts vor: Für die wenigen verbleibenden Applikationen (auf Windows-Basis), die heutzutage noch keinen VSS-Writer haben, gibt es meistens nur ein oder zwei Backup-Programme, die sie konsistent sichern können, ohne die Applikation anzuhalten. Und diese Programme gehören in der Regel nicht zu den am intuitivsten zu bedienenden oder auch nur zu den preiswertesten...


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 30. April 2019 21:01
  • Moin,

    "die verwendete Backup-Lösung" war aber in den von Dir angesprochenen Threads nicht VSS-aware. WSB ist es aber.

    Kannst Du bitte einen Link zu einer Ressource von Microsoft posten, die zweifelsfrei bestätigt, dass SQL Express den SQLWriter-Dienst nicht mitbringt? Meines Wissens fehlt der Express lediglich der Agent, der VSS-Writer ist hingegen vorhanden und funktionsfähig. 

    Natürlich hat ein Windows Fileserver ebenfalls einen VSS Writer, da kommt das Zeug ja auch ursprünglich her. DFS und FSRM haben jeweils eigene Writer. Ein Terminalserver nicht, aber wovon willst Du da eine Shadow Copy machen? Von den Benutzer-Sitzungen? Die sind beim Restore eh hin.

    Auch ein IIS hat einen VSS Writer, sogar zwei: Metabase und Config.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 1. Mai 2019 16:17

Alle Antworten

  • Grundsätzlich ist die Sicherung der VM's über den Host weniger zu empfehlen. Diese Sicherung kann nicht erkennen, wie viel Platz auf der VHDX tatsächlich verwendet ist.
    Beispiel: Die VHDX selber ist 100GB groß, das OS des Gastes meldet eine Belegung von 25GB.
    Somit sichert der Host 100GB und der Gast würde nur 25GB sichern.

    Zusätzlich ist eine Sicherung im laufenden Betrieb nicht zu empfehlen, wenn nicht sämtliche laufenden Anwendungen der VM sog. VSS-Writer haben (wie z.B. SQL-Server).

    Eine Sicherung des Gastes mit den Methoden des Gastes oder entsprechender Sicherungssoftware ist da halt besser.

    Dienstag, 30. April 2019 17:21
  • Beispiel: Die VHDX selber ist 100GB groß, das OS des Gastes meldet eine Belegung von 25GB.
    Somit sichert der Host 100GB und der Gast würde nur 25GB sichern.

    Moin,

    das ist natürlich grober Unfug. Ich habe hier eine VM, wo auf einer 60GB VHDX, welche auf 58GB aufgeblasen ist, 23GB belegt sind. Sowohl eine Hyper-V-Sicherung als auch eine Volume-Sicherung mit lediglich dieser VHDX ergeben ein Backup von 23 GB Größe. So intelligent ist der Hyper-V VSS Writer dann schon. Übrigens: in beiden Fällen wird ein VSS-Vorgang in der VM ausgelöst, wenn sie eingeschaltet ist und die ICs laufen.

    Der Unterschied zwischen dem Sichern der Applikation "Hyper-V" zum Sichern der einzelnen Dateien von VMs liegt darin, dass alle Bezüge zwischen den einzelnen Komponenten aufgezeichnet werden und beim Restore erhalten bleiben. Beispiel: eine VM mit einer differenziellen Platte und Snapshots. Basisplatte, Konfiguration, VHDX und Snapshots liegen auf vier unterschiedlichen Volumes. Mit einer Hyper-V-Sicherung kann ich die komplette VM auf einen Host wiederherstellen, der eine völlig andere Festplattenkonfiguration hat. Eine File-Sicherung hingegen wird mir keine funktionierende Konfiguration erzeugen, wenn ich z.B. nur ein großes Festplatten-Volume für alles habe. Ich werde alles mühsam händisch zusammen puzzeln müssen.

    Bedenken sollte man bei der Planung und Einrichtung, dass Backup im richtigen Leben völlig unwichtig ist - es zählt nur Restore. Beispiel: Ich habe in der VM eine Datenbank, die zufälligerweise keinen VSS-Writer hat. Von der mache ich mit Datenbank-Mitteln jede Stunde ein Backup auf eine zweite Platte der VM, und das reicht mir als RPO. Dann ist es mir vollkommen egal, ob die Datenbank nach dem Restore der VM konsistent oder nur crash-konsistent ist, denn ich werde ja sowieso das letzte native Backup einspielen und nicht das "rohe" Ergebnis des Restore benutzen!

    Und machen wir uns nichts vor: Für die wenigen verbleibenden Applikationen (auf Windows-Basis), die heutzutage noch keinen VSS-Writer haben, gibt es meistens nur ein oder zwei Backup-Programme, die sie konsistent sichern können, ohne die Applikation anzuhalten. Und diese Programme gehören in der Regel nicht zu den am intuitivsten zu bedienenden oder auch nur zu den preiswertesten...


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 30. April 2019 21:01
  • "das ist natürlich grober Unfug" kann ich so nicht stehen lassen.
    Wir haben hier schon einige Threads gehabt, wo sich jemand beschwert dass die Sicherung seiner VHD/X immer mehr Platz benötigt, da die verwendete Backuplösung den nicht belegten Platz von außerhalb nicht erkennen kann.
    Auch du hast da entsprechende Empfehlungen gegeben, eine Backuplösung "von innen" einzusetzen.

    "Für die wenigen verbleibenden Applikationen (auf Windows-Basis), die heutzutage noch keinen VSS-Writer haben" kann ich auch so nicht stehen lassen.
    Eher umgekehrt wird ein Schuh draus. VSS-Writer sind i.d.R. Sache der Anwendung wie SQL-Server, Oracle oder Exchange.
    SQL-Express z.B. hat keinen VSS-Writer und auch da gibt es von dir ab und an die Empfehlung, doch diesen zu verwenden, da ja Datenbanken bis 10GB sowieso die meisten Fälle abdecken würden;-).

    Bewege ich mich auf einem Terminalserver (TS) habe ich auch da i.d.R. keinen VSS-Writer, ein Fileserver hat ebensowenig einen VSS-Writer. Auch ein aktiver Web-Server hat keinen VSS-Writer und davon gibt es ja nun auch immer mehr.
    Und gerade die Fileserver (auch dazu gibts einen Thread) verteilen gerne die Daten auf den VHDx'n und beim Löschen wird nur in der MFT ausgetragen. Somit kann die Standardbackuplösung durchaus mehr sichern, als auf der dynamischen Platte wirklich belegt ist.

    Ich gebe dir natürlich Recht, dass ich auf jeden Fall eine Backuplösung benötige, die einen konsistenten Zusatnd der VM gewährleistet und für den Restorefall die geeigneten Mittel bereitstellt.

    Zum Thema Hyper-V-VSS-Writer finde ich nur eine Zusatzsooftware "Arcserve", die wohl einen allgemeineren VSS-Writer mitbringt.

    Zum Standardbackup via wbadmin finde ich auch nur Empfehlungen:
    a) Jede VM sichert sich selber
    b) VM's herunterfahren für die Konsistenz und den Host sichern

    Ansonsten gibt es natürloich auch kostenpflichtige Lösungen die das dann besser können.

    Mittwoch, 1. Mai 2019 12:33
  • Moin,

    "die verwendete Backup-Lösung" war aber in den von Dir angesprochenen Threads nicht VSS-aware. WSB ist es aber.

    Kannst Du bitte einen Link zu einer Ressource von Microsoft posten, die zweifelsfrei bestätigt, dass SQL Express den SQLWriter-Dienst nicht mitbringt? Meines Wissens fehlt der Express lediglich der Agent, der VSS-Writer ist hingegen vorhanden und funktionsfähig. 

    Natürlich hat ein Windows Fileserver ebenfalls einen VSS Writer, da kommt das Zeug ja auch ursprünglich her. DFS und FSRM haben jeweils eigene Writer. Ein Terminalserver nicht, aber wovon willst Du da eine Shadow Copy machen? Von den Benutzer-Sitzungen? Die sind beim Restore eh hin.

    Auch ein IIS hat einen VSS Writer, sogar zwei: Metabase und Config.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 1. Mai 2019 16:17
  • Hallo,

    also kann man sagen, das man WBAdmin besser nicht nutzt um vom Host aus eine Sicherung (Offline) der VM zu machen, wenn man ein VHDX Laufwerk ausschließen möchte.

    1. WBAdmin mit Parameter -hyperv bietet keinen zusätzlichen Parameter um ein VHD(X) Lauwerk auszuschließen.

    2. bei einer manuellen Sicherung ist die Rücksicherung sehr aufwendig bzw. durch Prüfpunkte sogar unmöglich

    Freitag, 3. Mai 2019 09:06
  • Ja, das kann man zusammenfassend so sagen.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 3. Mai 2019 09:08