..nachdem ich mittlerweile wirklich viele verschiedene software-lösungen gestestet habe, um mein zerstörtes system (storagepool) zu "retten", habe ich wohl EIN tool gefunden, was augenscheinlich mit storage spaces umgehen kann. ich sah bzw. vermute, das meine 1% nullung eh schon soweit war, dass mehr als nur die msr-partition überschrieben wurde, sondern auch der anfang der ms daten partition und manch programm, wie das minitool, dem pool mbr statt gpt zuschrieb und das kann ja so nix werden. hatte dort auch nix gefunden, um testehalber es erzwungener maßen "einzustellen", daher womgl. der unterschied zu @dk2000 bei seinem versuch dies nachzustellen und den pool zu rekonstruieren. das tool diskgenius hat nach click auf den pool sofort einen fehler erkannt und daraufhinn habe ich, nach anfänglicher zögerung diese korrektur fest gespeichert. jetzt ist mein pool bzw. dateisystemstruktur im raw-modus. mit dem tool wußte ich vorerst nicht weiter und bin zum minitool gewechselt und jetzt wird zumindest meine 2 partitionen angezeigt. mal sehen, wie es um die jetztige wiederherstellung der partition steht?! mit diskgenius werde ich ggf. einen vergleich ziehen, bevor iwelche änderungen fest geschrieben werden.. ich bleibe dran.

edit: ich habe es aufgegeben, meine odnerstruktur und deren dateinamen, zumindest teilweise wieder zurück zu erhalten, da anscheind kein "normalo" prog in der lage ist, einen einmal low level formatierten daten-bereich auf der hdd, wo die mft in mitleidenschaft gezogen wurde, wiederherzustellen. ich habe auch versucht ab dem unbeschädigten sektorbereich einzugrenzen, um wengisten diese struktur wiederherzustellen, aber dies war ebenfalls nicht mgl. es ist auch egal, ob die mftmirr oder sonstige ntfs bootsector backup unbeschädigt sind/waren und diese dann an den anfang zurückgeschrieben wurden.. mit dem prog diskgenius jedenfalls und mit dem tool testdisk hatte ich die größtmöglichen optionen..
photorec kennt weniger dateitypen, daher ist diskgenius z.z. auch besser um raw-daten zu interpretieren und ggf. zu sichern..
@dk2000 wenn du das szenario, wie anfangs bei dir gemacht, killdisk paar sekunden länger laufen lassen würdest, dann hättest du wahrscheinlich genau mein szenario. testdisk muss dir nur anzeigen, dass dein ntfs bootsector "schlecht" ist, dann wurde zuviel genullt.

so, nun habe ich leider die ernüchterung meiner vesuche mit testdisk den pool bzw. die daten zu retten, teils aufgegeben. alles bisherige hat leider nicht so geklappt, wie es sein sollte. ich kann nicht auf die daten zugreifen. ich habe mich im cgsecurity forum angemeldet, mein problem geschildert u nachgefragt u mir wurde von einem gesagt, da er aktuell mit dem entwickler kontakt hat, dass storage spaces NICHT unterstützt werden. ach und das image ist leider nicht eins zu eins mit dem pool zu vergleichen, da halt die sektoren abbildung beim kopieren/speichern in eine datei so verloren geht u dadurch keine bearbeitung dieser möglich ist..

ich habe mal einen anderen pool erstellt und da habe ich auch "nur" die 2 partitionen ms reserved u ms data u da sind bei boot beide ok. laut fallbeispiel https://www.cgsecurity.org/wiki/Schritt ... suchen_.3F wird das in den schritten so angezeigt. es ist ja nicht so, als hätte man keine wahl , aber einmal eine änderung dbzgl. gemacht u das war es evtl. dann..
ich getrau mich NOCH nicht an diese änderung, da ich es erst beim erstellten image testen möchte, ob ich dann die daten einsehen u evtl. sogar kopieren kann. ich meld mich einfach nochmal, wenn ich weiter gekommen bin.

edit: laut dieser seite, sollte es i.d.r. eine reserved und eine data partition geben https://www.ufsexplorer.com/de/articles ... spaces.php

edit 2: ich habe nochmal genauer in der dokumentation von testdisk nachgelesen und da heißt es, dass die rebuild bs funktion bei "versehentlich" überschriebenen dateisystemen z.b. fat zu ntfs oder umgekehrt zum einsatz kommt

Wenn ich das mache, sieht das bei mir so aus:
Was passiert denn, wenn Du auf "Rebuild BS" gehst? Der Bootsektor ist für GPT eigentlich uninteressant. Aber eventuell muss der "Protective MBR" in takt sein.

würdest du mal bitte testen, wenn du noch den kleinen pool mit den gespiegelten daten hast u killdsik bei 1% abgebrochen hast u du dann
1. mit testdisk_win.exe den msft auswählst
2. efi gpt bestätigst
3. advanced partition 2 mit ms data markierst und "unten" type auswählst
4. ms data "proceed" bestätigst
5. ntfs proceed wählst,
was bei dir "unten" als optionen möglich ist? da müsste boot wählbar sein.. gpt hat ja auch den backup header. boot sector is da vlt. nicht gut ausgedrückt. kannst du vorher schon die daten aufgelistet (iso) sehen? falls ja, muss mein dateisystem weiter beschädigt sein

edit: ach mist, mich ärgert es, dass ich bei killdisk versehentlich msft virtuelles laufwerk kurz genullt habe und nicht eine physische platte von dem pool. damit wäre die wiederherstellung des pools eigentlich problemlos gelungen..
es gibt noch von on-track ein tool was ich installiert habe, aber werd mich nach minitool erstmal auf mein kopiertes image von testdisk konzentrieren. mal sehn, ob ich endlich damit ausreichend erfolg haben werde

Gibt keinen Bootsektoren bei mir, da GPT so etwas nicht kennt. Bootsektoren gibt es nur bei MBR. Daher wunder mich das bei Dir.

MiniTool Partition Wizard lasse ich hauch gerade mal über die abgetrennte HDD laufen, aber Schnellsuche scheint da nicht viel zu brigen. Diese ganzen Einzelpartitinen findet der nur beim Vollscann.

MiniTool Partition Wizard ist genauso nutzlos, was die Wiederherstellung von Dateien angeht. Man kann nur betrachten, was gefunden wurde. Zum Wiederherstellen benötigt man einen Key. Das Selbe scheint auch für die Wiederherstellung von Partitionen zu gelten. Mist.

ich danke dir vielmals für deine mühe und das testen dieser konstellation. noch läuft auch minitool partition wizard und scannt (quick) noch, schon seit heute vormittag..
@dk2000 war bei dir unter advanced der boot sector vom ntfs noch i.o.?

Auch wenn man eine Zwei-Wege-Spiegelung verwendet und im Pool 4 HDDs sind, dann scheint Windows da alle HDDs gleichmäßig zu verwenden. Mann kann zwar nur als maximale Größe für den Speicherplatz die Kapazität von 2 HDDs verwenden, aber die Daten werden dann auf allen 4 HDDs verteilt.

Habe mir da auch mal die einzelnen Laufwerke im Disk Editor angeschaut und da ist irgendwie nicht mir vertrautes zu finden. Da ist etwas drauf, aber irgendwie anders organisiert. Ist zwar GPT und NTFS, aber halt nicht so, wie auf einer normalen HDD. Damit ist Testdisk wohl überfordert.

Habe dann mal MiniTool Power Data Recovery über diese eine HDD laufen lassen und dieses hat da tatsächlich die vier ISO Dateien in einer Partition 7 gefunden. Insgesamt hat es da 9 Partitionen gefunden. Ob sich diese wieder herstellen lassen, weiß ich nicht, da ich dazu das Tool kaufen müsste.

Aber eventuell gibt es da noch weitere Tools, auch Freeware, die damit klar kommen.

---

Was den Screenshot angeht, was hast Du da gemacht? Das sieht jetzt gar nicht gut aus.

das muss ich testen, da aber 4 hdds (davon 2 genutzter speicher) gespiegelt sind, werde ich höchstwahrscheinlich nur einen teil meiner daten sehen bzw. ggf. wiederherstellen können, da etwas mehr als 2 tb belegt waren..
ok, aber zwichen den beiden msft storage space gab es, glaube ich speichergrößenunterschiede. ich werde mal nach dem "proceed" beider msft, die unterpunkte hier nun reinstellen.. moment..

im post 12, siehst du das ergebnis von ..physicaldrive12.., nachdem ein komplettscan (analyse) durch testdisk gemacht wurde

edit: ich habe, fällt mir ein, ein image von der ms data "partition" (von physicaldrive12) schon angelegt. da werde ich mal eine kopie von machen und davon testen. nichtsdestotrotz stelle ich noch weiter die bilder ein..

edit 2: glaub, du hast recht, es macht bei der auswahl des media keine sichtbaren unterschied, welches msft man auswählt

edit 3: zu deinem beitrag weiter oben, nach der gpt auswahl konnte ich nur noch type,image creation oder quit auswählen,habe dann type alles wie gehabt "ms data" und danach "ntfs" ausgewählt und dann konnte ich, siehe bild, dieses auswählen
..hier der weg, den ich gegangen bin, zuerst msft (sdm) > proceed , efit gpt partition detect bestätigt > advanced (filesystem utilities) > 2 ms data partition markiert und "type" ms data proceed > partition type "ntfs" gewählt > proceed > "neue auswahlpunkte" > zum test undelete gewählt > filesystem seems damaged > quit > "boot" sector recovery > siehe bild
ich getraue mich das noch nicht auszuführen, aber dieses muss ja wohl geschehen, damit die daten darauf gesehen werden können?! wie gesagt, ich teste es mal zuerst mit dem image, aber kopiert noch..

Das ging bei mir mit beiden Varianten, \\.\PhysicalDrive12 und /dev/sdf ist das Selbe.

WIe sieht es denn bei Dir aus, wenn Du /dev/sdf auswählst, danach EFI GPT, jetzt Analyse auswählst?

..also, ich kann diese 57er "fehler" im slow ring (19041.172) bestätigen..
hatte den pool, aber in normal-winver weit davor erstellt, aber ich hab zur not nen win-server, um da einen neuen pool zu erstellen.
was aber mein hauptanliegen ist, warum ich hier wieder schreibe ist, dass "nur" die txt-dateien und paar wenige andere dateitypen durch tesdisk "wiederhergestellt" wurden. iso und andere typen sind leider in iwelche andere dateitypen aufgeteilt wurden
ich habe mal weitere tools, wie das minitool (verschiedene versionen partition, datenwiederherstellung getestet) genomm und es konnten wesentlich mehr typen richtig erkennen (auslesen) und "wiederherstellen", aber es reicht leider immernoch nicht, um auf meine z.b. selbst erstellten iso-typen und gepackten dateien wiederherzustellen. wichtig wäre mir schon die ordnerstruktur, da es mir so sonst nicht möglich ist, alles richtig zuzuordnen..
nun, da ich es weiter mit testdisk versuche, würde ich gern wissen, welches media (siehe bild) ich nehmen soll, um die dateistruktur (partition) wiederherzustellen? ich würde hier ggf. die weiteren "unterpunkte" in testdisk posten.
ich habe es mal auf die betreffenden "medien" gekürzt..
..physicaldrive12 ist ja das virtuelle laufwerk vom pool gewesen, also der erstellte speicherplatz mit dem laufwerksbuchstaben. ich glaub diser war nicht dynamisch, sondern fest eingestellt worden..
..disk..sdm ist ja aus den laufwerken (gespiegelt) sdi,sdj,sdk,sdl erstellte speicherpool
nun zurück zur obigen frage, physicaldrive12 oder sdm auswählen, um die partition wiederherzustellen?

Stimmt. Da gab es ja noch etwas im Slow Ring. Gut, schnell installiert, jetzt 19041.172, aber immer noch 0x00000057 beim Versuch, einen Pool zu erstellen. Daran lag es also nicht. Muss ein Bug sein. In der 20H2 keine Probleme gehabt, eine Pool mit 4 virtuellen 256 GB HDDs zu erstellt.

---

Habe da eine Zwei-Wege-Spiegelung mit vier HDDs angelegt, den daraus resultierenden Speicherplatz in zwei Partitionen geteilt und danach mittels Killdisk 1% des Laufwerks gelöscht, welches dem Speicherplatz repräsentierte. Beide Partitionen waren natürlich weg, das Laufwerk wurde als nicht-initialisiert und leer angezeigt.

Hatte danach aber mit Testdisk keine Probleme, die zweite Partition von Speicherplatz zu 100% wieder herzustellen. Die erste Partition war natürlich verloren. Das ging auch eigentlich schnell, da die alternative GPT noch vorhanden war. Konnte den Scan abbrechen und die Partion 2 war "Grün" und ließ sich ohne Probleme schreiben.

Als Du mit Testdisk gestartet hast, hattest Du das ausgewählt:

\\.\PhysicalDrive12 - .... - Msft Storage Space bzw. /dev/sdf - .... - Msft Storage Space

Je nachdem wie viele Laufwerke installiert sind, kann sich /dev/sdf bei Dir unterscheiden. Wichtig ist nur das Msft Storage Space am Ende.

Und danach [EFI GPT] EFI GPT partition map

Habe da auch einmal versucht, die Laufwerke im Pool einzeln zu scannen, aber das funktioniert irgendwie nicht. Das Endet dann so, wie auf Deinem Screenshot in dem Beitrag viewtopic.php?f=328&t=23506#p343294 zu sehen ist.

Mal auf die 19041.172 aktualisieren?

Wollte das mal so nebenbei in der VM nachstellen und mal schauen, was Testdisk da so genau macht bzw. wie das mit der Spiegelung überhaut funktioniert.

Aber es funktioniert nicht mit der 2004 (19041.153). Egal was ich da anstelle, ich kann keinen Pool erstellen. Das Endet immer mit 0x00000057 (Falscher Parameter) und der Vorgang wird abgebrochen. Auch über die Powershell kann ich keinen Pool erstellen. Die dafür vorgesehenen virtuellen HDDs werden alle mit "CanPool=True" angezeigt, aber wenn ich es dennoch versuche, endet das mit "Das angeforderte Objekt wurde nicht gefunden."

Mache ich genau das Selbe mit der 20H2 (19592.1001) funktioniert das alles wie erwartet. Kann den Pool ganz normal erstellen (über die GUI und in der Powershell). Keine Probleme.

Ist das in der 2004 (19041.153) ein weiterer Bug, der bislang an mir vorbei gegangen ist? Sehe da im Moment keinen Grund, warum das hier nicht klappt und mit 0x00000057 endet.

Na wenigstens eine gute Nachricht.