Windows Server Backup Hyper-V: Anleitung und Grenzen

Mit Windows Server Backup kannst Du Hyper-V-VMs sichern und wiederherstellen. Wichtig sind die korrekten VSS-Einstellungen und regelmäßig durchgeführte Rücksicherungen. Denn eine Sicherung hilft Dir erst dann wirklich, wenn auch die Anwendungen im wiederhergestellten Server funktionieren.

Die Windows Server-Sicherung eignet sich für überschaubare Sicherungsaufgaben auf einem einzelnen Host. In produktiven Umgebungen musst du aber Anwendungskonsistenz, Aufbewahrung, Ausfallschutz und Wiederherstellungszeit zusammen betrachten. Hier erfährst du, wie du Hyper-V mit Windows Server Backup sicherst, was die wbadmin-Befehle bedeuten und wann eine spezialisierte Lösung die bessere Wahl ist.

Windows Server Backup Hyper-V: Das Wichtigste zuerst

Windows Server Backup, kurz WSB, ist eine Sicherungsfunktion von Windows Server, die sich nachinstallieren lässt. Auf einem Hyper-V-Host kann sie ausgewählte virtuelle Maschinen samt zugehörigen virtuellen Festplatten und Konfigurationsdaten sichern. Dabei etwas anderes, als eine VHDX-Datei von Hand zu kopieren: Du wählst die Hyper-V-Komponente aus, statt einzelne Dateien einzusammeln.

Frage	Direkte Antwort
Ist eine Sicherung laufender VMs möglich?	Ja, wenn Gastbetriebssystem, Integrationsdienste und Speicheraufbau die verwendete Sicherungsmethode unterstützen.
Ist jede erfolgreiche Sicherung anwendungskonsistent?	Nein. Dafür müssen die betroffenen Anwendungen korrekt an der Sicherung beteiligt sein.
Passt WSB zu einem einzelnen Hyper-V-Host?	Für klar begrenzte Aufgaben kann es passen. Entscheidend sind die Anforderungen an Wiederherstellung und Sicherungsschutz.
Ersetzt WSB ein vollständiges Backup-Konzept?	Nein. Sicherungssoftware, getrennte Kopien, Aufbewahrung, Überwachung und Restore-Tests gehören zusammen.

Die folgende Anleitung bezieht sich auf Windows Server 2022 und Windows Server 2025 mit einem einzelnen Hyper-V-Host und VM-Dateien auf lokalen NTFS-Volumes. Die grafischen Schritte setzen die Desktopdarstellung voraus. Bei Server Core verwendest Du die Verwaltungswerkzeuge remote oder arbeitest mit PowerShell und wbadmin.

Was bedeutet anwendungskonsistente Hyper-V-Sicherung?

Anwendungskonsistenz bedeutet, dass eine Anwendung ihre Daten für einen zusammenpassenden Sicherungsstand vorbereitet hat. Bei Windows-Gästen kann der Volume Shadow Copy Service, kurz VSS, diese Abstimmung zwischen Sicherungsprogramm, Betriebssystem und geeigneten Anwendungen übernehmen. Grundlagen zu diesem Verfahren findest Du im Beitrag über Volume Shadow Copy und Schattenkopien.

Sicherungszustand	Bedeutung für die Wiederherstellung
Absturzkonsistent	Der gesicherte Zustand ähnelt einem plötzlichen Stromausfall. Betriebssystem und Anwendungen müssen ausstehende Vorgänge beim Start gegebenenfalls bereinigen.
Dateisystemkonsistent	Das Dateisystem wurde in einen zusammenpassenden Zustand gebracht. Daraus folgt noch keine vollständige Transaktionskonsistenz jeder Anwendung.
Anwendungskonsistent	Die beteiligten Anwendungen haben ihre Daten über einen geeigneten Mechanismus für die Sicherung vorbereitet.

Dass eine VM startet, beweist noch nicht, dass sich auch eine Datenbank korrekt wiederherstellen lässt. Vor allem bei SQL Server, Verzeichnisdiensten und anderen transaktionsbasierten Anwendungen musst du die jeweiligen Wiederherstellungsanforderungen von Anfang an mitplanen. Eine VSS-Option macht eine Anwendung ohne passenden Writer nicht automatisch konsistent.

Auch eine Sicherung im laufenden Betrieb garantiert nicht, dass alles völlig ungestört weiterläuft. Fehlen Voraussetzungen, braucht der gewählte Sicherungsweg unter Umständen einen gespeicherten Zustand der VM oder schlägt fehl. Beobachte den ersten Sicherungslauf deshalb am besten in einem geeigneten Wartungsfenster.

Voraussetzungen: Was Du vor dem Hyper-V-Backup festlegen solltest

Auf dem Host müssen die Hyper-V-Rolle und ein funktionierender Zugriff auf die VMs vorhanden sein. Falls Du noch beim Aufbau bist, hilft Dir die Anleitung zum Installieren und Einrichten von Hyper-V unter Windows Server 2025. Für die folgenden Verwaltungsbefehle verwendest Du eine mit ausreichenden Administratorrechten gestartete Windows PowerShell.

• Sicherungsumfang: Welche VMs, virtuellen Festplatten und zusätzlichen Daten gehören zur jeweiligen Anwendung?
• Sicherungsziel: Liegt das Backup auf einem getrennten Datenträger oder einem anderen System? Ein zweiter Laufwerksbuchstabe auf derselben physischen Platte bietet keinen Schutz gegen deren Ausfall.
• Kapazität: Reicht der freie Platz auf Quell- und Zielvolumes auch für temporäre Sicherungsdaten und mehrere benötigte Sicherungsstände?
• Zugriff: Funktionieren Berechtigungen und Zugangsdaten auch bei einer unbeaufsichtigten Ausführung?
• Wiederherstellung: Stehen ein geeigneter Zielhost, notwendige Schlüssel und eine dokumentierte Startreihenfolge zur Verfügung?

Dazu brauchst du zwei konkrete Ziele: Der RPO ist der maximal akzeptierte Datenverlust als Zeitspanne, der RTO die angestrebte Zeit, bis der Betrieb wieder läuft. Bei einer täglichen Sicherung können selbst im störungsfreien Ablauf fast 24 Stunden Arbeit fehlen, und eine fehlgeschlagene Sicherung vergrößert diesen Abstand noch.

Praxistipp: Lege für jede wichtige VM fest, welche Funktion nach einem Restore wirklich geprüft werden muss. Bei einem Dateiserver kann das der Zugriff auf eine Freigabe mit den richtigen Berechtigungen sein. Bei einer Fachanwendung gehört eine erfolgreiche Anmeldung mit Zugriff auf einen bekannten Datensatz dazu.

Schritt für Schritt: Hyper-V mit Windows Server Backup sichern

1. Windows Server-Sicherung auf dem Host installieren

Im Server-Manager findest Du die Windows Server-Sicherung unter „Rollen und Features hinzufügen“ im Bereich „Features“. Die Installation erfolgt auf dem Hyper-V-Host, wenn Du die virtuellen Maschinen von dort aus sichern möchtest. Alternativ kannst Du die Funktion mit PowerShell installieren:

Install-WindowsFeature -Name Windows-Server-Backup -IncludeManagementTools

Mit dem folgenden Befehl lässt sich der Installationsstatus anzeigen. Anschließend erreichst Du die grafische Verwaltung über „Tools“ im Server-Manager oder über die Suche nach „Windows Server-Sicherung“.

Get-WindowsFeature -Name Windows-Server-Backup

2. VM-Namen, Kennungen und Speicherorte erfassen

Vor der Auswahl lohnt sich eine kurze Bestandsaufnahme. Eine Übersicht mit Namen, Zustand und eindeutiger VM-Kennung erhältst Du mit diesem Befehl:

Get-VM | Select-Object Name, Id, State, Version, ConfigurationLocation

Die zugeordneten virtuellen Festplatten einer Beispiel-VM kannst Du separat anzeigen lassen. Dabei ersetzt Du SRV-FILE01 durch den tatsächlichen VM-Namen.

Get-VMHardDiskDrive -VMName "SRV-FILE01" |
    Select-Object VMName, Path, ControllerType, ControllerNumber, ControllerLocation

Weitere Möglichkeiten zur Bestandsaufnahme zeigt die Anleitung zum Abrufen von Hyper-V-VM-Informationen per PowerShell. Achte darauf, dass Konfiguration, virtuelle Festplatten und Prüfpunktdateien auf unterschiedlichen Volumes liegen können. Die Hyper-V-Standardordner für VMs und Festplatten allein beschreiben deshalb nicht zwingend die tatsächlichen Speicherorte vorhandener Maschinen.

Eine wichtige Ausnahme sind direkt an den Gast durchgereichte Datenträger und iSCSI-Verbindungen, die im Gast aufgebaut werden. Ihre Inhalte liegen nicht einfach als normale VHDX-Dateien im Sicherungsumfang des Hosts. Dafür brauchst du einen zusätzlichen Sicherungsweg, zum Beispiel innerhalb des Gasts. Davon zu unterscheiden ist ein am Host angebundenes iSCSI-Volume mit gewöhnlichen VHDX-Dateien.

3. Integrationsdienste und VSS im Gast überprüfen

In den VM-Einstellungen sollte die Sicherungsintegration aktiviert sein. Sie heißt je nach Oberfläche „Sicherung“ beziehungsweise „Sicherung (Volumeschattenkopie)“. Eine Übersicht der Integrationsdienste liefert auf dem Host:

Get-VMIntegrationService -VMName "SRV-FILE01"

Im Windows-Gast vermittelt der Dienst vmicvss zwischen der Hyper-V-Sicherung und VSS. Die folgenden Diagnosebefehle führst Du innerhalb dieser VM mit ausreichenden Rechten aus:

Get-Service -Name vmicvss
vssadmin list writers

Auch auf dem Host hilft vssadmin list writers bei der Fehlersuche. Ein unauffälliger Writer-Status vor dem Lauf ist allerdings keine Erfolgsgarantie. Entscheidend sind die Meldungen während der Sicherung und das Ergebnis der Wiederherstellung. Außerdem muss ein bedarfsgesteuerter Dienst nicht ständig laufen.

4. Eine benutzerdefinierte Sicherung mit Hyper-V-Auswahl anlegen

Für den ersten Durchlauf kannst Du in der Windows Server-Sicherung „Einmalsicherung“ auswählen. Über „Andere Optionen“ und „Benutzerdefiniert“ gelangst Du zur Auswahl der zu sichernden Elemente.

1. Über „Elemente hinzufügen“ lässt sich die verfügbare Hyper-V-Auswahl erweitern.
2. Du wählst die benötigten virtuellen Maschinen aus. Die Sicherung soll die VM als Hyper-V-Komponente erfassen.
3. Zusätzliche Hostdaten werden bei Bedarf ausdrücklich ergänzt. Eine ausgewählte VM ersetzt keine Sicherung des Hostbetriebssystems.
4. Unter den erweiterten Einstellungen überprüfst Du den VSS-Sicherungstyp. Für eine ergänzende Sicherung ist „VSS-Kopiesicherung“ häufig die passende Ausgangswahl.
5. In der Zusammenfassung vergleichst Du Auswahl und Ziel mit Deiner zuvor erstellten Bestandsaufnahme.

Das bloße Markieren eines Ordners mit VHDX-Dateien ist kein gleichwertiger Ersatz für diese VM-Auswahl. Ebenso fehlt bei einer einzelnen kopierten VHDX unter Umständen ein Teil der virtuellen Maschine. Dazu gehören beispielsweise ihre Konfiguration und abhängige Differenzdatenträger.

5. Sicherungsziel auswählen und ersten Lauf beobachten

Als Ziel kommt zum Beispiel ein getrenntes lokales Sicherungsvolume oder eine passende Netzwerkfreigabe infrage. Bei einer Freigabe müssen sowohl die Freigabe- als auch die Dateisystemberechtigungen stimmen. Den ersten Lauf beobachtest du am besten bis zum Ende und prüfst danach, welche VMs tatsächlich enthalten sind.

Richtest du später einen Datenträger ein, der nur für Sicherungen gedacht ist, kann der Assistent ihn formatieren. Vorhandene Daten gehen dabei verloren. Das unterscheidet sich von einer Sicherung auf ein bereits vorhandenes Volume. Lies dir deshalb die Zusammenfassung des Assistenten vor der Bestätigung besonders sorgfältig durch.

Hyper-V-VMs mit wbadmin und PowerShell sichern

Windows Server bietet zwei Möglichkeiten, um Hyper-V-Sicherungen über die Kommandozeile zu verwalten. Mit wbadmin.exe kannst Du regelmäßige Sicherungsaufträge einrichten und vorhandene Sicherungen starten. Alternativ stehen Dir die PowerShell-Cmdlets des Moduls WindowsServerBackup zur Verfügung. Damit kannst Du auch einzelne virtuelle Maschinen für eine einmalige Sicherung auswählen.

Beide Verfahren verwenden die Sicherungsfunktionen von Windows Server. Die folgenden Beispiele beziehen sich auf Windows Server 2022 und Windows Server 2025. Voraussetzung ist die installierte Windows Server-Sicherung. Alle Befehle werden mit Administratorrechten ausgeführt.

1. Hyper-V-VM mit WBADMIN auf ein lokales Laufwerk sichern

Mit wbadmin enable backup kannst Du einen regelmäßigen Sicherungsauftrag erstellen. Der Parameter -hyperv ermöglicht die Auswahl bestimmter virtueller Maschinen.

Das folgende Beispiel richtet eine tägliche Sicherung der VM SRV-FILE01 um 22 Uhr auf Laufwerk E: ein.

wbadmin enable backup -addtarget:E: -schedule:22:00 -hyperv:SRV-FILE01 -vssCopy

Wichtiger Hinweis: Das Sicherungsziel E: muss ein geeigneter Sicherungsdatenträger sein. Bei der Einrichtung eines dedizierten Sicherungsdatenträgers kann Windows Server Backup diesen formatieren und sämtliche vorhandenen Daten löschen. Die Auswahl des Sicherungsziels solltest Du deshalb besonders sorgfältig überprüfen.

Wenn Du den eingerichteten Sicherungsauftrag sofort starten möchtest, kannst Du folgenden Befehl verwenden:

wbadmin start backup

Ohne weitere Parameter startet wbadmin die Sicherung mit den bereits hinterlegten Einstellungen.

2. Mehrere Hyper-V-VMs mit WBADMIN sichern

Auch mehrere virtuelle Maschinen kannst Du in einem gemeinsamen Sicherungsauftrag zusammenfassen. Dazu werden die VM-Namen durch Kommas getrennt angegeben.

Das folgende Beispiel erstellt einen täglichen Sicherungsauftrag für SRV-FILE01 und SRV-APP01.

wbadmin enable backup -addtarget:E: -schedule:22:00 -hyperv:SRV-FILE01,SRV-APP01 -vssCopy

Dieser Befehl ist eine alternative Konfiguration zum vorherigen Beispiel. Beide Beispiele solltest Du nicht nacheinander ausführen, da wbadmin enable backup den vorhandenen Sicherungszeitplan verändern kann.

Die aktuelle Konfiguration kannst Du zuvor mit folgendem Befehl anzeigen:

wbadmin enable backup

3. Hyper-V-VM mit WBADMIN auf eine Netzwerkfreigabe sichern

Du kannst Deine Sicherungen auch auf einem anderen Server speichern. Das folgende Beispiel verwendet die Netzwerkfreigabe \\BACKUP01\HyperV\HV01 als Sicherungsziel.

wbadmin enable backup -addtarget:\\BACKUP01\HyperV\HV01 -schedule:22:00 -hyperv:SRV-FILE01 -vssCopy

Die Netzwerkfreigabe muss erreichbar sein und das verwendete Konto benötigt entsprechende Schreibberechtigungen. Falls andere Zugangsdaten erforderlich sind, können diese mit den dafür vorgesehenen wbadmin-Parametern angegeben werden. Kennwörter sollten allerdings nicht ungeschützt in Skripten gespeichert werden.

Beachte außerdem, dass bei wiederholten Sicherungen desselben Servers in denselben Netzwerkordner der vorherige Sicherungsstand überschrieben werden kann. Eine zusätzliche Aufbewahrungsstrategie ist deshalb erforderlich.

4. Einmalige Sicherung mit WBADMIN erstellen

Wenn Du keinen regelmäßigen Sicherungsauftrag einrichten möchtest, kannst Du mit wbadmin start backup auch einzelne Laufwerke oder Verzeichnisse sichern.

Im folgenden Beispiel wird das komplette Volume D: auf Laufwerk E: gesichert.

wbadmin start backup -backupTarget:E: -include:D: -vssCopy

Dieser Befehl erstellt eine Volume-Sicherung. Er verwendet keine gezielte Auswahl einer einzelnen Hyper-V-VM. Wenn sich VM-Konfigurationen und virtuelle Festplatten auf unterschiedlichen Volumes befinden, müssen alle benötigten Daten in die Sicherung aufgenommen werden.

Für zwei Volumes kannst Du beispielsweise folgenden Befehl verwenden:

wbadmin start backup -backupTarget:E: -include:D:,F: -vssCopy

Eine solche Volume-Sicherung ist nicht automatisch mit einer anwendungskonsistenten Hyper-V-Komponentensicherung gleichzusetzen. Für produktive VMs ist die VM-bezogene Sicherungsmethode daher vorzuziehen, sofern die eingesetzte Konfiguration sie unterstützt.

Hyper-V-VMs mit PowerShell sichern

PowerShell bietet eine flexible Möglichkeit, Hyper-V-Sicherungen direkt über Windows Server Backup zu erstellen. Das ist besonders praktisch, wenn Du nur bestimmte virtuelle Maschinen sichern willst, ohne dafür einen dauerhaften Sicherungszeitplan anzulegen.

Die folgenden Beispiele nutzen das PowerShell-Modul WindowsServerBackup. Das gehört zur Windows Server-Sicherung und stellt spezielle Cmdlets für Sicherungsaufträge, Sicherungsziele und Hyper-V-VMs bereit.

5. Verfügbare Hyper-V-VMs für die Sicherung anzeigen

Bevor Du eine Sicherung startest, kannst Du Dir alle virtuellen Maschinen anzeigen lassen, die Windows Server Backup auf dem Hyper-V-Host erkennt.

Import-Module WindowsServerBackup

Get-WBVirtualMachine | Format-Table VMName, Caption -AutoSize

Die Ausgabe enthält die erkannten Hyper-V-Komponenten. Der VM-Name wird anschließend für die Auswahl im Sicherungsskript verwendet. Falls eine vorhandene VM nicht angezeigt wird, solltest Du zunächst ihre Sicherungsintegration und den unterstützten Speicheraufbau überprüfen.

6. Einzelne Hyper-V-VM mit PowerShell auf E: sichern

Das folgende PowerShell-Skript erstellt eine einmalige Sicherung der virtuellen Maschine SRV-FILE01 auf dem Sicherungsvolume E:. Dabei wird ausdrücklich nur diese VM ausgewählt.

Import-Module WindowsServerBackup -ErrorAction Stop

$policy = New-WBPolicy

$vm = @(Get-WBVirtualMachine | Where-Object {
    $_.VMName -eq "SRV-FILE01"
})

if ($vm.Count -ne 1) {
    throw "Die VM SRV-FILE01 wurde nicht eindeutig gefunden."
}

Add-WBVirtualMachine -Policy $policy -VirtualMachine $vm

$target = New-WBBackupTarget -VolumePath "E:"

Add-WBBackupTarget -Policy $policy -Target $target

Set-WBVssBackupOption -Policy $policy -VssCopyBackup

Start-WBBackup -Policy $policy

Das Skript baut zuerst eine neue Sicherungsrichtlinie im Arbeitsspeicher auf. Danach wird die ausgewählte virtuelle Maschine hinzugefügt und das Sicherungsziel festgelegt.

Mit Set-WBVssBackupOption wird eine VSS-Kopiesicherung eingestellt. Start-WBBackup startet dann den eigentlichen Sicherungsvorgang.

Das Skript legt keinen dauerhaften Sicherungszeitplan an. Es eignet sich also für manuelle Sicherungen und kann bei Bedarf in einen eigenen Automatisierungsablauf eingebaut werden.

Auch hier muss E: ein geeignetes Sicherungsziel sein. Der erforderliche Speicherplatz und mögliche Auswirkungen auf bereits vorhandene Sicherungen müssen vor der Ausführung überprüft werden.

7. Mehrere Hyper-V-VMs mit PowerShell sichern

Wenn Du mehrere virtuelle Maschinen gemeinsam sichern möchtest, kannst Du diese über eine Liste von VM-Namen auswählen.

Das folgende Beispiel sichert SRV-FILE01 und SRV-APP01 auf Laufwerk E:.

Import-Module WindowsServerBackup -ErrorAction Stop

$policy = New-WBPolicy

$vmNames = @("SRV-FILE01", "SRV-APP01")

$vms = @(Get-WBVirtualMachine | Where-Object {
    $_.VMName -in $vmNames
})

$foundNames = @($vms | Select-Object -ExpandProperty VMName -Unique)

if ($foundNames.Count -ne $vmNames.Count) {
    throw "Nicht alle angegebenen VMs wurden gefunden."
}

Add-WBVirtualMachine -Policy $policy -VirtualMachine $vms

$target = New-WBBackupTarget -VolumePath "E:"

Add-WBBackupTarget -Policy $policy -Target $target

Set-WBVssBackupOption -Policy $policy -VssCopyBackup

Start-WBBackup -Policy $policy

Über die Variable $vmNames kannst Du die gewünschten virtuellen Maschinen festlegen. Das Skript überprüft vor dem Sicherungsstart, ob alle angegebenen VM-Namen gefunden wurden.

Damit verhinderst Du, dass eine Sicherung mit unvollständiger VM-Auswahl gestartet wird, nur weil ein virtueller Computer umbenannt oder entfernt wurde.

8. Hyper-V-VM mit PowerShell auf eine Netzwerkfreigabe sichern

Auch eine Netzwerkfreigabe kannst Du mit PowerShell als Sicherungsziel verwenden. Das folgende Beispiel sichert die virtuelle Maschine SRV-FILE01 auf \\BACKUP01\HyperV\HV01.

Import-Module WindowsServerBackup -ErrorAction Stop

$policy = New-WBPolicy

$vm = @(Get-WBVirtualMachine | Where-Object {
    $_.VMName -eq "SRV-FILE01"
})

if ($vm.Count -ne 1) {
    throw "Die VM SRV-FILE01 wurde nicht eindeutig gefunden."
}

Add-WBVirtualMachine -Policy $policy -VirtualMachine $vm

$cred = Get-Credential

$target = New-WBBackupTarget `
    -NetworkPath "\\BACKUP01\HyperV\HV01" `
    -Credential $cred

Add-WBBackupTarget -Policy $policy -Target $target

Set-WBVssBackupOption -Policy $policy -VssCopyBackup

Start-WBBackup -Policy $policy

Über Get-Credential erscheint eine sichere Eingabe für Benutzername und Kennwort. Dadurch musst Du keine Anmeldedaten im Klartext in Deinem Skript hinterlegen.

Auch bei dieser Variante muss das Sicherungsziel erreichbar sein. Außerdem solltest Du im Blick haben, dass wiederholte Sicherungen desselben Servers in denselben Netzwerkordner vorhandene Sicherungsstände überschreiben können.

9. Sicherungsstatus mit WBADMIN und PowerShell überprüfen

Nach einer Sicherung kannst Du den aktuellen Status eines laufenden WBADMIN-Auftrags anzeigen lassen.

wbadmin get status

Unter PowerShell steht Dir für Windows Server Backup folgender Befehl zur Verfügung:

Get-WBJob

Den zuletzt ausgeführten Sicherungsauftrag kannst Du mit diesem PowerShell-Befehl abfragen:

Get-WBJob -Previous 1

Wenn Du überprüfen möchtest, welche Sicherungsstände auf dem lokalen Laufwerk E: vorhanden sind, kannst Du folgenden WBADMIN-Befehl verwenden:

wbadmin get versions -backupTarget:E:

Für Sicherungen auf der Netzwerkfreigabe kannst Du zusätzlich den ursprünglichen Computernamen angeben:

wbadmin get versions -backupTarget:\\BACKUP01\HyperV\HV01 -machine:HV01

Dass eine Sicherung erfolgreich durchläuft, ist ein wichtiger erster Schritt. Es beweist aber noch nicht, dass sich die virtuelle Maschine auch vollständig wiederherstellen lässt. Gerade bei produktiven Anwendungen solltest Du deshalb regelmäßig eine Wiederherstellung in einer isolierten Testumgebung durchführen.

VSS Copy oder VSS Full: Welche Einstellung ist richtig?

Die VSS-Auswahl regelt, wie die Sicherung gegenüber beteiligten Anwendungen behandelt wird. Sie ist kein einfacher Umschalter zwischen einer vollständigen und einer inkrementellen Datenübertragung.

• -vssCopy: Die Kopiesicherung erhält die Sicherungsinformationen und Anwendungsprotokolle, auf die andere Sicherungsverfahren angewiesen sein können. Sie eignet sich daher häufig für ein ergänzendes Backup neben einer vorhandenen Lösung.
• -vssFull: Die vollständige VSS-Sicherung kann bei beteiligten Anwendungen eine Anpassung des Sicherungsverlaufs oder das Kürzen von Protokollen auslösen. Diese Wahl muss zur vorgesehenen Sicherungsstrategie der Anwendung passen.

VSS Copy heißt nicht, dass ohne VSS oder ganz ohne Anwendungskonsistenz gesichert wird. Umgekehrt garantiert VSS Full keine fehlerfreie Datenbankwiederherstellung. Sichert bereits eine andere Software Anwendungs- oder Transaktionsprotokolle, sollten die Verfahren aufeinander abgestimmt sein.

Automatische Sicherungen und Aufbewahrung richtig planen

Nach dem ersten erfolgreichen Test kannst Du über „Sicherungszeitplan“ einen wiederkehrenden Auftrag einrichten. WSB unterstützt tägliche Sicherungen auch zu mehreren Uhrzeiten. Ein engerer Abstand ist allerdings nur sinnvoll, wenn Sicherungsdauer, Änderungsmenge und verfügbare Leistung dazu passen.

Warum dieselbe Netzwerkfreigabe keine verlässliche Historie ergibt

Sicherst du denselben Server erneut in denselben Netzwerkzielordner, wird der vorherige Sicherungsstand dort überschrieben. Scheitert der Folgelauf, kann damit auch der bis dahin brauchbare Stand verloren sein. Der Parameter -vssCopy verhindert das nicht.

Getrennte Zielordner oder eine passende Rotation können mehrere Stände erhalten. Dafür brauchst du aber eine eigene Regelung für Speicherbedarf, Bereinigung und Wiederherstellbarkeit. Auch auf lokalen Sicherungsdatenträgern ist die Zahl der verfügbaren Versionen nicht unbegrenzt. Die Aufbewahrungsdauer, die du brauchst, muss sich mit der tatsächlich vorhandenen Historie decken.

Überwachung gehört zum Sicherungsauftrag

Ein angelegter Zeitplan beweist noch nicht, dass jede Sicherung erfolgreich abgeschlossen wurde. Neben Fehlermeldungen solltest Du auch ausgebliebene Läufe, ungewöhnliche Dauer und einen zu alten letzten erfolgreichen Sicherungsstand erkennen. Mehrere Sicherungsprodukte sollten ihre VSS-Aktivitäten nicht unkoordiniert gleichzeitig ausführen.

Für eine genauere Auswertung kannst Du die Windows-Ereignisanzeige mit PowerShell auslesen. Relevant sind insbesondere Meldungen zur Sicherung, zu Hyper-V, VSS und zum Speicher. Bei Anwendungsfehlern gehören auch die zeitlich passenden Meldungen aus dem Gast dazu.

Hyper-V-VM mit Windows Server Backup wiederherstellen

Der aussagekräftigste Test ist die Wiederherstellung auf einem getrennten Hyper-V-Testhost. Dort sollte keine VM mit derselben Kennung vorhanden sein. Ein anderer Zielordner allein erzeugt weder eine neue VM-Identität noch ein isoliertes Netzwerk. Eine Wiederherstellung an den ursprünglichen Ort kann die vorhandene VM ersetzen und neuere Daten verwerfen.

1. Sicherungsstand und enthaltene VM ermitteln

Die verfügbaren Sicherungsstände kannst Du mit wbadmin get versions anzeigen. Im Beispiel stammen die Sicherungen vom Host HV01 und liegen auf E:.

wbadmin get versions -backupTarget:E: -machine:HV01

Danach lässt Du die Elemente des gewünschten Stands auflisten. Die Versionskennung im folgenden Befehl ist nur ein Beispiel. Du übernimmst die tatsächliche Kennung unverändert aus Deiner Ausgabe, einschließlich Datumsformat und Uhrzeit.

wbadmin get items -version:10/26/2026-20:00 -backupTarget:E: -machine:HV01

Entscheidend ist die VM im ausgewählten Backup. Eine zwischenzeitlich neu angelegte Maschine mit demselben Anzeigenamen kann eine andere Kennung besitzen. Für die Auswahl reicht der Name des heute laufenden Servers deshalb nicht immer aus.

2. Zielhost und isolierte Testumgebung vorbereiten

Der Zielhost muss die Konfigurationsversion der gesicherten VM unterstützen und genügend Speicher sowie Arbeitsspeicher bereitstellen. Für einen abweichenden Host helfen die Hinweise zu unterstützten Hyper-V-Konfigurationsversionen. Die Bezeichnung des Gastbetriebssystems allein beantwortet diese Kompatibilitätsfrage nicht.

Vor dem ersten Start der wiederhergestellten VM trennst Du ihre Netzwerkadapter vom produktiven Netz. Alternativ kommt ein korrekt isolierter privater virtueller Switch infrage. Das verhindert Konflikte durch identische IP-Adressen, Computernamen oder gleichzeitig aktive Serverrollen. Die Zusammenhänge zwischen Speicherpfaden und virtuellen Switches erläutert auch der Beitrag zum Verschieben einer Hyper-V-VM auf ein anderes Laufwerk oder einen anderen Host.

3. VM über die Windows Server-Sicherung zurückholen

1. Auf dem vorgesehenen Wiederherstellungshost startest Du die Windows Server-Sicherung und wählst „Wiederherstellen“.
2. Für ein Backup eines anderen Hosts verwendest Du die Auswahl für einen anderen Server und gibst den tatsächlichen Sicherungsort an.
3. Nach der Auswahl von Datum und Uhrzeit folgt der Wiederherstellungstyp „Hyper-V“.
4. Du wählst die benötigte VM und einen geeigneten Wiederherstellungsort aus.
5. Vor dem Start vergleichst Du Quellhost, Sicherungsdatum, VM und Zielpfad mit Deinem Wiederherstellungsplan.
6. Nach der Wiederherstellung überprüfst Du Netzwerkanbindung und VM-Einstellungen, bevor Du den Gast startest.

Für PowerShell-Abläufe gibt es im Modul WindowsServerBackup auch Start-WBHyperVRecovery. Der Befehl braucht das ausgewählte Sicherungsobjekt und die darin enthaltene VM. Für produktive Wiederherstellungen taugt es nicht, einfach das erste gefundene Backup oder die erste VM zu nehmen.

4. Betriebssystem, Anwendung und Daten prüfen

Nach dem Start kontrollierst Du nicht nur die Anmeldung am Betriebssystem. Zum Test gehören die benötigten Dienste, Anwendungszugriffe, bekannte Datenbestände und die jeweiligen Integritätsprüfungen. Bei Datenbanken reicht es beispielsweise nicht, dass der Datenbankdienst läuft.

Aus der Administratorpraxis: Für einen aussagekräftigen Test erfasst Du die Zeit bis zur tatsächlich wieder verfügbaren Funktion. Zum Vergleich mit Deinem RTO gehören auch die Erkennung des Problems, die Entscheidung über die Wiederherstellung und die Vorbereitung der Umgebung. Ein vollständig kopierter virtueller Datenträger ist deshalb noch nicht der Endpunkt.

Einzelne Dateien aus einer VM-Sicherung wiederherstellen

Die Hyper-V-Wiederherstellung von WSB stellt eine VM wieder her. Sie bietet keinen komfortablen Browser für einzelne Dateien oder Anwendungsobjekte innerhalb des Gasts. Für einzelne Dokumente kannst Du eine isoliert wiederhergestellte VM verwenden oder mit einer separat wiederhergestellten Kopie ihrer virtuellen Festplatte arbeiten.

Beim Einbinden einer VHD- oder VHDX-Datei ist für reine Datenentnahme möglichst schreibgeschützter Zugriff sinnvoll. Dabei muss eine vorhandene Differenzdatenträgerkette vollständig und konsistent sein. Aktive Produktivdatenträger und die einzige vorhandene Sicherung sind keine Arbeitskopien. Datenbanken sollten über ihr geeignetes Wiederherstellungsverfahren zurückgeholt werden.

Was gilt nach dem vollständigen Ausfall des Hosts?

Eine VM-Sicherung und eine Bare-Metal-Wiederherstellung des Hosts erfüllen unterschiedliche Aufgaben. -allCritical umfasst die für die Systemwiederherstellung kritischen Volumes. Zusätzliche Volumes mit VM-Daten sind damit nicht automatisch vollständig abgesichert.

Für einen vollständigen Wiederanlauf brauchst du deshalb entweder einen neu eingerichteten Hyper-V-Host oder eine passende Hostwiederherstellung, danach die nötigen VM-Sicherungen. Bei einem BMR-Verfahren kann zusätzlich ein Hyper-V-Restore erforderlich sein. Welche VM-Volumes dafür gebraucht werden und wie der Ablauf aussieht, muss schon vor dem Ausfall feststehen.

Windows Server Backup und professionelle Hyper-V-Backups im Vergleich

Für die Entscheidung zählt, welche Wiederherstellung Du im Ernstfall leisten musst. Eine einzelne Test-VM stellt andere Anforderungen als ein produktiver Cluster mit Datenbanken und kurzen Ausfallzeiten. Die folgende Tabelle zeigt typische Unterschiede. Der Funktionsumfang spezialisierter Lösungen hängt jeweils von Version, Edition, Anwendung und Speicherziel ab.

Anforderung	Windows Server Backup	Spezialisierte VM-Backup-Lösung
Verwaltung	Grundlegende Sicherung pro Server mit begrenzter zentraler Steuerung.	Zentrale Aufträge, Übersichten und Richtlinien für mehrere Hosts sind typische Funktionen.
Anwendungskonsistenz	Abhängig von VSS, Gast und Speicheraufbau.	Zusätzliche Anwendungsverarbeitung möglich. Deren Erfolg muss ebenfalls geprüft werden.
Granulare Wiederherstellung	VM-Restore; Dateien aus dem Gast erfordern zusätzliche Arbeitsschritte.	Direkter Datei- oder Anwendungsobjekt-Restore für unterstützte Systeme möglich.
Aufbewahrung	Zielabhängige Versionierung und eigene Planung erforderlich.	Mehrstufige Aufbewahrung und zusätzliche Sicherungskopien lassen sich meist gezielter verwalten.
Schneller Wiederanlauf	Kein integrierter Instant-Recovery-Workflow für VMs.	Je nach Produkt kann eine VM zunächst direkt aus Sicherungsdaten gestartet werden.
Schutz vor Veränderung	Keine eigene WORM-Aufbewahrung. Zusätzlicher Schutz muss separat eingerichtet werden.	Unveränderbare Ablage ist mit geeigneten und korrekt eingerichteten Speicherzielen möglich.
Kontrolle	Protokolle und Wiederherstellungstests müssen in den eigenen Betrieb eingebunden werden.	Benachrichtigungen und automatisierte Prüfungen können Teil des Produkts sein.

Die wichtige Grenze bei Hyper-V-Clustern und CSV

Windows Server Backup unterstützt bei Cluster Shared Volumes nur absturzkonsistente Sicherungen auf Volume-Ebene. Eine anwendungskonsistente Sicherung der dort gespeicherten VMs bietet dieser Weg nicht. Ein entsprechender Fehlerhinweis kann sogar erscheinen, obwohl der Sicherungsvorgang abgeschlossen wurde. Diese Grenze bei der Sicherung von Cluster Shared Volumes ist für produktive Cluster entscheidend.

Bei VMs auf SMB-Freigaben, ReFS-Speicheraufbauten, gemeinsam verwendeten virtuellen Datenträgern oder abgeschirmten VMs brauchst Du ebenfalls eine Prüfung des konkreten Sicherungs- und Wiederherstellungswegs. Eine funktionierende Konfiguration auf einem lokalen NTFS-Einzelhost belegt dafür keine allgemeine Unterstützung.

Welche Alternativen kommen infrage?

Zu den möglichen Kandidaten gehören Veeam Backup & Replication, Hornetsecurity VM Backup und NAKIVO Backup & Replication. Sie bieten spezialisierte Sicherungs- und Wiederherstellungsfunktionen für virtuelle Umgebungen. Die Auswahl allein nach Produktname oder einer Liste von Zusatzfunktionen wäre trotzdem zu kurz gedacht.

Für einen belastbaren Vergleich testest du mit einer repräsentativen VM mindestens die Sicherung, einen vollständigen Restore und den Datei- oder Anwendungs-Restore, den du tatsächlich brauchst. Dazu kommen das Verhalten bei fehlgeschlagener Anwendungsverarbeitung und die Frage, wer Sicherungen löschen darf. Eine kurze Startzeit im Test ersetzt nicht die Prüfung aller Abhängigkeiten einer produktiven Anwendung.

Prüfpunkte, Export und Replikation richtig einordnen

Ein Hyper-V-Prüfpunkt hält einen Zustand innerhalb der VM-Speicherstruktur fest. Er bietet allein keine unabhängige Sicherungskopie gegen den Ausfall oder Verlust dieser Ablage. Auch ein Produktionsprüfpunkt ändert daran nichts.

Der Export und Import einer Hyper-V-VM ist beispielsweise für den Transfer einer Maschine hilfreich. Ein Export organisiert aber nicht von sich aus überwachte Sicherungsläufe, geschützte Aufbewahrung und regelmäßige Wiederherstellungstests. Replikation wiederum verbessert die Verfügbarkeit, kann jedoch unerwünschte Änderungen ebenfalls übertragen. Diese Verfahren erfüllen unterschiedliche Aufgaben innerhalb eines Wiederherstellungskonzepts.

Sicherungen gegen Verlust und Verschlüsselungstrojaner schützen

Ein dauerhaft beschreibbares Backupziel kann zusammen mit dem Host beschädigt, gelöscht oder verschlüsselt werden. Deshalb sollte mindestens eine weitere Kopie unabhängig geschützt sein. Eine praktikable Orientierung ist das 3-2-1-Prinzip: drei Datenkopien insgesamt, zwei unterschiedliche Medien oder Speichersysteme und eine Kopie außerhalb des Standorts. Eine offline aufbewahrte oder tatsächlich unveränderbare Kopie ergänzt diesen Schutz.

Verschlüsselung und Unveränderbarkeit lösen unterschiedliche Probleme. BitLocker kann Daten auf einem verlorenen Datenträger schützen, ein verbundenes und entsperrtes Ziel ist dadurch aber nicht automatisch vor Löschzugriffen sicher. Bei unveränderbaren Speicherzielen müssen Sperrfristen und Verwaltungsrechte so eingerichtet sein, dass ein kompromittiertes Sicherungskonto die Kopie nicht einfach entfernen kann.

Zum Wiederherstellungsplan gehören auch benötigte Schlüssel. Hinweise zum Finden und sicheren Aufbewahren von BitLocker-Wiederherstellungsschlüsseln helfen bei der Vorbereitung. Bei virtuellen TPMs und besonders geschützten VMs können zusätzliche Schutzinformationen erforderlich sein. Eine reine Kopie der virtuellen Festplatte reicht dann unter Umständen nicht.

Typische Fehler bei Windows Server Backup und Hyper-V

Problem	Sinnvolle Prüfung
VSS-Fehler oder abgebrochene Sicherung	Writer-Zustand, passende Ereignisse auf Host und Gast, freien Speicher und gleichzeitig laufende Sicherungsaufträge betrachten.
VM wird während der Sicherung gespeichert	Gastunterstützung, Sicherungsintegration und Gastdatenträger überprüfen. Dynamische Gastdatenträger sind nicht dasselbe wie dynamisch wachsende VHDX-Dateien.
Backupziel ist nicht erreichbar	UNC-Pfad, Namensauflösung, Berechtigungen und Ausführungskonto des geplanten Auftrags vergleichen.
Nach dem Restore fehlen Daten	Enthaltene virtuelle Festplatten, zusätzliche Datenvolumes sowie direkt im Gast angebundenen Speicher überprüfen.
Wiederhergestellte VM startet nicht	Konfigurationsversion, Datenträgerpfade, vollständige Datenträgerkette und benötigte Schutzinformationen berücksichtigen.
Ältere Sicherungsstände fehlen	Netzwerkziel, Rotation, freien Speicher und die tatsächlich verfügbaren Versionen prüfen.

Bei einem Zugriffsproblem wie Fehler 0x80070005 ist der konkrete Rechtekontext entscheidend. Eine interaktive Anmeldung mit funktionierendem Zugriff beweist noch nicht, dass der geplante Auftrag unter seinem Ausführungskonto dieselben Möglichkeiten besitzt.

Bleiben nach einer Sicherung Prüfpunkt- oder AVHDX-Dateien zurück, sollten diese niemals einfach im Explorer gelöscht werden. Der sichere Weg führt über die Verwaltung der VM und die Klärung der zugehörigen Sicherungsaufträge. Der Beitrag zum Löschen von Hyper-V-Prüfpunkten per PowerShell erläutert das reguläre Vorgehen. Auch Dienstneustarts auf einem produktiven Host gehören in einen abgestimmten Ablauf.

FAQ: Häufige Fragen zu Windows Server Backup und Hyper-V

Fazit: Windows Server Backup bewusst einsetzen

Windows Server Backup kann Hyper-V-VMs auf einem überschaubaren Einzelhost sinnvoll absichern. Seine Stärke ist eine vorhandene Grundfunktion mit grafischer Bedienung und Automatisierung über wbadmin. Im produktiven Einsatz zählen aber vor allem die nachgewiesene Wiederherstellbarkeit und die Grenzen der jeweiligen Umgebung.

Musst du mehrere Hosts, Cluster, kurze Ausfallzeiten oder granulare Anwendungs-Restores abdecken, lohnt sich der Vergleich mit einer spezialisierten Lösung. Unabhängig vom Werkzeug ist dein Konzept erst belastbar, wenn Sicherungsumfang, Anwendungskonsistenz, getrennte Kopien und ein erfolgreich getesteter Restore zusammenpassen.