Backup VMs ohne Downtime (GANZ! ohne)

[I.P.]

Host = Windows 2000 Server oder Windows Server 2003, auf jeden Fall ein System das Software RAID kann.

3 HDDs im RAID1

desnächtens wird das RAID aufgebrochen (mit DISKPART BREAK) und die weggebrochene partition auf band (oder NAS) gesichert. danach wird das RAID mit DISKPART ADD wieder aufgebaut. durch die 3 platten ist der spiegel auch noch funktionierend während gesichert wird.

was passiert in so einem fall mit geöffneten datenbanken (SQL Server, Exchange) in den VMs. ich denke etwas ähnliches wie bei einem stromausfall, nur dass nicht inmitten eines physischen schreibvorganges abgebrochen wird sondern erst danach, also keine inkonsistenz auftritt.

während des RAID-neuaufbaues ist die performance eingeschränkt, das ist mir klar.

habe ich irgend etwas nicht bedacht oder kann ich so wirklich systemvolumes ohne downtime sichern?

[continuum]

Hi
ganz sauber wird die Methode nicht sein - es fehlt in jedem Fall der Inhalt des RAMs. Also muesste man sicherheitshalber vorher alle disk-caches leeren.
Das koennte man mit sysinternals sync.exe machen.


Ich denke mal, wenn du direkt mit einplanst, dass die Dateien die in der backup-phase und kurz vorher offen waren danach unbrauchbar sind und von vorneherein entsorgt werden muessen, dann kannst du die backups in den meisten Faellen gebrauchen.
Da du ja in der dritten Platte einen "alive" Zustand hast den du beim Wiederherstellen von null booten musst baust du immer einen Systemcrash in deine Methode ein - NTFS ist zwar mittlerweile sehr unanfaellig fuer sowas - aber sicher kannst du dir nie sein. Beim 1000 Mal war vielleicht gerade ntoskrnl.exe im RAM - tja Pech gehabt.
Also kurz gesagt : anwenden ja - dem Boss verkaufen ??????

[I.P.]

der inhalt des rams fehlt auch auf klassischen backups

ich will ja keinen snapshot machen sondern daten ohne downtime sichern. ob die daten da den stand kurz vor oder genau zum zeitpunkt des raid-aufbrechens haben ist unter dieser zielsetzung egal.

aber sync.exe ist auf jeden fall ein gutes tool, danke.

warum stellt es ein problem dar wenn sich dateien im ram befinden? deshalb befinden sie sich ja auf der platte auch noch. in dem zustand in dem sie sich befunden haben bevor sie gelesen wurden.

gibt es eine möglichkeit gsx3 vms "einzufrieren"? ich meine genau den zustand herzustellen der passiert ist wenn man gsx2.5 images im laufenden betrieb kopiert hat - dann ist die vm eingefroren und man musste sie am host mit "retry" wieder zum leben erwecken. in diesem zustand findet keinerlei festplattenaktivität oder rechenarbeit statt. wenn das geht könnte man diesen zustand starten --> raid aufbrechen --> vm fortsetzen.

ich denke es gibt keine wirklich saubere methode laufende maschinen ohne downtime vollständig zu sichern. in gsx zumindest nicht, esx kann das von vorneherein.

[continuum]

Hi
klassische Backups haben nie offene Dateien dabei - bei offline Varianten wie ghost ist das kein Thema - bei online Varianten - ntbackup oder veritas oder wie auch immer muss irgendein Trick angewendet werden.
Ich merke gerade, dass ich gar nicht genau weiss, wie DISKPART BREAK im Detail arbeitet - wenn hierbei die Partition abgehaengt wird und das NTFS-journal sauber zu Ende geschrieben wird und die Partition nachher ohne NTFS-dirty flag frei gegeben wird, dann sehe ich eigentlich keine Probleme.
Ich hatte an Hardware-raids gedacht - deswegen die Bedenken - ich glaube ich schaue mir das doch mal genauer an mit den Software-raids - die Moeglichkeit die du beschreibst hoert sich sehr vielversprechend an ...

[zaptac]

Hi,

spontan fällt mir noch eine "billigere" Variante ein:
- Snapshot erstellen
- *.vmdk als Backup sichern (also ohne *REDO*)
- Snapshot entfernen

Steh' ich auf der Leitung oder macht das nicht genau das, was Du willst ("systemvolumes ohne downtime sichern")?

Gruß, Zaptac

[I.P.]

hi zaptac,

snapshots kann man meines wissens nicht im laufenden betrieb entfernen, dafür müsste man die vm runterfahren. oder weisst du eine möglichkeit?

[zaptac]

Hi,

snapshots kann man meines wissens nicht im laufenden betrieb entfernen, dafür müsste man die vm runterfahren. oder weisst du eine möglichkeit?

Leider nicht.
Ich hatte schon ein komisches Gefühl so früh am Tag zu posten..:)

Auf Linuxhosts würde ich in Richtung Logical Volume Manager forschen.
Für Windows habe ich folgende URL zu bieten: http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/spltmirr.mspx

Gruß, Zaptac

[I.P.]

das ist ja genau die version die ich mir gedacht habe

ich werd mir den artikel mal zu gemüte führen, danke für den link.

[I.P.]

ich habe heute erste tests durchgeführt, das klappt bisher hervorragend.

1. script: raid aufbrechen:
----------------------
sync c
diskpart /s break.txt
diskpart /s assign.txt
--------------------

die break.txt sieht so aus:
---------------
select volume 0
break disk=1
---------------

assign.txt:
--------------
select disk 1
select partition 1
assign letter=v
--------------

jetzt steht das inaktive volume als laufwerk v:\ zur verfügung und kann auf beliebige art und weise gesichert werden. das aufbrechen geht in sekundenschnelle. sync.exe ist die von sysinternals.com. break.txt und assign.txt sind getrennt falls das script auf ein bereits aufgebrochenes raid trifft.

das wiedereinbinden der disk passiert so:
------------------
diskpart /s del_add.txt
diskpart /s add.txt
------------------

mit den diskpart scripts del_add.txt:
-----------------
select disk 1
select partition 1
delete volume
select volume 0
add disk=1
------------------

und add.txt:
------------------
select volume 0
add disk=1
------------------

add.txt ist nötig falls das volume v:\ aus irgend einem grund vor dem wiederaufbau gelöscht wird (z.b. weil man bei dieser gelegenheit die hdd tauscht, die backup-hdd ist mehr belastet als die erste hdd weil zusätzlich zum tagesbetrieb auch das backup drüberläuft). diskpart bricht dann in der del_add.txt beim befehl "delete volume" ab weil das volume nicht existiert.

wie kann man zu whitepapers kommen wie diskpart break genau funktioniert und ob es dabei zu inkonsistenzen kommen kann?

[I.P.]

ich habe heute die splitmirror backup-methode ausformuliert und schon auf dem ersten host in produktiveinsatz gebracht.

erstmal habe ich manuell einen härtetest durchgeführt um festzustellen ob da wirklich keine inkonsistenzen auftreten. ich habe in einer VM eine defragmentierung durchgeführt und währenddessen das RAID1 aufgebrochen. auf der weggebrochenen partition habe ich dann die besagte VM (bzw. deren backup) gestartet und alles lief ohne probleme. start ohne chkdsk und alle files konsistent.

ein problem hat sich dann aufgetan, nämlich dass die volume-reihenfolge auf windows hosts nicht konsistent ist, d.h. laufwerk D:\ ist einmal Volume 1, dann wieder mal Volume 2. Das Microsoft tool DISKPART kann sich nicht auf laufwerksbuchtaben beziehen sondern immer nur auf volume nummern "SELECT VOLUME 1" z.b. aber NICHT "SELECT LETTER D", diese syntax gibts nicht.

ich habe dann ein commandline-tool geschrieben und es SPLITBACKUP.EXE genannt das genau diesen mißstand behebt und zudem befehle transparent durchführt, DISKPART muss man immer mit befehlsscripts füttern. einen konsolenaufruf "DISKPART SELECT VOLUME 3" gibt es nicht, das muss mit "DISKPART /s script.txt" geschehen wo in script.txt der befehl "SELECT VOLUME 3" drinsteht. mit SPLITBACKUP.EXE kann ich jetzt z.b. "SPLITBACKUP /letter=d /action="break disk=3"" ausführen das vom laufwerk D disk 3 wegbricht. da man auch die volume nummer der weggebrochenen disk nicht kennt versteht splitmirror auch die syntax "SPLITMIRROR /letter=? /action="assign letter=v"" mit der ich der höchsten volumenummer die keinen laufwerksbuchstaben besitzt einen zuweisen kann.

ich habe auf besagtem host eine konfiguration mit 3 gleich grossen hdds die ich so sichern möchte dass rotierend immer 2 als RAID1 werken und die 3. das split-backup enthält das offline (ohne den produktivbetrieb zu stören) auf NAS gesichert wird. nach jedem (täglichen) backup-durchlauf fungieren also 2 andere platten als RAID (einmal 1+2, dann 2+3, dann 3+1, dann wieder 1+2 u.s.w.). so kann ich sogar platten mit grown defects hot tauschen und die neue platte wird beim nächsten backup in den produktivbetrieb eingebunden.

das backup script sieht so aus:
----------------------------
fsutil dismount volume v:
splitbackup /letter=v /action="delete volume noerr"
splitbackup /letter=d /action="break disk=1"
splitbackup /letter=d /action="break disk=3"
splitbackup /letter=? /action="assign letter=v"
splitbackup /letter=d /action="add disk=1 noerr"
splitbackup /letter=d /action="add disk=2 noerr"
splitbackup /letter=d /action="add disk=3 noerr"
------------------------------

D:\ ist mein produktivvolume, V:\ ist der buchstabe der weggebrochenen partition die dann auf NAS gesichert wird (direkt im anschluß an das split-backup).

besteht vielleicht interesse an meiner SPLITBACKUP.EXE? :wink:

[I.P.]

splitbackup läuft jetzt 2 tage ohne probleme (ich lasse es im testbetrieb alle 2 stunden ausführen)

das einzige problem das sich auftun könnte ist wenn eine applikation (z.b. explorer.exe) das laufwerk V verwendet, dann kann es nämlich nicht ohne benutzerinteraktion gelöscht werden. fsutil volume dismount v hilft in diesem fall leider nicht. kennt jemand eine möglichkeit das zu umgehen?

[devzero]

>>spontan fällt mir noch eine "billigere" Variante ein:
>>- Snapshot erstellen
>>- *.vmdk als Backup sichern (also ohne *REDO*)
>>- Snapshot entfernen

>snapshots kann man meines wissens nicht im laufenden betrieb entfernen, dafür müsste >man die vm runterfahren. oder weisst du eine möglichkeit?

entfernen geht nicht - aber man kann den snapshot doch einfach bestehen lassen - vor dem nächsten backup macht man dann einen neuen snapshot und der überschreibt ja dann den alten snapshot und merged vorher den alten in die basedisk - hat zwar den nachteil, daß es _immer_ einen snapshot gibt und damit immer etwas mehr plattenplatz gebraucht wird - aber kann man doch eigentlich verschmerzen......