Datenverlust auf mehreren ReiserFS-Partitionen
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 Die Platten laufen NICHT als RAID. Die SATA-Platten sind gerade mal 2 Wochen alt. 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! 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. 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: Jun 1 04:43:32 bioserver kernel: ReiserFS: sdb1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [1 2 0x0 SD] Jun 1 04:43:32 bioserver kernel: ReiserFS: sdb1: warning: xattrs/ACLs enabled and couldn't find/create .reiserfs_priv. Failing mount. Jun 1 04:43:32 bioserver hal.hotplug[8059]: DEVPATH is not set Jun 1 07:02:43 bioserver kernel: reiserfs: using flush barriers Jun 1 07:02:44 bioserver kernel: reiserfs: disabling flush barriers on sda1 Jun 1 07:02:44 bioserver kernel: ReiserFS: warning: is_tree_node: node level 0 does not match to the expected one 65534 Jun 1 07:02:44 bioserver kernel: ReiserFS: sda1: warning: vs-5150: search_by_key: invalid format found in block 0. Fsck? Jun 1 07:02:44 bioserver kernel: ReiserFS: sda1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [1 2 0x0 SD] Jun 1 07:02:44 bioserver kernel: ReiserFS: sda1: warning: xattrs/ACLs enabled and couldn't find/create .reiserfs_priv. Failing mount. Jun 1 07:02:44 bioserver hal.hotplug[8503]: DEVPATH is not set fsck.reiserfs lieferte folgende Ergebnisse: # fsck.reiserfs --check /dev/sda reiserfs_open: the reiserfs superblock cannot be found on /dev/sda. Failed to open the filesystem. If the partition table has not been changed, and the partition is valid and it really contains a reiserfs partition, then the superblock is corrupted and you need to run this utility with --rebuild-sb. bioserver:~ # fsck.reiserfs --rebuild-sb /dev/sda reiserfsck 3.6.18 (2003 www.namesys.com) ************************************************************* ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to reiserfs-list@namesys.com, ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** ************************************************************* Will check superblock and rebuild it if needed Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes reiserfs_open: the reiserfs superblock cannot be found on /dev/sda. what the version of ReiserFS do you use[1-4] (1) 3.6.x (2) >=3.5.9 (introduced in the middle of 1999) (if you use linux 2.2, choose this one) (3) < 3.5.9 converted to new format (don't choose if unsure) (4) < 3.5.9 (this is very old format, don't choose if unsure) (X) exit 1 Enter block size [4096]: No journal device was specified. (If journal is not available, re-run with --no-journal-available option specified). Is journal default? (y/n)[y]: Did you use resizer(y/n)[n]: rebuild-sb: no uuid found, a new uuid was generated (c84d3dd2-b0cb-4a70-864b-ea1b2f9a4751) 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 Reiserfs super block in block 16 on 0x800 of format 3.6 with standard journal Count of blocks on the device: 61049632 Number of bitmaps: 1864 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 0 Root block: 0 Filesystem is NOT clean Tree height: 0 Hash function used to sort names: not set Objectid map size 0, max 972 Journal parameters: Device [0x0] Magic [0x0] Size 8193 blocks (including 1 for journal header) (first block 18) Max transaction length 1024 blocks Max batch size 900 blocks Max commit age 30 Blocks reserved by journal: 0 Fs state field: 0x1: some corruptions exist. sb_version: 2 inode generation number: 0 UUID: c84d3dd2-b0cb-4a70-864b-ea1b2f9a4751 LABEL: Set flags in SB: Is this ok ? (y/n)[n]: y The fs may still be unconsistent. Run reiserfsck --check. OK, also wieder reiserfsck --check ########### reiserfsck --check started at Wed Jun 1 07:08:32 2005 ########### Replaying journal.. No transactions found Zero bit found in on-disk bitmap after the last valid bit. Checking internal tree.. Bad root block 0. (--rebuild-tree did not complete) --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. Jetzt auf sdb: ########### reiserfsck --check started at Wed Jun 1 07:12:46 2005 ########### Replaying journal.. No transactions found Checking internal tree.. Bad root block 0. (--rebuild-tree did not complete) Hier hab ich noch kein rebuild-tree oder rebuild-sb gemacht. Was kann ich jetzt noch tun, um meine Daten noch zu retten? Bin für jede Hilfe dankbar. Freundliche Grüße, Reo Plonkert ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
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
participants (2)
-
reo plonkert
-
Sandy Drobic