10
HYPER-V-II-Backup mit VEEAM, unglaubliche Deduplizierung, kann das stimmen?
Hallo,
ich setze seit kurzem VEEAM Enterprise 6.5 zum Backup meines HYPER-V-II-Servers (W2K8R2) ein.
Sicherungsziel ist ein Celvin-NAS von Fujitsu (Fujitsu Celvin Q800, das sind umgelabelte QNAPs). Das ganze findet in einem Gigabit-Netzwerk statt.
Auf dem HYPER-V laufen insgesamt 7 virtuelle Maschinen, 4 davon sind W2K8R2-Enterprise-Server, außerdem 2 x W2K3R2-Server und 1 x Vista Business-Workstation. Diese Maschinen allokieren auf dem HYPER-V-Host insgesamt 1,2 Terabyte an Speicherplatz, gleichwohl der Platz höchstens zur Hälfte gefüllt ist (innerhalb der virtuellen Maschinen). Bleiben also ca. 600 Gigabyte an zu sichernden Daten.
Bei den Optionen des Backup-Jobs habe ich eingestellt, daß Deduplizierung verwendet werden soll, und habe dabei die empfohlene Deduplizierungs-"Stärke" bei Sicherung auf ein NAS verwendet.
Nun fällt mir bei den Sicherungsergebnissen auf, daß der gesamte Job für alle virtuellen Maschinen gerade einmal ca. 300 GB "frißt" (wohlgemerkt beim Full-Backup). Wenn das an der Deduplizierung liegen sollte, würde das bedeuten, daß die Deduplizierung die zu sichernden Daten ca. um die Hälfte "eindampft".
Frage:
Kann das wirklich sein?
Nachem hier allein 4 Server alle gleichen Typs sind (also W2K8R2 Enterprise m. SP1 und allen aktuellen Patches), gibt es da sicherlich recht viel zu deduplizieren, jedoch gleich um die Hälfte?
Um sicherzugehen, daß das Ganze auch nach einem Restore wieder läuft, habe ich eine der Maschinen an anderem Ort wiederhergestellt und dort ohne Netzwerkverbindung gestartet, das hat funktioniert (logischerweise bis auf ein paar Dienstefehler wegen fehlendem Netzwerk), das Backup ist also scheinbar in Ordnung.
Ist Deduplizierung tatsächlich solch eine Wunderwaffe (wenn's um Speicherplatz geht)? Oder sehe ich da was falsch und meine Backups (hab' jetzt natürlich nicht alle mögl. Restores ausprobieren können) sind vielleicht doch untauglich?
Grüße
von
departure
ich setze seit kurzem VEEAM Enterprise 6.5 zum Backup meines HYPER-V-II-Servers (W2K8R2) ein.
Sicherungsziel ist ein Celvin-NAS von Fujitsu (Fujitsu Celvin Q800, das sind umgelabelte QNAPs). Das ganze findet in einem Gigabit-Netzwerk statt.
Auf dem HYPER-V laufen insgesamt 7 virtuelle Maschinen, 4 davon sind W2K8R2-Enterprise-Server, außerdem 2 x W2K3R2-Server und 1 x Vista Business-Workstation. Diese Maschinen allokieren auf dem HYPER-V-Host insgesamt 1,2 Terabyte an Speicherplatz, gleichwohl der Platz höchstens zur Hälfte gefüllt ist (innerhalb der virtuellen Maschinen). Bleiben also ca. 600 Gigabyte an zu sichernden Daten.
Bei den Optionen des Backup-Jobs habe ich eingestellt, daß Deduplizierung verwendet werden soll, und habe dabei die empfohlene Deduplizierungs-"Stärke" bei Sicherung auf ein NAS verwendet.
Nun fällt mir bei den Sicherungsergebnissen auf, daß der gesamte Job für alle virtuellen Maschinen gerade einmal ca. 300 GB "frißt" (wohlgemerkt beim Full-Backup). Wenn das an der Deduplizierung liegen sollte, würde das bedeuten, daß die Deduplizierung die zu sichernden Daten ca. um die Hälfte "eindampft".
Frage:
Kann das wirklich sein?
Nachem hier allein 4 Server alle gleichen Typs sind (also W2K8R2 Enterprise m. SP1 und allen aktuellen Patches), gibt es da sicherlich recht viel zu deduplizieren, jedoch gleich um die Hälfte?
Um sicherzugehen, daß das Ganze auch nach einem Restore wieder läuft, habe ich eine der Maschinen an anderem Ort wiederhergestellt und dort ohne Netzwerkverbindung gestartet, das hat funktioniert (logischerweise bis auf ein paar Dienstefehler wegen fehlendem Netzwerk), das Backup ist also scheinbar in Ordnung.
Ist Deduplizierung tatsächlich solch eine Wunderwaffe (wenn's um Speicherplatz geht)? Oder sehe ich da was falsch und meine Backups (hab' jetzt natürlich nicht alle mögl. Restores ausprobieren können) sind vielleicht doch untauglich?
Grüße
von
departure
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 202803
Url: https://administrator.de/forum/hyper-v-ii-backup-mit-veeam-unglaubliche-deduplizierung-kann-das-stimmen-202803.html
Ausgedruckt am: 21.12.2024 um 05:12 Uhr
10 Kommentare
Neuester Kommentar
Moin,
ich teste das auch gerade für HyperV und bin bisher schwer begeistert. Momentan setzen wir noch Acronis Backup & Recovery ein, aber da der Support da grottig und das Produkt mittlerweile nicht mehr wirklich zu gebrauchen ist, bin ich auf Veeam gekommen.
Vom Funktionsumfang sind die Acronis Lichtjahre voraus, meine bescheidene Meinung.
Zu Deiner Frage: Das kann schon gut sein, weil allein schon die OS-Installation viel Platz braucht und der in den allermeisten Fällen mit denselben Informationen gefüllt ist, es unterscheiden sich nur Registry-Einträge, Konfigurationsdateien und ähnliches. Und wenn die Rücksicherung funktioniert, was gibt's da noch zu zweifeln?
Wie hast Du die VMs angebunden? iSCSI? Onhost- oder Offhost-Backup?
ich teste das auch gerade für HyperV und bin bisher schwer begeistert. Momentan setzen wir noch Acronis Backup & Recovery ein, aber da der Support da grottig und das Produkt mittlerweile nicht mehr wirklich zu gebrauchen ist, bin ich auf Veeam gekommen.
Vom Funktionsumfang sind die Acronis Lichtjahre voraus, meine bescheidene Meinung.
Zu Deiner Frage: Das kann schon gut sein, weil allein schon die OS-Installation viel Platz braucht und der in den allermeisten Fällen mit denselben Informationen gefüllt ist, es unterscheiden sich nur Registry-Einträge, Konfigurationsdateien und ähnliches. Und wenn die Rücksicherung funktioniert, was gibt's da noch zu zweifeln?
Wie hast Du die VMs angebunden? iSCSI? Onhost- oder Offhost-Backup?
Dein Kommentar beruhigt mich jetzt schonmal, danke.
Meine VM's laufen auf dem HYPER-V-HOST lokal (!), allerdings in einem flinken RAID5-Array aus 4 schnellen 15k-SAS-Platten, da ist Gigabit-iSCSI auch nicht unbedingt schneller. Hab' keine Performanceprobleme, die virtuellen Maschinen laufen superschnell, habe allerdings auch jeder eine eigene NIC gegeben (wie es Microsoft unter HYPER-V übrigens auch empfiehlt).
Was meinst Du mit Onhost- oder Offhost-Backup? Sollten mir diese Begriffe bei der Einrichtung von VEEAM begegnet sein?
Grüße
von
departure
Meine VM's laufen auf dem HYPER-V-HOST lokal (!), allerdings in einem flinken RAID5-Array aus 4 schnellen 15k-SAS-Platten, da ist Gigabit-iSCSI auch nicht unbedingt schneller. Hab' keine Performanceprobleme, die virtuellen Maschinen laufen superschnell, habe allerdings auch jeder eine eigene NIC gegeben (wie es Microsoft unter HYPER-V übrigens auch empfiehlt).
Was meinst Du mit Onhost- oder Offhost-Backup? Sollten mir diese Begriffe bei der Einrichtung von VEEAM begegnet sein?
Grüße
von
departure
Wie viele VMs hast Du denn da laufen? Also bei mir wirds mit 9 VMs lokal eng, läuft noch, aber nicht mehr superflott. Ist ein HP ProLiant ML370 G5 mit 40GB, die VMs brauchen allerdings teils auch recht viel RAM (Datev mit 16GB...). Gut, der Server ist jetzt auch schon 4 Jahre alt, auf dem iSCSI rennt das ganz gut.
Onhost-Backup heißt, dass Du alle Veeam Komponenten direkt auf dem HyperV Host installierst, mit Offhost sind die Backup Komponenten verteilt, also Verwaltungskonsole und Backup Proxy. Mich würde die Systemlast interessieren, die ein Onhost-Backup mit 9 VMs erzeugt (werde ich heute abend erleben). Wenn Du also ordentlich evaluiert hast, sollte Dir das ein Begriff sein
Onhost-Backup heißt, dass Du alle Veeam Komponenten direkt auf dem HyperV Host installierst, mit Offhost sind die Backup Komponenten verteilt, also Verwaltungskonsole und Backup Proxy. Mich würde die Systemlast interessieren, die ein Onhost-Backup mit 9 VMs erzeugt (werde ich heute abend erleben
). Wenn Du also ordentlich evaluiert hast, sollte Dir das ein Begriff sein
Hab' die genannten 7 VMs, der Server ist ein halbes Jahr alt (Fujitsu Primergy TX300S7), 2 SAS-Platten im RAID 1 für's System, 4 SAS-Platten im RAID5 für die VMs. Der Server hat 64 GB RAM, die virtuellen Maschinen jeweils zwischen 4 und 8 GB.
Nach Deiner Erklärung habe ich scheinbar ein Offhost-Backup konfiguriert, habe VEEAM auf meinem BACKUP-Exec-Server installiert und den HYPER-V dort eingehängt. Repository (Backup-Ziel) ist das beschriebene NAS, Restore entweder am Originalort (also dem HYPER-V-Server) oder lokal auf dem BE-Server. Backup-Exec und VEEAM kommen sich übrigens nicht in die Quere, sie laufen zu unterschiedlichen Zeiten (Bänder per BE ab 18.00 Uhr bis max. Mitternacht, VEEAM ab 01.00 Uhr früh bis längstens 4.30 Uhr morgens). Ich komme mit den Jobs zeitlich gut durch, bei den genannten Zeiträumen ist noch Luft.
Zum Thema Systemlast:
Beim Restore kann ich entweder nur auf den Originalhost zurücksichern (was im Testszenario natürlich nicht gewollt ist), oder auf den lokalen Server, wo VEEAM installiert ist (die lokalen Platten haben dafür noch genügend Platz).
Problem: Wenn ich lokal zurücksichere, kriege ich eine schier unglaubliche Festplattenlast (zwei 7200k-S-ATA-Platten im RAID1). CPU und Speicher haben einigermaßen Langeweile, aber die Festplatten kleben im Ressourcenmonitor an der Decke, solange der Restore läuft. Der Server "bewegt" sich in der Zeit gar nicht mehr, selbst ein Verzeichnis zu öffnen, ist in dieser Zeit ein Geduldsspiel von mehreren Minuten. Der Restore läuft aber einwandfrei, man muß den Server in der Zeit halt nur "in Ruhe lassen".
Weißt Du, woran das liegen könnte (also die hohe Datenträgerlast)? Die Daten werden beim Restore ja max. mit Gigabit-Netzwerkgeschwindigkeit (also etwa mit 110-112 MB/s) aus dem NAS geholt, und das können die lokalen Platten eigentlich locker wegschreiben (HDTune sagt, daß das RAID 1 ca. 160 MB/s schreiben kann).
Grüße
von
departure
Nach Deiner Erklärung habe ich scheinbar ein Offhost-Backup konfiguriert, habe VEEAM auf meinem BACKUP-Exec-Server installiert und den HYPER-V dort eingehängt. Repository (Backup-Ziel) ist das beschriebene NAS, Restore entweder am Originalort (also dem HYPER-V-Server) oder lokal auf dem BE-Server. Backup-Exec und VEEAM kommen sich übrigens nicht in die Quere, sie laufen zu unterschiedlichen Zeiten (Bänder per BE ab 18.00 Uhr bis max. Mitternacht, VEEAM ab 01.00 Uhr früh bis längstens 4.30 Uhr morgens). Ich komme mit den Jobs zeitlich gut durch, bei den genannten Zeiträumen ist noch Luft.
Zum Thema Systemlast:
Beim Restore kann ich entweder nur auf den Originalhost zurücksichern (was im Testszenario natürlich nicht gewollt ist), oder auf den lokalen Server, wo VEEAM installiert ist (die lokalen Platten haben dafür noch genügend Platz).
Problem: Wenn ich lokal zurücksichere, kriege ich eine schier unglaubliche Festplattenlast (zwei 7200k-S-ATA-Platten im RAID1). CPU und Speicher haben einigermaßen Langeweile, aber die Festplatten kleben im Ressourcenmonitor an der Decke, solange der Restore läuft. Der Server "bewegt" sich in der Zeit gar nicht mehr, selbst ein Verzeichnis zu öffnen, ist in dieser Zeit ein Geduldsspiel von mehreren Minuten. Der Restore läuft aber einwandfrei, man muß den Server in der Zeit halt nur "in Ruhe lassen".
Weißt Du, woran das liegen könnte (also die hohe Datenträgerlast)? Die Daten werden beim Restore ja max. mit Gigabit-Netzwerkgeschwindigkeit (also etwa mit 110-112 MB/s) aus dem NAS geholt, und das können die lokalen Platten eigentlich locker wegschreiben (HDTune sagt, daß das RAID 1 ca. 160 MB/s schreiben kann).
Grüße
von
departure
Also das erste, was der Veeam Support dazu sagen würde: Runter mit Backup Exec. Das die sich nach Zeitplan nicht in die Quere kommen, heißt erst mal gar nix, weil jede Datensicherung evtl. eigene Treiber installiert, Zugriff auf die VSS-Writer hat usw... Acronis habe ich auf meinem Testsystem jedenfalls brav runtergeworfen.
Was sagt denn die Netzwerkauslaustung während des Restore? Alternativ kannst Du die VM ja auch ohne Rücksicherung direkt aus der Backupdatei laufen lassen, weiß allerdings nicht, wie perfomant das bei der NAS-Anbindung laufen wird. Hast Du einen Backup-Proxy installiert oder wo läuft dieser Dienst? Verursacht ja aber laut Handbuch eher CPU-Last.
Was sagt denn die Netzwerkauslaustung während des Restore? Alternativ kannst Du die VM ja auch ohne Rücksicherung direkt aus der Backupdatei laufen lassen, weiß allerdings nicht, wie perfomant das bei der NAS-Anbindung laufen wird. Hast Du einen Backup-Proxy installiert oder wo läuft dieser Dienst? Verursacht ja aber laut Handbuch eher CPU-Last.
Danke für Deine Antwort.
ich denke nicht, daß sich VEEAM und BE stören. Die Zugriffe auf alles, was mit VSS zu tun hat, sind ja seit dem W2K3 durch Microsoft standardisiert, BE kann da nicht anders zugreifen als es VEEAM tut. Beide benutzen brav die gleiche (von BE installierte) Datenbank (MSSQL 2008R2 Express), natürlich jeder in einer eigenen Instanz. Die einzigen Treiber, die hier mit im Boot sind, sind die von BE mitgelieferten Tapedriver, mit denen VEEAM aber nichts zu tun hat.
Zumindest glaube ich nicht, daß das gleichzeitige Vorhandsein von VEEAM und BE meine Probleme mit der Datenträgerlast beim VEEAM-Restore verursacht.
Natürlich habe ich während des Restore im Ressourcenmonitor auch die Netzwerklast angesehen( so gut es ging, auch das Wechseln der Registerkarten hat Minuten gedauert), demnach war an der Netzwerkschnittstelle nur wenig mehr als "Grundrauschen" los.
Als Backup-Proxy ist nichts explizit eingerichtet, den Dienst gibt's natürlich dennoch, er läuft (wo auch sonst) auf dem Server, wo VEEAM installiert ist.
Zitat: "Alternativ kannst Du die VM ja auch ohne Rücksicherung direkt aus der Backupdatei laufen lassen ..." - wie soll das gehen? Bräuchte ich dazu nicht einen weiteren (oder anderen) HYPER-V-Host? oder was verstehe ich da jetzt nicht?
Grüße
von
departure
ich denke nicht, daß sich VEEAM und BE stören. Die Zugriffe auf alles, was mit VSS zu tun hat, sind ja seit dem W2K3 durch Microsoft standardisiert, BE kann da nicht anders zugreifen als es VEEAM tut. Beide benutzen brav die gleiche (von BE installierte) Datenbank (MSSQL 2008R2 Express), natürlich jeder in einer eigenen Instanz. Die einzigen Treiber, die hier mit im Boot sind, sind die von BE mitgelieferten Tapedriver, mit denen VEEAM aber nichts zu tun hat.
Zumindest glaube ich nicht, daß das gleichzeitige Vorhandsein von VEEAM und BE meine Probleme mit der Datenträgerlast beim VEEAM-Restore verursacht.
Natürlich habe ich während des Restore im Ressourcenmonitor auch die Netzwerklast angesehen( so gut es ging, auch das Wechseln der Registerkarten hat Minuten gedauert), demnach war an der Netzwerkschnittstelle nur wenig mehr als "Grundrauschen" los.
Als Backup-Proxy ist nichts explizit eingerichtet, den Dienst gibt's natürlich dennoch, er läuft (wo auch sonst) auf dem Server, wo VEEAM installiert ist.
Zitat: "Alternativ kannst Du die VM ja auch ohne Rücksicherung direkt aus der Backupdatei laufen lassen ..." - wie soll das gehen? Bräuchte ich dazu nicht einen weiteren (oder anderen) HYPER-V-Host? oder was verstehe ich da jetzt nicht?
Grüße
von
departure
Öhhhhhh.....
Sag mal, hast Du eigentlich jemals das Handbuch gesehen? Ich weiß, Männer lesen keine Handbücher, aaaaaaber: Den Backup Proxy (oder mehrere, wie es gebraucht wird) kannst Du auf einem weiteren Server installieren, ansonsten macht so eine verteilte Geschichte vielleicht weniger Sinn als gedacht.
Thema Rücksicherung: Der Backup Proxy ist ein Server 2008 / 2012, hier muss zwingend die HyperV-Rolle installiert sein. Nun kann der Proxy aus der Backupdatei die VM mounten. Weitere Infos im Handbuch "Evaluator's Guide Hyper-V Environments", Seite 16 ff. Siehe auch Seite 46, "Performing Instant VM Recovery".
Sag mal, hast Du eigentlich jemals das Handbuch gesehen?
Ich weiß, Männer lesen keine Handbücher, aaaaaaber: Den Backup Proxy (oder mehrere, wie es gebraucht wird) kannst Du auf einem weiteren Server installieren, ansonsten macht so eine verteilte Geschichte vielleicht weniger Sinn als gedacht.Thema Rücksicherung: Der Backup Proxy ist ein Server 2008 / 2012, hier muss zwingend die HyperV-Rolle installiert sein. Nun kann der Proxy aus der Backupdatei die VM mounten. Weitere Infos im Handbuch "Evaluator's Guide Hyper-V Environments", Seite 16 ff. Siehe auch Seite 46, "Performing Instant VM Recovery".
Hmm, tja, ähm, naja, nun denn, wie auch immer, ich bin in der Tat mehr ein Mann der Tat als ein Mann des Handbuchs. Trotzdem oder gerade deswegen vielen Dank für Deine Erklärung.
Ohne richtig zu wissen, um was es sich dabei handelt, habe ich natürlich versucht, einen Off-Host-Backup-Proxy für HYPER-V anzugeben. Problem: Ich habe keinen zweiten HYPER-V-Server. Und mein Windows 8 Pro, das mit aktivierter HYPER-V-III-Rolle mein Ausfallserver für den HYPER-V-Host darstellt (mächtige Desktop-Maschine, Leistung genügt vollauf), wird nicht akzeptiert. Somit bleibt mir nur jeweils, den Restore lokal auf den VEEAM-Server durchzuführen und die Dateien über Netzwerk auf den Win-8-Pro-Desktoprechner zu kopieren/verschieben.
Das macht aber nichts, das ist nur für das Ausfallszenario. Wenn irgendwann mal der HYPER-V-II-HOST kaputtgeht, brauche ich dann, grob geschätzt, ca. 4 Stunden, bis alle virtuellen Maschinen unter HYPER-V-III auf Win 8 Pro laufen (die dann fehlende Enterprise-Lizenz schenke ich Microsoft in den 2 Tagen bzw. bis dahin, bis der "Große" repariert ist). Siehe, bei Interesse, auch hier: Auf HYPER-V-III unter Windows 8 Pro alte VHDs laufen lassen - möglich
Ich habe das, was ich brauche, mit VEEAM nun für mich in akzeptabler Weise erreicht, auch dank der Beruhigung durch Dich, habe jetzt funktionierende Backups auf NAS (VEEAM) und auf Bändern (BE) und bin somit erstmal zufrieden.
Danke nochmals für Deine Antworten und auch für Deine Geduld mit einem Nicht-Handbuch-Leser wie mir.
Grüße
von
departure
Ohne richtig zu wissen, um was es sich dabei handelt, habe ich natürlich versucht, einen Off-Host-Backup-Proxy für HYPER-V anzugeben. Problem: Ich habe keinen zweiten HYPER-V-Server. Und mein Windows 8 Pro, das mit aktivierter HYPER-V-III-Rolle mein Ausfallserver für den HYPER-V-Host darstellt (mächtige Desktop-Maschine, Leistung genügt vollauf), wird nicht akzeptiert. Somit bleibt mir nur jeweils, den Restore lokal auf den VEEAM-Server durchzuführen und die Dateien über Netzwerk auf den Win-8-Pro-Desktoprechner zu kopieren/verschieben.
Das macht aber nichts, das ist nur für das Ausfallszenario. Wenn irgendwann mal der HYPER-V-II-HOST kaputtgeht, brauche ich dann, grob geschätzt, ca. 4 Stunden, bis alle virtuellen Maschinen unter HYPER-V-III auf Win 8 Pro laufen (die dann fehlende Enterprise-Lizenz schenke ich Microsoft in den 2 Tagen bzw. bis dahin, bis der "Große" repariert ist
). Siehe, bei Interesse, auch hier: Auf HYPER-V-III unter Windows 8 Pro alte VHDs laufen lassen - möglichIch habe das, was ich brauche, mit VEEAM nun für mich in akzeptabler Weise erreicht, auch dank der Beruhigung durch Dich, habe jetzt funktionierende Backups auf NAS (VEEAM) und auf Bändern (BE) und bin somit erstmal zufrieden.
Danke nochmals für Deine Antworten und auch für Deine Geduld mit einem Nicht-Handbuch-Leser wie mir.
Grüße
von
departure
Ne, ich habe zu danken! Das Thema ist für mich auch neu, da ist der Austausch ja nicht verkehrt. Bei Interesse gern PM an mich!
Noch ein kleiner Tipp: Wenn es mit dem Umzug der VMs mal schneller gehen muss, leisten Export und Import gute Dienste, geht schneller als das reine Kopieren der VMs. Dank Veeam ist ja aber auch Replikation möglich, von daher egal...
Gruß
Noch ein kleiner Tipp: Wenn es mit dem Umzug der VMs mal schneller gehen muss, leisten Export und Import gute Dienste, geht schneller als das reine Kopieren der VMs. Dank Veeam ist ja aber auch Replikation möglich, von daher egal...
Gruß
Hab' jetzt noch was gefunden:
Ich kann zwar den Windows-8-Rechner nicht als HYPER-V-Off-Host-Backup-Proxy hinzufügen, aber als "normalen" Windows Server (so wie der Rechner, auf dem VEEAM installiert ist, auch). Entsprechend kann ich diesen dann auch als direktes Restore-Ziel verwenden und muß nichts nachträglich umkopieren. Das einzige, was damit trotzdem nicht geht, ist das Instant Recovery, ich muß also die virtuellen Maschinen auf dem Windows-8-Pro-Rechner noch anlegen und von Hand starten, aber zumindest sind alle dazu nötigen Dateien nach dem Restore dann schon dort, eine gewaltige Erleichterung!
Die eingebauten Export-/Import-Features von HYPER-V sind mir bekannt. Mit den passenden Powershell-Skripten läßt sich das sogar automatisieren und kann dann eigentlich ein Backup komplett ersetzen. Rein technisch ist ein Export m. E. sogar die sauberste Lösung für solch ein Backup. Problem ist aber, daß die Maschinen dazu nicht laufen dürfen, sie müssen mindestens "schlafen" (Suspended).
Automatisierter HYPER-V-Export/Import per Powershell: http://www.hyper-v-server.de/tools/hyper-v-sicherung-mittels-powershell ...
Grüße
von
departure
Ich kann zwar den Windows-8-Rechner nicht als HYPER-V-Off-Host-Backup-Proxy hinzufügen, aber als "normalen" Windows Server (so wie der Rechner, auf dem VEEAM installiert ist, auch). Entsprechend kann ich diesen dann auch als direktes Restore-Ziel verwenden und muß nichts nachträglich umkopieren. Das einzige, was damit trotzdem nicht geht, ist das Instant Recovery, ich muß also die virtuellen Maschinen auf dem Windows-8-Pro-Rechner noch anlegen und von Hand starten, aber zumindest sind alle dazu nötigen Dateien nach dem Restore dann schon dort, eine gewaltige Erleichterung!
Die eingebauten Export-/Import-Features von HYPER-V sind mir bekannt. Mit den passenden Powershell-Skripten läßt sich das sogar automatisieren und kann dann eigentlich ein Backup komplett ersetzen. Rein technisch ist ein Export m. E. sogar die sauberste Lösung für solch ein Backup. Problem ist aber, daß die Maschinen dazu nicht laufen dürfen, sie müssen mindestens "schlafen" (Suspended).
Automatisierter HYPER-V-Export/Import per Powershell: http://www.hyper-v-server.de/tools/hyper-v-sicherung-mittels-powershell ...
Grüße
von
departure
