[XFS crash] data definitief weg?

[VROEM!]

Mijn servertje deed het ineens niet meer, het root FS bleek corrupt te zijn geraakt. Het is een debian testing bakkie met XFS als root FS. De kernel panicte bij het opstarten na een melding dat er fouten in het bestandssysteem zaten.

Dit moet me natuurlijk net gebeuren na dat ik in een grote schoonmaak aktie even alle backups e.d. weggeflikkerd had om later opnieuw backups te laten uitvoeren . Kortom, er is nu van alles weg waar ik geen kopie meer van heb.

Ik heb nu de schijf gemount met een andere disk als root en probeer xfs_repair te draaien. Die klapt eruit met de volgende melding:

code:

fatal error --can't read block <groot nummer> for directory inode <ander nummer>

Ik mis nu nogal wat bestanden, is die data nu definitief weg? Ik heb niets kunnen vinden om xfs_repair die directory te laten skippen en door te gaan met repareren wat er verder nog mis is.

[PenguinPower]

met xfs_repair zou je dat probleem kunnen oplossen. Deze zit in XFStools. Je zal wel niet alles kunnen repareren, maar je kan je schijf tenminste weer mounten.

Probeer eens een Gentoo Boot CD ofzo, deze heeft XFSTools aanboord, en je kan je root via deze cd gewoon proberen te repairen en vervolgens proberen te mounten

[ Voor 34% gewijzigd door PenguinPower op 13-04-2004 21:54 ]

[VROEM!]

Dat is dus min of meer wat ik nu al doe. Ik heb een andere harddisk met daarop een werkende debian installatie in de pc geduwd. De pc boot van die werkende disk en vanaf die disk draai ik xfs_repair op het corrupte filesystem van de "originele" disk. Met die aktie krijg ik na een poos de genoemde melding.

Ik heb een deel van de data al terug kunnen halen, maar een groot en belangrijk deel is ook tot nu toe foetsie.

[ Voor 20% gewijzigd door VROEM! op 13-04-2004 21:58 ]

[Guru Evi]

is het een hardwarematige crash of verdenk je een software corruption?
Indien hardware valt er waarschijnlijk niet veel meer aan te doen dan naar een gespecialiseerd bedrijf. Voor software corruption kun je misschien proberen raw de data te lezen met een of ander tooltje

[VROEM!]

bacblocks /dev/hdc1 gaf geen output, het is dus denk ik software

[Guru Evi]

Het probleem met XFS is dat als je geen auto-repair hebt door de Journaling dat je het meestal mag vergeten. Er zijn inderdaad tooltjes geleverd als xfs_repair of xfs_check maar echt , als deze niet werken mag je het vergeten. Lees eens de manual van die tools, dan kun je zien wat er wordt hersteld. Wat is er eigenlijk gebeurd dat het zo opgef**ked is geraakt?

[VROEM!]

Ik zou het niet weten, hij draait gewoon, staat vooral keihard niks te doen eigenlijk.
's Morgens was alles ineens plat.

Ik draai de server zonder vga kaart, dus hij moet altijd even uit en weer aan om te troubleshooten met VGA erin als hij niet boot. bij het booten gelijk een panic omdat hij het root fs niet kon mounten en ook geen init kreeg...

/etc is weg, de logs zijn weg, er is nog meer pleite. Het wordt wat lastig zoeken naar oorzaken dan. Ik ga xfs in elk geval niet meer gebruiken, dat heeft bij mij nu op 2 schijven rare meldingen gegeven en op een ervan deze crash. Ik hou het lekker bij de ext fs-en.

Meer niet, het fs was niet meer te mounten. Na xfs_repair wel weer, maar er staan nog fouten in en ik heb niet alles kunnen recoveren.

[ Voor 23% gewijzigd door VROEM! op 13-04-2004 23:01 ]

[Verwijderd]

Dataverlies op een journal FS is toch over het algemeen een hardwarefout hoor. Ik heb mezelf vele softwarecrashes aangedaan (ikke = brakke programmeur. ) toen ik met mijn kernel driver bezig was en XFS heeft het altijd overleefd. Ik had ook vaak dat xfs_repair eruitklapte in de automatische checkmodus, en het is dan echt simpelweg een kwestie van de FAQ op sgi.com en de manpage van de tool lezen om erachter te komen welke optie je moet meegeven om deze te laten repareren. En als de data dan weg is, dan was het toch echt een hardwarefout (anders zou je nl. kunnen recoveren, da's het hele principe van een journal FS).

(Overigens gebruik ik ook geen XFS meer, omdat de kernelupdates te lang duurden...)

[VROEM!]

Ik kreeg vanmorgen op die machine ook een panic omdat de interrupt handler op zijn muil ging en direct erover nog eentje met "could not handle kernel null pointer". Ik ga mijn moederbordje maar eens aan de haaien voeren vrees ik

[VROEM!]

Ik heb nu met xfsdump een dump van het fs op een andere disk gezet. Als ik daar doorheen blader staat er precies dezelfde data op als op de originele schijf, maw er mist nogal wat. Als ik op de kopie xfs_repair loslaat blijft er helemaal niets over wat nu?

[Verwijderd]

Data die weg is krijg je helaas niet meer terug. . Maar zelfs een xfs_repair op een werkende computer kan al betere resultaten opleveren dan op een kapotte, dus probeer dat eens. . /me moet lezen! .

En als je de schijf direct in een andere computer plaatst en daar xfs_repair op loslaat? .

[ Voor 26% gewijzigd door Verwijderd op 14-04-2004 18:28 ]

[VROEM!]

Dat is inmiddels net voltooid, ik heb ook een 40 GB schijf bijgekocht om maar eens structureel te gaan backuppen

ik heb met xfsdump en xfsrestore toch nog wat data weten te redden, zij het dat het meeste de meest onwaarschijnlijke nummers als directory en/of bestandsnaam heeft.
Ik heb alleen even moeten leren dat ik ook kon dumpen naar een bestand en dat bestand vervolgens restoren in een directory.

Nou ja, wat ik heb heb ik en wat weg is...daar heb ik van geleerd zullen we maar zeggen

[Berik]

@VROEM!
hoe heb je xfsdump en xfsrestore gebruikt, want ik probeer nu ook van een xfs-partitie waarvan de superblocks kapot zijn, de data te redden.
alleen wordt er bij xfsdump om een "label" gevraagd en ik weet niet wat ik hier moet invullen