SSD mit VMFS. Partition gerettet. VMDK nicht zu finden. Blockgröße falsch?

[LordB]

Hallo,

ich hoffe man kann mir hier die passenden Tipps geben.

In einem Desktop-Server steckte neben einer HDD auch eine einzelne SSD.
Auf dieser 480GB SSD lag eine durch den Benutzer eingerichtete einzelne vmfs5 Partition für ESX 5.5.
Über die komplette Größe wurde ein Datenspeicher angelegt.
Auf dem Datenspeicher befindet sich eine VM-Festplatte (vmdk bzw vmdk.flat)

Nun ist (/ironie an/ wie unerwartet /ironie aus/) die SSD ausgefallen bzw. stehen geblieben, da der Datenspeicher überfüllt worden ist und die SSD offenbar keine Zeit oder Platz für eine Garbage Collection hat.

Sie ist schlicht offline gegangen und stand dem System nicht mehr zur Verfügung.

Nach einem Neustart zeigte sich die SSD wieder - für ein paar Minuten - und zeigte die Partition und den Datenspeicher an. Einige Minuten wie gesagt, denn dann plötzlich nur noch 0Byte statt 447,13 GB für den Datenspeicher und anschließend viel die Partition bzw. die SSD erneut aus.

Ich habe diese SSD nun ausgebaut und in ein Gehäuse gesteckt.

Mit Testdisk wurde anfangs erst mal gar nichts gefunden. Nach einem Deep Scan für intel/PC basierte Partitionen wurde die VMFS dann letztendlich gefunden und ich habe diese Konfig schreiben lassen. Seit dem ist die vmfs Partition wieder da, die SSD läuft ohne auszufallen.

An einem ESX angeschlossen ist zwar nun die SSD mit der vmfs Partition, aber der Datenspeicher nicht mehr da.
Ich kann also nicht auf die vmdk zugreifen um die virtuelle Platte zu sichern.

Testdisk beschreibt nun die Partition wie folgt:
Partition...Start.............End....Size in sectors
1 * VMFS 0 32 33 58352 65 17 937426944

Schaue ich in die Geometrie der SSD wurde für die Partition folgendes genutzt:

Cylinders 58369 Heads 255 Sectors 63 Sector Size 512

Was mich iritiert: im ESX wird die Blockgröße mit 7,84MB angezeigt. Außerdem mbr. Das finde ich ungewöhnlich. Andere VMFS Partitionen haben immer 1MB Blockgröße. Ob gpt der Standard ist, kann ich jetzt nicht

Hier eine normale VMFS Partition:
gpt
Typ VMFS
Startblock 0
Endblock 1019742
Blockgröße 1 MB
Größe 995,84 GB (1019742 Blöcke)

Hier die die SSD
mbr
Typ VMFS
Startblock 0
Endblock 58352
Blockgröße 7,84 MB
Größe 447 GB (58352 Blöcke)

Ich habe in jedem Fall ein Image gezogen, sodass man experimentieren kann. Ziel ist es die Festplattendatei zu retten. Es ist leider nicht hilfreich Daten aus der vmdk selbst zu holen. Es handelt sich um >400GB Userdaten in verschiedenen Ordnern.


Darüber, was an der Planung/Nutzung einer einzelnen SSD in einem ESX Server (selbstverständlich ohne Datensicherung) falsch ist, brauchen wir nicht reden. Das habe ich bereits zur Genüge gepredigt... :-/

Ich hoffe jedenfalls mal sehr auf einen Tipp.

 

[Baalthorun]

Normal ist das Partitionsformat GPT(MBR wird bis vmfs3 supported) und die Blockgröße kann durchaus größer als 1MB sein. Zumindest über die GUI lässt sich dies aber nur in ganzen MB Schritten konfigurieren. Nicht 7,84!

So aus der Ferne würde ich sagen das mindestens die Partitionstabelle beschädigt ist. Vermutlich noch mehr!

Wie dies wiederherzustellen ist, übersteigt allerdings meine Kentnisse. Ich fürchte dies wird nicht ohne weiteres möglich sein.

 

[LordB]

Okay, ist ein Anfang, Danke schon mal für Deine Antwort.
Auf gpt wechseln ist weniger das Problem, aber wie bekomme ich die Blockgröße auf 1MB OHNE neu zu partitionieren? (Testdisk?)

Wenn ich Photorec drauf los lasse, findet es die Dateien der User.
Also die Inhalte sind noch da und können - natürlich unsortiert wiederhergestellt werden. Das nutzt mir aber so nichts. Ich brauche die vmdk (vmdk.flat) als Ganzes, sonst ist die Ordnerstruktur futsch. Oder kann Photorec auch die originalen Strukturen wieder herstellen und ich kenne nur die Option nicht?

 

[Baalthorun]

Vermutlich wird die Blockgröße nur fehlerhaft in der Partitionstabelle hinterlegt sein. Evtl diese mal reparieren/neu erstellen. Du hast ja eine Kopie der Platte.

Pfotorec kenne ich nicht aber du kannst es mal mit vmfs Treibern für Windows probieren ob du damit direkt an die vmdk ran kommst. http://woshub.com/how-to-access-vmfs-datastore-from-linux-windows/#h2_2
Habe ich selbst noch nicht gemacht ist also eher theoretischer Natur.

Denke am besten fährst du aber wenn du die Partitionstabelle repariert bekommst. Oder ne ganz andere Alternative hättest du noch wenn ihr Support bei VmWare habt. Oder ist das eine rein private Angelegenheit?

 

[LordB]

Photorec gehört zum Testdisk quasi dazu. Es stellt Daten wieder her. Das läuft jetzt auch seit Gestern erst mal. Leider stellt es die Daten nicht mit Ordner- /Dateinamen etc wieder her. Ärgerlich, aber nicht zu ändern.

Die Partitionstabelle würde ich ja gerne entsprechend herstellen, da fehlt mir dann aber jetzt die Expertise um auf die richtige Blockgröße von 1MB zu kommen.

Es besteht kein Supportvertrag.

 

[Holt]

Nun ist (/ironie an/ wie unerwartet /ironie aus/) die SSD ausgefallen bzw. stehen geblieben, da der Datenspeicher überfüllt worden ist und die SSD offenbar keine Zeit oder Platz für eine Garbage Collection hat.

Sowas kann nicht passieren, da jede, wirklich jede SSD immer mehr NAND als Nutzkapazität hat und daher der Controller immer über eine Free Area verfügt um seine Garbage Collection durchzuführen. Eine SSD wird nämlich immer mehr NAND Kapazität in GiB als Nutzkapazität in GB haben, da habe ich noch keine gesehen wo dies anderes wäre.

Sie ist schlicht offline gegangen und stand dem System nicht mehr zur Verfügung.

Wird sie nicht mehr erkannt oder hat VM sie offline genommen weil das Filesystem voll war? Zwar kenne ich mich mit den VMWare Filesystemen nicht aus, aber bei Linux darf ein normaler User nur 90% der Kapazität eines Filesystems beschreiben, die letzten 10% sind nur mit root Rechten beschreibbar.

Nach einem Neustart zeigte sich die SSD wieder - für ein paar Minuten - und zeigte die Partition und den Datenspeicher an. Einige Minuten wie gesagt, denn dann plötzlich nur noch 0Byte statt 447,13 GB für den Datenspeicher und anschließend viel die Partition bzw. die SSD erneut aus.

Welche SSD ist es denn?

habe diese Konfig schreiben lassen. Seit dem ist die vmfs Partition wieder da, die SSD läuft ohne auszufallen.

Bei der Datenrettung sollte man niemals etwas auf die Platte Schreiben von der die Daten gerettet werden sollen. Außerdem ist klar das hinterher angezeigt wird, was vorher geschrieben wurde, dies sagt aber eben nicht, dass dies auch korrekt ist. Immerhin zeigt es, dass die HW der SSD selbst wohl nicht das Problem ist, wenn etwas geschrieben wurde und danach so auch wieder ausgelesen wird.

Ich habe in jedem Fall ein Image gezogen, sodass man experimentieren kann.

Hoffentlich vor der oben beschriebenen Aktion mit Testdisk.

 

[LordB]

Sowas kann nicht passieren, da jede, wirklich jede SSD immer mehr NAND als Nutzkapazität hat und daher der Controller immer über eine Free Area verfügt um seine Garbage Collection durchzuführen. Eine SSD wird nämlich immer mehr NAND Kapazität in GiB als Nutzkapazität in GB haben, da habe ich noch keine gesehen wo dies anderes wäre.

Dieses verhalten ist mir schon zum zweiten mal untergekommen. Ich weiß nicht ob uns eine Grundsatzdiskussion an dieser Stelle weiter bringen würde. Meine Crucial SSD MX300 750GB hat genau dieses Verhalten an den Tag gelegt, Hintergrund war vor allen Dingen, dass eben keine Zeit für die Garbage Collection zur Verfügung stand und sie somit voll gelaufen ist. (Ggf auch die Free Area?) Dann schaltete sich die SSD schlicht ab.

 

[Holt]

Es steht einem SSD Controller immer eine Free Area zur Verfügung, zur Not schafft er sich den freien Platz eben indem er die Garbage Collection ausführt, dann ist die Schreibperformance zwar mies, aber dies ist eben SSDs auf NAND Basis eben so und ist in Tests wie dem er Performance Consistancy auch schön zu sehen, da bleiben die SSDs auch nicht stehe oder schalten sich ab. Wenn Deine MX300 dies gemacht hat, lag dafür eine andere Ursache vor.

Etwas anderes ist es was auf Seiten des OS passiert wenn die Nutzkapazität voll ist, aber da gibt es dann keinen Unterscheid ob es eine HDD oder eine SSD ist, wenn nicht mehr geschrieben werden kann weil kein Platz auf der Partition mehr frei ist, dann hat man ein Problem und eigentlich immer Datenverlust.

 

[LordB]

Dann weißt Du an dieser stelle mehr als der Hersteller ...

 

[Holt]

Welcher Hersteller behauptet denn das Gegenteil? Die NAND Kapazität ist bei jeder SSD immer höher als die Nutzkapazität, oder zeige mir eine SSD bei der dies nicht der Fall ist. Vergiss nicht, dass die Kapazität von NAND Dies immer in Gigabit angegeben wird.

 

[LordB]

Wie geschrieben habe ich kein Interesse an einer Grundsatzdiskussion. Wenn Du meinst das Abschalten hätte andere Gründe als die, die Micron mir mitgeteilt hat will ich nicht dagegen argumentieren. Insbesondere da es vom akuten Problemfall abschweift.

 

[Holt]

Wenn der Support von Micron/Crucial behauptet die SSD hätte ein Problem weil sie ganz voll geworden ist, dann hatte der Mitarbeiter keine Ahnung oder Du hast es missverstanden, denn nicht die SSD bekommt dann schnell ein Problem, wohl aber das Filesystem. Deshalb darf man unter Linux auch nur mit root Rechten die letzten 10% der Kapazität einer Partition beschreiben.

TestDisk unterstützt viele Filesysteme aber laut der Liste auf der Homepage kein VMFS, es kann lediglich seit Version 6.13 die VMFS Partitionen erkennen. Zur Datenwiederherstellung wirst Du also auf andere Tools wie VMFS Recovery zurückgreifen müssen, es gibt davon immerhin eine kostenlose Testversion. Ich selbst kenne weder VMFS Recovery noch andere Tools für VMFS, Goolgle hat mir dies nur ausgespuckt und wird Dir ggf. dann auch Alternativen vorschlagen können.