Bandlaufwerke und LINUX - Versionsgeschichte

Robi: neuer aktueller Link

2014-01-08T01:22:13Z

neuer aktueller Link

Robi: intern verlinkt

2008-09-09T20:23:43Z

intern verlinkt

Robi: mal wieder Tandberg-Links auf neusten Stand gebracht

2008-01-18T19:42:01Z

mal wieder Tandberg-Links auf neusten Stand gebracht

Robi: Spezifizierung der getesteten Version

2007-04-08T13:47:30Z

Spezifizierung der getesteten Version

Robi: Spezifizierung der getesteten Version

2007-04-08T13:43:38Z

Spezifizierung der getesteten Version

Robi: Links aktualisiert

2007-04-08T13:26:49Z

Links aktualisiert

Robi: Das reicht jetzt, sonst wirds noch ein Buch - Freigabe

2006-11-16T15:04:44Z

Das reicht jetzt, sonst wirds noch ein Buch - Freigabe

Änderungen zeigen

Robi: kleine Korrekturen

2006-11-15T17:05:08Z

kleine Korrekturen

Robi: getestete Beispiele

2006-11-15T16:47:59Z

getestete Beispiele

Robi: Pufferung der Daten zwischen Laufwerk und LINUX

2006-11-15T15:04:50Z

Pufferung der Daten zwischen Laufwerk und LINUX

@@ Zeile 410: / Zeile 410: @@
 : 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 ==
 * [http://www.linux-club.de/viewtopic.php?t=15197 Script für Backup] erklärt das Schreiben eines eigenen konfortablem Backupscript für Tapelaufwerke von Grund auf.

@@ Zeile 286: / Zeile 286: @@
 === 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.
+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 allgemein|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.
@@ Zeile 410: / Zeile 410: @@
 : 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 ==

@@ Zeile 258: / Zeile 258: @@
 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 [http://www.devdaily.com/unix/man/man8/stinit.8.shtml Manpage von stinit]. Als Vorlage kann auch eine fertige Version einer stinit.def für die von [http://www.tandbergdata.com/de/homesite Tandberg] vertriebenen Laufwerke dienen ( [http://www.tandbergdata.com/artikeldatenbank_v1.1/download/driver/stinit.def /etc/stinit.def])
+Ü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 [http://www.devdaily.com/unix/man/man8/stinit.8.shtml Manpage von stinit]. Als Vorlage kann auch eine fertige Version einer stinit.def für die von [http://www.tandbergdata.com Tandberg] vertriebenen Laufwerke dienen ( [http://www.tandbergdata.ru/products/download/stinit.def /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.

@@ Zeile 337: / Zeile 337: @@
 ==== einige Bemerkungen zu mbuffer ====
-* mbuffer gibt auf LINUX in den neuen Versionen folgende Warnung aus:
+* mbuffer gibt auf LINUX in der getesteeten Version 20060728 folgende Warnung aus:
 <pre>
 warning: unable to determine maximum value of semaphores
@@ Zeile 351: / Zeile 351: @@
 * mbuffer wurde multi-thread und sehr effizient programmiert, die dadurch erzeugte Prozessorlast hält sich in Grenzen.
 ==== getestete Beispiele mit mbuffer ====

@@ Zeile 297: / Zeile 297: @@
 ==== Das Programm mbuffer ====
-Das Programm [http://www.maier-komor.de/mbuffer.html '''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 Anmerkekungen sind für die aktuelle Version'')
+Das Programm [http://www.maier-komor.de/mbuffer.html '''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,
@@ Zeile 334: / Zeile 334: @@
 Unsupported buffer options: -t -Z -B
 </pre>
 ==== einige Bemerkungen zu mbuffer ====

@@ Zeile 235: / Zeile 235: @@
 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 [http://www.devdaily.com/unix/man/man8/stinit.8.shtml Manpage von stinit]. Als Vorlage kann auch eine fertige Version einer stinit.def für die von [http://www.tandberg.com/de/homesite Tandberg] vertriebenen Laufwerke dienen ( [http://www.tandberg.com/artikeldatenbank_v1.1/download/driver/stinit.def /etc/stinit.dev])
+Ü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 [http://www.devdaily.com/unix/man/man8/stinit.8.shtml Manpage von stinit]. Als Vorlage kann auch eine fertige Version einer stinit.def für die von [http://www.tandberg.com/de/homesite Tandberg] vertriebenen Laufwerke dienen ( [http://www.tandberg.com/artikeldatenbank_v1.1/download/driver/stinit.def /etc/stinit.def])
 <!-- Wesentliche Teile des erweiterten SCSI-Fehlerlogging ist bei SuSE Standarddistributionen abgeschalten, ebenso scheint die Dokumentation zur Laufwerksspezifischen Cleaningkonfiguration sehr dürftig, jedenfalls bekomme ich beides im Moment nicht zum laufen. Wird bei Gelegenheit nachgetragen Robi 14.11.2006  -->

← Nächstältere Version		Version vom 15. November 2006, 16:47 Uhr
Zeile 302:		Zeile 302:


−	==== getestete Beispiele ====	+	==== einige Bemerkungen zu mbuffer ====
		+	* mbuffer gibt auf LINUX in den neuen Versionen folgende Warnung aus:
		+	<pre>
		+	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!
		+	</pre>
		+	: 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.
		+	* die Multi-Volumes-Funktion wurde hier auch 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 zu lesen und auch 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 durch Umleitung der Ausgabekanäle nicht so leicht zu unterdrücken.
		+	* mbuffer wurde multi-thread und sehr effizient programmiert
		+
		+
		+	==== 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'''
		+	<pre>
		+	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
		+	</pre>
		+	: Wieder zurückspielen der Sicherung
		+	<pre>
		+	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
		+	</pre>
		+	----
		+
		+
		+	* Sicherung eines lokalen Filesystems mit '''cpio'''
		+	<pre>
		+	server:/home # mtst -f /dev/nst0 rewind
		+	server:/home # find . -mount \| cpio -ocC262144 \| mbuffer -L -s 256k -m 1G -P85 > /dev/nst0
		+	</pre>
		+	: Wieder zurückspielen der Sicherung
		+	<pre>
		+	server:/home # mtst -f /dev/nst0 rewind
		+	server:/home # < /dev/nst0 mbuffer -L -s 256k -m 1G -p25 \| cpio -icdumC262144
		+	</pre>
		+	----
		+
		+
		+	* 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, günstiger wäre ein direktes Tunneln über ssh''<br>
		+	: 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
		+	ssh server " < /dev/nst0 mbuffer -L -s 256k -m 1G -p10 " \| cpio -icdumC262144

	== weiter Links zum Thema Linux Backup auf Tapelaufwerken ==		== weiter Links zum Thema Linux Backup auf Tapelaufwerken ==

@@ Zeile 253: / Zeile 253: @@
 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 speziellen 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.
-=== Bufferung der Daten zwischen Laufwerk und LINUX ===
+=== Pufferung der Daten zwischen Laufwerk und LINUX ===
-==== getestete Beispiele ====
+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 Pakete werden in einem Puffer im Speicher zwischengespeichert. Erst wenn der Speicher gefüllt ist dann 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 diese 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 eingestellt, bis das Puffer wieder gefüllt ist.
 == weiter Links zum Thema Linux Backup auf Tapelaufwerken ==