Hier sind wir noch am Arbeiten, also ausgereift ist das Ganze noch nicht. Die bandübergreifende "Multi-Volume" Version haben wir noch nicht mit einer DLT Lib am Laufen. Auch das Abfragen der wichtigen Drive Blockgröße hat noch Macken. Aber wir sind dran, sogar 26 Stunden am Tag.

Der erste Punkt ist der Ethernet Switch in Ihrem Netzwerk, der bei Ihnen verfügbar ist. Wir arbeiten bei DLT und "tar" am Ende mit recht kleinen 64KB Paketen (das ist die interne DLT Puffer Blockgröße). Wie das "tar" Programm davon unabhängig die Daten vom Server holt, weiß ich noch nicht.

Manche Switches haben da Probleme, vor allem die billigen. Die von LevelOne und Allnet sind sehr bescheiden. Alleine der Umstieg auf nur noch einen Bay Networks Centillion100 brachte die Leserate (bei IPX/SPX) von 2,4MB/s auf ca. 3,3MB/s rauf. Bei TCP/IP mag es deutlich schneller sein, der IPX Treiber ist die Bremse. Aber immerhin, der Switch macht einiges aus.

Die einfache Kommandozeile in der root Konsole ist unter Suse 9.2 und 10.2 beschrieben.

# tar cfM - /mnt/das-moechte-ich-sichern/ -b 128 | mbuffer -m 400M -p 98 > /dev/st0

Hiermit gelang es, ca 750Mb in einem Rutsch auf das Band zu schreiben, bevor tüchtig nachgeladen wurde.

Mit der höheren Leserate sind es inzwischen 1,1GB pro Schreibvorgang, denn er lädt ja kontinuierlich weiter, während er schreibt.

Die CPU Belastung ist im DMA Betrieb von Streamer und Netzwerkkarte minimal bei unserem 800er Duron, knapp 4%. Die mittlere Last "average load" wird in ksysguard mit 1,4 angezeigt.

Waren es beim ersten Versuch nur 2,4MB/s

	Kalkulation : 2,4MB/sec = 144MB/min = 8,4 Giga/Std
	bei 35 Gig pro Band = etwa 4 Std. (mit unserem Server "File by File")

so sind es jetzt bei 3,3MB/s

	Kalkulation : 3,3MB/sec = 198MB/min = 11,8 Giga/Std
	bei 35 Gig pro Band = nur noch etwa 2,9 Std.

bei folgender Kommando Zeile mit doppeltem tar Puffer:

# tar cfM - /mnt/das-moechte-ich-sichern/ -b 256 | mbuffer -s 65536 -m 400M -p 98 > /dev/st0

Das mit der "M" Option bei "tar" klappt so nicht. Mit der Option "M" kann (soll können) ein Backup auf mehrere Bänder verteilt werden, wobei das Backup am Ende eines Bandes automatisch auf das nächste Band wartet. Mit der zwischengeschalteten Pufferung klappt das Erkennen des Bandendes so nicht mehr. Diese Funktionalität müsste in das Pufferprogramm verlagert werden. "mbuffer" kennt zwar schon eine Option (-n), um mehrere aufgeteilte Sicherungen einzulesen, aber noch keine, um eine laufende Sicherung auf mehrere Bänder aufzuteilen. Als Alternative zu "tar" gibt es noch "star", das ein internes Puffern schon eingebaut hat, aber nicht ganz die Flexibilität wie "mbuffer" zum Puffern bietet.

Sind die zu sichernden Daten in einem Format, das der optimalen 2:1 Kompression nicht entspricht und das DLT-Laufwerk wegen zu hoher Kompression nicht mehr streamt, dann bleibt leider nur übrig, die Kompression abzuschalten. Ein gleichmäßig laufendes DLT kann ohne Kompression sogar schneller sein als ein ständig stoppendes Laufwerk bei dem wegen der hohen Kompression der Daten die maximale Datentransferrate ständig überschritten wird. Dazu läßt sich mit den mt-Tools per "mt -f /dev/nst0 datcompression 0" einfach die Kompression vor dem Start der Sicherung abschalten.

Auch hier werden wir kontinuierlich neue ausprobierte Komandozeilen nachtragen.

gefunden:

http://www.die.net/doc/linux/man/man1/star.1.html