kaputte Tar Archive ...

[stefan at hegner-online.de]

>> 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.
>> 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 ?

> 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.

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

Nicht exact:
# ls -l rec0041*
-rw-------  1 root root 1146335 2006-08-02 09:28
rec00410root-sicherung-rep-31.07.2006.tbz2
-rw-------  1 root root  899982 2006-08-02 09:28
rec00411root-sicherung-rep-31.07.2006.tbz2
-rw-------  1 root root  936673 2006-08-02 09:28
rec00412root-sicherung-rep-31.07.2006.tbz2
-rw-------  1 root root  934117 2006-08-02 09:28
rec00413root-sicherung-rep-31.07.2006.tbz2
-rw-------  1 root root  895214 2006-08-02 09:28
rec00414root-sicherung-rep-31.07.2006.tbz2
-rw-------  1 root root  895845 2006-08-02 09:29
rec00415root-sicherung-rep-31.07.2006.tbz2
-rw-------  1 root root  894715 2006-08-02 09:29
rec00416root-sicherung-rep-31.07.2006.tbz2
-rw-------  1 root root  893373 2006-08-02 09:29
rec00418root-sicherung-rep-31.07.2006.tbz2
-rw-------  1 root root  895036 2006-08-02 09:29
rec00419root-sicherung-rep-31.07.2006.tbz2

> 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.

> 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.

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.

[...]
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.

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.

Gruß

Stefan.