Drive Seeking LTO-5 medien

minimike

Berufsrevolutionär
Hi

Code:
 Start Backup JobId 456, Job=Backup_int-phy-mightychicken.2012-12-06_11.42.53_03
int-phy-mightychicken 3304 Issuing autochanger "load slot 3, drive 0" command.
int-phy-mightychicken 3305 Autochanger "load slot 3, drive 0", status is OK.
int-phy-mightychicken Volume "000003L5" previously written, moving to end of data.

Das Volume ist ein LTO 5 Medium. Wie lange kann es eurer Meinung im Durschschnitt maxímal dauert bis FreeBSD das Drive abgesucht hat und auf dem Band anfängt zu schreiben?

Ich bin schon seit einer Stunde dran und finde das etwas arg lang
 
Lto-4

Kann ich leider nur mit LTO-4 aus schwammiger Ereinnerung sagen. Ich denke unter 1 Stunde lief ein retension mit mt (pos 0->end->0).
Vieleicht kann ich noch eine echte Zeit dazu liefern.


So ist das mit den schwammigen Erinnerungen:
Ein retension geht mit dem aktuellen LTO Laufwerk garnicht. Es war also noch das alte S-DLT (160/320) mit ich ein retension gefahren habe, demnach wohl irrelevant.
 
Zuletzt bearbeitet:
Das das Ding keine Brote toastet hatte ich mir ja schon gedacht ... :D

Mich interessierte eigentlich, ob das Band im Laufwerk bewegt wird oder ob das ganze System hängt und es sich mechanisch dann auch nicht mehr bewegt.
Das könnte dann ein Hardwareproblem des Streamers oder Tapes sein.
Irgendwie erinnern mich diese ganzen DAT-Technologien mit schnell laufenden Bändern immer an Hobelbänke. Die Ausfallquoten waren mir immer zu hoch und ich habe dann lieber auf mehrere HDs gesichert.
SyQuest hatte noch tolle Dinger, aber die haben sich leider auch nicht durchgesetzt.
 
Das das Ding keine Brote toastet hatte ich mir ja schon gedacht ... :D

Mich interessierte eigentlich, ob das Band im Laufwerk bewegt wird oder ob das ganze System hängt und es sich mechanisch dann auch nicht mehr bewegt.
Das könnte dann ein Hardwareproblem des Streamers oder Tapes sein.
Irgendwie erinnern mich diese ganzen DAT-Technologien mit schnell laufenden Bändern immer an Hobelbänke. Die Ausfallquoten waren mir immer zu hoch und ich habe dann lieber auf mehrere HDs gesichert.
SyQuest hatte noch tolle Dinger, aber die haben sich leider auch nicht durchgesetzt.

Das derzeitige Verhalten ist so das wenn die Library spackt der Controller abraucht und sich die Library nicht mehr ansprechen lässt. Auch wenn ich den Treiber mps oder mpslsi per Modul lade und entlade klappt das nur in Ausnamefällen. In der Regel kann ich nach jeder Störung den Server einmal sowie die Library zwei mal neu starten. Beschriebene LTO Bänder sofern das Konstrukt gespackt hat kann ich bisher immer noch nicht nach anderen erfolgreich gesicherten Backups durchsuchen. Es endet dann mit einem Drive Seeking das ich dann nach 24 Stunden abbreche. Wenn die Library sauber laufen würde dann wäre ich mit meinem Bacula-Projekt unter FreeBSD zu 97% fertig. Das ist alles sehr frustrierend. Zur Zeit überlege ich auf Debian zu setzen.
 
Jain. Wenn es denn weiter spackt dann ja. Wenn nicht habe ich über die Monate ein Spitzensystem aufgesetzt und dann nur auf Verdacht hin platt gemacht. Die Kiste hat nur 31 TB Storage. Das reicht für ein paar Tage bis es auf den Bändern ist. FreeBSD hilf mir ungemein die knappen Resourcen zu optimieren um das alles bei dem Budget möglich zu machen.
 
Teste doch von einem Livesystem und mach von dort ein paar Backups. Sollte doch gehen oder?

Nein. Ich muss den Storage mit 31 TB adressieren können zweck Copy Jobs. Zudem es wäre extrem aufwendig. Die PostgreSQL DB ist 40 GB groß der PgSQL Server speziell angepasst worden. Allein die Kiste mit allen extras aufsetzen dauert 3 Tage.
 
Irgendwie beschleicht mich das Gefühl, Du solltest mal die Jungs Fragen, die das Kernel-Modul gebastelt haben.

Alternativ dazu würde ich noch eine AMANDA-Variante aufsetzen, aber das ist erst mal reines stochern im Trüben und müßte auch mit einfachen Shell-Commands zu testen sein.
 
Bacula hat doch auch eine Doku zu FreeBSD-Verhalten bei Bändern und liefert angepasste Skripte mit. Die hatte ich im Einsatz, allerdings mit einem DLT IV Laufwerk von Tandberg. Unser LTO braucht auch sehr lange, um die Bänder zu durchsuchen (allerdings keine 24h ;)).
 
Frage ich bin zur Zeit nicht am Gerät weil Wochenende. Gibt es Betreff Programmen gravierende Unterschiede zwischen chio und mtx? Zur Zeit spreche ich den Autoloader via mtx an. Bei einer Recherche hat jemand chio anstatt mtx empfohlen.
 
Zurück
Oben