Datenrettung defektes Splitarchiv

alter_Bekannter

N.A.C.J.A.C.
Registriert
14 Juli 2013
Beiträge
4.767
Ort
Midgard
Folgende Situation:
Ich habe ein ca 600GB großes Rar Archiv geteilt auf 900MB Stücke.

Da drin sind um die 1000 Dateien die sich einzeln nutzen lassen. CD images um genau zu sein.

Welches Programm taugt um zum Beispiel einfach zu versuchen alle einzeln zu entpacken?
Alle durchiterieren wäre nicht das Problem, aber dann habe ich selbst im Best case die meisten Dateien wohl um die 30 mal. Also müsste ich mitschreiben was geklappt hat um das danach zu ignorieren etc...

Idealer wäre daher irgendwas fertiges.

NZB:


Wie gesagt ca 600GB daher ist die NZB selber schon fast 100Mb groß.
 
Warum stellst du das nicht einfach aus deinem Backup wieder her? Hast du doch bei wichtigen Daten sicher gemacht...
 
Wenn du per winrar entpackst, dann gibt es die Option defekte Dateien zu behalten.
 
  • Thread Starter Thread Starter
  • #4

Okay, läuft, geschätzte Zeit 5 Stunden.

Sieht gut aus, im Log scheint er festzuhalten welche images alle kaputt sind.
Okay, Problem:
Winrar hört einfach auf nach irgendeinem Fehlerpunkt. Vermutlich wenn er alle angefangenen Dateien "entpackt" hat nachdem er auf den ersten Fehler gestoßen ist. (4 "unerwartetes Archivende" Fehler im Log) Diesen Stop müsste man auch noch irgendwie ignorieren. Denn danach folgen noch mehrere Hundert komplett intakte Parts.


Fortbildung für Antworter mit besonderen Bedürfnissen (der richtige wird sich schon angesprochen fühlen):
Glückwunsch dazu eine dumme Antwort zu geben die stark impliziert das man entweder den Beitrag nicht gelsen oder nicht verstanden hat.

Testfragen:
1) Was ist eine NZB Datei?
2) Merkste was?

Hilfe:
Ich habe ein Backup von jemand anderes wiederhergestellt.
Eine Mordkopie aus dem bösen Usenet.

Kurs zur Weiterbildung:




Ups, scheinbar habe ich beim letzten Link nur die Überschrift gelesen. Da haben wir wohl alle heute was gelernt!
 
Zuletzt bearbeitet:
Kenne kein passendes fertiges Programm.
Persönlich würde ich da eher ein Skript gegen laufen lassen.

Nicht unbedingt der eleganteste Ansatz:

[src=bash]
#!/bin/bash

IFS="
"
ErstesRarPart="backup.part0001.rar"

#Dateinamen dumpen
unrar lb "$ErstesRarPart" > FileList.txt
#CRC-Lookup dumpen
unrar lt "$ErstesRarPart" | egrep 'Name:|CRC32:' > FileListInfo.txt


#Jede Datei entpacken, CRC32 prüfen, wenn CRC32 falsch -> error.log und Datei löschen
for Content in $(cat FileList.txt)
do
unrar e "$ErstesRarPart" "$Content"
rawname=$(basename "$Content")
crcsum=$(find . -name "$rawname" -exec crc32 "{}" \;)

crcok=$(grep -A1 "$rawname" FileListInfo.txt | grep -i "$crcsum" | wc -l)

if [ "$crcok" == "0" ]
then
echo "$Content" >> error.log
find . -name "$rawname" -exec rm "{}" \;
fi


done



[/src]
 
  • Thread Starter Thread Starter
  • #6
Sieht gut aus.

Allerdings muss ich da noch einiges korrigieren:
Die Liste des ersten Parts hat nur 3 Einträge. (wie es aussieht nur Dateien die in dem Part selbst zumindest anfangen. Theorie wurde mit ein paar Stuchproben verifiziert. Höhere Nummern enthalten Alphabetisch höhere Einträge.)
Wird autoamtisch auf andere Parts zugegriffen falls ich zB Nr 30 Auswähle und noch was aus 29 benötigt wird? (Wenns nicht geht egal ignorieren, nächster, Liste kaputter Einträge updaten)

Test durchgeführt mit unrar lb und unrar lt, meine unrar version kommt also offenbar mit den Archiven klar.
 
Interessante Sache. Bei den von mir getesteten Split-Archiven waren alle Dateien in der ersten Rar gelistet.
Eigentlich sollte man mit
[src=bash]unrar e FOO.part01.rar foo.bar[/src]
arbeiten. Also immer die erste Rar als Archiv-Parameter übergeben.

Hab mal ein wenig dran gebastelt.

[src=bash]
#!/bin/bash

IFS="
"

########
#
########
function initScript {
rm error.log 2>/dev/null
rm FileList.txt 2>/dev/null
rm FileInfoList.txt 2>/dev/null
#rm DoneCRC.txt >2/dev/null
touch error.log
touch FileList.txt
touch FileInfoList.txt
touch DoneCRC.txt
}
########
#
########

function extract_and_check {

echo "Extract and Check $1 -- $2"
rawname=$(basename "$2")
sollcrc=$(grep -A1 "$rawname" FileInfoList.txt | grep "CRC32" | cut -d ':' -f 2)

echo "$2 - Sollcrc $sollcrc"
isdone=$(grep -i "$sollcrc" DoneCRC.txt | wc -l)

if [ "$isdone" == "0" ]
then

unrar e "$1" "$2"
crcsum=$(find . -name "$rawname" -exec crc32 "{}" \;)
crcok=$(grep -A1 "$rawname" FileInfoList.txt | grep -i "$crcsum" | wc -l)

if [ "$crcok" == "0" ]
then
echo "$2" >> error.log
find . -name "$rawname" -exec rm "{}" \;
else
echo "$crcsum" >> DoneCRC.txt
fi
fi

}

########
#
########
function extract_info {
find . -name '*.rar' -exec unrar lb "{}" \; >> FileList.txt
find . -name '*.rar' -exec unrar lt "{}" \; | egrep 'Name:|CRC32:' >> FileInfoList.txt
}


########
#
########
function progress_file_list {
for EFILE in $(sort -u FileList.txt)
do
rarfile=$1
extract_and_check "$rarfile" "$EFILE"

done
}

########
#
########


initScript
extract_info
FirstRarPart="MeinRiesigesSplit.part01.rar"
progress_file_list "$FirstRarPart"

[/src]
 
Zuletzt bearbeitet:
  • Thread Starter Thread Starter
  • #8
Die Dateien sind wie es scheint PSX Images in einem komprimierten Format(PBP, aktuelle Emulatoren kommen damit klar wie es scheint). Also hunderte große Dateien die sich wenig/garnicht komprimieren lassen.

Falls du es reproduzieren willst:
Splitgröße 900MB
enthaltene Dateien meistens: 300-700MB
Ausreisser nach unten: bis ~50MB
nach oben: bis ~3000MB
 
Zuletzt bearbeitet:
Hab die letzte Iteration des Skripts (12:17 edition) mal auf einem meiner Server gegen ein Split-Rar rennen lassen (110GB, Splits 1GB, sehr viele kleine Dateien [2GB] danach das ganze Spektrum bis maximal 4GB).
Die Dateinamen sind darin, wie Du auch schon beobachtet hattest, nicht alle in der ersten Rar gelistet.
Hab eine rar-Datei davon zerschossen ( mit dd count=900 bs=1M nur den Anfang der part100.rar kopiert)
Einige Dateien die im kaputten Rar waren konnten nicht entpackt werden, der Rest lief aber durch (mit 64GB Ram, ner ordentlichen SSD ging das sogar noch recht zügig).
 
  • Thread Starter Thread Starter
  • #10
Das klingt doch super allerdings mache ich gerade eine Kopie auf eine Externe USB 3.0 Festplatte daher würde es jetzt zu versuchen beides in die Länge ziehen. Komme daher leider erst später zum testen. Schade, denn es sieht so aus als wäre dein Skript eine vollständige Lösung.
 
  • Thread Starter Thread Starter
  • #12
Nur 1 (von 72 ;)) davon ließ sich downloaden, hat nicht geholfen. Also ja, habe ich vorher schon probiert.

Die NZB für die Par archive editier ich auch mal in den opener.

edit:
NGB frisst den Anhang nicht und das Ding hat eh kaum Wert, wenn einer anderer Meinung ist bitte Hoster nennen, ich lads dann gerne da hoch.

Anleitung zum selber besorgen:
nzbindex "pipiggies" suchen (mindestgröße 500GB)
View Collection
PAR Dateien auswählen
NZB runterladen

oder hier


Entsprechenden Einträge auswählen. (PAR Dateien sind untern.)

--- [2019-12-16 21:15 CET] Automatisch zusammengeführter Beitrag ---

Okay, Problem:

[src=php]
...
Extracting from PiPiggies.Renegade.ROMS-psx.part025.rar


Extracting from PiPiggies.Renegade.ROMS-psx.part026.rar

Corrupt header is found
No files to extract
[/src]

Und dann ist Ende. Fehlen noch ein paar hundert.

--- [2019-12-16 22:58 CET] Automatisch zusammengeführter Beitrag ---

Bin gerade das Archiv über den passendne Torrent am verifizieren.

Die gute Nachricht:
Abgesehen von 27-37 sehen wohl all Teile gut aus (Checkfortschritt 155/628)

Die Schlechte:
Davon sind einige in einem so lausigen Zustand das kein einziger intakter 8MB Block gefunden wurde.

Die ersten 37 zu überspringen und danach weiter zu machen wäre also eventuell einen Lsöung wenn ich ein Programm dazu bewegen kann.
 
Zuletzt bearbeitet:
  • Thread Starter Thread Starter
  • #13
Wider erwarten hat par recovery doch geklappt. Was halt auch in sofern seltsam war als das davon wie erwähnt auch nicht all zu viel da war. Da gabs auf jeden Fall unterwegs einiges an Schluckauf.

Ich hatte es abgeschrieben weil ich dachte der Prozess wäre abgeschmiert, da ich das Ding aber Tagelang nicht gebraucht habe dachte: lass ihn mal machen kannst es ja immer noch neustarten wenn du es wieder brauchst.

Tja, hat sich gelohnt. Nach ungefähr 3 Tagen(ja, über 70 Stunden) ist er tatsächlich fertig geworden... (Wer daran noch geglaubt hätte soll sich bitte melden.)
 
Zurück
Oben