tar-Fehlermeldung
Hallo Liste, ich lasse über Nacht eine umfangreiche Sicherung auf Band laufen. tar schnappt sich anhand einer Liste die diversen Verzeichnisse, komprimiert sie und schreibt sie auf ein Band. Gesichert werden über 200000 Dateien. Leider bricht die Sicherung immer wieder (jede zweite etwa) mit dieser Fehlermeldung ab: 'Error exit delayed from previous errors'. Habe ich eine softwaretechnische Methode, um der Fehlerquelle auf die Spur zu kommen? (Die Sicherung lasse ich mir so mitloggen, daß mir aufgezeichnet wird, was gesichert wurde). Angenommen, das Band wäre voll oder am Ende nicht mehr in Ordnung, würde ich dann die gleiche Fehlermeldung erhalten? (Über die Hardware des Bandes kann ich leider nichts sagen). Helga -- ## Netikette nein danke? -- http://www.suse-etikette.de.vu/ ## Mit vielen nützlichen Tipps -- Lesen lohnt sich ## Rückmeldungen erbeten und erwünscht
Hallo Helga, ist schon ne weile her seit ich mich mit Bandlaufwerken rumgeschlagen habe. :) On Mon, Feb 16, 2004 at 09:27:43AM +0100, Helga Fischer wrote:
ich lasse über Nacht eine umfangreiche Sicherung auf Band laufen. tar schnappt sich anhand einer Liste die diversen Verzeichnisse, komprimiert sie und schreibt sie auf ein Band. Gesichert werden über 200000 Dateien.
Leider bricht die Sicherung immer wieder (jede zweite etwa) mit dieser Fehlermeldung ab: 'Error exit delayed from previous errors'.
tar -cvf benutzen und die Ausgabe in eine Datei schreiben. Darin findest du dann meisstens so etwas wie: Die Datei XXX wurde wärend der Sicherung verändert.
Habe ich eine softwaretechnische Methode, um der Fehlerquelle auf die Spur zu kommen? (Die Sicherung lasse ich mir so mitloggen, daß mir aufgezeichnet wird, was gesichert wurde).
gut, dann hast du ja schon ein Log greppe das mal nach dem Wort error oder failed. egrep -i "(error|failed|fail)" logdatei.txt
Angenommen, das Band wäre voll oder am Ende nicht mehr in Ordnung, würde ich dann die gleiche Fehlermeldung erhalten? (Über die Hardware des Bandes kann ich leider nichts sagen).
Die (Fehler)meldungen sehen anderst aus wenn ich mich recht entsinne. Greetings Daniel -- Linux - life is too short for reboots.
Hi Daniel, Am Montag, 16. Februar 2004 10:07 schrieb Daniel Lord:
ist schon ne weile her seit ich mich mit Bandlaufwerken rumgeschlagen habe. :)
Bei mir ist's das erste Mal und dann auch noch ein so hartnäckiger Fehler; hat mich schon vor einigen Wochen mal kurz beschäftigt.
On Mon, Feb 16, 2004 at 09:27:43AM +0100, Helga Fischer wrote:
tar -cvf benutzen und die Ausgabe in eine Datei schreiben. Darin findest du dann meisstens so etwas wie: Die Datei XXX wurde wärend der Sicherung verändert.
Die Sicherung läuft mitten in der Nacht, da sollte eigentlich niemand mehr Dateien verändern.
Habe ich eine softwaretechnische Methode, um der Fehlerquelle auf die Spur zu kommen? (Die Sicherung lasse ich mir so mitloggen, daß mir aufgezeichnet wird, was gesichert wurde).
gut, dann hast du ja schon ein Log greppe das mal nach dem Wort error oder failed.
egrep -i "(error|failed|fail)" logdatei.txt
Bis auf die allerletzte Zeile (und gesicherte Errorlogs aus anderen Vorgängen) war nichts zu finden.
Angenommen, das Band wäre voll oder am Ende nicht mehr in Ordnung, würde ich dann die gleiche Fehlermeldung erhalten? (Über die Hardware des Bandes kann ich leider nichts sagen).
Die (Fehler)meldungen sehen anderst aus wenn ich mich recht entsinne.
Ja, so hätte ich auch gedacht, aber man weiß ja nie. Daher meine Frage. Zur Qualität der Bänder und der Durchführung der Sicherung selbst kann ich nämlich nichts sagen. Helga -- ## Netikette nein danke? -- http://www.suse-etikette.de.vu/ ## Mit vielen nützlichen Tipps -- Lesen lohnt sich ## Rückmeldungen erbeten und erwünscht
Hallo Helga, On Mon, Feb 16, 2004 at 10:45:54AM +0100, Helga Fischer wrote:
Am Montag, 16. Februar 2004 10:07 schrieb Daniel Lord:
tar -cvf benutzen und die Ausgabe in eine Datei schreiben. Darin findest du dann meisstens so etwas wie: Die Datei XXX wurde wärend der Sicherung verändert.
Die Sicherung läuft mitten in der Nacht, da sollte eigentlich niemand mehr Dateien verändern.
crond ist da ab und an der Übeltäter bzw. irgend ein anderen Dämon der Dateien schreibt (logs/daten/datenbanken) Greetings Daniel -- One wordly wisdom: "Most people use doors, not windows."
Hallo Daniel, Am Montag, 16. Februar 2004 11:27 schrieb Daniel Lord:
On Mon, Feb 16, 2004 at 10:45:54AM +0100, Helga Fischer wrote:
Die Sicherung läuft mitten in der Nacht, da sollte eigentlich niemand mehr Dateien verändern.
crond ist da ab und an der Übeltäter bzw. irgend ein anderen Dämon der Dateien schreibt (logs/daten/datenbanken)
An crons habe ich auch schon gedacht und die Sicherungszeit der zweiten Sicherung schon nach hinten verschoben, damit sich beide Bänder nicht in die Quere kommen. Datenbanken oder andere Cronjobs habe ich nicht gefunden, aber es ist auch nicht sicher, ob ich alle Daemonen gefunden habe. Die zu sichernden Dateien, die nicht aufs Band kommen sind statischer Kram, Programme, die vermutlich irgendwann mal auf Windows installiert wurden und von denen man sich nicht trennen wollte. Wenn sich etwas verändert, dann können es nur Logs sein, die doch etliche Zeit vorher gesichert wurden (Oracle und Konsorten). Könnte sich ein solcher Zugriff so spät im Sicherungslauf auch noch auswirken? Da müßte der Datenbankkram doch schon auf dem Band sein. Helga -- ## Netikette nein danke? -- http://www.suse-etikette.de.vu/ ## Mit vielen nützlichen Tipps -- Lesen lohnt sich ## Rückmeldungen erbeten und erwünscht
Helga Fischer schrieb am Mon, 16 Feb 2004 11:49:27 +0100: tar-Fehlermeldung
Hallo Daniel,
Am Montag, 16. Februar 2004 11:27 schrieb Daniel Lord:
On Mon, Feb 16, 2004 at 10:45:54AM +0100, Helga Fischer wrote:
Die Sicherung läuft mitten in der Nacht, da sollte eigentlich niemand mehr Dateien verändern.
crond ist da ab und an der Übeltäter bzw. irgend ein anderen Dämon der Dateien schreibt (logs/daten/datenbanken)
An crons habe ich auch schon gedacht und die Sicherungszeit der zweiten Sicherung schon nach hinten verschoben, damit sich beide Bänder nicht in die Quere kommen.
Datenbanken oder andere Cronjobs habe ich nicht gefunden, aber es ist auch nicht sicher, ob ich alle Daemonen gefunden habe.
Die zu sichernden Dateien, die nicht aufs Band kommen sind statischer Kram, Programme, die vermutlich irgendwann mal auf Windows installiert wurden und von denen man sich nicht trennen wollte.
Wenn sich etwas verändert, dann können es nur Logs sein, die doch etliche Zeit vorher gesichert wurden (Oracle und Konsorten). Könnte sich ein solcher Zugriff so spät im Sicherungslauf auch noch auswirken? Da müßte der Datenbankkram doch schon auf dem Band sein.
Helga
Kann es Probleme (welche??? Hab auch keine Idee) mit der -p -Option geben? Wenn es irgendwelcher Windows-Kram ist? Nur so'ne Idee... Sind die Daten in $config o.k. zum Zeitpunkt des Lesens. Wird $config nirgendwo mehr offen gehalten (das könnte tar in einen Lesefehler treiben, wenn er kein EOF in $config findet). Bei mir heißt die Option übrigens --files-from=<file>. ^^^^^ hth -- Joerg Thuemmler sysadmin@vordruckleitverlag.de
Hallo Jörg, Am Montag Februar 16 2004 14:02 schrieb Joerg Thuemmler:
Kann es Probleme (welche??? Hab auch keine Idee) mit der -p -Option geben? Wenn es irgendwelcher Windows-Kram ist?
Es ist nur Windowskram, der scheint sich jedoch ziemlich nett zu benehmen. Mir sind keine Probleme bekannt.
Nur so'ne Idee... Sind die Daten in $config o.k. zum Zeitpunkt des Lesens.
$config enthält nur die zu sichernden Verzeichnisse. Mit der zweiten $config, die für das andere Band eingerichtet wurde, klappt alles anstandslos.
Wird $config nirgendwo mehr offen gehalten (das könnte tar in einen Lesefehler treiben, wenn er kein EOF in $config findet).
Blöde Frage: Wie sehe ich denn ein EOF? Die Datei könnte ich nur noch einmal abschreiben.
Bei mir heißt die Option übrigens --files-from=<file>.
Mmhhh... die Zeile habe ich so von meinem Vorgänger übernommen, ohne sie zu hinterfragen. Helga -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## Werkstatt & Information zu OpenSource -- http://www.eschkitai.de/ ## Etikette, nein Danke? -- http://www.suse-etikette.de.vu/
Helga Fischer schrieb am Mon, 16 Feb 2004 20:35:38 +0100: tar-Fehlermeldung
Hallo Jörg,
Am Montag Februar 16 2004 14:02 schrieb Joerg Thuemmler:
..
Wird $config nirgendwo mehr offen gehalten (das könnte tar in einen Lesefehler treiben, wenn er kein EOF in $config findet).
Blöde Frage: Wie sehe ich denn ein EOF? Die Datei könnte ich nur noch einmal abschreiben.
Sehen kannst Du das schlecht. Aber ein schreibender Prozeß (wer erstellt Deine $config?) könnte den Dateidescriptor noch offen haben. Im mc sieht man sowas z.B. daran, daß bei der (Text-)Dateianzeige mit F3 in der Statuszeile "growing" steht, evt. bleibt auch ein "tail -f $config" am Laufen - nee, Mist, bleibt es eh immer, auch bei geschlossenen Dateidescriptoren... Evt. kannst Du sie nicht zum Schreiben öffnen, dann muß das Proggi das aber direkt tun, Editoren z.B. öffnen i.allg. nur eine Kopie. ..
Helga
Vielleicht sind es ja wirklich nur ein paar Sockets, wenn Dir sonst nix fehlt. Jedenfalls keine Bänder und Laufwerke IMHO. cu -- Joerg Thuemmler sysadmin@vordruckleitverlag.de
Helga Fischer schrieb am Mon, 16 Feb 2004 09:27:43 +0100: tar-Fehlermeldung
Hallo Liste,
ich lasse über Nacht eine umfangreiche Sicherung auf Band laufen. tar schnappt sich anhand einer Liste die diversen Verzeichnisse, komprimiert sie und schreibt sie auf ein Band. Gesichert werden über 200000 Dateien.
Leider bricht die Sicherung immer wieder (jede zweite etwa) mit dieser Fehlermeldung ab: 'Error exit delayed from previous errors'.
Habe ich eine softwaretechnische Methode, um der Fehlerquelle auf die Spur zu kommen? (Die Sicherung lasse ich mir so mitloggen, daß mir aufgezeichnet wird, was gesichert wurde).
Angenommen, das Band wäre voll oder am Ende nicht mehr in Ordnung, würde ich dann die gleiche Fehlermeldung erhalten? (Über die Hardware des Bandes kann ich leider nichts sagen).
Helga
Hallo, bei der Fehlermeldung würde ich darauf tippen, daß tar abbricht, weil z.B. eine pipe nicht korrekt liefert. Wenn Du Dein script oder Deine Kommandozeile mitteilst, kann man das vielleicht besser sehen. Wenn tar selbst aufgrund von Bandfehlern etc. abbricht, gibt es IMHO klare Fehler für das Device aus. Ich habe seit 3 Jahren kein tar mit Band mehr gemacht, damals war es noch SINIX 5.24 auf NSC, aber ich erinnere mich deutlich an Fehler, wie "... i/o Error ... bytes AC 0A CC ... write error on device /dev/rmt0 ..." und ähnliches Geschreibsel in solchen Fällen, denke, daß das nicht groß anders geworden ist. Diese "delayed" Fehler habe ich bislang nur bei sowas wie einer abgestürzten Operation, die was in eine pipe liefert, an deren anderem Ende z.B. ein tar wartet, gesehen. just my 2c -- Joerg Thuemmler sysadmin@vordruckleitverlag.de
Hallo Jörg, Am Montag, 16. Februar 2004 10:19 schrieb Joerg Thuemmler:
Helga Fischer schrieb am Mon, 16 Feb 2004 09:27:43 +0100:
Habe ich eine softwaretechnische Methode, um der Fehlerquelle auf die Spur zu kommen? (Die Sicherung lasse ich mir so mitloggen, daß mir aufgezeichnet wird, was gesichert wurde).
bei der Fehlermeldung würde ich darauf tippen, daß tar abbricht, weil z.B. eine pipe nicht korrekt liefert. Wenn Du Dein script oder Deine Kommandozeile mitteilst, kann man das vielleicht besser sehen.
Vorher wird getestet, ob die Verzeichnisse nicht zu viele Daten enthalten, ein Band eingelegt ist und ähnlicher Kleinkram. Variablen sind ganz vorne definiert. [...] $tar -cvf $streamer -p --files-from $config >& $file || { (echo " ---------------------------------------------------------------------- Sorry, Your backup was NOT successful. [...] " ) | $mail $mailto -s "Attention: Backup NOT successful" \ && ( echo " --------------------------------------------------- #### #### `date`: Backup NOT successful" >> $mainlog ) exit 1 } echo " ------------------------------- `date` Backup successful " >> $mainlog [...]
Wenn tar selbst aufgrund von Bandfehlern etc. abbricht, gibt es IMHO klare Fehler für das Device aus.
Danke. Helga -- ## Netikette nein danke? -- http://www.suse-etikette.de.vu/ ## Mit vielen nützlichen Tipps -- Lesen lohnt sich ## Rückmeldungen erbeten und erwünscht
Helga Fischer
ich lasse über Nacht eine umfangreiche Sicherung auf Band laufen. tar schnappt sich anhand einer Liste die diversen Verzeichnisse, komprimiert sie und schreibt sie auf ein Band. Gesichert werden über 200000 Dateien.
Leider bricht die Sicherung immer wieder (jede zweite etwa) mit dieser Fehlermeldung ab: 'Error exit delayed from previous errors'.
Habe ich eine softwaretechnische Methode, um der Fehlerquelle auf die Spur zu kommen? (Die Sicherung lasse ich mir so mitloggen, daß mir aufgezeichnet wird, was gesichert wurde).
Angenommen, das Band wäre voll oder am Ende nicht mehr in Ordnung, würde ich dann die gleiche Fehlermeldung erhalten? (Über die Hardware des Bandes kann ich leider nichts sagen).
wenn man beim tar'en die option -v (verbose) angibt und das ganze dann in eine datei schreibt: tar -c .. -v ... 2>&1 | tee log-daatei dann reicht ein einfaches grep tar: log-datei Die Fehler sind meistens irgendwelche sockets oder so, die gesichert werden wollen. Ich empfehle sowieso LVM + snapshots zu benutzen. Bye Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 9204871 Fax: +49(721) 24874 Juergen.Vollmer@[informatik-vollmer.de|alumni.uni-karlsruhe.de|acm.org] www.informatik-vollmer.de
Hallo Helga, Helga Fischer wrote on Montag, 16. Februar 2004 09:27 about tar-Fehlermeldung:
Leider bricht die Sicherung immer wieder (jede zweite etwa) mit dieser Fehlermeldung ab: 'Error exit delayed from previous errors'.
Die Fehlermeldung ist an sich noch nicht schlimm. Sie kommt auch, wenn ein Backup ordentlich durchgelaufen ist, aber zwischenzeitlich bestimmte Zustände aufgetreten sind, wie sockets, die nicht mitgesichert werden, ... Bricht er wirklich ab? Wenn Du komplett mitloggst, fehlen dann noch eine Reihe von Files? Könnte natürlich sein, dass die Bändern verschlissen sind und daher der Platz nicht mehr ausreicht, aber ich meine da dann andere Meldungen gesehen zu haben. Schau mal im Log nach "tar: ", das leitet normalerweise Fehlermeldungen ein. -- Gruss Marcus Marcus Roeckrath -- Vikarsbusch 8 -- D-48308 Senden -- Germany Phone : +49-2536-9944 -- Mailer/BBS/Fax : +49-2536-9943 (V34, X75) FidoNet: 2:2449/523 E-Mail : marcus.roeckrath@gmx.de WWW : http://home.foni.net/~marcusroeckrath/
Hallo Marcus, Am Montag Februar 16 2004 19:47 schrieb Marcus Roeckrath:
Helga Fischer wrote on Montag, 16. Februar 2004 09:27
Leider bricht die Sicherung immer wieder (jede zweite etwa) mit dieser Fehlermeldung ab: 'Error exit delayed from previous errors'.
Die Fehlermeldung ist an sich noch nicht schlimm. Sie kommt auch, wenn ein Backup ordentlich durchgelaufen ist,
Gut zu wissen.
aber zwischenzeitlich bestimmte Zustände aufgetreten sind, wie sockets, die nicht mitgesichert werden, ...
Bricht er wirklich ab? Wenn Du komplett mitloggst, fehlen dann noch eine Reihe von Files?
Gute Frage. Du meinst, ob eine Reihe von Files auf dem Band fehlt. Das ist das einzige, an dem ich noch nicht 'rumgespielt' habe. Ich sitze nicht in der Firma, sondern werkle nur per ssh auf deren Rechnern rum. Ich habe nur aus meinem Log geschlossen, daß etwas fehlen muß, da ja sonst das Log weiterliefe bis zum Ende.
Könnte natürlich sein, dass die Bändern verschlissen sind und daher der Platz nicht mehr ausreicht, aber ich meine da dann andere Meldungen gesehen zu haben.
Auf Platz prüft das Skript ab, ist aber nur eine Schätzung. Würde man das nicht merken, wenn man morgens das Band in die Hand nimmt? (Leider sind die Jungs in dieser Firma nicht besonders helle). Vielleicht, weil es sich automatisch zurückgespult hat oder ausgeworfen wurde? (Sorry, aber ich hatte noch nie so ein Bandgerät zum Ausprobieren in den Händen - irgendwie bin ich allein auf gesunden Menschverstand angewiesen).
Schau mal im Log nach "tar: ", das leitet normalerweise Fehlermeldungen ein.
Ich habe jetzt nach "/bin/tar" gegreppt, das hat tatsächlich noch eine Datei zu Tage gefördert, die sich während des Sicherungslaufs geändert hat. Das war jedoch die einzige Fehlermeldung so mitten drin im Logfile. Helga -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## Werkstatt & Information zu OpenSource -- http://www.eschkitai.de/ ## Etikette, nein Danke? -- http://www.suse-etikette.de.vu/
Hallo Helga, Helga Fischer wrote on Montag, 16. Februar 2004 20:44 about Re: tar-Fehlermeldung:
Gute Frage. Du meinst, ob eine Reihe von Files auf dem Band fehlt. Das ist das einzige, an dem ich noch nicht 'rumgespielt' habe. Ich sitze nicht in der Firma, sondern werkle nur per ssh auf deren Rechnern rum.
Müsste sich doch sehr einfach feststellen lassen. Du sicherst doch bestimmte Verzeichnissebäume. tar greift sich die Dateinen unsortiert, also müsste man mal nachsehen, ob die letzte nach Log gesicherte datei auch die letzte zu sichernde gewesen wäre.
Ich habe nur aus meinem Log geschlossen, daß etwas fehlen muß, da ja sonst das Log weiterliefe bis zum Ende.
Woraus schliesst Du, dass das Log nicht bis zum Ende durchläuft? Wenn diese "previous errors"-Fehlermeldung kommt ist tar am Ende und weist bei einem ansonsten problemlosen Lauf eigentlich nur daraufhin, dass zwischenzeitlich etwas "unklares" aber eventuell völlig belangloses passiert ist. Diese aufgetretenen Probleme sind halt nich so schwerwiegend gewesen, dass sie zu einem sofortigen Stop geführt haben, also nicht "critical" waren und deshalb "delayed" werden konnten. Wenn Du feststellen kannst, dass die zuletzt im Log stehende Datei auch gleichzeitig die als letzte zu sichernde war, sollte das Backup in Ordnung sein, gegebenenfalls Dateien sich während des Sicherns geändert haben, sockets nicht mitgesichert wurden, ...
Auf Platz prüft das Skript ab, ist aber nur eine Schätzung. Würde man das nicht merken, wenn man morgens das Band in die Hand nimmt?
Dem Band siehst Du nicht an, ob es noch in Ordnung ist. Tritt ein Bandfehler auf, werden die gleichen Daten eben ein Stück weiter nochmal gesichert. Das kann bei stark abgenutztem Band schon dazu führen, dass die Kapazität deutlich runtergeht; aber so ein Band gehört auf den Müll.
(Leider sind die Jungs in dieser Firma nicht besonders helle). Vielleicht, weil es sich automatisch zurückgespult hat oder ausgeworfen wurde? (Sorry, aber ich hatte noch nie so ein Bandgerät zum Ausprobieren in den Händen - irgendwie bin ich allein auf gesunden Menschverstand angewiesen).
Zurückspulen hängt vom Device ab, welches bei des Sicherung angegeben wurde. Auswerfen muss man normalerweise manuell tun oder überläßt es dem Tool mt, aber tar ejected IMHO nicht.
Ich habe jetzt nach "/bin/tar" gegreppt, das hat tatsächlich noch eine Datei zu Tage gefördert, die sich während des Sicherungslaufs geändert hat. Das war jedoch die einzige Fehlermeldung so mitten drin im Logfile.
Wieso greppst Du nach /bin/tar? Die Fehlermeldungen beginnen doch mit "tar: ". Ein solcher Fehler, dass sich ein Datei genau zum zeitpunkt der Sicherung verändert führt zu einem "delayed error", IMHO ganz normal und somit nicht kritisch für den Backupvorgang. -- Gruss Marcus Marcus Roeckrath -- Vikarsbusch 8 -- D-48308 Senden -- Germany Phone : +49-2536-9944 -- Mailer/BBS/Fax : +49-2536-9943 (V34, X75) FidoNet: 2:2449/523 E-Mail : marcus.roeckrath@gmx.de WWW : http://home.foni.net/~marcusroeckrath/
Hallo Marcus, Am Montag Februar 16 2004 21:35 schrieb Marcus Roeckrath:
Helga Fischer wrote on Montag, 16. Februar 2004 20:44 about Re: tar-Fehlermeldung:
Gute Frage. Du meinst, ob eine Reihe von Files auf dem Band fehlt. Das ist das einzige, an dem ich noch nicht 'rumgespielt' habe. Ich sitze nicht in der Firma, sondern werkle nur per ssh auf deren Rechnern rum.
Müsste sich doch sehr einfach feststellen lassen. Du sicherst doch bestimmte Verzeichnissebäume.
Yo, richtig.
tar greift sich die Dateinen unsortiert, also müsste man mal nachsehen, ob die letzte nach Log gesicherte datei auch die letzte zu sichernde gewesen wäre.
Nein, das ist nicht der Fall. Allerdings fehlt nicht besonders viel. Es läuft also fast bis zum Ende, aber eben nicht ganz. Das ist irgendwie unbefriedigend.
Ich habe nur aus meinem Log geschlossen, daß etwas fehlen muß, da ja sonst das Log weiterliefe bis zum Ende.
Woraus schliesst Du, dass das Log nicht bis zum Ende durchläuft?
Aus der Fehlermeldung, die die letzte Zeile des Logs ausmacht. Würde nach dieser Fehlermeldung noch etwas gesichert, müßte es ja aufgelistet werden. Dabei fällt mir auf, daß ich vielleicht dem menschlichen Denken aufgesessen bin. Für mich war immer relevant, was spuckt ein 'ls' aus und was steht im Log. Natürlich ging ich davon aus, daß tar genau so durch's Filesystem sichert, wie ls mir das auflistet. Liegt vielleicht hier mein Fehler? Ggfs würde dann ja reichen, sich das Inhaltsverzeichnis vom Band gegen zu lassen und mit dem zu vergleichen, was die Platte liefert? *autsch*
Wenn diese "previous errors"-Fehlermeldung kommt ist tar am Ende und weist bei einem ansonsten problemlosen Lauf eigentlich nur daraufhin, dass zwischenzeitlich etwas "unklares" aber eventuell völlig belangloses passiert ist.
Das würde ja zu der Meldung passen, die ich zwischenrein gefunden habe. [...]
Auf Platz prüft das Skript ab, ist aber nur eine Schätzung. Würde man das nicht merken, wenn man morgens das Band in die Hand nimmt?
Dem Band siehst Du nicht an, ob es noch in Ordnung ist. Tritt ein Bandfehler auf, werden die gleichen Daten eben ein Stück weiter nochmal gesichert. Das kann bei stark abgenutztem Band schon dazu führen, dass die Kapazität deutlich runtergeht; aber so ein Band gehört auf den Müll.
OK.
(Leider sind die Jungs in dieser Firma nicht besonders helle). Vielleicht, weil es sich automatisch zurückgespult hat oder ausgeworfen wurde?
Zurückspulen hängt vom Device ab, welches bei des Sicherung angegeben wurde. Auswerfen muss man normalerweise manuell tun oder überläßt es dem Tool mt, aber tar ejected IMHO nicht.
Yo. Hab' gesehen, daß es einen Befehl 'eject' gibt.
Ich habe jetzt nach "/bin/tar" gegreppt, das hat tatsächlich noch eine Datei zu Tage gefördert, die sich während des Sicherungslaufs geändert hat. Das war jedoch die einzige Fehlermeldung so mitten drin im Logfile.
Wieso greppst Du nach /bin/tar? Die Fehlermeldungen beginnen doch mit "tar: ".
Weil ich (aus alter Gewohnheit) nur mit grep irgendwas arbeite. Ich sollte mir wohl mal die " " angewöhnen. Die Zeile fängt bei mir übrigens tatsächlich mit /bin/tar an.
Ein solcher Fehler, dass sich ein Datei genau zum zeitpunkt der Sicherung verändert führt zu einem "delayed error", IMHO ganz normal und somit nicht kritisch für den Backupvorgang.
Danke, das ist gut zu wissen. Helga -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## Werkstatt & Information zu OpenSource -- http://www.eschkitai.de/ ## Etikette, nein Danke? -- http://www.suse-etikette.de.vu/
Hallo! Am Montag, 16. Februar 2004 22:18 schrieb Helga Fischer:
Dabei fällt mir auf, daß ich vielleicht dem menschlichen Denken aufgesessen bin. Für mich war immer relevant, was spuckt ein 'ls' aus und was steht im Log. Natürlich ging ich davon aus, daß tar genau so durch's Filesystem sichert, wie ls mir das auflistet. Liegt vielleicht hier mein Fehler?
Vielleicht: AFAIK liefert ls -f die Dateien in der Reihenfolge, wie sie im Verzeichnis liegen, und wohl auch von find, tar, etc. gefunden werden.
Ggfs würde dann ja reichen, sich das Inhaltsverzeichnis vom Band gegen zu lassen und mit dem zu vergleichen, was die Platte liefert? *autsch*
Yup! [...]
Auf Platz prüft das Skript ab, ist aber nur eine Schätzung. Würde man das nicht merken, wenn man morgens das Band in die Hand nimmt?
Wenn der Speicherplatz zu knapp ist, sollte doch irgendetwas in der Form "no space left on device" kommen, auch bei einem Band. Habe allerdings kein funktionierendes Laufwerk mehr, so daß ich es nicht ausprobieren kann. Thilo -- ------------------------------------------------------------------------------------ Thilo Gramlich Thilo (a dot) Gramlich (an at symbol) aktivanet (a dot) de
Hallo Thilo, Thilo Gramlich wrote on Montag, 16. Februar 2004 23:52 about Re: tar-Fehlermeldung:
Vielleicht: AFAIK liefert ls -f die Dateien in der Reihenfolge, wie sie im Verzeichnis liegen, und wohl auch von find, tar, etc. gefunden werden.
Schrieb gerade an Helga, dass es möglicherweise ls -U ist, aber ls -f (= -aU) scheint wegen der sonst fehlenden .-Dateien wahrscheinlicher.
Wenn der Speicherplatz zu knapp ist, sollte doch irgendetwas in der Form "no space left on device" kommen, auch bei einem Band.
Irgendsoetwas kommt, hatte ich auf meinem alten DDS2-Gerät auch schon. Aber eine Garantie übernehme ich nicht dafür, ist zu lange her. -- Gruss Marcus Marcus Roeckrath -- Vikarsbusch 8 -- D-48308 Senden -- Germany Phone : +49-2536-9944 -- Mailer/BBS/Fax : +49-2536-9943 (V34, X75) FidoNet: 2:2449/523 E-Mail : marcus.roeckrath@gmx.de WWW : http://home.foni.net/~marcusroeckrath/
Hallo Helga, Helga Fischer wrote on Montag, 16. Februar 2004 22:18 about Re: tar-Fehlermeldung:
Woraus schliesst Du, dass das Log nicht bis zum Ende durchläuft?
Aus der Fehlermeldung, die die letzte Zeile des Logs ausmacht. Würde nach dieser Fehlermeldung noch etwas gesichert, müßte es ja aufgelistet werden.
Denkfehler: Die von Dir beobachtete Fehlermeldung kommt immer erst am Ende! Sie wird ja gerade delayed bis tar fertig ist (erfolgreich oder durch critical error). Da aber kein kritischer Fehler vorgekommen ist, würde ich fast sagen, dass Backup ist ok.
Für mich war immer relevant, was spuckt ein 'ls' aus und was steht im Log. Natürlich ging ich davon aus, daß tar genau so durch's Filesystem sichert, wie ls mir das auflistet. Liegt vielleicht hier mein Fehler?
tar sichert IMHO in der Reihenfolge, die ein ls -U liefert. -- Gruss Marcus Marcus Roeckrath -- Vikarsbusch 8 -- D-48308 Senden -- Germany Phone : +49-2536-9944 -- Mailer/BBS/Fax : +49-2536-9943 (V34, X75) FidoNet: 2:2449/523 E-Mail : marcus.roeckrath@gmx.de WWW : http://home.foni.net/~marcusroeckrath/
Hallo Helga, hallo Leute, Am Montag, 16. Februar 2004 20:44 schrieb Helga Fischer:
Am Montag Februar 16 2004 19:47 schrieb Marcus Roeckrath:
Helga Fischer wrote on Montag, 16. Februar 2004 09:27
Leider bricht die Sicherung immer wieder (jede zweite etwa) mit dieser Fehlermeldung ab: 'Error exit delayed from previous errors'. [...] Ich habe jetzt nach "/bin/tar" gegreppt, das hat tatsächlich noch eine Datei zu Tage gefördert, die sich während des Sicherungslaufs geändert hat. Das war jedoch die einzige Fehlermeldung so mitten drin im Logfile.
Das reicht dann schon für die Fehlermeldung "Error exit delayed from previous errors". Gruß Christian Boltz -- Wenn du in deiner procmail spamassassin stehen hast, dann wird für jede eintrudelnde Mail das komplette Programm gestartet, inclusive Initialisierung und PiPaPo - also, ich mache meine Wohnung am liebsten mit der Zentralheizung warm, nicht mit meiner Festplatte. ;-) [Ratti in suse-linux]
Helga Fischer hat am Dienstag, 17. Februar 2004 geschrieben:
Habe ich eine softwaretechnische Methode, um der Fehlerquelle auf die Spur zu kommen? (Die Sicherung lasse ich mir so mitloggen, daß mir aufgezeichnet wird, was gesichert wurde).
Hallo Helga, ich hatte mal ein ähnliches Problem. Aber strace tar <tar-optionen> > tar.errors 2>&1 konnte mir weiterhelfen. Einfach die Datei tar.errors nach Fehlern durchsuchen. (Jaaaa, die wird ziemlich groß...) Im übrigen hat bei mir ein Reinigngsband auch schon seltsame Fehlermeldungen ausgebügelt. Gruß, Philip. -- Philip Link www.link-development.de linux@link-development.de
participants (8)
-
Christian Boltz -
Daniel Lord -
Dr. Jürgen Vollmer -
Helga Fischer -
Joerg Thuemmler -
Marcus Roeckrath -
Philip Link -
Thilo Gramlich