Probleme bei Backup auf Tape mit tar

kangaroo72

Forums-Beuteltier²
Themenstarter
Registriert
2 Mai 2007
Beiträge
2.035
Hallo zusammen ...

trotz enger Zusammenarbeit mit cuco habe ich immense Probleme bei der Datensicherung auf ein HP 1760 LTO-4-Drive.

1. Die Datenübertragung kommt nie höher als 72MB/s ... lt. HP-Specs 120MB/s ... far away ... läuft aber dank mbuffer stabil

Nur ... das Hauptproblem ist, das das Tape zu schnell voll ist ...

Code:
tar -clpM --acls --totals -b 512 -V="Backup" Backup | mbuffer -L -s 256k -m 2000M -P 95 -v 4 -o /dev/nst0

Der Ordner Backup ist (gemessen mit du -s --si) 785GB groß. Nach einiger Zeit kommt dann ...

Code:
mbuffer: inputThread: starting with threadid 140526371677952...in @ 15.0 MB/s, out @ 15.0 MB/s,  684 GB total, buffer 100% full
mbuffer: end of volume - last block on volume: 2802763
mbuffer: time for writing volume: 3:13:23.652577
in @  0.0 kB/s, out @  0.0 kB/s,  684 GB total, buffer 100% full
volume full - insert new media and press return when ready...

Mehrfach getestet - auch schon anderes Tape (neu). Da ist doch noch dick Platz.
Hat jemand eine Idee?
 
Da die Zeile zum Sichern von mir kommt, antworte ich mal:
Damit man tar anweist, immer 512x512 Bytes = 256k Daten an mbuffer zu liefern. mbuffer wiederum arbeitet ebenfalls mit 256k-Blöcken und müsste so dann auch 256k-Blöcke ans Laufwerk liefern.
 
Das "Platzproblem" könnte daher kommen, daß die "800GB" des LTO4 Bandes wie bei Festplatten nur 800.000.000.000 Bytes sind. ;)
 
Kommt aber nicht hin, da meine Daten 784.255.923.476 sind

Momentan läuft das mal auf ein IBM-Band - statt ein HP-Band ...

Stay tuned
 
Bei "800GB" hast ca. 745GB brutto Platz auf dem Band. Diese können problemlos mit 684GB + Verzeichnisse + Zusatzinfos (ACLs usw.) gefüllt sein.
 
Hab ich doch geschrieben: 684GB + ca. 10% Overhead (Verzeichnise+Zusatzinfos) = voll
 
800GB sind 800 GB... Da gibt's nichts dran zu rütteln ;) Also 800.000.000.000 Bytes. Oder 745,06 GiB. Er will 784,256 GB sichern, das wären 730,395 GiB. Müsste also passen. So viel Platz ziehen die ACLs, Verzeichnisse usw. auch nicht. Ich bekomme mit obiger Befehlszeile und unkomprimierbaren Daten auch immer knapp über 1500 GB auf ein LTO5. Verzeichnisinfos und ACLs sind vllt. n paar kB. Nicht der Rede wert.

Internet sagt das hier: https://www.veritas.com/support/en_US/article.TECH193200

kangaroo meinte, das nach einer weiteren Reinigung der Streamer auf jeden Fall schon mal wieder deutlich flotter sichert. Mal gucken, ob nun auch wieder 800GB draufpassen.
 
(ich hatte das "--si" oben übersehen ;))
Wenn die Sicherung nicht durchläuft, kostet jedes "Wiederanlaufen" des Bandes zusätzlich etwas Platz, da nicht direkt angesetzt wird / werden kann.

Sind die Daten komprimiert? Eigentlich sollte (bei unkomprimierten Daten) durch die Hardwarekomprimierung des Laufwerkes sowieso mehr auf's Band passen...
 
Ich sicher die Daten unkomprimiert. Ist die Hardwarekompression default-mäßig an??
 
Jo aber ist von verbauter HW / Anschluss unterschiedlich. Auf Wikipedia steht "nur" der definierte Standard die ein LTO-4-Laufwerk erreichen kann.

HP verbaut vermutlich auch nur Ultrium von IBM, und die sind nicht immer die schnellsten, dafür recht zuverlässig.

Grüße
 
Fein - Thanks

- - - Beitrag zusammengeführt - - -

Na wer sagt's denn ...

Code:
summary:  730 GByte in 2 h 52 min 72.4 MB/s
 
Auf Wikipedia steht "nur" der definierte Standard die ein LTO-4-Laufwerk erreichen kann.
Von FH-Laufwerken wird das in der Regel auch eingehalten bzw. geschafft. HH-Laufwerke können - wie auf Wikipedia auch steht - etwas langsamer sein. Betonung liegt auf "können". Mein LTO5 in HH schafft die Maximalgeschwindigkeit. Dieses LTO4 in HH wohl nicht...

Aber 72,4MB/s bei 80MB/s angegebenem Maximum klingt ja schon wieder ganz gut :) Und selbst manches performantes RAID kann bei >100MB/s große Probleme bekommen, konstant so einen Datenstrom zu liefern. Wenn es bei meinem an die kleinen Dateien geht, läuft auch schon mal der Buffer leer... Trotz 24GB Buffer :D
 
Kleines Update als Totengräber:

Habe eine sehr ähnliche Zeile genommen für LTO6. Hier aber ohne -b 512 und mit 96G Write Buffer (lief über den 128GB RAM Server. Komme auf >160 Mbyte schreibend wenn Kompression an ist.
 
  • ok1.de
  • IT Refresh - IT Teile & mehr
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben