[gelöst] Tape Sicherung - LTO4 Parameter

crams · 23 Nov. 2010

Tape Sicherung - LTO4 Parameter / verhindern von Start-Stop

Hallo

hat jemand Erfahrung mit LTO 4 Bändern?

Basierend auf diesem Wiki Artikel http://www.linupedia.org/opensuse/Bandlaufwerke_und_LINUX
schreibe ich mit folgendem Befehl:
tar -c -b 512 -f - /data/ 2>/dev/null | mbuffer -L -s 256k -m 6G -P 95 > /dev/nst0

in @ 512 kb/s, out @ 0.0 kB/s, 32GB total, buffer 32% full
mache ich was falsch? Es sind noch daten im buffer aber es wird nicht geschrieben bzw. nur in ca. 30 Sekunden Schüben bei ca. 160 Mb/s

Es sollen später sehr verschieden Dateien in Bezug auf ihre Größe und Anzahl auf Tape gesichert werden,
von hunderttausenden kleinen Mails (wie in meinem Test) bis zu 3GB plus disk Images.

Hardware:
eine DELL PowerVault TL2000
oder besser:
mtx -f /dev/sg3 inquiry
Product Type: Medium Changer
Vendor ID: 'IBM '
Product ID: '3573-TL '
Revision: '7.40'
Attached Changer API: No

mtx -f /dev/nst0 inquiry
Product Type: Tape Drive
Vendor ID: 'IBM '
Product ID: 'ULT3580-HH4 '
Revision: '89B1'
Attached Changer API: No

Alles via SAS an einem Debian Lenny mit zwei Quad cores und 12 GB RAM.
Zum buffern stehen also genug RAM bei bedarf zur Verfügung um das Laufwerk im Stream zu halten denke ich.

danke schon mal für Hilfe und anregungen.

RME · 23 Nov. 2010

Hallo,

Nur ein paar, möglicherweise unnütze, Bemerkungen:

Du sagst nichts über die Version des "mbuffer" welches Du anwendest, bzw. ob 32 od. 64 Bit. Du hast eine Buffer size "-m 6G" spezifiziert. Dies ist unter Umständen zu gross:

Soll in Ausnahmefällen Puffergrößen größer als 2 GB benötigt werden, muss das Programm für 64Bit kompiliert werden,

(http://www.maier-komor.de/mbuffer.html)

Als Vergleich:

Code:

http://www.maier-komor.de/mbuffer.html --> Version = 20060728
                                     suse: Versiom = 20080212-50.1
                                   neuste: Version = 20100526 (latest stable)

Wenn Du eine andere Version als diejenige in http://www.maier-komor.de/mbuffer.html verwendest, wäre noch zu berücksichtigen:

Achtung: in den älteren Versionen sind einige Optionen anders, die nachfolgenden Beispiele und Anmerkungen beziehen sich auf die getestete Version 20060728

Mein Vorschlag: reduziere die Buffergrösse auf 1G und versuche es so.

Gruss,
Roland

crams · 25 Nov. 2010

RME schrieb:
Du sagst nichts über die Version des "mbuffer" welches Du anwendest, bzw. ob 32 od. 64 Bit.

zur Software:
Kernel:2.6.26-2-amd64
tar (GNU tar) 1.20
mbuffer version 20100526 (mit env CFLAGS="-O -g -m64" ./configure vorbereitet)

RME schrieb:
Mein Vorschlag: reduziere die Buffergrösse auf 1G und versuche es so.

Hat das Problem leider nicht gelöst es passiert weiterhin das Daten im buffer sind die nicht bzw. nur in Intervallen geschrieben werden.

getestete Version 20060728

werde als nächstes mal ein downgrade versuchen.

Anonymous · 25 Nov. 2010

Das Problem hier sind wohl mehr die 100 tausend kleinen Dateien die du testest. Tar packt diese kleinen Dateien sehr ineffizient. pro Datei in einen 512Byte Tarheader + dann die kleinen Dateiendaten die dann am Ende auch noch mit sehr vielen Nullen aufgefüllt werden. Die Hardwarekomprimierung des Laufwerkes kann dieses extrem hoch komprimeren und langweilt sich trotz buffer zu tote, da es Unmengen an Daten aus dem Buffer schlucken kann aber immer noch nicht genügend fertig komprimierte Blöcke im internen Buffer hat, um mit schreiben anfangen zu können. Wenn du permanent extrem viele winzige Dateien sichern willst, ist es zB ratsam diese schon vor dem buffer zu komprimieren, oder sonstwie erstmal in ein eigenes kompaktes Archiv zupacken, wo die ganzen vielen Nullen aus tar verschwinden. Und dann dieses Archiv zu sichern. Ansonsten hat hier tar zu zu viel overhead um das Laufwerk sinnvoll zu beschäftigen.

robi

crams · 26 Nov. 2010

hallo
das war die Lösung wie es scheint.

gehe jetzt wie folgt beim mail backup vor:
erstelle ein raw image in der nativen tape größe
qemu-img create /data/lto4.tape 800G

mounte es als loop device
losetup /dev/loopX /data/lto4.tape
mkfs.ext3 /dev/loopX
mount /dev/loopX /mnt/tape

erstelle mein Backup in /mnt/tape

umount und löse das loop device
schreibe anschließend mit
dd bs=256k if=/data/lto4.tape | mbuffer -L -s 256k -m 3G -P 95 | dd bs=256k of=/dev/nst0

-> brauch in dem fall mbuffer die block Größe überhaupt?

buffer kommt nur noch sehr selten gegen 0% und das LW bleibt fast die ganze Zeit im Stream Lesen/wiederherstellen kalappt auch gut.

Danke an alle!

[gelöst] Tape Sicherung - LTO4 Parameter

crams

Newbie

RME

Advanced Hacker

crams

Newbie

Anonymous

Gast

crams

Newbie