Hallo,
ich muss alle meine VMs täglich auf Tape wegsichern. Ein Herunterfahren kommt nicht in Frage.
Gibt es da eine einfache Lösung, z.B. über einen Snapshot, oder muss ich hierzu den ESX-Server kaufen?
Viele Grüße
Matthias
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Online-Backup allee VMs unter VMWare-Server
Man kann es wohl über vmware-cmd und addredo und commit machen.
Z.B.
/usr/bin/vmware-cmd -v "/vmware/test/Windows 2000 Professional.vmx" addredo "/vmware/test/Windows 2000 Professional.vmdk"
Leider scheint das laut VMWare nicht unter VMWare-Server nicht zu laufen:
"Note: This operation applies only to ESX Server."
http://www.vmware.com/support/esx2/doc/vmware-cmd.html
Macht hier noch jemand Backups von VMs?
Z.B.
/usr/bin/vmware-cmd -v "/vmware/test/Windows 2000 Professional.vmx" addredo "/vmware/test/Windows 2000 Professional.vmdk"
Leider scheint das laut VMWare nicht unter VMWare-Server nicht zu laufen:
"Note: This operation applies only to ESX Server."
http://www.vmware.com/support/esx2/doc/vmware-cmd.html
Macht hier noch jemand Backups von VMs?
> backup agent in der vm installieren und wie einen echten server sichern.
Das will ich ja gerade nicht. Es muss doch auch anders gehen, als die Maschinen runterzufahren, die Files zu sichern und danach die VM wieder zu starten. Das ist zwar alles mit dem Shellscripten zu lösen, aber nicht wirklich elegant.
Das will ich ja gerade nicht. Es muss doch auch anders gehen, als die Maschinen runterzufahren, die Files zu sichern und danach die VM wieder zu starten. Das ist zwar alles mit dem Shellscripten zu lösen, aber nicht wirklich elegant.
Wie soll denn dieses Backup genau von Statten gehen?
- VM läuft (Ausgangszustand). Nennen wir die Datei die als HDD dient mal "ImageA"
-"take snapshot" => ab jetzt wird "ImageA" nicht mehr verändert, änderungen nur noch in eine Snapshotdatei geschrieben. Nennen wir diese Datei mal "ImageB"
- Da "ImageA" keinerlei Veränderungen mehr erfährt, kann diese Datei nun auf ein Backupmedium geschrieben werden.
- Nun müssen beide Dateien zusammengeführt werden. "ImageB" löst sich bei diesem Vorgang auf, die Inhalte von "ImageB" werden in "ImageA" geschrieben.
Und das soll mit dem VMWare Server nicht via Console machbar sein? Bezweifel ich.
Das einzige Problem hierbei wird sein, dass die Snapshot-Aktionen -- sowohl das Erstellen, als auch das Zusammenführen -- eine kurzzeitige Pause ("Suspend") der VM bedeuten.
Sofern es wirklich nicht per Console funktioniert könntest du -- was definitiv per Console geht -- die VM einfach in den Suspend fahren, dann alles backuppen und den Suspend wieder lösen. Dauert zwar ein klein wenig Länger weil die VM so lange im Suspend bleiben muss, bis das vmdk-File gesichert ist aber wenigstens kommst du so um einen Shutdown herum.
- VM läuft (Ausgangszustand). Nennen wir die Datei die als HDD dient mal "ImageA"
-"take snapshot" => ab jetzt wird "ImageA" nicht mehr verändert, änderungen nur noch in eine Snapshotdatei geschrieben. Nennen wir diese Datei mal "ImageB"
- Da "ImageA" keinerlei Veränderungen mehr erfährt, kann diese Datei nun auf ein Backupmedium geschrieben werden.
- Nun müssen beide Dateien zusammengeführt werden. "ImageB" löst sich bei diesem Vorgang auf, die Inhalte von "ImageB" werden in "ImageA" geschrieben.
Und das soll mit dem VMWare Server nicht via Console machbar sein? Bezweifel ich.
Das einzige Problem hierbei wird sein, dass die Snapshot-Aktionen -- sowohl das Erstellen, als auch das Zusammenführen -- eine kurzzeitige Pause ("Suspend") der VM bedeuten.
Sofern es wirklich nicht per Console funktioniert könntest du -- was definitiv per Console geht -- die VM einfach in den Suspend fahren, dann alles backuppen und den Suspend wieder lösen. Dauert zwar ein klein wenig Länger weil die VM so lange im Suspend bleiben muss, bis das vmdk-File gesichert ist aber wenigstens kommst du so um einen Shutdown herum.
> Und das soll mit dem VMWare Server nicht via Console machbar sein? Bezweifel ich.
Ich muss jeden Tag backups machen. Das muss also automatisiert (per Shell) von statten gehen. Bin ich denn der einziege, der seine VMs sichern will?
> Sofern es wirklich nicht per Console funktioniert
Die Jungs von VMWare haben die benötigten Funktionen nicht in dem kostenfreien Produkt integriert. Es geht ja per "addredo" und "commit", nur ist dies nur im ESX implementiert
> könntest du -- was definitiv per Console geht -- die VM einfach in den Suspend fahren,
> dann alles backuppen und den Suspend wieder lösen. Dauert zwar ein klein wenig Länger
> weil die VM so lange im Suspend bleiben muss, bis das vmdk-File gesichert ist aber
> wenigstens kommst du so um einen Shutdown herum.
Dieses Zeitfenster von ca. 30 Minuten um die 20 GB jeder VM wegzusichern, habe ich nicht. Mir bleibt wohl nur das Upgrade auf den ESX übrig...
Ich muss jeden Tag backups machen. Das muss also automatisiert (per Shell) von statten gehen. Bin ich denn der einziege, der seine VMs sichern will?
> Sofern es wirklich nicht per Console funktioniert
Die Jungs von VMWare haben die benötigten Funktionen nicht in dem kostenfreien Produkt integriert. Es geht ja per "addredo" und "commit", nur ist dies nur im ESX implementiert
> könntest du -- was definitiv per Console geht -- die VM einfach in den Suspend fahren,
> dann alles backuppen und den Suspend wieder lösen. Dauert zwar ein klein wenig Länger
> weil die VM so lange im Suspend bleiben muss, bis das vmdk-File gesichert ist aber
> wenigstens kommst du so um einen Shutdown herum.
Dieses Zeitfenster von ca. 30 Minuten um die 20 GB jeder VM wegzusichern, habe ich nicht. Mir bleibt wohl nur das Upgrade auf den ESX übrig...
Wieviel Zeit hast du denn?
- temporäres Verzeichnis erstellen bzw dessen Inhalt löschen
- VM in Suspend schicken
- Inhalt der VMs ins temporäre Verzeichnis kopieren
- VM wieder starten
- den Inhalt des temporären Verzeichnises backupen
Sofern s dein Rechner hinkriegt, 20GB auf der HDD in 5 Minuten durch die Gegend zu kopieren haste genau diese 5 Minuten Stillstandszeit.
- temporäres Verzeichnis erstellen bzw dessen Inhalt löschen
- VM in Suspend schicken
- Inhalt der VMs ins temporäre Verzeichnis kopieren
- VM wieder starten
- den Inhalt des temporären Verzeichnises backupen
Sofern s dein Rechner hinkriegt, 20GB auf der HDD in 5 Minuten durch die Gegend zu kopieren haste genau diese 5 Minuten Stillstandszeit.
Hallo,
ich mache die Online-Backups täglich ohne Downtime meiner Gäste mit ...
siehe http://www.acronis.com
1A Sahne-Tool
cu
Hugo
ich mache die Online-Backups täglich ohne Downtime meiner Gäste mit ...
Code: Alles auswählen
Acronis TrueImagesiehe http://www.acronis.com
1A Sahne-Tool
cu
Hugo
Aber so ganz 100% das wahre ist TrueImage auch nicht. Ich hab s auch an laufen momentan, allerdings brechen manche Sicherungsläufe mit "konnte Quelldaten nicht lesen" (sinngemäß übersetzt) ab. Dass tritt vornehmlich auf, wenn der Server zu dieser Zeit ordentlich unter Last steht.
Machen wir uns mal klar, was online-Backup-Tools eigentlich tun: Sie verschaffen sich "unaufhebbaren Zugriff aufs Dateisystem". Wenn ein beliebiges Programm seine Dateien öffnet sind diese Dateien blockiert, bis das entsprechende Programm sie wieder schließt und freigibt. Auf Betriebssystemebene gibt es Möglichkeiten, diese Sperre zu umgehen, sodass ein Backup-Tool auch auf die Dateien zugreifen kann, wenn ein anderes Programm sie gerade blockiert.
Allerdings hat diese Sperrung der Dateien vor gleichzeitigem Fremdzugriff durchaus seinen Sinn. Stellen wir uns mal eine 5gb große Datei vor, in die ein Programm durchgehend Daten schreibt. Ein gut ausgelasteter SQL-Server tut das zum beispiel. Jetzt fängt Acronis an, diese Datei zu sichern, obwohl der SQL-Server gerade noch schreibt. Heißt wenn Acronis in der Mitte angenommen ist -- das Sichern einer 5gb großen Datei benötigt eben leider eine gewisse Zeit -- schreibt der SQL-Server am Anfang wieder was rein. Wenn Acronis bei 75% ist schreibt der SQL-Server am Ende was rein. Die Sicherung die Acronis enthält jetzt zu vielleicht 80% alten und zu 20% neuen Datenbestand. Dass eine solche Sicherung nutzlos ist steht außer frage.
Acronis wird da zwar entsprechende Gegenmaßnahmen ergreifen, allerdings kann es auch nur einen gewissen Aufwand dafür treiben. Wenn der SQL-Server zu viel verändert ist der Aufwand den Acronis treiben müsste zu groß und es bricht ab. Macht auch Sinn. Wenn der Aufwand den Acronis zur "Vermeidung" dieses Problems unternimmt darin besteht, sich zu merken wohin der SQL-Server geschrieben hat und wohin nicht käme die Sicherung nie zum Ende, wenn der SQL-Server schneller Daten verändern kann als Acronis diese in die Sicherung einpflegen.
Eine solche Onlinesicherung ist also immer mit Vorsicht zu genießen. Auch wenn Acronis ein recht mächtiges Programm ist -- was man für 600€ auch erwarten kann -- ist es trotzdem keine 100%-Lösung.
Machen wir uns mal klar, was online-Backup-Tools eigentlich tun: Sie verschaffen sich "unaufhebbaren Zugriff aufs Dateisystem". Wenn ein beliebiges Programm seine Dateien öffnet sind diese Dateien blockiert, bis das entsprechende Programm sie wieder schließt und freigibt. Auf Betriebssystemebene gibt es Möglichkeiten, diese Sperre zu umgehen, sodass ein Backup-Tool auch auf die Dateien zugreifen kann, wenn ein anderes Programm sie gerade blockiert.
Allerdings hat diese Sperrung der Dateien vor gleichzeitigem Fremdzugriff durchaus seinen Sinn. Stellen wir uns mal eine 5gb große Datei vor, in die ein Programm durchgehend Daten schreibt. Ein gut ausgelasteter SQL-Server tut das zum beispiel. Jetzt fängt Acronis an, diese Datei zu sichern, obwohl der SQL-Server gerade noch schreibt. Heißt wenn Acronis in der Mitte angenommen ist -- das Sichern einer 5gb großen Datei benötigt eben leider eine gewisse Zeit -- schreibt der SQL-Server am Anfang wieder was rein. Wenn Acronis bei 75% ist schreibt der SQL-Server am Ende was rein. Die Sicherung die Acronis enthält jetzt zu vielleicht 80% alten und zu 20% neuen Datenbestand. Dass eine solche Sicherung nutzlos ist steht außer frage.
Acronis wird da zwar entsprechende Gegenmaßnahmen ergreifen, allerdings kann es auch nur einen gewissen Aufwand dafür treiben. Wenn der SQL-Server zu viel verändert ist der Aufwand den Acronis treiben müsste zu groß und es bricht ab. Macht auch Sinn. Wenn der Aufwand den Acronis zur "Vermeidung" dieses Problems unternimmt darin besteht, sich zu merken wohin der SQL-Server geschrieben hat und wohin nicht käme die Sicherung nie zum Ende, wenn der SQL-Server schneller Daten verändern kann als Acronis diese in die Sicherung einpflegen.
Eine solche Onlinesicherung ist also immer mit Vorsicht zu genießen. Auch wenn Acronis ein recht mächtiges Programm ist -- was man für 600€ auch erwarten kann -- ist es trotzdem keine 100%-Lösung.
Hallo,
@al!ve
also ich kann von hier aus nur bestätigen, dass die aktuelle Version 9.x keine (!) Probleme, auch nicht bei Server-Volllast, hat.
Nach meinen Infos klingt sich TrueImage als Datei-Treiber in's Betriebssystem ein, so dass eine Anwendung, auch bei einer 5 GB Datei, einen völlig transparenten Zugriff auf die Datei hat. Änderungen werden von TI zunächst in einer Änderungsdatei geschrieben. Nach Fertigstellung der Sicherung werden Original- und Änderungsdatei gemerged. Auch dies erfolgt transparenz ohne Kenntnis seitens der Anwendung.
Also hier funktioniert es.
@geraldg
Du benötigst nur eine (!) Lizenz für den Host, nicht für alle Gäste.
cu und frohe Ostern
Hugo
@al!ve
also ich kann von hier aus nur bestätigen, dass die aktuelle Version 9.x keine (!) Probleme, auch nicht bei Server-Volllast, hat.
Nach meinen Infos klingt sich TrueImage als Datei-Treiber in's Betriebssystem ein, so dass eine Anwendung, auch bei einer 5 GB Datei, einen völlig transparenten Zugriff auf die Datei hat. Änderungen werden von TI zunächst in einer Änderungsdatei geschrieben. Nach Fertigstellung der Sicherung werden Original- und Änderungsdatei gemerged. Auch dies erfolgt transparenz ohne Kenntnis seitens der Anwendung.
Also hier funktioniert es.
@geraldg
Du benötigst nur eine (!) Lizenz für den Host, nicht für alle Gäste.
cu und frohe Ostern
Hugo
wenn der host vss unterstützt (tut windows server 2003 und windows xp) dann kannst du die laufenden vms einfach mit ntbackup sichern ohne sie runterfahren zu müssen. so einfach ist das
wenn du anwendungen/dienste in der vm laufen hast die für ein konsistentes sichern ein ordungsgemäßes runterfahren des dienstes / der anwendung erfordern dann musst du das auch machen, da kann keine virtualisierungssoftware der welt etwas dagegen tun, auch nicht esx.
wenn du anwendungen/dienste in der vm laufen hast die für ein konsistentes sichern ein ordungsgemäßes runterfahren des dienstes / der anwendung erfordern dann musst du das auch machen, da kann keine virtualisierungssoftware der welt etwas dagegen tun, auch nicht esx.
>wenn der host vss unterstützt (tut windows server 2003 und windows xp) dann kannst du die laufenden vms einfach mit ntbackup sichern ohne sie runterfahren zu müssen. so einfach ist das Wink
sicher?
wenn ich einen snapshot mit OS - mitteln mache dann ist das eine momentaufnahme eines Systems dessen platten sich im gemounteten zustand befinden, d.h. das dirty-flag ist gesetzt.
beim nächsten boot schlägt dann fsck zu - bzg. entspr. journalling funktion des dateisystems.
dass das ein konsistentes backup ist kann ich mir eigentlich nicht vorstellen.
comments ?
grüsse
roland
sicher?
wenn ich einen snapshot mit OS - mitteln mache dann ist das eine momentaufnahme eines Systems dessen platten sich im gemounteten zustand befinden, d.h. das dirty-flag ist gesetzt.
beim nächsten boot schlägt dann fsck zu - bzg. entspr. journalling funktion des dateisystems.
dass das ein konsistentes backup ist kann ich mir eigentlich nicht vorstellen.
comments ?
grüsse
roland
devzero hat geschrieben:>wenn der host vss unterstützt (tut windows server 2003 und windows xp) dann kannst du die laufenden vms einfach mit ntbackup sichern ohne sie runterfahren zu müssen. so einfach ist das Wink
sicher?
wenn ich einen snapshot mit OS - mitteln mache dann ist das eine momentaufnahme eines Systems dessen platten sich im gemounteten zustand befinden, d.h. das dirty-flag ist gesetzt.
ja, sicher. die platten sind gemountet, das ist korrekt und dienste die durch ihren speziellen umgang mit daten damit probleme haben sollte man so nicht sichern. datenbanken sollte man z.b. ohnedies mit der integrierten funktion backupen. sobald das backup file als konsistente datei im filesystem liegt wird die auch mit vss der gesamten vm korrekt gesichert.
devzero hat geschrieben:beim nächsten boot schlägt dann fsck zu - bzg. entspr. journalling funktion des dateisystems.
das os wurde dabei nicht korrekt heruntergefahren (wie auch bei einem snapshot), das ist richtig. die vss-sicherung ist wie ein raid-split oder aus der sicht der vm ein stromausfall zu einem zeitpunkt wo kein schreibvorgang läuft zu sehen. ein laufender schreibvorgang in der vm wird durch vss nicht unterbrochen sondern zu ende geführt.
devzero hat geschrieben:dass das ein konsistentes backup ist kann ich mir eigentlich nicht vorstellen.
betrachtest du theorie oder business case? in der reinen theorie ist das beste backup und einzige perfekte backup die vm herunterfahren, images offline sichern und die vm wieder hochfahren. wer die möglichkeit hat das zu automatisieren oder die zeit und muße das manuell zu machen kann das tun. in allen praxisfällen ist es um ein vielfaches besser ein regelmäßiges online-backup automatisiert zu haben als keines.
ich verwende diese methode in der praxis seit mehreren jahren, habe auch schon backups benötigt und es hab noch keinen einzigen fall wo nicht alles korrekt und konsistent gesichert war.
Zurück zu „VMserver 1 und GSX“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste