Re: Datensicherung

From: Greg Lehey <grog(at)lemis.com>
Date: Tue, 12 Oct 1999 11:02:25 +0930

On Monday, 11 October 1999 at 19:32:25 +0200, Bernd Walter wrote:
> On Mon, Oct 11, 1999 at 06:24:22PM +0100, Christoph Prevezanos wrote:
>>> Na, so würde ich nicht sprechen. Ein Segmentation Fault ist ein
>>> Programmfehler. War's wirklich so einer? Hat's Meldungen in
>>> /var/log/messages gegeben?
>>
>> Ok, ich habe ich tatsaechlich was vertauscht. Das war eine
>> andere Fehlermeldung. Sorry !
>>
>> cpio sagt natuerlich "warning: skipped xxx bytes of junk,
>> invalid header: checksum error".
>> Also wirklich ein Bandlesefehler und kein Programmfehler.
>
> Ein richtiger Lesefehler sollte Spuren in der messages hinterlassen,
> da dieser ueber den SCSI-Layer gemelded wird.
>
>> Das Problem bleibt aber das selbe: Ich habe staendig jede
>> Menge Lesefehler auf den Baendern. Die Cassetten sind
>> alle neu und das Laufwerk auch so gut wie.
>>
>> Muss ich jetzt nach jeder Sicherung das Reinigungsband
>> einwerfen, oder was ?

Hast Du keine Bedienungsanleitung für's Gerät? Da gibt es
Blinkenlights, die angeben, wann gereinigt werden soll. Häufiger
reinigen hilft nicht.

> Ich kann das eigendlich aus meiner Erfahrung nicht bestaetigen. DDS
> ist zwar nicht das beste aber soo schlimm nun auch nicht. Im
> Regelfall merkt das Laufwerk doch recht frueh wenn ein Reinigungs-
> band sinnvoll ist - vorausgesetzt man versteht die Blinkcodes :) Es
> ist wird allerdings nach der Erstbenutzung eines Bandes empfohlen
> eines einzulegen.

Die Empfehlung kenne ich nicht. Das eine Mal könnte aber nicht
schaden.

>>> Ich würde tar benutzen, andere empfehlen sicher dump.
>>
>> tar hatte ich vorher auch verwendet, habe es jetzt aber mal
>> mit cpio probiert, da tar bei Lesefehlern abbricht, cpio aber
>> weitermacht.
>
> Meiner Erfahrung nach gibt es immer wieder Aerger mit dem Bandende.
> Keine Ahnung warum das heute noch ein Problem darstellt.

Man kann sich nicht einigen, wie es zu behandeln ist.

On Tuesday, 12 October 1999 at 1:30:23 +0100, Christoph Prevezanos wrote:
> Hallo Bernd,
>
>>> cpio sagt natuerlich "warning: skipped xxx bytes of junk,
>>> invalid header: checksum error".
>>> Also wirklich ein Bandlesefehler und kein Programmfehler.
>
>> Ein richtiger Lesefehler sollte Spuren in der messages hinterlassen,
>> da dieser ueber den SCSI-Layer gemelded wird.
>
> Hmm, da bin ich nicht so der Fachmann fuer SCSI usw.
> Wie saehe denn so eine Spur aus?

Je nach Fehlermeldung. Die Zeit wird aber übereinstimmen, und
irgendwo in der Meldung erscheint auch der Name der Bandeinheit.

> Das Band ist bei mir auf keinen Fall voll, beim Schreiben kommen da
> auch keine Fehlermeldungen. Nur, wenn ich versuche das Band spaeter
> wieder zu lesen kommen die o.g. Meldungen und dahinter der Name der
> Datei, die es betrifft. Ich kann diese dann auch nicht vom Band
> zurueck auf die Platte schreiben.

Hört sich nach echten Fehlern an. Und das passiert bei mehreren neuen
Bändern?

> Kennst Du evtl. die von mir beschriebene Fehlermeldung und
> weisst, was sie sonst bedeuten koennte ?

Vermutlich kommt das von cpio und bezieht sich auf das eigene Format.
Am Ende eines Datenblocks erwartet cpio einen Headerblock und findet
ihn nicht.

> tar hat immer etwas aehnliches gesagt und dann abgebrochen.

"Etwas ähnliches" ist etwas schwammig. Genaue Fehlermeldungen helfen
weiter.

>> Schau dich erst mal in der Messages um.
>> Ueberpruefe dann ob es evtl mit dem Bandende zu tun hat.
>> Ansonsten kommt natuerlich noch wie so oft mal wieder das RAM in
>> Verdacht. Mach doch hierzu mal eine Sicherung in ein File...
>
> Wie koennte / sollte denn die Message sonst aussehen, wenn es
> sich um einen "echten" Lesefehler handelt ?
> RAM-maessig ist der Rechner eigentlich gut ausgestattet.

Damit wird's auch nichts zu tun haben.

> Wenn ich das Backup in eine Datei irgendwo auf der Platte
> mache, geht alles problemlos.
>
>> Meiner Ansicht nach ist DDS nicht unbedingt das Medium fuer taegliche
>> Sicherungen - aber fuer woechentliche durchaus geeignet.
>> Als sehr zuverlaesig haben sich meiner Erfahrung nach DLT, MLR und MO
>> erwiesen. Die Unterschiede im Kaufpreis sind allerdings ein guter Grund private
>> Nutzer fernzuhalten.
>
> Nun, was den Preis angeht, ist mir das nicht so wichtig.
> Aufgrund der grossen Datenmenge laesst sich ja schon vermuten,
> dass das System nicht privat genutzt wird, sondern in einer Firma
> installiert ist. Mir ist vom Begriff her sonst eigentlich nur DLT bekannt,
> gearbeitet habe ich damit aber noch nicht. Sollte halt ein System sein,
> dass sich fuer taegliche Backups eignet und recht zuverlaessig ist.

Gut, mit dem Bernd stimme ich hier nicht überein. Meine Erfahrungen
waren eher die, dass die Geräte eine sehr kurze Lebensdauer hatten
(DDS-1: 8 Monate; DDS-2: 18 Monate).

> Da wir hier mit Geo-Daten, GIS und Landschaftsplanung arbeiten,
> faellt da jeden Tag echt tierisch was an Daten an. Wenn die weg sind
> koennen wir den Laden dicht machen. Deshalb geht Sicherheit absolut
> vor. Im Grunde habe ich dieses DAT-Tape auch nur, weil es mir seinerzeit
> empfohlen wurde. Es sollte angeblich schnell sein, viele Daten fassen und
> sicher sein. War wohl evtl. ein Fehler....

Gut, DLT ist zuverlässiger, kostet aber etwa 5 bis 10mal so viel wie
DDS (obwohl gerade die DDS-3 nicht billig sind). Aber solche
Probleme, wie Du sie beschreibst, sind schon die Ausnahme.

Ich denke, Dein Problem ist entweder:

1. Das Teil ist defekt.

2. Irgendwie bringst Du die Blöcke durcheinander. Ich habe eine
    Reihe Bänder, die ich über's Netz mit Hilfe von dd geschrieben
    habe, die tar absolut nicht riechen kann, da die Blöcke
    unterschiedlich lang. Sowas könnte auch zu Deinen Problemen
    führen. Was benutzt Du (genau) für einen Befehl beim Sichern?
    Beim Verfizierung?

Greg

--
When replying to this message, please copy the original recipients.
For more information, see http://www.lemis.com/questions.html
See complete headers for address, home page and phone numbers
finger grog(at)lemis.com for PGP public key
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 12 Oct 1999 - 03:32:53 CEST

search this site