kaputte Tar Archive ...

Jan-Benedict Glaw jbglaw at lug-owl.de
Wed Aug 2 18:09:29 CEST 2006 

On Wed, 2006-08-02 17:20:22 +0200, stefan at hegner-online.de <stefan at hegner-online.de> wrote:
> > > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > > hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=40565736,
> > > sector=4056
> > > 5734
> > > ide: failed opcode was: unknown
> > > end_request: I/O error, dev hda, sector 40565734
> > >
> > > Das heißt jetzt, dass die Platte hin ist, ja?
> >
> > Ja, richtig. ...und vermutlich hätte Dich eine Überwachung der
> > SMART-Werte vorher schon gewarnt.
> 
> Wenn Du das sagst. Ich weiß dass es da wohl ein SMART-Mon Tool gibt, habe
> mich aber bisher nicht damit beschäftigt ... Es gibt immer so viel anders
> zu tun.

...bis, ja, bis dann mal wirklich 'ne Platte mit Daten stirbt, die
nicht aktuell im Backup sind.

apt-get install smartmontools
vi /etc/default/smartmontools
vi /etc/smartd.conf
man smartd
vi /etc/smartd.conf
/etc/init.d/smartmontools start

> > > Habe die Übrigen
> > > 684
> > > Dateien entpackt und in ein seperates Verzeichnis geschoben. Nun habe
> > > ich
> > >
> > > # tar -x rec*     bzw.
> > > # cat rec* | tar -x
> > >
> > > probiert. Ohne Erfolg. Hab' das Gefühl, dass ich ganz nah dran bin. Wie
> > > kriege ich diese Dateien nun enttart. Wenn das hinhaut, brauche ich
> > > nicht
> > > aufs Juni-Backup zurückgreifen ...
> >
> > Das ist jetzt so eine Frage, für die ich in die Original-Dateien
> > gucken müßte.
> 
> kann ich dir gerne auszugsweise mailen. wie wär 415 - 419 ?

Mindestens soviel, daß ein vorher ein vollständiger tar header ist,
sodaß es einen Ansatz gibt. Sonst muß man das 2mal machen...

> > In der Theorie nimmt bzip2 einen Block von (variabler,
> > abhängig vom Kompressions-Wert 0..9) vermutlich den maximalen 900KB
> > Größe und komprimiert diesen. Das Ergebnis wird dann in die bz2-Datei
> > geschrieben.
> >
> > bzip2recover versucht nun, einen solchen beschädigten Block zu
> > identifizieren. 900k ist für tar natürlich keine block size, jetzt
> > geht es also darum, die fehlenden 900k (mal davon ausgehend, daß nur
> > ein bz2-Block weggeflogen ist)
> 
> danach sieht es aus, da bunzip2 sonst nicht gemeckert hat.

Dann hast Du 900k Datenverlust, plus ggf. eine kaputte Datei vorher
und eine kaputte Datei hinterher.

> > so zu ersetzen, daß tar damit zurande
> > kommt.
> >
> > Sind die rec*-Fragmente alle 900k groß?

Dein Mail-Programm macht übrigens furchtbar dumme Dinge mit den
Umlauten...

> > Du könntest versuchen, den
> > einen kaputten durch null'en zu ersetzen und tar dann mit
> > --ignore-zeros dazu zu überreden, dieses Archiv-Ende-Zeichen zu
> > ignorieren :)  (Damit kann man mehrere tar-Archive
> > hintereinanderpacken und tar entpackt sie alle der Reihe nach.)
> 
> Mach doch diesbezügl. mal einen konkreteren Vorschlag.

Wie soll das noch konkreter werden?

Unter'm Strich alle "vorher"- und "hinterher"-Fragmente wieder
aneinander-cat-ten und dann dazwischen einige KB 0x00 packen und die
dann manuell mit einem Hex-Editor so bearbeiten, daß am Ende ein file
header steht, der den "Schrott" am Anfang des ersten heilen
Fragments nach der Fehlerstelle bis zum nächsten file header erdet.

> > Im schlimmsten Fall muß noch ein tar header eingebaut werden, damit
> > tar über die Datei-Fragmente im ersten Block nach dem kaputten Block
> > nicht fällt.
> 
> Davon keine Ahnug hab.

Dann nimmt man die Sourcen von GNU tar und guckt mal in die header
files, wie die file header genau aussehen :)

> Also ich hab' zwischenzeitlich alle Datein (bis auf den kaputten block
> 417) mal in ein Verz. gepackt und
> 
> # cat ../sdb4/rec0* |tar -tvv
> 
> gemacht. Resultat:
> 
> [...]
> drwxr-xr-x root/root         0 2006-07-15 02:46:20
> ./opt/opera/lib/opera/9.0-20060616.5/
> -rwxr-xr-x root/root   9159960 2006-07-15 02:46:19
> ./opt/opera/lib/opera/9.0-20060616.5/opera
> tar: Springe zum nächsten Kopfteil.
> tar: Archiv enthält veraltete Base64-Kopfteile
> tar: Fehler beim Beenden, verursacht durch vorhergehende Fehler.
> 
> Habe das ganze jetzt nochmal mit der "--ignore-zeros" Option probiert. Das
> ist nicht wirklich besser:
> 
> drwxr-xr-x root/root         0 2006-07-15 02:46:20
> ./opt/opera/lib/opera/9.0-20060616.5/
> -rwxr-xr-x root/root   9159960 2006-07-15 02:46:19
> ./opt/opera/lib/opera/9.0-20060616.5/opera
> tar: Springe zum nächsten Kopfteil.
> tar: Archiv enthält veraltete Base64-Kopfteile
> tar: Archiv enthält ,,,\017\214B\002\000\000\203ø"' wo nummerische
> major_t-Werte stehen sollten.
> tar: Archiv enthält ,,,h\017\204m\002\000\000é"' wo nummerische
> minor_t-Werte stehen sollten.
> ---------- 0/0               0 1970-01-01 01:00:00
> tar: Springe zum nächsten Kopfteil.
> tar: Archiv enthält ,,,~\a\000\000D\001"' wo nummerische major_t-Werte
> stehen sollten.
> tar: Archiv enthält ,,,\004\000\000\000\200\001"' wo nummerische
> minor_t-Werte stehen sollten.
> tar: Archiv enthält ,,,\000Õ\006\000\000,"' wo nummerische uid_t-Werte
> stehen sollten.
> tar: Archiv enthält ,,,\000\004\000\000\000\200"' wo nummerische
> gid_t-Werte stehen sollten.
> tar: Archiv enthält ,,,\000Õ\006\000\000,"' wo nummerische uid_t-Werte
> stehen sollten.
> tar: Archiv enthält ,,,\000\004\000\000\000\200"' wo nummerische
> gid_t-Werte stehen sollten.
> ---------- -1/-1             0 1970-01-01 01:00:00
> tar: Springe zum nächsten Kopfteil.
> tar: Archiv enthält ,,,\017\214B\002\000\000\203ø"' wo nummerische
> major_t-Werte stehen sollten.
> tar: Archiv enthält ,,,h\017\204m\002\000\000é"' wo nummerische
> minor_t-Werte stehen sollten.
> ---------- 0/0               0 1970-01-01 01:00:00
> tar: Springe zum nächsten Kopfteil.

Klar. Er findet den nächsten Anfang einer Datei nicht. Das wird man
ihm manuell via Hexeditor beibringen müssen.

--ignore-zeros ist nur dafür da, daß null'en (die eigentlich das Ende
eines Archives anzeigen) ignoriert werden; somit wird einfach
weitergemacht. Der erlaubt Dir hier überhaupt erst, mit einem gefakten
file header den Rest vom Archiv erreichbar zu machen.

> [...]
> tar: Read 6341 bytes from -
> tar: Fehler beim Beenden, verursacht durch vorhergehende Fehler.
> 
> Das ist nicht wirklich besser. So wie es aussieht, findet tar in den
> übrigen Blöcken keine korrekten Dateianfänge mehr.

Genau.

> Ach Mist! Wo Du das mit den 900k Blöcken geschrieben hast, hatte ich mich
> schon so gefreut ... Aber im Moment fehlt mir da der Glaube, dass das ans
> Laufen kommt. - Ich krieg's jedenfalls nicht hin.

Das ist doch garnicht so schwer. Du weißt, daß ca. 900k fehlen. Also
solltest Du gut 900k an die Stelle des alten Blockes packen (also
einfach mal 2MB, sicher ist sicher :)  Wenn das alles Nullen sind,
kann man tar dazu überreden (--ignore-zeros), weiterzumachen, obwohl
die vorhergehende Datei vielleicht schon zuende ist.

Die alternative ist, einfach das Ding 2geteilt auszupacken: einmal den
Anfang, der ja heile ist.

...dann den Rest. Hier jeweils vom ersten Fragment am Anfang solange
ein Byte abknipsen, bis tar das wieder frißt. Oder alternativ danach
suchen (bvi kann das): So ein Header fängt IIRC immer mit dem
Dateinamen an (~100 byte), dann Permissions (dezimale Ziffern), 'nen
bißchen Müll, "ustar" und Eigentümer/Gruppe in ausgeschrieben.

Sprich: wenn Du das mit bvi aufmachst, sollte das eigentlich schnell
zu finden sein. Einfach mal nach "ustar" suchen und dann 100..300
bytes zurück nach dem Dateinamen suchen.

MfG, JBG

-- 
       Jan-Benedict Glaw       jbglaw at lug-owl.de                +49-172-7608481
 Signature of:                     ...und wenn Du denkst, es geht nicht mehr,
 the second  :                            kommt irgendwo ein Lichtlein her.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20060802/a9d989d0/attachment.sig>

More information about the Linux mailing list