Bandlaufwerke und LINUX

Bandlaufwerke bieten die Möglichkeit größere Datenmengen zu Sichern. Tägliche Backups von mehreren Rechnern und täglich einigen hundert GigaByte oder gar TerraByte Größe, die dann auch einige Tage aufbewahrt werden müssen, sind mit anderen derzeit verfügbaren Medien wie zB. DVD oder externe Festplatten nicht mehr handelbar. Besonders die modernen Bandlaufwerke die enorme Sicherungsgeschwindigkeiten und Bandkapazitäten erlauben, stellen an das Backupkonzept einige Anforderungen, die LINUX per default so nicht berücksichtigt. Speziell für den Einsatz solcher modernen Laufwerke und den Einsatz zum Sichern in kleinen Netzwerken oder in kleineren Büroumgebungen unter LINUX werden hier einige spezielle Hinweise gegeben.

Backup mit Bandlaufwerken

Bandlaufwerke eine Übersicht

Was ist ein Streamer und wie funktioniert er

Streamer ist eine andere Bezeichnung für Magnetband-Laufwerk. Der Ausdruck Streamer entstammt dem englischen Begriff "stream". Gemeint ist damit der kontinuierliche Daten-Strom, der sequentiell auf ein Magnetband gespeichert wird. Während also zum Beispiel eine Festplatte im Normalfall im Blockmodus betrieben wird, (es werden also größere Datenblöcke abgelegt und deren genaue Position im Filesystem vermerkt, damit die Blöcke auch wahlfrei wieder gelesen werden können) wird ein Streamer immer von Anfang an sequentiell von vorne nach hinten beschrieben, und die Daten müssen auch wieder so ausgelesen werden. Ein Bandlaufwerk kann man sich vorstellen wie ein Tonband mit 2 Spulen und einem Schreiblesekopf. Die Speicherung erfolgt jedoch nicht wie auf einem herkömmlichen Tonband mit analogen Methoden, sondern auf einen Streamer wird prinzipiell digital gesichert. Dabei haben sich Laufwerke mit wechselbaren Medien in Form von Kassetten ( Cartridges ) durchgesetzt, ähnlich zB. dem Kassetten eine Kassettenplayers oder zB von VHS-Videorecorder. Dabei ist ein wahlfreier Zugriff, wie zB. von einer Festplatte, so nicht möglich.

Auf einen Streamer werden in aller Regel keine einzelnen Dateien geschrieben, sondern die Dateien werden mit einem Archiver zB tar oder cpio in Archive gepackt. Der Streamer schreibt beim Sichern zwischen solche Archive spezielle Markierungen (EOF End Of File) und kann so Anfang und Ende solcher Archive erkennen und auch dorthin positionieren. Auf eine bestimmte Datei innerhalb eines Archives kann so aber nicht direkt positioniert werden, da der Streamer und die Backupsoftware die Position der Datenblöcke der einzelnen Dateien innerhalb eines solchen Archives nicht kennt. Das Archiv muss also vom Anfang gelesen werden, bis die gewünschte Datei im Archiv gefunden wird. Da beim Positionieren wirklich eine mechanische Positionierung erfolgt, (sprich ein Umspulen des Bandmaterials) dauert eine Positionierung auch einige Sekunden bis Minuten, je nach Laufwerkstype und Technologie. Moderne höhere Backupsoftware packt die Archive aus Frames zusammen, wobei sich in den Headern der einzelnen Frames noch Zusatzinformationen über das Archiv und die darin befindlichen Dateien befinden und/oder legt im Rechner noch zusätzliche Indexdateien an, mit deren Hilfe es möglich wird, auch innerhalb eines Archives in die Nähe einer bestimmten Datei zu positionieren. Damit kann uU. einiges an Zeit für das Auslesen einzelner Dateien von einem Band gespart werden.

Was jedoch auf einem Tonband geht, dass man an irgend einer Stelle einfach neu aufnehmen kann, und damit einen Teil der alten Daten dort einfach überschreiben kann, das geht mit Streamern nicht. Wenn irgendwo auf einem Band geschrieben wird, dann sind automatisch alle sich physikalisch dahinter befindliche alten Daten ungültig und nicht mehr zu lesen. Der Versuch dort hin zu positionieren wird mit einer Fehlermeldung abgewiesen. Auch muss immer zwingend am letztem Datenende oder am Ende eines Archives weitergeschrieben werden. Wenn das Beschreiben des Bandes beendet oder abgebrochen wird, wird an dieser Stelle immer ein EOF (End of File) und ein EOD (End of Data) geschrieben. Nur so wird es möglich das das Laufwerk diese Position auch wiederfinden kann, um zB dort wieder weiterzuschreiben.

Anschlusskonzepte von Bandlaufwerken

Da der Hauteinsatz dieser Laufwerke in der Vergangenheit immer Rechenzentren umfasste, und das bevorzugte Anschlusskonzept dort SCSI ist und war, werden auch heute noch die meisten Streamer mit SCSI angesteuert, oder in der neusten Variante SCSI über Fibre Channel . Daneben gibt es auch einige Geräte die über USB, IDE, SATA usw. angeschlossen werden können, das ist aber ehr die Ausnahme. Die meisten über SCSI angeschlossenen Geräte werden von LINUX problemlos unterstützt. Bei anderen Anschlusskonzepten kann es zu Treiberproblemen kommen.

Aufnahmetechnologie und Bandmaterial

Es gibt eine ganze Reihe von Technologien, die ihrerseits von der Aufnahmetechnologie und der Bandbreite unterschiedlich sind und untereinander nicht kompatibel. Es gibt zB Technologien mit 4mm breiten Bändern, mit 8mm breiten Bändern mit 1/4 Zoll und 1/2 Zoll breiten Bändern. Zwischen dem Bandmaterial und den eigentlichen Schreibleseköpfen muss eine hohe Geschwindigkeit erzeugt werden, um die Menge der Daten auch verarbeiten zu können. Dazu wurden verschieden Methoden entwickelt.

Beim Schrägspurverfahren, wie wir es auch von einem Videorecorder her kennen, sind mehrere Schreib-Leseköpfe auf einer sich ständig schnell drehenden Kopftrommel angeordnet. Die Achse der Trommel ist schräg gegen die Bandlaufrichtung geneigt, und das Band wird langsam um die sich drehende Kopftrommel geführt. Dadurch werden die Daten in Streifen schräg auf die gesamte Bandbreite geschrieben.

Beim Längsspurverfahren werden von einem feststehenden Kopf gleichzeitig mehrere Spuren parallel und längs der Bandrichtung geschrieben. Hier wird das Bandmaterial mit einer hohen Geschwindigkeit am Kopf vorbeigeführt. Das Band wird aber nicht über die gesamte Breite mit einem mal beschrieben, sondern in Serpentinen vor und zurück beschrieben, wobei der Kopf in der Hohe verstellt wird, so dass eine Vielzahl einzelner Spuren über die gesamte Bandlänge geschrieben werden.

Selbst bei den einzelnen Herstellern und der einzelnen Technologie gibt es ständig Verbesserungen der Datendichte auf den Bändern, was wiederum neue Standards und andere Aufzeichnungsverfahren und neue Bandtypen nach sich ziehen. Neue Laufwerkstypen unterstützen oftmals einen Teil von früheren Aufzeichnigsstandards, manchmal diese jedoch auch nur lesend.

Beispiele für Hersteller und Technologien

• QIC - Abkürzung für "Quarter-Inch-Cartridge", QIC spezifiziert einen Standard für (Streamer)-Kassetten mit 1/4 Zoll breiten Bändern.

• Travan - eine Untergruppe des QIC-Standards und ein Name, der von der Firma 3M (heute/ehemals Imation) ins Leben gerufen wurde. Die Cartridges sind etwas größer als Mini Cartridges und können aufgrund der längeren Bänder mehr Daten speichern.

• LTO - Abkürzung für "Linear Tape-Open Technology" Diesen Standard für Streamer / Bandlaufwerke haben IBM, Hewlett-Packard und Seagate Anfang 1998 vorgestellt.

Moderne heutige Technologien LTO Ultrium 3 ermöglichen Nettokapazitäten von mehr als 160GB und Schreibgeschwindigkeiten von mehr als 70MB/s. Ein Ende der Entwicklung immer schnellerer Laufwerke mit immer größerer Kapazität ist derzeitig nicht abzusehen.

Zwei Entwicklungrichtungen

• "Ultrium" war optimiert auf hohe Kapazität,
• "Accelis" für schnellen Zugriff auf gespeicherte Daten.

• DLT - Abkürzung für "Digital Linear Tape" Bandspeichertechnologie mit linearer Aufzeichnung, die sich lange Zeit als de facto Standard im Midrange und High-End PC Server Markt gehalten hat. Verwendung fand ein 1/2-Zoll breites Magnetband.

• DDS - Abkürzung für "Digital Data Storage" Datensicherungs- System mit DAT-Technologie und folgenden Spezifikationen:

mit Übertragungsgeschwindigkeit und Mediumkapazität ohne Kompression

• DDS-1 -183-366 Kb/s 1.3 bis 2.0 GB
• DDS-2 -500-600 Kb/s 2 - 4 GB
• DDS-3 -bis zu 1 Mb in der Sekunde ;bis 12 GB
• DDS-4 -bis zu 4 Mb in der Sekunde ;20 GB (kompatibel zu den anderen DDS Standards)

• AIT - Abkürzung für "Advanced Intelligent Tape" Sony-Weiterentwicklung der 8mm-Helical Scan-Technologie zur Datenaufzeichnung mit dem besonderen Merkmal, dass sich das Inhaltsverzeichnis auf einem Chip als Bestandteil der Cartridge befindet.

Die Entwicklung geht in einem rasendem Tempo vonstatten. Siehe am Beispiel die LTO Ultrium Technologie, bei der sich mehrere Hersteller auf einen gemeinsamen Standard geeinigt haben, mit dem Ziel mehrere Generationen von solchen Laufwerken zu entwickeln bis zu 6.4TB Kapazität pro Bandkassette und mit Geschwindigkeiten bis 540MB/s. Da solche Geräte heute in großen Stückzahlen produziert werden, und auch das Preis-Leistungsverhältins ständig sinkt, wird es auch für immer kleinere Anwender interessant, mit solchen Geräten zu arbeiten. (siehe auch www.lto-technology.com und http://www.usedlto.com/lto-com-toc.0.html).

Unterstützung von Bandlaufwerken unter LINUX

Treiber und Programme

SCSI-Bandlaufwerke werden per default von Linux unterstützt. Der Treiber der dazu genutzt wird ist der st-Treiber, das Programm zur Ansteuerung der verschiedenen Tape-Operationen ist mt. Weitere Laufwerksinterne Operationen und Unterstützung auf SCSI-Ebene kann mit dem optionalem Paketen scsi und xscsi erfolgen. Eine Erweiterung des mt-Befehles und wesentlich bessere Unterstützung für viele Bandlaufwerke und einen besseren Funktionsumfang hat der Befehl mtst aus dem optionalen Paket mt_st. Da die Ansteuerung ausschließlich über den default SCSI-Befehlssatz für Sequentielle Devices des SCSI-Standards beruht, gibt es für die wesentlichen Befehle auch kaum Probleme bei der Unterstützung von einzelnen Laufwerkstypen, und auch die modernsten Laufwerke funktionieren in der Regel uneingeschränkt.

Viele Programme können direkt auf das Bandlaufwerk zugreifen, darunter

• tar,
• cpio,
• dd
• sowie weiter optionale Backuptools und Backupsoftware soweit sie Bandlaufwerken unterstützen.

Leider sind die default Einstellung von LINUX und von vielen Backupprogrammen nicht auf der Höhe der heutigen Laufwerkstechnologien, sondern beruhen noch auf den verfügbaren Technologien der 80er und 90er Jahre. Um die modernen Laufwerkstypen einigermaßen im Rahmen der Parameter zu betreiben, für die sie gebaut wurden, sind einige Einstellungen zu beachten, da sonst sowohl die Backup- wie auch die Restoregeschwindigkeit so quälend langsam sind, dass damit nicht nur das Backup zur Geduldsache wird, sondern auch Bandmaterial und Laufwerk unter einem stark erhöhtem Verschleiß und mit erhöhtem Fehlerrisiko betrieben wird.

Der richtige Controller

Meistens haben wir es bei Laufwerken mit SCSI SE (Single Ended) oder SCSI LVD (Low Voltage Differential) zu tun, (man sollte aber bedenken, es gibt durchaus auch Laufwerke mit SCSI HVD (alte Bezeichnung: SCSI DIFF) Anschluss, für diese wird ein anderer Controller oder ein SCSI-Adapter benötigt, da die einzelnen Spannungspotentiale am SCSI-Bus hier andere Werte einnehmen, ist bei dem Versuch eines Mischbetriebs von HVD und LVD oder SE am gleichen Bus durchaus auch einmal mit Hardwareschrott als Ergebnis zu rechnen ). Auf die Spezifikationen der Technologie und die daraus resultierenden Anforderungen und Ansprüche an Kabel, Kabellängen und Terminatoren, sowie die Einstellung von SCSI-IDs soll hier nicht näher eingegangen werden. Die älteren Bandlaufwerke arbeiten mit Schreib-Lesegeschwindigkeiten bis 5MB/s oder unwesentlich schneller. Schon hier sollte man aber bedenken für anständige Performance der Bandlaufwerke möglichst nur PCI-Controller verwenden, und möglichst nur ein bis maximal 3 gleichartige Laufwerke am selben SCSI-Bus. Für viele ältere Laufwerke reicht zB ein Adaptec AHA-2940U oder AHA-2940UW vollkommen aus. Moderne Bandlaufwerke arbeiten mit Datenraten von 15-72MB/s und noch schneller. Für diese Laufwerke reicht ein solcher Controller bei Weitem nicht mehr aus, um den Datenhunger des Laufwerkes zu stillen. Für solche Laufwerke wird dann ein "Wide Ultra2, Fast-40 Wide" , "Ultra3, Ultra160, Fast-80" oder "Ultra320, Fast-160" Controller benötigt. Diese Controller sind für die 32Bit PCI-Systeme eines normalen PCs zwar nicht alltäglich, eventuell jedoch trotzdem erhältlich, aber hier können durchaus bei Vollauslastung Engpässe innerhalb des 32 Bit PCI-Bus des Systems auftreten, besonders wenn gleichzeitig auch noch andere PCI-Controller unter Last arbeiten (die theoretisch maximale Obergrenze liegt bei ca. 120MB/s über den gesamten PCI-Bus). Für eine wirklich performanten Anschluss von modernen SCSI-Bandlaufwerken zB für den Neuaufbau eines Backupservers, sollte man also von vorne herein gleich Serverhardware mit einem 64Bit PCI-Bus klar bevorzugen. Bei Benutzung eines heute durchaus üblichen Doppelcontrollers in dieser Leistungsklasse und im System eventuell vorhandenen 66MHZ PCI-Bus-Slot, dann ist auch überlegenswert, diesen hierfür zu nutzen. Ein heute vielfach verkauftes LTO3 Laufwerk zB. wird man jedenfalls nicht mehr performant über normale PC-Hardware ansteuern können.

Die richtigen Einstellungen

Das richtige Aufzeichnungsformat

Viele Laufwerke unterstützen neben ihrem ureigenen Aufzeichnungsverfahren das default benutzt wird, auch einige Aufzeichnungsverfahren ihrer Vorgängermodelle. Das schließt Spezifikationen des Aufzeichnungsformates und der verwendetet Bandtypen ein. Die Laufwerke sind so eingestellt, dass sie beim Beschreiben eines Bandes vom Bandanfang immer ihr eigenes default Format wählen, oder wenn das nicht möglich ist, das "höchste Format" dass sowohl das Laufwerk als auch die verwendete Cartridge unterstützt. Wird das Band weiterbeschrieben, wird in dem Format weitergeschrieben, dass am Bandanfang benutzt wurde. Beim Lesen erkennt das Laufwerk das Format mit dem das Band beschrieben ist automatisch. Das verwendete Format wird also beim Lesen des Bandanfanges erkannt und beim Beschreiben am Bandanfang festgelegt. Hier braucht nur selten etwas geändert zu werden.

In Ausnahmefällen, wenn zB mit einem neuerem Laufwerk Daten geschrieben werden, die dann auch mit einem älterem Laufwerk gelesen werden sollen, kann es dennoch notwendig werden, das Format festzulegen. Dann muss beim Beschreiben mit dem neuem Laufwerk dieses anzuweisen werden, das Format zu benutzen, dass dem des altem Laufwerkes entspricht. Das Aufzeichnungsformat ist ein vom Hersteller definierter Hexadezimaler Wert ( density Code ), der dem Laufwerk mitgeteilt werden muss. Der Befehl mstst kennt eine ganze Reihe gebräuchlicher density code, aber längst nicht alle.

root@LINUX:/ # mtst densities
Some SCSI tape density codes:
code   explanation                   code   explanation
0x00   default                       0x20   QIC-6GB
0x01   NRZI (800 bpi)                0x21   QIC-20GB
0x02   PE (1600 bpi)                 0x22   QIC-2GB
0x03   GCR (6250 bpi)                0x23   QIC-875
0x04   QIC-11                        0x24   DDS-2
0x05   QIC-45/60 (GCR, 8000 bpi)     0x25   DDS-3
0x06   PE (3200 bpi)                 0x26   DDS-4 or QIC-4GB
0x07   IMFM (6400 bpi)               0x27   Exabyte Mammoth
0x08   GCR (8000 bpi)                0x28   Exabyte Mammoth-2
0x09   GCR (37871 bpi)               0x29   QIC-3080MC
0x0a   MFM (6667 bpi)                0x30   AIT-1 or MLR3
0x0b   PE (1600 bpi)                 0x31   AIT-2
0x0c   GCR (12960 bpi)               0x33   SLR6
0x0d   GCR (25380 bpi)               0x34   SLR100
0x0f   QIC-120 (GCR 10000 bpi)       0x40   DLT1 40 GB, or Ultrium
0x10   QIC-150/250 (GCR 10000 bpi)   0x41   DLT 40GB
0x11   QIC-320/525 (GCR 16000 bpi)   0x45   QIC-3095-MC (TR-4)
0x12   QIC-1350 (RLL 51667 bpi)      0x47   TR-5
0x13   DDS (61000 bpi)               0x80   DLT 15GB uncomp. or Ecrix
0x14   EXB-8200 (RLL 43245 bpi)      0x81   DLT 15GB compressed
0x15   EXB-8500 or QIC-1000          0x82   DLT 20GB uncompressed
0x16   MFM 10000 bpi                 0x83   DLT 20GB compressed
0x17   MFM 42500 bpi                 0x84   DLT 35GB uncompressed
0x18   TZ86                          0x85   DLT 35GB compressed
0x19   DLT 10GB                      0x86   DLT1 40 GB uncompressed
0x1a   DLT 20GB                      0x87   DLT1 40 GB compressed
0x1b   DLT 35GB                      0x88   DLT 40GB uncompressed
0x1c   QIC-385M                      0x89   DLT 40GB compressed
0x1d   QIC-410M                      0x8c   EXB-8505 compressed
0x1e   QIC-1000C                     0x90   EXB-8205 compressed
0x1f   QIC-2100C                   

Das setzten erfolgt vor dem Beschreiben der ersten Daten am Bandanfang.

root@LINUX:/ # mtst -f /dev/nst0 rewind
root@LINUX:/ # mtst -f /dev/nst0 setdensity 0x27

Falsche Werte oder Werte die das Laufwerk oder die Cartridge nicht unterstützen werden mit einem Fehler abgewiesen. Das Überprüfen des Formates mit dem auf eine Cartridge geschrieben wurde, kann man aus der Statusausgabe herauslesen.

root@LINUX:/ # mtst -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 1024 bytes. Density code 0x27 (Exabyte Mammoth).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Kompression

Die modernen Streamer und Technologien ermöglichen Datenkomprimierung im Bandlaufwerk selbst. Diese Komprimierung darf man getrost als Hardwarekomprimierung bezeichnen. Diese Komprimierung ist äußerst effizient und Hardware dazu so ausgelegt, dass sie auch die Daten in enormen Geschwindigkeiten verarbeiten kann. Innerhalb der Verarbeitung und Komprimierung im Laufwerk sind die Daten mehrfach mit Quersummen und ECC-Verfahren abgesichert, so dass sie der Softwarekomprimierung, die wir mit den Programmen in Linux erreichen können, oftmals überlegen und wesentlich sicherer ist. Normaler Weise wird die Komprimierung schon mit dem gewähltem Datenformat gewählt und ist bei modernen Laufwerkstypen in aller Regel voreingestellt. Einige Datenformate ermöglichen jedoch unabhängig vom Schreibformat die Hardwarekomprimierung des Laufwerkes ein- oder auszuschalten.

Wie das von den Softwarekomprimierungsmethoden bekannt ist, so können verschiedene Daten verschieden stark komprimiert werden. Dateien mit reinen Zufallswerten werden beim Komprimieren noch größer, schon komprimierte Daten, lassen sich sehr schlecht bis gar nicht komprimieren, Texte und Logdateien sehr gut, und Dateien mit sich ständig wiederholenden kleinen Sequenzen oder Dateien die fortwährend die gleiche Bytesequenz enthalten, lassen sich enorm komprimieren. Als Richtwert über eine große Datenmenge der unterschiedlichsten Dateien wird meist eine Kompression von 2 zu 1 angenommen. Viele Hersteller geben die Kapazität bei Bandlaufwerken als Nativ Kapazität ( unkomprimierte Kapazität ) und komprimierter Kapazität (doppelter Nativ Kapazität) an. Aus ideologischen Gründen wird bei einigen Herstellern in Benennungen allerdings oftmals das Nativ vergessen oder irgendwo klein im Text versteckt und die komprimierte Kapazität angegeben. Wieviel Daten dann letztendlich auf das Band passen, hängt aber von der Art der Daten ab. Man muss sich also nicht wundern, wenn zB auf ein DDS3 Band, das mit 24GB Kapazität angepriesen wird, dann doch nur 11 oder 12GB Bilder passen, aber nach weit über 30GB Logdateien das Band immer noch nicht voll ist.

Die Kompression sollte man wenn möglich angeschaltet lassen. In einigen wenigen Fällen kann es aber dennoch notwendig erscheinen sie abzuschalten. Mit mtst kann man die Kompression für verschiedene Laufwerke und Formate ein ( 1 ) oder ausschalten ( 0 )

LINUX > mtst -f /dev/nst0 compression 0
LINUX > mtst -f /dev/nst0 compression 1    

Ob komprimiert geschrieben wurde oder nicht, erkennt das Laufwerk beim lesen automatisch, es muss also hier nicht extra beim lesen noch einmal angegeben werden.

Wie man daraus jetzt auch sehr leicht ableiten kann, sind Optionen bei Backupprogrammen die die Kapazität des Backupmediums beschreiben und nach erreichen einer solchen gesicherten Datenmenge automatisch ein neues Medium anfordern, nicht mehr auf dem Stand er heutigen Zeit und für Bandlaufwerke nur sehr eingeschränkt von Nutzen. Sie würden nur im unkomprimierten Modus einigermaßen funktionieren. Allerdings sollte man auch bedenken, dass auch noch einige andere Faktoren die Kapazität auf einem Band trotz ausgeschalteter Komprimierung die Kapazität negativ beeinflussen. Beispiele dafür sind ungünstige Blockgrößen, die einen sehr großen Overhead erzeugen, und die Eigenschaft einiger moderner Laufwerke, die schlechte physikalische Blöcke auf dem Bandmaterial als bad markieren und diese dann später nicht mehr nutzen und somit die mögliche Gesamtkapazität des Bandes verringern.

Das Streaming Problem

Anders als zB bei Festplatten, bei denn sich runde Scheiben ständig am Schreiblesekopf vorbei drehen, wird bei Bandlaufwerken ein oft mehrere hundert Meter langes dünnes Magnetband am Schreiblesekopf vorbeigespult. Kopf und Band muss sich zum lesen und schreiben immer mit bestimmten konstanten Geschwindigkeiten bewegt werden, und die Daten stehen sequentiell also logisch in einer Reihe auf dem Band. Wird das Laufwerk mit den richtigen Parametern betrieben, dann kann die Mechanik einen durchgehenden Bandtransport gewährleisten. Die Daten werden über die interne Elektronik durchgehend verarbeitet und in einem internen Puffer für den Transport über SCSI zwischengespeichert. Kann der Kopf die Daten nicht schnell genug verarbeiten, dann wird irgendwann die SCSI-Verbindung für einige Zeit unterbrochen, oder langsamer. In jedem Fall dreht sich das Band immer mit gleicher Geschwindigkeit weiter. Dieses Verhalten nennt man streaming und ist die optimale Situation und sollte ständig angestrebt werden.

Bei ungünstigen oder falschen Parametern, werden am Kopf ständig mehr Daten verarbeitet, als über SCSI und interne Elektronik verarbeitet werden können. Das Ergebnis ist, die Mechanik muss für eine Moment gestoppt werden, weil keine Daten mehr zum schreiben da sind, oder die gelesenen Daten erst mal aus dem Laufwerk raus müssen. Nach kurzer Zeit kann dann wieder weitergelesen oder geschrieben werden. Jetzt muss das Laufwerk erst einmal ein Stück zurückspulen und dann der Vortrieb wieder neu gestartet werden, damit durch die Trägheit der Mechanik dann an der richtigen Bandposition auch wieder die richtige Bandgeschwindigkeit anliegt. Bei diesem Modus wird die Mechanik also ständig gestartet und angehalten, man nennt das deshalb auch Start-Stopp-Betrieb. Die mechanische Belastung für Motoren, Antrieb, Lager und ähnlichem sorgt hier für einen starken Verschleiß an der Mechanik. Aber auch das Bandmaterial unterliegt hier einem extrem hohem Verschleiß. Die Fehlerrate von einzelnen falsch gelesenen Bits ist in diesem Modus sehr hoch, das wird zwar durch ausgeklügelte Technologien von Einzelfehlerkorrekturverfahren wie zB ECC in einem hohem Mass wieder ausgeglichen, es kommt dennoch häufig vor, dass ein Block noch einmal komplett neu gelesen muss, was wiederum nur nur über ein zusätzliches Start-Stopp der Mechanik funktioniert.
Dieser Modus sollte also wenn immer möglich verhindert werden, da hier nicht nur das Risiko von Fehlern besonders hoch ist, sondern auch Bandmaterial und Laufwerk sehr schnell "altern".

Die richtige Blockgröße

Die Blockgröße ist die Option, bei der von Laufwerksunerfahrenen das meiste falsch gemacht werden kann, und auch die default-Einstellungen der Laufwerke und der meisten Programme und Tools ungünstig ist. Deshalb soll das Problem hier etwas genauer beleuchtet werden.

Die Blockgröße (blocksize) ist die Menge an Daten, die bei einem einzigem Transportbefehl von einem Programm bei Ein- oder Ausgabeoperationen transportiert wird. Bei normalen Operationen innerhalb eine Filesystems ist das unerheblich. Das Filesystem ist im Hauptspeicher des Rechners gecacht, und der Rechner ist so schnell, dass es kaum einen Unterschied macht, ob man 64 mal 16 Byte in den Speicher transportiert oder aber nur 1 mal 1024 Byte. Der Cache des Filesystems arbeitet davon unabhängig mit einer eigenen voreingestellten Blockgröße mit der Festplatte. Anders schon, wenn wir den Cache des Filesystems umgehen. Es gibt Operationen bei denen wir direkt auf die Festplatte schreiben, unter vollkommener Umgehung des Filesystems, wenn zB. die Festplatte mittels dd gelöscht oder überschrieben werden soll. Würden wir jetzt hier mittels dd 64 mal 16 Byte auf die Festplatte schreiben, dann müssten über den Controller 64 Pakete über den IDE- , USB- oder SCSI-Bus transportiert werden, und für jedes Paket würde auf dem Bus eine oK Meldung wieder vom Laufwerk zurück über den Bus transportiert werden müssen. Das ist schon wesentlich langsamer als nur mit einem Paket von 1024 Byte zu verschicken. Ist aber immer noch nicht tragisch, denn die meisten Festplatten haben intern wiederum einen Puffer. Erst wenn das Laufwerk der Meinung ist, ich muss jetzt die Daten aus dem Puffer auch wirklich auf die Festplatte schreiben, werden dann die Daten aus dem Puffer wiederum mit speziellen Blockgrößen innerhalb der Festplatte wirklich auf die Platte geschrieben. Im ungünstigsten Fall würden wir also die Festplatte dazu verleiten mehrere Male ein und den selben Block auf die Festplatte zu schreiben. Man kann also schon hier beim direkten Schreiben auf die Festplatte mit einer falschen Blockgröße unnötige Zeit verschenken.
Ähnlich auch bei falschen Blockgrößen über das Internet. Im ungünstigstem Fall werden sehr sehr viele kleine Pakete übers Internet transportiert, was dann schon eine enorme Zeitverschleppung bedeuten kann.

Die selben Übertragungsprobleme haben wir jetzt bei Bandlaufwerken auch, allerdings kommt hier noch etwas dazu. Das Laufwerk sammelt erst einmal die an ihm übertragenen Daten in einem internem Puffer, merkt sich allerdings immer was jetzt ein Übertragungsblock war. Ist der Puffer einigermaßen gefüllt, fängt das Laufwerk an, und schickt jeweils einen solchen Datenblock durch den Kompressor, und baut aus den jetzt unterschiedliche großen komprimierten Blöcken mittels Quersummen und Verwaltungs- und ECC Informationen durch aufteilen oder aneinanderreihen die Blöcke zusammen, die dann wirklich physikalisch auf das Band geschrieben werden. Das bedeutet, je mehr kleine Blöcke an das Laufwerk gesendet werden, um so mehr Arbeit hat das Laufwerk mit Verwaltungsdaten, Komprimierung und Umwandlung zu den Blöcken die geschrieben werden können. Wenn jetzt genügend physikalische Pakete vorrätig sind, dann wird die Mechanik gestartet und mit dem Schreiben begonnen.
Werden jetzt nicht schnell genug physikalische Blöcke nachgeliefert, weil die Umwandlung zu lange dauert, muss das Schreiben unterbrochen werden. Wir haben den typischen Start-Stopp-Modus.

Die Laufwerke haben 2 mögliche Modus um Blockgröße zu interpretieren, diese können im Laufwerk eingestellt werden.

• Die Laufwerke interpretieren jeden Block der über SCSI kommt als einen eigenen Datenblock. Da die Größe der Datenblöcke jetzt von der Größe abhängt die das Programm an das Laufwerk über SCSI sendet (das Programm kann sich ja beim nächsten Aufruf durchaus auch für eine andere Blockgröße entscheiden, oder sogar jeden Block mit einer völlig anderen Blockgröße über SCSI versenden), ist die Blockgröße das für die Laufwerke variabel. Man spricht deshalb von variabler Blockgröße

Eingestellt wird dieser Modus mit der Option ( 0 ) und die eingestellte Größe kann man bei geladenem Band mittels Status ermitteln.

root@LINUX:/ # mtst -f /dev/nst0 setblk 0
root@LINUX:/ # mtst -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x27 (Exabyte Mammoth).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

• Oder dem Laufwerk wird angewiesen, " egal wie groß die Blöcke sind, die über SCSI reinkommen, du machst daraus immer Blöcke einer festen Größe. Ist die Bockgröße über SCSI zu groß, dann werden die Blöcke aufgeteilt, ist die Blockgröße zu klein, dann füllst du die Daten einfach mit NULLen auf die richtig Länge auf". Diesen Modus nennt man feste Blockgröße

Eingestellt wird dieser Modus mit der genauen Angabe der Blockgröße in Byte, Abfrage ebenfalls bei geladenen Band mittels Status.

root@LINUX:/ # mtst -f /dev/nst0 setblk 1024
root@LINUX:/ # mtst -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 1024 bytes. Density code 0x27 (Exabyte Mammoth).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Doch damit noch nicht genug. Die Daten sollen ja auch irgendwann mal wieder aus dem Laufwerk gelesen werden. Das Backupprogramm gibt also den Befehl, "gib mir einen Block Daten vom Band" an das Laufwerk über SCSI heraus. Das Laufwerk liest jetzt einige physikalische Blöcke vom Band, nimmt den ersten und extrahiert daraus den ersten komprimierten Block, und dekomprimiert diesen. Dieser Datenblock hat jetzt genau die selbe Größe, wie damals als er geschrieben wurde. Hat jetzt allerdings das Programm eine andere Blockgröße über SCSI angefordert, als zum Zeitpunkt des Schreibens der Daten, dann ist der Block im Laufwerk jetzt entweder zu klein oder zu groß für die Größe die über SCSI vom Backupprogramm jetzt abgeholt werden soll. Entsprechend der unterschiedlichen Einstellungen kann jetzt folgendes passieren:

• das Laufwerk gibt eine Fehlermeldung
• was zu viel ist wird abgeschnitten und geht bei der Übertragung verloren
• ein zu kleiner Block wird mit Nullen aufgefüllt.
• das Laufwerk füllt einen zu kleinen Block mit Daten aus dem nächstem Block auf

Man kann sich also an 2 Fingern abzählen, dass das Backupprogramm nicht in jedem Fall die Daten auch wieder richtig herstellen kann, wenn beim Speichern und Lesen mit unterschiedliche Einstellungen der Blockgrößen gearbeitet wird.

Es gilt also:

• Immer mit der selben Blockgröße lesen, mit der geschrieben wurde
• Ob man mit variabler oder fester Blockgröße arbeitet sollte für dieses Laufwerk an diesem Rechner klar festgelegt werden, da diese Einstellung im Laufwerk gespeichert wird, und erst über einen Befehl oder durch Reset des Laufwerks geändert wird. In der Praxis wird in den meisten Fällen mit variabler Blockgröße gearbeitet. Dann haben auch unterschiedliche Backupprogramme auf dem selbem Rechner die Gewissheit, dass die in ihnen festgelegten Blockgrößen richtig verarbeitet werden.

per Voreinstellung werden sich die meisten Laufwerkstypen nach einem Reset auf eine feste Blockgröße (oftmals 512 oder 1024) einstellen. Es muss also in jedem Fall eine Einstellung der Blockgröße auf variable oder größeren festen Wert vor der ersten Benutzung des Laufwerkes nach dem Start von Linux vorgenommen werden.

• Kleine Blockgrößen immer vermeiden.

Welche Blockgrößen für welches Laufwerk optimal ist, hängt vom Laufwerkstype ab. Bei Blockgrößen unterhalb von 8 KB sinkt bei allen Laufwerken die Performance in den Keller, und der Start-Stopp-Modus ist garantiert.

Blockgrößen die nicht durch 512 teilbar sind, werden von einige Laufwerken nicht unterstützt. In den meisten Fällen wird man 4, 8, 16, 32, 64, 128, 256 (jeweils KB) benutzen.

Für ältere Laufwerke sind Blockgrößen von 32KB 48KB 64KB 96KB geeignet.

bei moderne Laufwerken ist die optimale Blockgröße gleich der eingestellten maximale Blockgröße die SCSI in LINUX erlauben würde also 256 KB

• Blockgrößen die zu groß für das Laufwerk sind, werden vom Laufwerk mit Fehlermeldung quittiert. Solche Grenzen liegen bei modernen Laufwerken jedoch oftmals oberhalb von 1MB
• Die Blockgröße für SCSI ist auch beschränkt, bei LINUX default bei 256 KB. Wird diese überschritten, dann kommt je nach Konfigurationseinstellungen entweder ein Fehler vom Kernel, oder es werden die zu großen Blöcke innerhalb des SCSI-Treibers in mehrere Blöcke geteilt. (Beispiel: 384KB werden aufgeteilt in 256Kb und 128KB) Ein solches stillschweigendes Aufteilen der Blöcke bleibt oft erst einmal unbemerkt, da auch ein sequentielles lesen mit variabler Blockgröße funktioniert. Moderne Backupprogramme werden jedoch beim Positionieren auf einzelne Dateien Probleme bekommen, da der Index der Blöcke den sich das Backupprogramm merkt, nicht dem entspricht, wie die Blöcke vom Laufwerk auf das Band geschrieben werden.

Die Laufwerks Verriegelung

Einige Laufwerkstypen lassen sich Verriegeln (lock). Diese Verriegelung sorgt uA. dafür, das ein eingelegtes Band nicht aus dem Laufwerk entfernt werden kann. Auch der Auswurftaster am Laufwerk wird nicht funktionieren. In Multihost Umgebungen ( mehrere Rechner haben über eigene Controller Zugriff auf das Laufwerk) kann nur der Controller mit dem Laufwerk arbeiten, von dem aus der Lockbefehl gekommen ist. Der Lockbefehl wird erst durch einen Unlockbefehl vom gleichen Controller oder durch ein Reset des Laufwerkes ( eventuell auch über SCSI von einem anderem Controller angestoßen) wieder aufgehoben werden.

root@LINUX:/ # mtst -f /dev/nst0 lock  
root@LINUX:/ # mtst -f /dev/nst0 unlock

Bei verriegelten Laufwerk wird bei einem Unloadkommando, die Cartridge zwar intern aus der Bandführung ausgefädelt, die Cartridge aber nicht aus dem Laufwerk herausgeführt. Durch einen Loadbefehl kann dann die Cartridge wieder geladen und weiterbeschrieben werden. Damit können Bänder auch längere Zeit im Laufwerk verbleiben, ohne dass dabei das Bandmaterial übermäßiger Abnutzung durch Umwelteinflüsse oder der Abnutzung durch eine sich permanent drehende Kopftrommel ausgesetzt ist.

Weitere Einstellungen

Die Laufwerke sind alle so vorkonfiguriert, dass sie per default schon optimale Einstellungen benutzen würden, und somit außer der Blocksize in der Vielzahl der Fälle keine weiteren Einstellungen vorzunehmen sind, um mit dem Laufwerk schreiben und lesen zu können. Dennoch gibt es noch einen ganze Reihe weiterer Einstellungen die an einem Laufwerk vorgenommen werden könnten. Einige davon sogar über mtst. Solche Einstellungen betreffen zum Beispiel die Nutzung des internen Puffers, dem Verhalten und die Interpretation auf bestimmte Fehlersituationen, dem Timeoutverhalten, dem Fehlerkorrekturverhalten, den Defaulteinstellungen nach einem Reset usw. Diese Einstellungen sind Laufwerkstypeabhängig und sollten bei Bedarf nur von Spezialisten vorgenommen werden, da einige davon die Laufwerkseigenschaften auch sehr negativ beeinträchtigen können. Weiter Funktionen siehe auch die Manpage von mtst

Einige SCSI-spezifische Geräteeinstellungen und Informationen aus den Laufwerken sind nur über die scsi- und sg-tools zu tätigen. Ein grafisches FrontEnd dafür ist scsi-config, aber wie gesagt für Spezialisten und die "SCSI Reference" für das entsprechende Laufwerk sollte dabei daneben liegen.

Über stinit können Laufwerke vorkonfiguriert werden, wenn wider erwarten an den Laufwerken doch größere Voreinstellungen vorgenommen werden sollen. Siehe dazu die Dateien im Verzeichnis /usr/share/doc/packages/mt_st/ und die Manpage von stinit. Als Vorlage kann auch eine fertige Version einer stinit.def für die von Tandberg vertriebenen Laufwerke dienen ( /etc/stinit.def)

Einige Laufwerkstypen erlauben das Partitionieren von Bändern, dabei kann aus einem physikalischem Band mehrere logische Bänder gemacht werden. Diese logischen Bänder können einzeln beschrieben und gelöscht werden, ohne das dabei der Inhalt auf den anderen logischen Bändern nicht mehr lesbar ist. Das Partionieren kann mit mtst am Bandanfang erfolgen, ebenso erfolgt ein Wechsel der Partitionen mittels mtst. Dieses Feature wird selten benutzt, und man sollte auch beachten, sollte das Bandmaterial zB. irreparapel beschädigt werden, dann sind alle Partitionen nicht mehr lesbar. Die Unterstützung für partitionierte Bänder fehlt in den meisten Backupprogrammen komplett. Hier muss immer vorher mittels Script und mstst die richtige Partition vorgewählt werden.

die Geräteknoten

Es werden per Voreinstellung für 4 Laufwerke jeweils 8 Geräteknoten angelegt.

crw-rw----  1 root disk 9,  0 2004-04-06 15:27 /dev/st0
crw-rw----  1 root disk 9, 96 2004-04-06 15:27 /dev/st0a
crw-rw----  1 root disk 9, 32 2004-04-06 15:27 /dev/st0l
crw-rw----  1 root disk 9, 64 2004-04-06 15:27 /dev/st0m
crw-rw----  1 root disk 9, 128 2004-04-06 15:27 /dev/nst0
crw-rw----  1 root disk 9, 224 2004-04-06 15:27 /dev/nst0a
crw-rw----  1 root disk 9, 160 2004-04-06 15:27 /dev/nst0l
crw-rw----  1 root disk 9, 192 2004-04-06 15:27 /dev/nst0m

Dabei ist vorgesehen über die Minornumber und damit auch über den Knotennamen bestimmte Eigenschaften wie Schreibformat, Kompression, Blocksize, Autorewind usw zu steuern. Die Unterstützung ist jedoch, wenn überhaupt, dann nur für einige wenige ältere Laufwerkstypen sichergestellt. Nur bei Einsatz spezieller Treibern einiger Laufwerkshersteller anstatt des nativen st-Treibers ist hier für einige Laufwerkstypen eine gute und verlässliche Unterstützung dieser Funktionen gewährleistet. Die Einzige Funktion die hier bei allen Laufwerken zuverlässig funktioniert ist die norewind-autorewind Funktion.

• Bei Geräteknoten ohne ( n ) am Anfang wird beim Schließen des Devices zurückgespult.
• Bei Geräteknoten mit ( n ) wir beim Schließen des Devices nicht zurückgespult.

In der Praxis wird meistens /dev/nst? benutzt werden. Das Positionieren und Zurückspulen obliegt dann der Backupsoftware oder dem User selbst.

Pufferung der Daten zwischen Laufwerk und LINUX

Mit den oben genannten Hinweisen sollte es jetzt möglich sein, die etwas älteren Bandlaufwerke in permanentem Streaming zu halten. Zumindestens solange es sich um lokale Dateien handelt, die gesichert werden, und die Daten auch lokal wieder abgelegt werden. Moderne Laufwerke verlangen hier einen viel dichteren Datenstrom zwischen Laufwerk und Rechner, damit es zum Streaming kommt. Selbst wenn wir ein solches Laufwerk an einen "dicken" Controller angeschlossen haben, und die Geschwindigkeit zwischen Laufwerk und Rechner über SCSI mehr als 40 MB/s erlauben würde, die Daten die wir zum Laufwerk senden oder von dort empfangen, müssen irgendwie auf die Festplatten. Selbst modernste Festplatten im RAID-Verbund werden wir nicht dazu überreden können zB sehr viele kleinste Dateien mit 30 MB/s zu verarbeiten. Große Dateien bringen hier schon eine bedeutend bessere Performance. Dennoch reicht auch diese Performance oftmals nicht aus, um den Datenhunger der heutigen modernen Bandlaufwerke zu stillen. Die Lösung dazu ist eine Pufferung der Daten.

Die Idee dahinter ist folgende, die Backupsoftware holt sich die Daten die gesichert werden sollen von den Festplatten oder über das LAN, schreibt aber nicht selbst auf das Bandlaufwerk, sondern die Datenpakete werden in einem Puffer im Speicher zwischengespeichert. Erst wenn der Speicher gefüllt ist, beginnt der Puffer auf das Laufwerk zu schreiben, während unabhängig davon die Backupsoftware weiterhin in das Puffer schreibt. Ist das Laufwerk langsamer als die Backupsoftware arbeiten kann, dann wird die Software irgendwann einmal kurz gebremst wenn der Puffer voll ist, ist jedoch das Laufwerk zu schnell, dann wird das Puffer irgendwann einmal leer sein, dann wird das Schreiben solange angehalten, bis das Puffer wieder annähernd gefüllt ist. Wenn man hier mit genügend großen Puffern arbeitet, dann kann man damit die Ungleichheiten in der Verarbeitung zwischen den Festplatten und der Verarbeitung innerhalb des Bandlaufwerkes auffangen, und selbst "dünne" Datenströme zB. über das LAN Schubweise performat im Streamingmodus auf das Laufwerk schreiben.

Das Lesen erfolgt dann in umgekehrter Richtung. Das Laufwerk schreibt die Daten in das Puffer. Das Puffer gibt die Daten an die entsprechende Backupsoftware zur Verarbeitung weiter. Ist das Laufwerk zu schnell, ist der Puffer irgendwann voll, und das Lesen vom Laufwerk wird solange unterbrochen bis die Backupsoftware den Pufferinhalt fast komplett verarbeitet hat. Somit kann auch beim Lesen das Laufwerke jeweils für eine gewisse Zeit am streamen gehalten werden, anstatt durchgehend im Start-Stopp-Betrieb zu verweilen.

Das Programm mbuffer

Das Programm mbuffer ist ein solches Tool, dass als Puffer zwischen die Backupsoftware und dem Bandlaufwerk eingesetzt werden kann. Das Programm wird in den Archiven der Distributionen auch als Paket angeboten. Allerdings handelt es sich hier um eine ältere Version, die unter anderem ein wichtiges Feature nicht unterstützt, das effektive puffern der Daten beim Lesen vom Laufwerk. Es soll also hier empfohlen werden, sich die aktuelle Version von der Originalseite zu holen und selbst zu kompilieren.( Achtung: in den älteren Versionen sind einige Optionen anders, die nachfolgenden Beispiele und Anmerkungen beziehen sich auf die getestete Version 20060728)

Das Kompilieren das Programmes an sich stellt keinerlei Probleme dar. Soll in Ausnahmefällen Puffergrößen größer als 2 GB benötigt werden, muss das Programm für 64Bit kompiliert werden,

 CFLAGS="-O -g -m64" ./configure

Das Programm hat eine ganze Reihe von Optionen und bringt auch seine eigene Manpage mit:

robi@LINUX:~/> /usr/local/bin/mbuffer --help
usage: mbuffer [Options]
Options:
-b <num>   : use <num> blocks for buffer (default 256)
-s <size>  : use block of <size> bytes for buffer (default 10240)
-m <size>  : use buffer of a total of <size> bytes
-L         : lock buffer in memory (unusable with file based buffers)
-P <num>   : start writing after buffer has been filled more than <num>%
-p <num>   : start reading after buffer has been filled less than <num>%
-i <file>  : use <file> for input
-o <file>  : use <file> for output
-I <h>:<p> : use network port <port> as input, allow only host <h> to connect
-I <p>     : use network port <port> as input
-O <h>:<p> : output data to host <h> and port <p>
-n <num>   : <num> volumes for input
-t         : use memory mapped temporary file (for huge buffer)
-T <file>  : as -t but uses <file> as buffer
-l <file>  : use <file> for logging messages
-u <num>   : pause <num> milliseconds after each write
-r <rate>  : limit read rate to <rate> B/s, where <rate> can be given in k,M,G
-R <rate>  : same as -r for writing; use eiter one, if your tape is too fast
-f         : overwrite existing files
-a <time>  : autoloader which needs <time> seconds to reload
-A <cmd>   : issue command <cmd> to request new volume
-v <level> : set verbose level to <level> (valid values are 0..5)
-q         : quiet - do not display the status on stderr
-c         : write with synchronous data integrity support
-V
--version  : print version information
Unsupported buffer options: -t -Z -B

einige Bemerkungen zu mbuffer

• mbuffer gibt auf LINUX in der getesteeten Version 20060728 folgende Warnung aus:

 
warning: unable to determine maximum value of semaphores
warning: Could not stat output device (unsupported by system)!
This can result in incorrect written data when
using multiple volumes. Continue at your own risk!

Die Warnungen zwecks der Semaphore und dem Output device können ignoriert werden, sie sind wohl dem Umstand geschuldet, dass das Programm auch auf anderen Betriebssystemen kompiliert werden kann. Die Funktionen die hier abgefragt werden und zur Warnung führen, sind im aktuellem LINUX-Kernel nicht vorhanden.

• mbuffer hat eine Multi-Volumes-Funktion, (der manuelle Bandwechsel wurde bei der Erstellung dieses Artikels getestet), konnte aber nicht wirklich überzeugen, so daß wir uns hier der Warnung des Autors anschließen möchten. Experimental: und auf eigenes Risiko
• mbuffer hat integrierten Network support, kann also selbst Daten über TCP/IP in das Puffer einlesen und auch direckt von dort versenden, Das macht es besonders für Backupserver in Netzumgebungen interessant.
• Unter Linux gibt es uU ein kleines Problem, wenn ein laufender mbuffer-Prozess durch vorzeitiges Beenden des aufgerufenen Befehls beendet werden soll. Dieses Problem dürfte beim austesten der richtigen Optionen gelegentlich einmal auffallen, im späterem praktischen Einsatz kaum von Bedeutung sein.
• Das Programm gibt auf der Konsole sehr schön permanent die aktuellen IN und Out Geschwindigkeiten aus, diese waren bei Tests allerdings durch Umleitung der Ausgabekanäle nicht so leicht zu unterdrücken.
• mbuffer wurde multi-thread und sehr effizient programmiert, die dadurch erzeugte Prozessorlast hält sich in Grenzen.

getestete Beispiele mit mbuffer

Die folgenden Beispiele wurden unter SuSE 10.1 mit folgender Hardware getestet ( Rechnername server )

• 2 x Pentium III (Coppermine) 933 MHz
• 2GB Hauptspeicher
• 2 x Symbios Logic 53c1010 Ultra3 SCSI
• IBM LTO1-Ultrium sowie IBM LTO2-Ultrium
• 2 x SEAGATE ST336704LC alle Partitionen RAID1

Als blocksize wurde 256KB verwendet

Als Buffer wurde 1GB Hauptspeicher benutzt

Die Optionen haben sowohl mit LTO1 als auch mit LTO2 optimales Streamingverhalten gezeigt.

• Sicherung eines lokalen Filesystems mit tar

server:/home # mt -f /dev/nst0 rewind
server:/home # tar -cl -b 512 -f - ./ 2>/dev/null | /usr/local/bin/mbuffer -L -s 256k -m 1G -P 85  > /dev/nst0

Wieder zurückspielen der Sicherung

server:/home # mt -f /dev/nst0 rewind
server:/home # < /dev/nst0  /usr/local/bin/mbuffer -L -s 256k -m 1G -p 25 | tar -xb 512 -f - 2>/dev/null 

---

• Sicherung eines lokalen Filesystems mit cpio

server:/home # mtst -f /dev/nst0 rewind
server:/home # find . -mount | cpio -ocC262144 | mbuffer -L -s 256k -m 1G -P85 > /dev/nst0

Wieder zurückspielen der Sicherung

server:/home # mtst -f /dev/nst0 rewind
server:/home # < /dev/nst0 mbuffer -L -s 256k -m 1G -p25 | cpio -icdumC262144

---

• Sicherung über Netzwerk mit tar und netcat am Client

Befehl am SERVER

/usr/local/bin/mbuffer -L -s 256k -m 1G -P 90 -I 3333  > /dev/nst0

Befehl am ClIENT

cd /data1 ; tar -cl -b 512 -f - ./ 2>/dev/null | netcat server 3333

Zurückspielen der Sicherung über das Netz

Befehl am CLIENT

cd /data1 ; netcat -l -p 3333 -w 300 | tar -xb 512 -f - 2>/dev/null 

Befehl am SERVER

< /dev/nst0  /usr/local/bin/mbuffer -L -s 256k -m 1G -p 10 -O client:3333

---

• Experimentale Sicherung über ssh-Verbindung,( günstiger wäre ein direktes Tunneln über ssh)
  

Sicherung über Netzwerk mit cpio über ssh-gesicherte Pipe vom Server aus angestoßen

ssh client "cd /data1 ;(find . -mount | cpio -ocC262144 2>/dev/null )" | mbuffer -L -s 256k -m 1G -P95 > /dev/nst0

Rückspielen dieser Sicherung von der Clientseite aus

cd /data1; ssh server " < /dev/nst0 mbuffer -L -s 256k -m 1G -p10 " | cpio -icdumC262144

weiter Links zum Thema Linux Backup auf Tapelaufwerken

• [Quadstor Virtual Tape Library] Interessantes Projekt, Opensource, virtuelle Laufwerke, Jukeboxen und Bandpools, mit Datenbankunterstützung und Webkonfiguration, unterstützt die wichtigsten professionellen Archivierungssoftware, iSCSI, FibreChannel und mehr.

• Script für Backup erklärt das Schreiben eines eigenen konfortablem Backupscript für Tapelaufwerke von Grund auf.

--Robi 18:51, 12. Nov 2006 (CET)