Achtung, testdisk versucht, die Partitionstabelle "am lebenden Leichnam" zu restaurieren. Im Ernstfall würde ich das auf dem Sektor-Image der Platte zuerst versuchen.
vdr läuft nicht mehr...
-
-
Die 5TB hingegen klingt normal, wird im BIOS brav erkannt und fdisk, parted, smartctl meinen folgendes:
Das bestätigt meine Vermutung: 5TB o.k., 500GiB tot .
Eine Kleinigkeit an der 5TB-Platte ist auffällig:
Power_On_Hours [...] 8484 Stunden Laufzeit, das ist verdächtig wenig.
msftdata ist nur ein Flag in der GPT, kann man wohl einfach ignorieren. Linux ignoriert den Bootflag ja auch.
File systemist bei parted leer. GPT sollte eigentlich in Ordnung sein und der Fehler nur in der Partition liegen. Ich schätze, da ist beim Absturz was kaputt gegangen.
Einige Dateisysteme haben Ersatz-Masterblöcke, mit denen es beim Mounten versuchen kann (natürlich nur readonly!).
Mit XFS kenne ich mich aber nicht aus.
Laut wiki.archlinux.org kann man da mit xfs_repair -n die Consistenz prüfen, ohne was zu verändern.
-
Ja, das ist natürlich auch schlicht gelogen - die 84 Stunden Laufzeit. Ich nehme an, das hängt damit zusammen, dass smartctl disabled war. Bevor ich smarctl überhaupt auf die Platte loslassen konnte, musste ich es erst enablen. Smartctl -s
Das bestätigt meine Vermutung: 5TB o.k., 500GiB tot .
Eine Kleinigkeit an der 5TB-Platte ist auffällig:
Power_On_Hours [...] 8484 Stunden Laufzeit, das ist verdächtig wenig.
msftdata ist nur ein Flag in der GPT, kann man wohl einfach ignorieren. Linux ignoriert den Bootflag ja auch.
File systemist bei parted leer. GPT sollte eigentlich in Ordnung sein und der Fehler nur in der Partition liegen. Ich schätze, da ist beim Absturz was kaputt gegangen.
Einige Dateisysteme haben Ersatz-Masterblöcke, mit denen es beim Mounten versuchen kann (natürlich nur readonly!).
Mit XFS kenne ich mich aber nicht aus.
Laut wiki.archlinux.org kann man da mit xfs_repair -n die Consistenz prüfen, ohne was zu verändern.
Hmm, ich hab jetzt mal testdisk gestartet vor gut einer Stunde. Seither ist er dabei zu analyzen. Und zwar Cylinder für Cylinder. Bis jetzt hat er 12%, das läuft also noch die ganze Nacht durch. Meinst du das bringt nicht so viel und ich kann das abbrechen? Und stattdessen xfs_repair versuchen?
Dankeschön und viele Grüße
Peter
-
Achtung, testdisk versucht, die Partitionstabelle "am lebenden Leichnam" zu restaurieren. Im Ernstfall würde ich das auf dem Sektor-Image der Platte zuerst versuchen.
Also testdisk hat anfangs eine Partitionstabelle erkannt und angeboten, ein Backup davon ins Logfile zu speichern. Das hab ich bejaht. Und dann ging's weiter mit Analyze. Aber da kam bis jetzt keinerlei Meldung, dass testdisk irgendwas an der Partitionstabelle würde schreiben wollen.
Bei 5 TB läuft das voraussichtlich noch bis ca 06:30
-
Die Laufzeit zählen die Platten normalerweise von sich aus. Allein schon wegen Garantie usw.
War zumindest bei mir immer der Fall, auch bei Platten, die ich gebraucht bekommen habe.
Hmm, ich hab jetzt mal testdisk gestartet vor gut einer Stunde. Seither ist er dabei zu analyzen. Und zwar Cylinder für Cylinder. Bis jetzt hat er 12%, das läuft also noch die ganze Nacht durch. Meinst du das bringt nicht so viel und ich kann das abbrechen? Und stattdessen xfs_repair versuchen?
Testdisk kann die Partitionstabelle reparieren und Dateien im Filesystem finden. Also 2 unterschiedliche Funktionen.
Dateisysteme reparieren macht man eher mit den entsprechenden Tools.
Dateien suchen, das dauert halt und man muss den Kram danach womöglich noch sortieren.
Wenn man es schafft das Dateisystem irgendwie ro zu mounten tut man sich halt einfacher. Da hat man dann die Verzeichnisstruktur, was einem die Arbeit deutlich erleichtert. Dann kopiert man erstmal runter was geht und muss nur den Rest zusammenklauben.
"xfs_repair -n" erstmal prüft nur. Evtl. ist das Aufschlussreich.
Ich würde zuerst versuchen es ro zu mounten
(mount -o ro,norecovery)
und zu retten, was geht.Danach soll man es mit
xfs_repair
oder, wenn das nicht gehtxfs_repair -L
versuchen.XFS bin ich aber kein Experten, das hab ich selbst nicht im Einsatz.
Also testdisk hat anfangs eine Partitionstabelle erkannt und angeboten, ein Backup davon ins Logfile zu speichern. Das hab ich bejaht. Und dann ging's weiter mit Analyze. Aber da kam bis jetzt keinerlei Meldung, dass testdisk irgendwas an der Partitionstabelle würde schreiben wollen.
Wenn ich das noch recht erinnere schreibt er erst, wenn man was reparieren oder wiederherstellen will.
-
Tja , das hab ich jetzt versucht. Read-only geht auch nicht. Das Biest lässt sich nicht mounten
Codemount /dev/sdb3 /mnt -o ro,norecovery -t xfs mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb3, missing codepage or helper program, or other error. dmesg(1) may have more information after failed mount system call.
Ich hab's mal auch als ext4 und nur aus Verzweiflung auch als ext3 versucht. Niente. Ich bin mir fast sicher, dass es xfs sein muß. ext4 kööönnte es vielleicht auch noch sein. ext3 sicher nicht.
Dann starte ich wohl wieder testdisk, oder hast du noch eine Idee?Dankeschön und viele Grüße
Peter
-
Hi, ext3 oder 4 sind kompatibel. 4 ist als 3 lesbar.
Teste doch mal xfs_repair -L wie vorgeschlagen.
MfG Stefan
-
Besser erstmal "xfs_repair -n".
Dann sollte man wenigstens wissen, ob es überhaupt xfs ist.
Ohne das Dateisystem zu wissen ist in so einem Fall nicht wirklich was zu machen.
-
Achso, oder wie Homer sagen würde: DOH!
Ich dachte, das geht nur mounted. Hab's eben gestartet
Dankeschön und Grüße
Peter
-
So, xfs_repair -n ist durchgelaufen. Hat dann doch 12 Stunden gedauert für die 5TB. Leider ohne Erfolg.
Die Meldung war folgende:
Sieht schlecht aus.
Ich bin mir wie bereits erwähnt nicht 100% sicher, ob das tatsächlich ein xfs war. Ich meine schon, aber das ist Jahre her, dass ich dieses fs kreiert hab. Möglich wäre auch ein ext4. Was ist denn die geschätzte allgemeine Meinung? Ich würd mal auf Verdacht auch einen
drüber laufen lassen. Spricht da was dagegen?
Dankeschön und viele Grüße
Peter
-
Ich dachte, das geht nur mounted.
Anders herum, es geht nur nicht gemounted .
Ich hab zwar mit XFS keine Erfahrung, aber die Meldung lässt mich vermuten, dass es kein XFS ist.
Irgend ein Superblock findet sich eigentlich immer.
e2fsck -n sollte sicher sein (-n Open the filesystem read-only, and assume an answer of `no' to all questions.)
Besser wäre es natürlich zu wissen, um was für ein Fs es sich handelt...
-
Bei Debian sind standardmässig wohl keine xfstools drauf (zumindest bei mir nicht). Das würde bei Debian eher gegen xfs sprechen.
EXT3/4 Partitionen sollte Testdisk zuverlässig erkennen, auch wenn die stärker beschädigt sind. TestDisk_Step_By_Step_A_partition_is_still_missing
Das hat bei mir bislang auch immer geklappt.
XFS Partitionen soll Testdisk auch finden können, aber da scheint der Support nicht so tief zu gehen.
Testdisk sollte die Partition also eigentlich was finden und auch wissen um welches FS es sich handelt.
Die undelete Funktion von Testdisk ist in diesem Fall übrigens nicht sinnvoll, da die Dateien ja nicht gelöscht wurden. Dann geht es nur bei FAT, EXT und NTFS und ab ext4 klappt das AFAIK auch nicht mehr richtig.
Gleiches gilt für Photorec. Das wird die Dateien zwar finden, aber was will man mit einem Haufen namenloser .ts Dateien anfangen? Die sind im dümmsten Fall dann auch noch fragmentiert. 5TB Dateien zusammen puzzeln zu wollen kann man eher vergessen.
Irgendwie muss man die Partition also wieder lesbar bekommen.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!