Zerstörte Files wiederherstellen

[betrazivis]

Hallo,
mir ist heute Nacht ein kleines Unglück passiert: Eine Serverfestplatte hat es zerschossen.
Glücklicherweise sind alle Daten dank RAID noch vorhanden, nur mit meinem Bilderordner(ca. 2.000.000 Dateien) scheint etwas passiert zu sein. "ls" zeigt zwar an, dass Dateien da sind, kann diese aber nicht finden.

z.B.

Code: Select all

/bin/ls: 53f5e90_default.gif: No such file or directory

Gibt es für Linux ein Programm mit dem ich diese verlorenen Daren wiederherstellen kann?

[Joe User]

Für die Zukunft: Mit XFS wäre es nicht (in dem Umfang) passiert. Ext2/3 und ReiserFS sind in solchen Fällen viel zu anfällig für Datenverluste...

Bei der Menge an betroffenen Files ist eine Wiederherstellung für Amateure extrem Zeitaufwendig bis unmöglich. Hier hilft nur eine darauf spezialisierte Datenrettungsfirma, was nicht unbedingt günstig sein mag. Wenn es also ein Hobby-Projekt ist, ist der Vorfall unter "shit happens" zu verbuchen und künftig durch die Wahl eines diesbezüglich stabileren FS (XFS) zu vermeiden...

[betrazivis]

Wenn es also ein Hobby-Projekt ist, ist der Vorfall unter "shit happens" zu verbuchen...

ne leider kein Hobby-Projekt ;( ...So...EIN..MIST...

[Roger Wilco]

Gibt es für Linux ein Programm mit dem ich diese verlorenen Daren wiederherstellen kann?

Je nach verwendetem Dateisystem fsck, reiserfsck oder xfs_check/xfs_repair. Bei anderen, exotischeren Dateisystemen sollte es entsprechende Programme geben.

[betrazivis]

Also xfs_check spuckt mir sowas hier aus, da scheint also schonmal was nicht zu stimmen:

Code: Select all

xfs_check: unexpected XFS SB magic number 0x00000000
xfs_check: read failed: Invalid argument
xfs_check: data size check failed
xfs_check: cannot read root inode (22)
xfs_check: cannot read realtime bitmap inode (22)
/usr/sbin/xfs_check: line 56:  9238 Segmentation fault      xfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1

//EDIT
Da es bei 1&1 aber Probleme mit der Sercon und dem Rescuesystem gibt und ich mich zur Zeit nicht traue das Ding zu rebooten, werde ich auch einen Teufel tun, jetzt Partionen auszuhängen.
Richtig scheint aber zu sein, dass etwas nicht stimmt.
Die Hoffnung stirbt zuletzt.

[Joe User]

Du hast xfs_check aber nicht auf eine gemountete Partition losgelassen? Sowas macht man grundsätzlich nur im ungemounteten Zustand.
Stimmen die Versionen der xfsprogs beim Anlegen und Reparieren überein beziehungsweise ist die zum Rearieren genutzte aktueller als die zum Anlegen genutzte? Am Besten ist es zuerst die aktuellsten xfsprogs 2.9.8 zu installieren und diese zum Check/Dump/Repair zu nutzen.
Bitte xfsdump vor einem xfs_repair durchführen...

[betrazivis]

Du hast xfs_check aber nicht auf eine gemountete Partition losgelassen? Sowas macht man grundsätzlich nur im ungemounteten Zustand.
Stimmen die Versionen der xfsprogs beim Anlegen und Reparieren überein beziehungsweise ist die zum Rearieren genutzte aktueller als die zum Anlegen genutzte? Am Besten ist es zuerst die aktuellsten xfsprogs 2.9.8 zu installieren und diese zum Check/Dump/Repair zu nutzen.
Bitte xfsdump vor einem xfs_repair durchführen...

Soweit ich das bis hier verstanden habe, ist das bei xsf_check nicht wirklich schlimm. Sebstverständlich sollte ich die Partitionen aushängen, da hast du Recht. Sicher werde ich keine Rearatur im gemounteten Zusatnd druchführen wollen, das wäre das Ende meiner Daten.

Vielen Dank für den Hinweis mit xfsprogs,wenn 1&1 die Sercon und dem Rettungssystem wieder gebogen hat, werde ich das mal durcharbeiten.

[Joe User]

Soweit ich das bis hier verstanden habe, ist das bei xsf_check nicht wirklich schlimm.

man xfs_check

DESCRIPTION
xfs_check checks whether an XFS filesystem is consistent. It is normally run only when there is reason to believe that the filesys‐
tem has a consistency problem. The filesystem to be checked is specified by the device argument, which should be the disk or volume
device for the filesystem. Filesystems stored in files can also be checked, using the -f flag. The filesystem should normally be
unmounted or read-only during the execution of xfs_check. Otherwise, spurious problems are reported.

read-only halte ich für suboptimal, da read-Zugriffe mindestens die Ausführungszeit verlängern und eventuell auch andere Nebenwirkungen verursachen könnten. Zudem müsstest Du die Partition hierzu eh remounten, was letztendlich einem umount+mount gleichkommt.

[sogo]

Für die Zukunft: Mit XFS wäre es nicht (in dem Umfang) passiert. Ext2/3 und ReiserFS sind in solchen Fällen viel zu anfällig für Datenverluste...

Falsch.
Wie kommst Du darauf ? Das Gegenteil ist korrekt, XFS auf PC Hardware ist zu komplex und hat noch immer Caching Probleme. ext2/3 ist wesentlich robuster, da die FS Struktur wesentlich einfacher ist (Dateihashes & zusaetzliche trees sind nur Optional...)

Bei der Menge an betroffenen Files ist eine Wiederherstellung für Amateure extrem Zeitaufwendig bis unmöglich. Hier hilft nur eine darauf spezialisierte Datenrettungsfirma, was nicht unbedingt günstig sein mag. Wenn es also ein Hobby-Projekt ist, ist der Vorfall unter "shit happens" zu verbuchen und künftig durch die Wahl eines diesbezüglich stabileren FS (XFS) zu vermeiden...

Tja, ein Backup fuer ein Koenigreich ... :-({|=

[daemotron]

Meine Erfahrung mit XFS und ext2/3: Ext2/3 wird schneller mal als nicht clean markiert, lässt sich aber eigentlich leicht fixen. Einen Totalausfall mit Datenverlust hatte ich bei ext3 noch nie, selbst ein mit dd_rescue gezogenes Image einer halbtoten Platte ließ sich noch mit den e2fsprogs restaurieren. Bei XFS kommt es äußerst selten vor, dass das Dateisystem dirty wird - aber wenn XFS mal kaputt ist, kriegt man es kaum noch repariert. Außerdem ist mir XFS beim Caching noch zu aggressiv, das kommt bei mir nur noch auf Maschinen mit USV.

[betrazivis]

Tja, ein Backup fuer ein Koenigreich ... :-({|=

...wenn mir mein Backupscript nicht seit nem halben Jahr korrupte Tarballs geschrieben hätte, wäre das Posting überflüssig gewesen ;)

[Joe User]

Dann mache ich etwas flachs: Ich habe hier durchschnittlich acht Stromausfälle pro Jahr und keine USV. Trotzdem hatte ich in den letzten sechs Jahren kein defektes XFS, sieben defekte Ext3 und stolze elf defekte ReiserFS. Ext2 war ebenfalls nicht defekt, kommt hier aber nur für /boot zum Einsatz, während die anderen FS produktive Daten beherbergen. ReiserFS ist hier bereits vor eineinhalb Jahren als FS rausgeflogen und Ext3 kommt ab nächstem Jahr nur noch auf älteren Notebooks zum Einsatz, der Rest wird vollständig auf XFS umgestellt. JFS habe ich leider noch keinem Langzeittest unterzogen und andere FS sind für mich eh uninteressant. Aber wie bereits gesagt, mache ich hier irgendetwas flachs...

[sogo]

lese mal Theos Meinung ueber xfs:
http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc
XFS hat einige nette Features, aber bei einem Dateisystem sollte man so konservativ wie moeglich sein. Ein paar % Performance sind es nicht wert...
Wenn Du Dir das Design von XFS anschaust geht es nicht kaputt, aber die Dateien gehen kaputt (google mal ein wenig herum, da sind einige Reproducer vorhanden).
ext3 hat wenige Schwachstellen bei denen es kaputt geht, die Meisten sind hardwarebedingt - solange der Kernel sicher ist dass etwas geschrieben wurde und dies auch geschrieben wurde sollte es keine Korruption geben. Kernel interne Speicherkorruption zaehlt natuerlich nicht.
Die meisten ext3 Korruptionen, die ich gesehen habe, sind auf write-caches und kaputte Hardwaretreiber (beides meistens nach dem Motto: "Hauptsache ich quetsch noch 10% mehr Performance heraus") zurueckzufuehren...

-- sogos

[daemotron]

XFS hat einige nette Features, aber bei einem Dateisystem sollte man so konservativ wie moeglich sein. Ein paar % Performance sind es nicht wert...

Das würde ich so nicht stehen lassen wollen. Klar, wenn Du völlig überdimensionierte Hardware hast, kommt es nicht drauf an. Für einen DB-Server unter Last sind aber XFS und JFS deutlich besser geeignet als ext2 oder ext3 (Reiser wurde bei mir auch zum Un-Dateisystem erklärt), insbesondere, wenn es um etwas größere Dateisysteme (z. B. Plattenverbünde in einem SAN) geht. Ein solches System verfügt aber in der Regel auch über entsprechende Absicherungen (batteriegepufferter RAID-Controller Cache, USV), so dass die intensivere RAM-Nutzung nicht zum Problem werden kann.

Wenn Du Dir das Design von XFS anschaust geht es nicht kaputt, aber die Dateien gehen kaputt (google mal ein wenig herum, da sind einige Reproducer vorhanden).

Die Schwächen betrafen vor allem ältere Versionen. Das verschweigt auch das von SGI geführte Changelog nicht.

Dann mache ich etwas flachs: Ich habe hier durchschnittlich acht Stromausfälle pro Jahr und keine USV. Trotzdem hatte ich in den letzten sechs Jahren kein defektes XFS, sieben defekte Ext3 und stolze elf defekte ReiserFS. Ext2 war ebenfalls nicht defekt, kommt hier aber nur für /boot zum Einsatz, während die anderen FS produktive Daten beherbergen. ReiserFS ist hier bereits vor eineinhalb Jahren als FS rausgeflogen und Ext3 kommt ab nächstem Jahr nur noch auf älteren Notebooks zum Einsatz, der Rest wird vollständig auf XFS umgestellt. JFS habe ich leider noch keinem Langzeittest unterzogen und andere FS sind für mich eh uninteressant. Aber wie bereits gesagt, mache ich hier irgendetwas flachs...

Ext2/3 hat IMHO durchaus seine Macken, zumal einige Distributionen nicht gerade restriktiv bei den Default-Einstellungen sind (z. B. Journal Mode). Doch selbst mit diesen kommt es auch ohne sichtbaren Grund (Stromausfall etc.) immer mal wieder vor, dass sich mein ext2 hier zu Hause (große Datenaustausch-Partition) für korrupt hält. Es ließ sich bisher nur immer wieder reparieren. Ein XFS habe ich bisher erst einmal verloren, bei einem Plattencrash. Auf der Platte befanden sich auch noch einige ext3-Partitionen. Die Images der ext3-Partitionen ließen sich recovern, aber das Image der XFS-Partition leider nicht mehr. Daraus habe ich für mich abgeleitet, dass XFS ziemlich robust ist - aber wenn es dann doch mal kaputt gekriegt wurde, dann richtig. Liegt ja auch ein wenig am Design des File Systems, dass - wenn die "richtigen" Blöcke (am besten die mit den Allocation Group Zuordnungen) zerstört wurden - sich auch Teilbereiche nicht wieder herstellen lassen.

[sogo]

XFS hat einige nette Features, aber bei einem Dateisystem sollte man so konservativ wie moeglich sein. Ein paar % Performance sind es nicht wert...

Das würde ich so nicht stehen lassen wollen. Klar, wenn Du völlig überdimensionierte Hardware hast, kommt es nicht drauf an. Für einen DB-Server unter Last sind aber XFS und JFS deutlich besser geeignet als ext2 oder ext3 (Reiser wurde bei mir auch zum Un-Dateisystem erklärt), insbesondere, wenn es um etwas größere Dateisysteme (z. B. Plattenverbünde in einem SAN) geht. Ein solches System verfügt aber in der Regel auch über entsprechende Absicherungen (batteriegepufferter RAID-Controller Cache, USV), so dass die intensivere RAM-Nutzung nicht zum Problem werden kann.

Datenbanken laufen entweder auf raw devices oder via O_DIRECT. Das Dateisystem ist dabei bei der Performance quasi unerheblich.

Wenn Du Dir das Design von XFS anschaust geht es nicht kaputt, aber die Dateien gehen kaputt (google mal ein wenig herum, da sind einige Reproducer vorhanden).

Die Schwächen betrafen vor allem ältere Versionen. Das verschweigt auch das von SGI geführte Changelog nicht.

Es ist das Design, dies kann auch nicht behoben werden. Wenn Daten geschrieben werden, kommen diese erstmal in den Buffer. Wenn Strom weg ist sind die Daten weg, daran kann kein Dateisystem der Welt etwas aendern (auch wenn es die SGI Entwickler versucht haben ;-) )
Die Aufgabe des Dateisystems ist es sicher zu stellen dass die Daten konsistent sind.
ext3 kann (und macht defaultmaessig) Block journaling, das heisst dass die eigentlichen Daten, die geschrieben werden in dem Journal markiert werden. XFS macht nur Metadata journaling, dass heisst, dass von einer Operation open(),seek(),write() usw. nur markiert wird, dass *inode* X veraendert wurde. Welche Bloecke da letzendlich geschrieben wurden ist nicht nachvollziehbar. Wenn waerend des Schreibens von einem Block der Storage weg ist oder der Kernel crashed oder aehnliches, weiss man nur noch welche Dateien betroffen sind, aber die Dateikonsistenz ist nicht gesichert.
Bedenke, dass XFS von SGI kommt und fuer Performance entwickelt wurde.
Block journaling im Gegensatz schreibt auf, welche Bloecke gerade geschrieben werden. Das ist natuerlich aufwendiger, aber danach weiss man, dass die Konsistenz der Daten auch gesichert wurde.
ZFS macht uebrigens einige interessante Sachen, um Block Journaling zu beschleunigen (oder zu verlagsamen -> http://www.opensolaris.org/jive/thread. ... 3115&93115 8-[ ), aber wird auf absehbare Zeit nicht performant (FUSE only) Linux sein...

Ext2/3 hat IMHO durchaus seine Macken, zumal einige Distributionen nicht gerade restriktiv bei den Default-Einstellungen sind (z. B. Journal Mode). Doch selbst mit diesen kommt es auch ohne sichtbaren Grund (Stromausfall etc.) immer mal wieder vor, dass sich mein ext2 hier zu Hause (große Datenaustausch-Partition) für korrupt hält. Es ließ sich bisher nur immer wieder reparieren. Ein XFS habe ich bisher erst einmal verloren, bei einem Plattencrash. Auf der Platte befanden sich auch noch einige ext3-Partitionen. Die Images der ext3-Partitionen ließen sich recovern, aber das Image der XFS-Partition leider nicht mehr. Daraus habe ich für mich abgeleitet, dass XFS ziemlich robust ist - aber wenn es dann doch mal kaputt gekriegt wurde, dann richtig. Liegt ja auch ein wenig am Design des File Systems, dass - wenn die "richtigen" Blöcke (am besten die mit den Allocation Group Zuordnungen) zerstört wurden - sich auch Teilbereiche nicht wieder herstellen lassen.

Consumer Hardware ist broken by Design, da es billig und schnell sein muss. Wenn die el-cheapo IDE Platte meldet, dass der Block schon geschrieben wurde, waerend noch geschrieben wird (damit Sie bei Benchmarks gut aussieht), helfen kein Dateisystem. Software kann keine Hardware fixen.
Was Du beschreibst ist doch normal, das Dateisystem meldet Dir dass es Inkonsistenzen gefunden hat und diese beheben moechte und fsck behebt das.
Wichtig ist, dass dies *immer* der Fall ist und dass Du sicher sein kannst dass Daten nicht halb geschrieben wurden...

-- so ' traue keinem Filesystem' gos

[betrazivis]

Ich habe heute "xfs_repair" auf die betreffende Partition angewendet, leider bekommen ich bei einer bestimmten iNode einen "Killed". Das Programm beendet sich dann.
Vielleicht weiß jemand was ich tun kann um diese Inode zu reparieren bzw zu überspringen. Ich denke mal da liegt der Grund warum meine Bilder kaputt sind.

Code: Select all

~# xfs_repair /dev/sda8
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - clear lost+found (if it exists) ...
        - clearing existing "lost+found" inode
        - deleting existing "lost+found" entry
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - ensuring existence of lost+found directory
        - traversing filesystem starting at / ...
bad hash table for directory inode 539142172 (no leaf entry): rebuilding
rebuilding directory inode 539142172
Killed