Hallo,

wenn ich .tar.gz- bzw. tar Band- Archive entpacke, bekomme ich bei einigen Einträgen Fehlermeldungen:

Kann open nicht ausführen: Datei oder Verzeichnis nicht gefunden

Kann mkdir nicht ausführen: Datei oder Verzeichnis nicht gefunden

Die Dateien werden auch tatsächlich nicht entpackt, was natürlich für eine Datenwiederherstellung schlecht wäre.

Wer kennt das Problem und kann mir die Ursache bzw. eine Lösung drauf sagen.

Vielen Dank schon mal im voraus.

Poste mal die Ausgabe von 'ls' und den vollständigen Befehl zum Entpacken, den du nimmst.

Poste mal die Ausgabe von 'ls' und den vollständigen Befehl zum Entpacken, den du nimmst.

ls? das ist doch nur zum Anzeigen von Dateien in einen Verzeichnis, ähnlich wie 'dir' unter DOS. :confused:

Falls Du damit das Verzeichnis meinst, wo ich die Dateien hin entpackt habe, das würde den Rahmen sprengen, sind 10tausende Dateien.

Ansonsten habe ich zum Entpacken vom Band folgenden Befehl genommen:

tar -xvf /dev/st0 -C /tmp/test

Für das Entpacken aus einem Dateiarchiv folgenden Befehl:

tar -xzvf backup.tar.gz -C /tmp/test

Hoffe, es hilft trotzdem.

Ansonsten habe ich zum Entpacken vom Band folgenden Befehl genommen:

tar -xvf /dev/st0 -C /tmp/test

Für das Entpacken aus einem Dateiarchiv folgenden Befehl:

tar -xzvf backup.tar.gz -C /tmp/test

Wie hast du denn die Dateien gepackt? Bei dem ersten Befehl verwendest du gzip (-z), beim Zweiten nicht. Wenn die Dateien mit -z auf /dev/st0 gepackt worden sind, dann musst du die auch mit -z entpacken.

Mit tar -tzvf /dev/st0 solltest du sehen was auf dem Band ist. Vielleicht hilft dir auch mt -f /dev/st0 status weiter. Befindet sich das Band denn ueberhaupt am Anfang? Das kannst du mit mt -f /dev/st0 rewind ueberpruefen.

mfg

Unix

Das mit dem GZIP- Komprimieren in eine Datei und nicht auf Band ist schon richtig. Die Rücksicherung vom Band dauert so schon einen halben Tag. Mit Komprimierung würde das noch mehr Zeit beanspruchen und die Bandgröße ist vollkommen ausreichend für eine unkomprimierte Sicherung.

Das Listing mit dem Parameter -t vom Band klappt.

'mt -f /dev/st0 status' bringt nach dem letzten Wiederherstellungsvorgang folgende Ausgabe:

drive type = Generic SCSI-2 tape

drive status = -2130705408

sense key error = 0

residue count = 0

file number = 0

block number = 0

Tape block size 1024 bytes. Density code 0x81 (DLT 15GB compressed).

Soft error count since last status=0

General status bits on (41010000):

 BOT ONLINE IM_REP_EN

'mt -f /dev/st0 rewind' bringt keine Meldung, d.h. keinen Fehler hervor.

Das schlimme ist, gerade die Datei, die ich zum Wiederherstellen brauche, entpackt mir das Ding nicht

was sagt eigentlich tar -tf /dev/st0 ???

was sagt eigentlich tar -tf /dev/st0 ???

Bringt natürlich das Archivlisting vom Tape. Is nur zu viel, um das hier einfach mal zu posten

wenn -t bis zum Ende durchläuft, dann könnte das Problem woanders liegen ... darauf wollte ich hinaus. Aber die Zeit, wo ich noch mit Tapes zu tun hatte, die liegt auch schon 15 Jahre zurück ... damals waren 150 MB noch ein großes Tape und schwer vollzukriegen. :-)

wenn -t bis zum Ende durchläuft, dann könnte das Problem woanders liegen ... darauf wollte ich hinaus. Aber die Zeit, wo ich noch mit Tapes zu tun hatte, die liegt auch schon 15 Jahre zurück ... damals waren 150 MB noch ein großes Tape und schwer vollzukriegen. :-)

Ich schieb's mal über Nacht an. Dauert ja doch 'ne Weile :schlaf:

Die Tapes nehm ich eigentlich auch nur, um von vergangenen Wochen die Daten wiederherzustellen. Sonst wird in ein tar.gz- File jeden So die Komplett- und Mo-Fr eine Teilsicherung mit Snapshots gemacht.

Manchmal fällt's den Kollegen doch bissel später als bei der Komplettsicherung ein, wenn'se eine Datei versaut haben

tar mit dem Parameter '-t' ist ohne Probleme durchgelaufen.

Das macht die Fehlersuche nicht viel einfacher. tar schreibt ja alles einfach hintereinander ... und die Ausgaben von -t sind über's Band verstreut. Bist du sicher, dass die Daten, die du jetzt suchst, überhaupt auf'm Band sind?

Ich habe zum Glück die Bildschirmausgabe parallel in eine Logdatei schreiben lassen. Dort steht die wiederherzustellende Datei drin, wenn ich 'less' mache und dann danach suchen lasse.

An den Bändern selbst kann es auch nicht liegen. Die sind erst vor kurzem getauscht worden und auch das Bandlaufwerk wurde parallel dabei gereinigt.

ich erinnere mich an 'n Artikel in der c't, als die für ihre Webserver 'n Bandlaufsystem gegen ein Raid5-Platten-Storage ausgetauscht haben, weil die Bänder immer so viele Probleme gemacht haben ... aber egal :-)

*nachdenk*

Du schreibst am Anfang

"Kann open nicht ausführen: Datei oder Verzeichnis nicht gefunden

Kann mkdir nicht ausführen: Datei oder Verzeichnis nicht gefunden"

Dann siehst du die Dateinamen aber:

"Dort steht die wiederherzustellende Datei drin, wenn ich 'less' mache und dann danach suchen lasse."

Spontan fällt mir dazu ein, dass die Dateinamen vielleicht Sonderzeichen wie Backspace in sich haben (ja, das haben mal DBA-Helden bei mir in der Firma über 'ne Gui geschafft ... da sucht man tagelang nach 'ner Ursache ... "a Backspace b", 3 Buchstaben, wird als b angezeigt). Oder 'ne groß und Kleinschreibung nicht beachtet wurde ... sonst wär's 'n Abschlußprojekt wert, eure Backup-Situation mal zu checken (auch auf Performance bzw unter hoher Last) :-)

Du schreibst am Anfang

"Kann open nicht ausführen: Datei oder Verzeichnis nicht gefunden

Kann mkdir nicht ausführen: Datei oder Verzeichnis nicht gefunden"

Dann siehst du die Dateinamen aber:

"Dort steht die wiederherzustellende Datei drin, wenn ich 'less' mache und dann danach suchen lasse."

Schon komisch

Nur zum Verständnis: Vor dem open und mkdir Zeugs steht dann immer der Pfad oder Dateiname natürlich. Und weil ich nicht '-p' mache, kann es ja auch keine Besitzerprobleme o.ä. geben. Selbst wenn, schreibt Linux glaube nur die IDs beim 'ls' bin.

Spontan fällt mir dazu ein, dass die Dateinamen vielleicht Sonderzeichen wie Backspace in sich haben (ja, das haben mal DBA-Helden bei mir in der Firma über 'ne Gui geschafft ... da sucht man tagelang nach 'ner Ursache ... "a Backspace b", 3 Buchstaben, wird als b angezeigt). Oder 'ne groß und Kleinschreibung nicht beachtet wurde ... sonst wär's 'n Abschlußprojekt wert, eure Backup-Situation mal zu checken (auch auf Performance bzw unter hoher Last) :-)

Ja im Pfad sind Umlaute und Leerzeichen mit drin. Das kannste den Mitarbeitern 10x sagen, dass sie das nicht machen sollen und sie machen's trotzdem . Deshalb entpacke ich häufig auch immer das komplette Archiv/ Band.

frag' mich bitte nicht zu Linux und tar ... ich kam aus der Solaris-Ecke und mache jetzt HPUX, da geht alles etwas anders.

Aber ich denke, dir wird nix anderes übrig bleiben als 'ne Ebene höher im Dateibäumchen anzusetzen.

Na danke trotzdem.

Vielleicht hat ja jmd. anders noch einen Geistesblitz

Hier die Regel:

--------------

packen mit tar gzip

tar cfvz [ARCHIV].tar.gz [VERZEICHNIS1] [DATEI1]

entpacken mit tar gzip

tar xfvz [ARCHIV].tar.gz

Für alle Fälle:

------------

Prüf mal auch mit "ls" ob die "tar.gz-Archives" überhaupt vorhanden sind?

Prüf mal ob "tar" installiert ist?

H.

Ja so habe ich den Versuch bei tar.gz- Dateien gemacht.

Bei Bändern fällt der -z- Parameter weg und statt einer Datei halt /dev/st0

Dateiarchive sind vorhanden und da der Banddurchlauf mit -t funzt, scheint auch dort was drauf zu sein.

tar und gzip sind definitiv installiert. Sonst würde gar nix funktionieren

eine Idee noch ... gzip oder tar hatte mal Probleme mit Dateigrößen um und über 2GB ...

euro

als root anmelden, irgendwo Platz suchen und dort mit tar xvf ... das ganze Band einspielen.

Bei Sonderzeichen im Dateinamen musst Du die schon kennen ... also ist das der einfachste Weg.

Mich würde mal die Meldung vom open und mkdir PRÄZISE interessieren.

Es ist mir völlig neu, daß ein tar ein "open" Kommando oder einen Syscall benutzt. Das Band stammt von DEINER Anlage oder hat das ein anderes OS beschrieben ?