Zugriff auf ein Spanned Volumes mit mehreren VMDKs

[pirx]

Hallo,

ich versuchen eine VM mit einem großen spanned Windows Volumes zu sichern. Das funktioniert grundsätzlich. Wie sieht es im Fehlerfall aus? Ich kenne mich zu wenig mit W2Kx aus, kann ich immer noch in die einzelnen VMDKs reinschauen und auf die Dateien dort zugreifen? Unsere Backup Software bietet die Möglichkeit in VMDKs die im Backup Repository liegen zu browsen und single file restores durchzuführen. Eine Lösung mit mehreren Laufwerken die alle in ihrem eigenen VMDK liegen, scheidet aus. vSphere 5.5 wo ich größere VMDKs anlegen kann, ist aktuell auch nicht verfügbar.

Ich kann das am Mo. mit 3 kleineren VMDKs testen, grüble aber gerade schon über die Umsetzung....

[mbreidenbach]

Grundsätzlich kann man eine VMDK in eine andere VM reinhängen und darauf zugreifen.

Wie das mit logischen Laufwerken funktioniert die über mehrere VMDKs gesplittet sind habe ich allerdings nie getestet. Sollte ich mal.

Ich habe schon mal einen zerlegten Fileservern aus einer neuen Windowsinstallation und den alten Daten VMDKs zusammengebastelt. Solange der Fileserver einfach Domänenmitglied ist geht das recht gut. Die Freigaben habe ich aus der Registry ex- und importiert.

[Dayworker]

Auch solche VMDKs lassen sich umhängen. Man sollte dann aber auch wirklich alle dazugehörenden VMDKs mitnehmen, da die VMDKs bzw das Volume keinerlei Raid-Funktionalität besitzt und eine vergessene VMDK folglich immer zu einem Komplettausfall des Volumes führt. Lies dir dazu mal http://vmtoday.com/2013/04/is-spanning-vmdks-using-windows-dynamic-disks-a-good-idea/ durch.

[pirx]

Ich muss vielleicht etwas weiter ausholen. In dem spanned Windows Laufwerk befinden sich auf den 5TB die über 3 VMDKs gehen, die Backup anderer VMs. Auf dem Volume ist Dedup aktiviert, rehydriert liegen aktuell 23TB auf dem Laufwerk.

Diese Daten sollen am Wochenende zu einem zweiten Standwort gesichert werden, da unsere B2T Lösung mit dem W2012 Dedup Volume nicht viel anfangen kann, sichert sie immer die 23TB. Dafür reicht aber das Zeitfenster nicht. Deswegen will ich nun, dass sich die B2D Lösung selber sichert und die VMDKs auf ein Share (wieder mit Dedup) am zweiten Standort ablegt. Die VMDKs haben ja nur 5TB, das ist im Zeitfenster möglich.

Soweit so gut, im Idealfall kann ich durch Dedup am zweiten Standort auch mehrere Backup Versionen der B2D VM aufbewahren und über die "Browse Files" Funktion der Software in die VMDKs schauen und auf ältere Backups von gesicherten VMs zugreifen. Dazu muss ich dann aber in den 3 VMDKs der Backup VM die passenden Dateien finden...

[~thc]

Beim Lesen dieses Beitrags fühlte ich mich an IPSec erinnert: Too complex to be secure.

Was mir noch an Info fehlt: Sind auf dem Spanned Volume VMDKs anderer VMs abgelegt? Wenn ja, welchen Fehlerfall meinst du? Musst du regelmäßig (oder nur im Fehlerfall) auf die Inhalte des Spanned Volumes zugreifen und meinst den Fehlerfall der 2012er VM? Das Backup-Ziel der B2D-VM liegt auf einem Dedup-Volume? Ist das auch ein solches Spanned Volume?

Ob die Backup-Software auf ein NTFS-Dateisystem innerhalb einer VMDK zugreifen kann, das Teil eines Spanned Volumes mit Dedup ist, möchte ich doch bezweifeln - das hat ja eher etwas mit den Möglichkeiten der Software als mit dem 2012er Windows zu tun.

[JustMe]

Sorry, wenn ich was nicht richtig verstanden habe, aber:
Was hat dieses Thema jetzt mit Virtualisierung im Allgemeinen, sowie mit VMware im Besonderen zu tun?

Die Frage, die zu klären wäre, ist m.E. doch, ob ein Server2012 auf das Buendel von drei Festplatten sinnvoll zugreifen kann, wenn diese in einen anderen Rechner eingebaut werden (das zumindest sollte er doch hoffentlich koennen); bzw. auch auf eine einzelne davon, wenn nicht alle verfuegbar sind. Nichts anderes ist doch das Umhaengen der vmdk an eine andere VM.
Wenn das machbar ist, ist alles gut; falls nicht, hilft da auch nicht weiter, dass der Windows-Rechner virtualisiert ist.
Ob sich die Sicherungsloesung selbst sichern kann, ist dann wieder noch ein anderes Thema. Ich bezweifel' mal, dass das (inkl. des Sicherungsziels) geht...
Ansonsten wird ein Weg gewaehlt, einfach die vmdk-Dateien moeglichst rasch von A nach B zu uebertragen, unabhaengig von dem, was drauf gespeichert ist, und gut ist's...