reo plonkert wrote:
Hallo! Ich betreibe einen Server mit Suse Linux 9.2 (jetzt 9.3) und 3 Festplatten. Hier eine Auflistung inklusive der Partitionen (alle ReiserFS). 1. Festplatte (IDE): /dev/hda /dev/hda1 --> swap /dev/hda2 --> / /dev/hda3 --> daten
2. Festplatte (SATA): /dev/sda /dev/sda1 --> daten
3. Festplatte (SATA): /dev/sda /dev/sda2 --> daten
Wenn dies eine weitere Festplatte ist, sollte sie dann nicht als /dev/sdb, /dev/sdb1 eingehängt sein?
Die Platten laufen NICHT als RAID. Die SATA-Platten sind gerade mal 2 Wochen alt.
RAID schützt nur vor Hardware-Ausfall, nicht vor einem Versagen der Software-Datenstruktur wie hier. Das hätte dir auch auf Hardware-RAID passieren können.
Nach einer Unterbrechung der Stromzufuhr und anschließendem Neustart startete Suse 9.2 nur noch im Maintenance Mode, da die Daten auf meinen Partitionen beschädigt waren - und zwar anscheinend auf allen!
Hängt der Server nicht hinter einer USV? Die kosten heute nicht mehr so viel und filtern dazu noch Überspannungen und Co aus dem Netz.
hda3, sda1 und sda2 (daten) ließen sich gar nicht mehr mounten, hda2 (/) zumindest noch readonly.
Da mein Versuch, hda alleine mit fsck.feiserfs zu reparieren (fix-fixable, check, rebuild-tree), scheiterte, ist dort inzwischen Suse 9.3 installiert und die Platte funktioniert. Hierzu musste ich die komplette Festplatte neu partitionieren, da sich der Rechner sonst beim Schreiben auf die Partitionstabelle oder beim Formatieren vorhandener Partitionen aufhängte.
Das klingt doch interessant. Kann es sein, dass deine Partitionstabelle durcheinandergekommen ist? Versuche doch mal die typischen Rettungstools auf die Partitionstabelle anzusetzen und prüfe, ob die wirklich in Ordnung ist.
die beiden PArtitionen auf den SATA-Platten lassen sich immer noch nicht mounten.
auf sda1 hab ich rebuild-tree und rebuild-sb versucht, auf sdb1 noch nichts. Hier die Fehlerausgaben beim mounten:
Eigentlich schon zu spät, aber trotzdem: bevor du Rettungsversuche auf solchen Platten machst, solltest du vorher eine identische Kopie mit dd erstellen und auf DIESER die Reparaturversuche laufen lassen.
rebuild-sb: You either have a corrupted journal or have just changed the start of the partition with some partition table editor. If you are sure that the start of the partition is ok, rebuild the journal header. Do you want to rebuild the journal header? (y/n)[n]: y
Gibt es irgendwelche Meldungen (aus dmsg etwa) welche darauf hindeuten? Ist vielleicht im BIOS des Servers der Eintrag der Platte geändert, steht dort automatisch und das BIOS hat eine anderes Mapping für die Platte eingetragen?
--rebuild-tree endet hiermit: No reiserfs metadata found. If you are sure that you had the reiserfs on this partition, then the start of the partition might be changed or all data were wiped out. The start of the partition may get changed by a partitioner if you have used one. Then you probably rebuilt the superblock as there was no one. Zero the block at 64K offset from the start of the partition (a new super block you have just built) and try to move the start of the partition a few cylinders aside and check if debugreiserfs /dev/xxx detects a reiserfs super block. If it does this is likely to be the right super block version. If this makes you nervous, try www.namesys.com/support.html, and for $25 the author of fsck, or a colleague if he is out, will step you through it all.
Wieder der Hinweis auf die Partitionstabelle(n). Es scheint, alle deine Probleme hängen damit zusammen.
Jetzt auf sdb: Hier hab ich noch kein rebuild-tree oder rebuild-sb gemacht.
Gut! Dann würde ich erst einmal eine Kopie mit dd anlegen und alle weiteren Versuche damit fortführen.
Was kann ich jetzt noch tun, um meine Daten noch zu retten? Bin für jede Hilfe dankbar. Freundliche Grüße,
Prüfe wie gesagt die Partitionstabellen und die Art, wie die Platten im Bios eingetragen sind. Und wie üblich, wenn dir die Daten etwas wert sind, dann mache ein Backup dieser Daten. Sandy