"Mehrere Wege führen nach Rom" sagt man im Volksmund. Wir haben bis jetzt mehrere Lösungen ausprobiert und sind wieder zum direkten "File by File" Backup zurückgekehrt. Alle Interims-Lösungen mit riesen Zip Dateien oder gzip tars oder temporären 400 Giga Platten sind bei der Rücksicherung mühselig bis unpraktikabel.

Aus der Erfahrung von 20 Jahren EDV ist die Absicherung vor einem totalen Platten- Ausfall der wichtigste Grund für eine Band-Sicherung. Wenn man ganze Volumes sichert, würde sogar der Volume Name und das Datum auf dem Etikett völlig ausreichen. Eine primitive Logdatei ist zusätzlich mit geringstem Aufwand machbar und dazu sehr hilfreich.

Wir wollen pro Backup-Session alle Files in den entsprechenden Verzeichnissen auf Bänder (in 6er Sets) sichern. Also unser Server soll sich auf 6 x 35 Giga Bändern abbilden lassen. Die beiden Boot Partitionen sichern wir mit Netware Hausmitteln in unregelmäßigen Abständen auf einen kleinen DLT-2000 Streamer

Dieser Text ist uralt und in 2022 sind die DLT Streamer obsolet geworden.
.

Wie bekomme ich einen schnellen DLT oder S-DLT (oder LTO) Drive zum "Streamen", wenn der Server definitiv langsamer ist ?

Fest steht, unser 284Giga Server unter NW4.11 liefert die Daten zur Zeit (Jan 2005) im Schnitt mit 3,4MB/s, mehr nicht. Unser DLT-7000 will mindestens 5MB/s haben. Selbst ohne Kompression im DLT Drive würde das ein elend langer Start-Stop Betrieb, der dem Laufwerk arg zusetzt. Aus der Erfahrung überhitzen die Motoren, wenn durch das Laufwerk nicht extrem viel Luft durchgeblasen wird.

Also ist die oberste Forderung :

Das Laufwerk muß möglichst lange den vollen Datenstrom bekommen.

Es ist uns bekannt, über die mittlere Daten-Lese-Geschwindigkeit kommen wir sowieso nicht hinaus. Also müssen die Daten in einem optimierten, möglichst großen, Ringpuffer eingelesen und vorgehalten werden.

Der Datenabfluß aus dem Ringpuffer an das DLT Laufwerk muß per "Threshhold" Option (andere sagen Watermark) so gesteuert werden, daß es erst bei 99% Füllstand los geht und beim Erreichen des Leerlaufs bis zum nächsten "Voll-" Füllstand pausiert wird.

Während aus dem Puffer Daten zum DLT geschickt werden, soll (muß) dieser mit maximaler Lese-Geschwindigkeit nachgefüllt werden. Wir wissen, daß der Puffer dennoch ziemlich schnell leer läuft.

Das funktioniert bei uns schon mit "tar" und "mbuffer" und einer 35 Giga DLT-Kassette. Das "mbuffer" Programm beginnt (in unseren Tests) mit 400 MB Füllstand Daten auf das DLT Laufwerk zu schreiben und läuft dann etwa bis zu einer Gesamtmenge von 800MB am Stück, bis der Puffer völlig leer ist. Dann muß das DLT Laufwerk warten, bis wieder 400 MB vom Server gepuffert sind und es geht weiter.