Frage zu Backup von Windows 2003 Server auf Linux

[chrisw]

Hallo Forum,

ich habe eine ziemlich einfache Frage. Es geht darum, dass von einem Windows 2003 Server Daten auf ein Linux System (Debian Etch) gesichert werden sollen. Der Backup Server bietet folgende Möglichkeiten für ein Backup an:

rsync, scp und Amanda

Die anderen Linux Boxen werden alle via rsync gesichert, so dass bei einem Crash die Maschinen schnellstens wieder aufgesetzt werden können, da alle wichtigen Verzeichnisse sowie die Paketlisten mitgesichert werden.

Dieses Konzept funktioniert bisher wunderbar, allerdings kommt jetzt dieser Windows 2003 Server dazu.

Am liebsten wäre es mir, wenn ich ihn genau wie die Linux Maschinen so sichern könnte, dass er im Notfall schnell wiederherzustellen wäre. Allerdings habe ich bisher noch nicht wirklich eine Möglichkeit gefunden, da Windows ja ein bißchen eigen ist.

Ich hab auch eine Weile gegoogled, finde dazu allerdings nichts, was mir so wirklich gefällt...

Hat jemand von euch eine ähnliche Konfiguration, oder eine Idee ?

(Ich möchte niemanden die Arbeit klauen, ich suche nur einen Denkanstoß, umsetzen werde ich es dann selber. Mir schwebt nur soviel vor, und ich kann mich für nichts entscheiden :roll: )

Lg
Chris

[sycronic]

ich habe auch lange nach einer guten lösung gesucht. das einfachste (und kostengünstigste) wäre wohl eine imagesicherung (true image oder sowas) bzw. einfach ntbackup (ist allerdings nicht 100% vollständig).
beides ist unter windows schwierig in sachen wiederherstellung. deshalb kaufen wir grad für eine neue lösung ein, die dann ab januar/februar produktiv wird.

ein vmware-server (kostenlos) auf einer kräftigen hardware (6gb, quadcore) unter winxp pro oder ubuntu 7.10 server installieren. darin dann den windows 2k3 installieren und 1x nächtlich snapshot erstellen. dann vm kurz suspenden, restliche dateien sichern (sind dann nur noch ein paar gig) und wieder anschmeissen. ist ne downtime von max 20-30 minuten. für ein 24/7 system ist das also nix. dann die plattendatei wegsichern (die große vmdk). das geht während die vm läuft. wiederherstellung auf fast jeder hardware innerhalb von wenigen minuten (je nach geschwindigkeit der festplatten. kannst aber auch zwei server hinstellen. wenn du dann auf den zweiten die vm-dateien spiegelst, kannst du deinen win2k3 innerhalb von 2-3 minuten wieder ans netz bringen.

erste tests sind damit ganz gut verlaufen. wenn noch jemand anregungen hat oder probleme sieht: immer her damit

[chrisw]

Hallo,

das habe ich ganz vergessen zu erwähnen - die W2K3 ist in einer VMWare auf einem Intel Xeon mit 8 GB RAM...

vmdk wegsichern bei suspend habe ich mir auch schon überlegt. Der Haken bei der Sache ist, dass auf diesem Server noch ein .... Exchange läuft, der Endpunkt für die Emailzustellung ist. Daher leider 24/7.

Bei deinem Konzept verstehe ich das mit den Snapshots nicht. Wenn die Snapshots nicht aktiv sind, reicht ja nur ein suspend mit anschließendem Sichern der vmdk.

So würde ich es ja machen, nur haben die 3 virtuellen Disks des Servers zusammen 250 GB, was selbst über das Gigabit Netzwerk einfach zu lange dauert, da ja der Server praktisch solange down ist.

Was ich mich bisher noch nicht zu testen getraut habe:

Wenn die Snapshot-Funktion aktiv ist, werden die Änderungen am Festplatteninahlt afaik ja in eine extra Datei geschrieben, und irgendwann dann in die vmdks eingespielt. Währenddessen sind die vmdks ja praktisch read-only und müssten eigentlich komplett gesichert werden können. Bei einem Crash müsste man ja dann praktisch nur die gesicherten Dateien zurückspielen und hätte dann den Stand vom Vortag. Oder habe ich da einen Denkfehler ?

[Joe User]

Solange die virtuellen Disks read-only sind, kannst Du sie problemlos "live" sichern und hättest somit keine Downtime. Ob Du mit dem gesonderten File für die temporären Änderungen richtig liegst, weiss ich allerdings nicht, da ich kein VMWare-Server nutze.

[sycronic]

richtig. das ist auch genau das, was ich meinte. während der server läuft einfach die vmdks sichern (vorher snapshot machen). das geht während des betriebes!
die anderen dateien, also eine der vmem dateien und noch irgendeine sind währenddessen im exclusiven zugriff von vmware. die kannst du während eines suspends sichern. da dies nur die größe des rams der vm sind und ein paar festplattendeltas, kommst du hier je nach maschine ab max. 4 gb (mehr wird bei vmware-server glaub ich für eine vm gar nicht unterstützt). und 4gb sind in 10-20 min weggesichert.

wenn du einen mailserver für 10-20 min offline nimmst, kommt höchstens weniger spam an, weil z.B. beim greylisting mails ABSICHTLICH über minuten hin nicht angenommen werden. mails hängen oft stundenlang in irgendwelchen queues rum und nachts sollte doch eine pünktliche annahme sowieso egal sein (oder arbeitet ihr 24x7??)

[chrisw]

Guten Morgen

Danke für die ausführliche Erklärung.

Momentan läuft es so:

Snapshot wird täglich um 19 Uhr erstellt, um 23 Uhr beginnt dann rsync von Backup-Server aus mit der Sicherung der *.vmdk (150 GB), während die Windows Kiste weiterhin läuft. Dank Gigabit-LAN funktioniert das auch einigermaßen schnell (obwohl es unerheblich ist, da das System ja nicht down ist).

Dieses Spielchen läuft jede Nacht, es tritt dabei nur ein kleines Problem auf:

Die Snapshots bzw. Redo-Logs werden nicht commited. Eigentlich sollte doch bei Erstellen eines neuen Snapshot der alte per commit in die vmdk gegeben werden.
Passiert aber nicht.

Funktioniert commit während des laufenden Betriebes nicht ? Im Vmware-Forum habe ich gelesen, dass dafür die VMWare-Tools installiert sein müssen (sind sie auch). Über die VMWare-Server Console habe ich noch den Punkt "delete snapshot", wo auf jeden Fall ein Commit gemacht wird. Dieser Menüpunkt ist jedoch ausgegraut und kann nicht angeklickt werden.

Über die Shell kann ich auch nichts machen, entweder stimmt was mit dem Befehl nicht, oder dutzende Tutorials im Internet sind falsch:

Code: Select all

vmware:~# vmware-cmd /vmware/Win2003/Win2003.vmx commit /vmware/Win2003/Win2003.vmdk 0 0 1


Use of uninitialized value in subroutine entry at /usr/local/lib/perl/5.8.8/VMware/VmPerl/VM.pm line 397.

Use of uninitialized value in subroutine entry at /usr/local/lib/perl/5.8.8/VMware/VmPerl/VM.pm line 397.

Use of uninitialized value in subroutine entry at /usr/local/lib/perl/5.8.8/VMware/VmPerl/VM.pm line 397.

commit(/vmware/Win2003/Win2003.vmdk 0 0 1) =

Alles probiert, von scsi0:0 bishin zur Angabe des vmfs.

Naja, ich glaube das ganze geht jetzt ein wenig ins OffTopic ?

[sycronic]

passiert das nicht automatisch beim snapshot, dass die temp-daten in die vmdk übertragen werden?
welche version vom vmware-server setzt du denn ein? vielleicht ist das nur ein versionskonflikt perl/linux/vmware??

Naja, ich glaube das ganze geht jetzt ein wenig ins OffTopic ?

ich finde, jetzt wirds erst interessant. ich konnte diese lösung auch noch nicht auf herz und nieren prüfen, hätte mich jetzt zwischen weihnachten und neujahr weitergehend damit beschäftigt.

[chrisw]

Hallo,

ich setze den VMWare Server 1.0.4 auf einer Debian Etch amd64 Minimal-Installation ein.

Hier mal zu dem was offensichtlich nicht geht, das Commit:

Code: Select all

vmware:/vmware/Win2003# ls

core                          Win2003-000002-s021.vmdk          Win2003 (2)-000002-s018.vmdk       Win2003 (3)-000002-s010.vmdk

vmware-0.log                  Win2003-000002.vmdk               Win2003 (2)-000002-s019.vmdk       Win2003 (3)-000002-s011.vmdk

vmware-1.log                  Win2003-000002.vmdk.WRITELOCK     Win2003 (2)-000002-s020.vmdk       Win2003 (3)-000002-s012.vmdk

vmware-2.log                  Win2003 (2)-000001-s001.vmdk      Win2003 (2)-000002-s021.vmdk       Win2003 (3)-000002-s013.vmdk

vmware.log                    Win2003 (2)-000001-s002.vmdk      Win2003 (2)-000002-s022.vmdk       Win2003 (3)-000002-s014.vmdk

Win2003-000001-s001.vmdk      Win2003 (2)-000001-s003.vmdk      Win2003 (2)-000002-s023.vmdk       Win2003 (3)-000002-s015.vmdk

Win2003-000001-s002.vmdk      Win2003 (2)-000001-s004.vmdk      Win2003 (2)-000002-s024.vmdk       Win2003 (3)-000002-s016.vmdk

Win2003-000001-s003.vmdk      Win2003 (2)-000001-s005.vmdk      Win2003 (2)-000002-s025.vmdk       Win2003 (3)-000002-s017.vmdk

Win2003-000001-s004.vmdk      Win2003 (2)-000001-s006.vmdk      Win2003 (2)-000002-s026.vmdk       Win2003 (3)-000002-s018.vmdk

Win2003-000001-s005.vmdk      Win2003 (2)-000001-s007.vmdk      Win2003 (2)-000002.vmdk            Win2003 (3)-000002-s019.vmdk

Win2003-000001-s006.vmdk      Win2003 (2)-000001-s008.vmdk      Win2003 (2)-000002.vmdk.WRITELOCK  Win2003 (3)-000002-s020.vmdk

Win2003-000001-s007.vmdk      Win2003 (2)-000001-s009.vmdk      Win2003 (3)-000001-s001.vmdk       Win2003 (3)-000002-s021.vmdk

Win2003-000001-s008.vmdk      Win2003 (2)-000001-s010.vmdk      Win2003 (3)-000001-s002.vmdk       Win2003 (3)-000002-s022.vmdk

Win2003-000001-s009.vmdk      Win2003 (2)-000001-s011.vmdk      Win2003 (3)-000001-s003.vmdk       Win2003 (3)-000002-s023.vmdk

Win2003-000001-s010.vmdk      Win2003 (2)-000001-s012.vmdk      Win2003 (3)-000001-s004.vmdk       Win2003 (3)-000002-s024.vmdk

Win2003-000001-s011.vmdk      Win2003 (2)-000001-s013.vmdk      Win2003 (3)-000001-s005.vmdk       Win2003 (3)-000002-s025.vmdk

Win2003-000001-s012.vmdk      Win2003 (2)-000001-s014.vmdk      Win2003 (3)-000001-s006.vmdk       Win2003 (3)-000002-s026.vmdk

Win2003-000001-s013.vmdk      Win2003 (2)-000001-s015.vmdk      Win2003 (3)-000001-s007.vmdk       Win2003 (3)-000002.vmdk

Win2003-000001-s014.vmdk      Win2003 (2)-000001-s016.vmdk      Win2003 (3)-000001-s008.vmdk       Win2003 (3)-000002.vmdk.WRITELOCK

Win2003-000001-s015.vmdk      Win2003 (2)-000001-s017.vmdk      Win2003 (3)-000001-s009.vmdk       Win2003-f001.vmdk

Win2003-000001-s016.vmdk      Win2003 (2)-000001-s018.vmdk      Win2003 (3)-000001-s010.vmdk       Win2003-f002.vmdk

Win2003-000001-s017.vmdk      Win2003 (2)-000001-s019.vmdk      Win2003 (3)-000001-s011.vmdk       Win2003-f003.vmdk

Win2003-000001-s018.vmdk      Win2003 (2)-000001-s020.vmdk      Win2003 (3)-000001-s012.vmdk       Win2003-f004.vmdk

Win2003-000001-s019.vmdk      Win2003 (2)-000001-s021.vmdk      Win2003 (3)-000001-s013.vmdk       Win2003-f005.vmdk

Win2003-000001-s020.vmdk      Win2003 (2)-000001-s022.vmdk      Win2003 (3)-000001-s014.vmdk       Win2003-f006.vmdk

Win2003-000001-s021.vmdk      Win2003 (2)-000001-s023.vmdk      Win2003 (3)-000001-s015.vmdk       Win2003-f007.vmdk

Win2003-000001.vmdk           Win2003 (2)-000001-s024.vmdk      Win2003 (3)-000001-s016.vmdk       Win2003-f008.vmdk

Win2003-000001.vmdk.READLOCK  Win2003 (2)-000001-s025.vmdk      Win2003 (3)-000001-s017.vmdk       Win2003-f009.vmdk

Win2003-000002-s001.vmdk      Win2003 (2)-000001-s026.vmdk      Win2003 (3)-000001-s018.vmdk       Win2003-f010.vmdk

Win2003-000002-s002.vmdk      Win2003 (2)-000001.vmdk           Win2003 (3)-000001-s019.vmdk       Win2003-f011.vmdk

Win2003-000002-s003.vmdk      Win2003 (2)-000001.vmdk.READLOCK  Win2003 (3)-000001-s020.vmdk       Win2003-f012.vmdk

Win2003-000002-s004.vmdk      Win2003 (2)-000002-s001.vmdk      Win2003 (3)-000001-s021.vmdk       Win2003-f013.vmdk

Win2003-000002-s005.vmdk      Win2003 (2)-000002-s002.vmdk      Win2003 (3)-000001-s022.vmdk       Win2003-f014.vmdk

Win2003-000002-s006.vmdk      Win2003 (2)-000002-s003.vmdk      Win2003 (3)-000001-s023.vmdk       Win2003-f015.vmdk

Win2003-000002-s007.vmdk      Win2003 (2)-000002-s004.vmdk      Win2003 (3)-000001-s024.vmdk       Win2003-f016.vmdk

Win2003-000002-s008.vmdk      Win2003 (2)-000002-s005.vmdk      Win2003 (3)-000001-s025.vmdk       Win2003-f017.vmdk

Win2003-000002-s009.vmdk      Win2003 (2)-000002-s006.vmdk      Win2003 (3)-000001-s026.vmdk       Win2003-f018.vmdk

Win2003-000002-s010.vmdk      Win2003 (2)-000002-s007.vmdk      Win2003 (3)-000001.vmdk            Win2003-f019.vmdk

Win2003-000002-s011.vmdk      Win2003 (2)-000002-s008.vmdk      Win2003 (3)-000001.vmdk.READLOCK   Win2003-f020.vmdk

Win2003-000002-s012.vmdk      Win2003 (2)-000002-s009.vmdk      Win2003 (3)-000002-s001.vmdk       Win2003-f021.vmdk

Win2003-000002-s013.vmdk      Win2003 (2)-000002-s010.vmdk      Win2003 (3)-000002-s002.vmdk       Win2003-Snapshot2.vmem.WRITELOCK

Win2003-000002-s014.vmdk      Win2003 (2)-000002-s011.vmdk      Win2003 (3)-000002-s003.vmdk       Win2003.vmdk

Win2003-000002-s015.vmdk      Win2003 (2)-000002-s012.vmdk      Win2003 (3)-000002-s004.vmdk       Win2003.vmdk.READLOCK

Win2003-000002-s016.vmdk      Win2003 (2)-000002-s013.vmdk      Win2003 (3)-000002-s005.vmdk       Win2003.vmsd

Win2003-000002-s017.vmdk      Win2003 (2)-000002-s014.vmdk      Win2003 (3)-000002-s006.vmdk       Win2003.vmx

Win2003-000002-s018.vmdk      Win2003 (2)-000002-s015.vmdk      Win2003 (3)-000002-s007.vmdk       Windows Server 2003 R2 Standard _1.nvram

Win2003-000002-s019.vmdk      Win2003 (2)-000002-s016.vmdk      Win2003 (3)-000002-s008.vmdk

Win2003-000002-s020.vmdk      Win2003 (2)-000002-s017.vmdk      Win2003 (3)-000002-s009.vmdk

Win2003.vmdk, Win2003 (2).vmdk und Win2003 (3).vmdk sind die virtuellen Disks, mit je 50 GB (2 GB pro Datei [also split-files])
Eine gesplittete virtuelle Disk heißt z.B. Win2003-f00x.vmdk (also f für filepart, nehme ich an). X steht hier für die Nummer des Festplattenteils. Für die zweite und dritte Disk fehlen die Splitfiles, da sie auf einer anderen Partition liegen.
Ein Snapshot dagegen heißt z.B. Win2003-s00000X-s000Y.vmdk (s für snapshot). Y steht hier für die Nummer des Festplattenteils, und X macht mich stutzig, denn X steht für die Nummer des Snapshots.

Du siehst, ich hab 2 Snapshots gemacht. Wenn bei Erstellen eines neuen Snapshots der alte committed wird, wieso sind die Dateien für X = 1 dann noch da ?

Änderungszeitpunkte:

Code: Select all

-rw------- 1 vmware vmware 126M 2007-12-17 16:32 Win2003-000002-s001.vmdk

-rw------- 1 vmware vmware 104M 2007-12-13 14:11 Win2003-000001-s001.vmdk

Snapshot 1 wurde schon tagelang nicht mehr verwendet, da ja bereits Snapshot 2 aktiv ist, der auch ein aktuelles Änderungsdatum aufweist.

Ohne genauere Tests traue ich mich jetzt natürlich nichts mehr, da ich nicht weiß, ob IRGENDEIN commit erfolgt ist.

Ich habe noch einen zweiten Windows Server 2003 zu Testzwecken aufgesetzt, mit dem ich ab morgen ein bißchen spielen werde.

Übrigens: Der von mir angewendete Backup-Plan funktioniert... während ein Snapshot vorhanden ist, lassen sich die virtuellen Disks wunderbar im laufenden Betrieb kopieren. Die Kopie kann dann in einer neuen Maschine importiert und problemlos gestartet werden

lg

[sycronic]

normalerweise erlaubt vmware-server nur ein snapshot, wenn ich das richtig verstanden habe. ich will am donnerstag auch nochmal die vm auspacken und ein wenig rumexperimentieren.

hast du den filesplit aus einem bestimmten grund konfiguriert?

Übrigens: Der von mir angewendete Backup-Plan funktioniert... während ein Snapshot vorhanden ist, lassen sich die virtuellen Disks wunderbar im laufenden Betrieb kopieren. Die Kopie kann dann in einer neuen Maschine importiert und problemlos gestartet werden

du meinst, mit stand vor dem snapshot, ohne das snapshot mitkopiert zu haben? damit ließe sich das ganze dann doch 24/7 anwenden.

[chrisw]

Richtig, ich kopier immer ohne den Snapshot - bei einem Worst Case Szenarion würden maximal 24 Stunden Daten verloren gehen, was für dieses System akzeptabel ist.

Das mit dem filesplit hat zwei Gründe:

- zum einen wurde damals das Backup auf einen SMB-Share gelegt, der mit Dateien > 2 GB Probleme hatte
- wenn das Backup abraucht, muss man nur die kaputten Dateien ersetzen, anstatt die minimal 50 GB neu zu ziehen.

Im Nachhinein bereu ich das, weil grad jetzt mit den Snapshots geht mir die Übersichtlichkeit verloren.

Mit dem einen Snapshot ist es ein bißchen anders:

Der freie VMWare Server erlaubt nur einen aktiven Snapshot.

[chrisw]

So, und hier ist das Problem:

Code: Select all

Dec 13 14:11:19: vmx| DISKLIB-SPARSECHK: [/vmware/Win2003/Win2003-000001-s016.vmdk] GT Error (ZG): [30][313] 0/431360
Dec 13 14:11:19: vmx| DISKLIB-SPARSECHK: [/vmware/Win2003/Win2003-000001-s016.vmdk] Resolving [30][313] = 431360
Dec 13 14:11:19: vmx| DISKLIB-SPARSE: "/vmware/Win2003/Win2003-000001-s016.vmdk" : failed to open (14): Disk needs repair.
Dec 13 14:11:19: vmx| DISKLIB-DSCPTR: Failed to open extents for descriptor file in normal mode
Dec 13 14:11:19: vmx| DISKLIB-LINK  : "/vmware/Win2003/Win2003-000001.vmdk" : failed to open (The specified virtual disk needs repair). 
Dec 13 14:11:19: vmx| DISKLIB-CHAIN : "/vmware/Win2003/Win2003-000001.vmdk" : failed to open (The specified virtual disk needs repair).
Dec 13 14:11:19: vmx| DISKLIB-LIB   : Failed to open '/vmware/Win2003/Win2003-000001.vmdk' with flags 0x18 (The specified virtual disk needs repair).
Dec 13 14:11:19: vmx| SNAPSHOT:SnapshotCombineDisks failed 5
Dec 13 14:11:19: vmx| SNAPSHOT:SnapshotConsolidate failed 5
Dec 13 14:11:19: vmx| SNAPSHOT:Consolidate failed 5
Dec 13 14:11:19: vmx| VMXVmdbTakeUndopointCB: Starting reqPath '/vm/#d6f0ec91da52b2de/vmx/chkptState/req/#102/'
Dec 13 14:11:19: vmx| VMXVmdbTakeUndopointCB: Finishing up, ending BusyOp.
Dec 13 14:11:19: vcpu-0| Sync monModules(5).
Dec 13 14:11:19: mks| MKS set guest selection request with invalid state 2 

Eine der Snapshot-Teildateien ist defekt und verhindert den Commit in das große Diskfile - deswegen werden neue Snapshots angelegt, ohne den alten zu commiten. Lösungsmöglichkeit: keine verläßliche.

Werd die Win VM wohl per Linux booten und sämtliche Filesysteme mit dd auf neue identische Platten ziehen, in einer neuen VM booten, checkdisk und co.
Und wohl nicht mehr mit Snapshots weiterarbeiten, sondern mit suspend VM und rsync der kompletten VM...

@ sycronic

Am Testsystem funktionierte es einwandfrei:

Snapshot erstellen, auf dem System rumfummeln, neuen Snapshot erstellen
=> alter Snapshot geht per commit in die virtuelle Disk, und es wird ein neuer begonnen...