Next: ANSI und IBM Tape Up: Bacula User's Guide Previous: Migration Contents Index
Bacula unterstützt Autochanger zum Lesen und Schreiben von Tapes. Damit Bacula mit einem Autochanger arbeiten kann, müssen einige Voraussetzungen erfüllt sein, die Details werden im folgenden geklärt.
In Version 1.37 und später, gibt es eine neue Autochanger-Konfiguration die erlaubt, bestimmte Device-Einträge zu gruppieren um einen Autochanger mit mehreren Laufwerken zu konfigurieren. Diese Konfiguration müssen Sie benutzen, wenn Sie einen Autochanger verwenden wollen.
Bacula benutzt sein eigenes mtx-changer Script als Interface zu dem Programm, dass die Steuerung des Autochangers übernimmt. mtx-changer kann im Prinzip so angepasst werden, dass es mit jedem Steuerungsprogramm für beliebige Autochanger funktioniert. Die derzeitige Version von mtx-changer arbeitet mit mtx. FreeBSD-Benutzer haben ein Script zur Verfügung gestellt (im Verzeichnis examples/autochangers), dass Bacula chio benutzen lässt.
Bacula unterstützt Autochanger mir Barcode-Lesern, dieses beinhaltet zwei Consolen-Kommandos: label barcodes und update slots. Im Abschnitt "Barcode Unterstützung" (siehe unten) erfolgt eine detaillierte Beschreibung dieser Kommandos.
Momentan beinhaltet die Autochanger-Unterstützung keine Stacker und Silos, und auch keine Laufwerks-Reinigung (Cleaning). Stacker und Silos werden nicht unterstützt, da sie keinen wahlfreien Zugriff auf ihre Slots erlauben. Unter Umständen schaffen Sie es vielleicht, einen Stacker (GravityFeed o. ä.) mit Bacula zum laufen zu bringen, indem Sie Ihre Konfiguration soweit anpassen, dass auf den Autochanger nur sequentiell zugegriffen wird. Die Unterstützung für Autochanger mit mehreren Laufwerken erfordert eine Konfiguration wie in Autochanger resource beschrieben. Diese Konfiguration ist aber auch für Autochanger mit nur einem Laufwerk zu benutzen.
Wenn mtx korrekt mit Ihrem Autochanger zusammenarbeitet, dann ist es nur eine Frage der Anpassung des mtx-changer Scripts (falls nötig) um den Autochanger mit Bacula zu benutzen. Eine Liste mit von mtx unterstüzten Autochangern, finden Sie unter folgendem Link: http://mtx.opensource-sw.net/compatibility.php. Die Homepage des mtx Projekts ist: http://mtx.opensource-sw.net/.
Anmerkung: wir haben Rückmeldungen von einigen Benutzern erhalten, die über gewisse Inkompatibilitäten zwischen dem Linux-Kernel und mtx berichten. Zum Beispiel zwischen Kernel 2.6.18-8.1.8.el5 von CentOS und RedHat und Version 1.3.10 und 1.3.11 von mtx. Ein Umstieg auf Kernel-Version 2.6.22 hat diese Probleme behoben.
Zusätzlich scheinen einige Versionen von mtx, z.B. 1.3.11, die maximale Anzahl der Slots auf 64 zu begrenzen, Abhilfe schafft die Benutzung von mtx-Version 1.3.10.
Wenn Sie Probleme haben, benutzen Sie bitte das auto Kommando im btape Programm, um die Funktionalität des Autochangers mit Bacula zu testen. Bitte bedenken Sie, dass bei vielen Distributionen (z.B. FreeBSD, Debian, ...) der Storage-Dienst nicht als Benutzer und Gruppe root läft, sonder als Benutzer bacula und Gruppe tape. In diesem Fall müssen Sie sicherstellen, das der Benutzer oder die Gruppe entsprechende Rechte hat, um auf den Autochanger und die Laufwerke zuzugreifen.
Manche Benutzer berichten, dass der Storage-Dienst unter Umständen beim laden eines Tapes in das Laufwerk blockiert, falls schon ein Tape im Laufwerk ist. Soweit wir das ermitteln konnten, ist es einfache eine Frage der Wartezeit: Das Laufwerk hat vorher ein Tape beschrieben und wird für eine ganze Zeit (bis zu 7 Minuten bei langsamen Laufwerken) im Status BLOCKED verbleiben, während das Tape zurückgespult und entladen wird, erst danach kann ein anderes Tape in das Laufwerk geladen werden.
Unter Linux können Sie:
cat /proc/scsi/scsi
ausführen, um zu sehen welche SCSI-Geräte Sie haben. Zudem können Sie:
cat /proc/scsi/sg/device_hdr /proc/scsi/sg/devices
benutzen, um herauszufinden, welches das Autochanger-Kontroll-Device ist, (/dev/sg0 für die erste Zeile, /dev/sg1 für die zweite, ...) das Sie in der Konfiguration unter Changer Device = angeben müssen.
Für weiterführende Information über SCSI-Geräte, schauen Sie bitte in den Abschnitt Linux SCSI Tricks aus dem Tape-Testing-Kapitel des Handbuchs.
Unter FreeBSD können Sie:
camcontrol devlist
benutzen, um SCSI-Geräte und die Kontroll-Devices /dev/passn des Autochangers anzuzeigen, die Sie in der Konfiguration unter Changer Device = angeben müssen.
Bitte stellen Sie sicher, dass der Storage-Dienst auf diese Geräte zugreifen darf.
Der folgende Tipp für FreeBSD-Benutzer kommt von Danny Butroyd: beim Neustart des Computers hat Bacula keine Berechtigung auf das Autochanger-Kontroll-Device (z.B. /dev/pass0) zuzugreifen, Um dies zu umgehen, editieren Sie die Datei /etc/devfs.conf und fügen unten diese Zeilen hinzu:
own pass0 root:bacula perm pass0 0666 own nsa0.0 root:bacula perm nsa0.0 0666
Das gibt der Gruppe bacula, nur um sicher zu gehen, auch die Schreib-Berechtigung für das Gerät nsa0.0. Damit die neue Konfiguration wirksam wird, müssen Sie:
/etc/rc.d/devfs restart
ausführen. Danach brauchen Sie nie wieder die Berechtigungen von Hand zu setzen, wenn der Computer neu gestartet wurde.
Lesen Sie bitte den nachfolgenden Abschnitt, damit Sie verstehen wie Bacula mit Autochangern arbeitet. Auch wenn Bacula ein standard mtx-changer Script installiert, benötigen Sie für Ihren Autochanger eventuell einige Anpassungen. Falls Sie Beispiele sehen wollen, schauen Sie bitte in das Verzeichnis <bacula-src>/examples/devices, wo Sie eine HP-autoloader.conf Bacula-Geräte-Konfiguration, sowie mehrere mtx-changer Scripte finden werden, die schon für unterschiedliche Autochanger angepasst sind.
Um den Autochanger richtig ansteuern zu können, muss Bacula wissen welches Volume in welchem Slot des Autochangers ist. In den Slots werden die Tapes aufbewahrt, die nicht in einem Laufwerk geladen sind. Bacula nummeriert diese Slots von eins bis zur Anzahl der vorhandenen Tapes im Autochanger.
Bacula benutzt niemals ein Volume im Autochanger, dass nicht gelabelt ist, dem keine Slotnummer im Katalog zugewiesen ist oder wenn das Volume nicht als InChanger im Katalog markiert ist. Bacula muss wissen wo das Volume/Tape ist, sonst kann es nicht geladen werden. Jedem Volume im Autochanger muss über das Console-Programm eine Slot-Nummer zugewiesen werden. Diese Information wird im Katalog, zusammen mit anderen Informationen über das Volume, gespeichert. Wenn kein Slot angegeben, oder der Slot auf Null gesetzt ist, wird Bacula das Volume nicht benutzen, auch wenn alle anderen benötigten Konfigurationsparameter richtig gesetzt sind. Wenn Sie das mount Console-Kommando ausführen, müssen Sie angeben welches Tape aus welchem Slot in das Laufwerk geladen werden soll. Falls schon ein Tape im Laufwerk ist, wird es entladen und danach das beim bf mount angegeben Tape geladen. Normalerweise wird kein anderes Tape im Laufwerk sein, da Bacula beim unmount Console-Kommando das Laufwerk leert.
Sie können die Slot-Nummer und die InChanger-Markierung überprüfen, indem Sie:
list Volumesim Consolen-Programm ausführen.
Einige Autochanger haben mehr als ein Laufwerk. Die in Version 1.37 vorgestellte Autochanger-Konfiguration, erlaubt Ihnen mehrere Geräte-Konfigurationen, die jeweils einem Laufwerk entsprechen, zu einem Autochanger zu gruppieren. Der Director-Dienst könnte trotzdem die Laufwerke direkt ansprechen, aber dies zu erlauben, würde die einwandfreie Zusammenarbeit der Laufwerke einschränken. Anstelle dessen sollte dem Director-Dienst, in der Director-Storage-Konfiguration, eine Autochanger-Konfiguration zugewiesen werden. Dieses erlaubt dem Storage-Dienst sicherzustellen, dass nur auf ein Laufwerk zur Zeit vom mtx-changer Script zugegriffen wird und nicht beide Laufwerke auf dasselbe Volume verweisen.
Mehrere Laufwerke erfordern das Setzen des Drive Index in den Geräte-Einträgen der Storage-Dienst-Konfiguration. Laufwerks-Nummern bzw. der Drive Index beginnen standardmäßig bei Null. Um mit dem zweiten Laufwerk im Autochanger arbeiten zu können, muss ein weiterer Geräte-Eintrag erstellt werden, wobei der Drive Index dann Eins ist. Normalerweise wird das zweite Laufwerk dasselbe Changer Device verwenden, aber ein anderes Archive Device.
Bacula Jobs werden bevorzugt auf das Volume geschrieben, dass schon in einem Laufwerk geladen ist. Wenn Sie mehrere Laufwerke haben und Bacula auf mehreren Laufwerke gleichzeitig Jobs, die denselben Pool verwenden, schreiben soll, muss der Parameter Prefer Mounted Volumes in der Director-Dienst-Konfiguration in den entsprechenden Job-Einträgen auf "no" gesetzt werden. Der Storage-Dienst wird daraufhin so viele Volumes wie möglich in die Laufwerke laden.
Bacula's Autochanger-Konfiguration wird in den Geräte-Einträgen des Storage-Dienstes festgelegt. Vier Parameter: Autochanger, Changer Device,Changer Command, und Maximum Changer Wait steuern wie Bacula den Autochanger benutzt.
Diese vier Parameter der Device-Konfiguration, sind unten detailliert beschrieben. Changer Device und Changer Command werden in der Gräte-Konfiguration nicht benötigt, wenn sie in der Autochanger-Konfiguration stehen.
Unter FreeBSD liegt das Kontroll-Device zwischen /dev/pass0 und /dev/passn.
Unter Solaris finden Sie das Kontroll-Device im Verzeichnis /dev/rdsk.
Stellen Sie bitte sicher, dass der Storage-Dienst die notwendigen Rechte besitzt, um auf die entsprechenden Geräte zugreifen zu dürfen.
%% = %
%a = archive device name
%c = changer device name
%d = changer drive index base 0
%f = Client's name
%j = Job name
%o = command (loaded, load, or unload)
%s = Slot base 0
%S = Slot base 1
%v = Volume name
Hier ist ein Beispiel f[ur die Benutzung von mtx mit dem mtx-changer Script, dass in der Bacula-Distribution enthalten ist:
Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d"
Falls das mtx-changer Script nicht in /etc/bacula liegt, müssen Sie den Pfad entsprechend anpassen, Einzelheiten zu den drei von Bacula benutzten Kommandos (loaded, load, unload), sowie zu den von Bacula erwarteten Ausgaben des mtx-changer Scripts, werden weiter unten im Abschnitt Bacula Autochanger Schnittstelle beschrieben..
Wenn der Autochanger nicht innerhalb der Maximum Changer Wait Zeit antwortet, wird das Kommando abgebrochen und Bacula wird das Eingreifen des Bedieners verlangen.
Device Index = 1
Um das zweite Laufwerk nutzen zu können, muss ein zweiter Device-Eintrag in der Konfigurationsdatei des Storage-Dienstes erstellt werden. Einzelheiten dazu stehen, weiter oben in diesem Kapitel, in dem Abschnitt mehrere Laufwerke
Damit der Autochanger zuverläßig funktioniert, muss zusätzlich ein Autochanger-Eintrag erstellt werden.
In der Autochanger-Konfiguration können Autochanger mit einzelnen oder mehreren Laufwerken angelegt werden, indem eine oder mehrere Gerätekonfigurationen zu einer Einheit, die Bacula Autochanger nennt, gruppiert werden. (Autochangerherrsteller nennen so etwas auch "Tape Library")
Damit Ihr Autochanger korrekt funktioniert, müssen Sie eine Autochanger-Konfiguration in der Konfigurationsdatei des Storage-Dienstes erstellen und in der Konfiguration des Director-Dienstes muss ein entsprechender Storage-Eintrag auf den Autochanger-Namen in der Storage-Dienst-Konfiguration verweisen. In früheren Bacula-Versionen verwies die Autochanger-Konfiguration des Director-Dienstes direkt auf Geräte-Konfigurationen des Storage-Dienstes. Seit Version 1.38.0 ist es nicht mehr möglich, aus einer Autochanger-Konfiguration des Director-Dienstes, direkt auf die Autochanger-Geräte zu verweisen.
Das Folgende ist ein Beispiel einer gültigen Autochanger-Konfiguration:
Autochanger {
Name = "DDS-4-changer"
Device = DDS-4-1, DDS-4-2, DDS-4-3
Changer Device = /dev/sg0
Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d"
}
Device {
Name = "DDS-4-1"
Drive Index = 0
Autochanger = yes
...
}
Device {
Name = "DDS-4-2"
Drive Index = 1
Autochanger = yes
...
Device {
Name = "DDS-4-3"
Drive Index = 2
Autochanger = yes
Autoselect = no
...
}
Bitte beachten Sie dass es wichtig ist, dass Autochanger = yes in allen Device-Einträgen angegeben wird die zum Autochanger gehören. Ein Device-Eintrag darf nie zu mehr als einem Autochanger gehören. Außerdem darf die Storage-Konfiguration des Director-Dienstes nur auf die Autochanger-Konfiguration zeigen und nicht auf die Device-Einträge.
Wenn Sie ein Laufwerk des Autochangers nicht automatisch durch Bacula benutzen lassen wollen, z.B. um immer ein freies Laufwerk für Rücksicherungen zu haben, können Sie folgendes dem entsprechenden Device-Eintrag hinzufügen:
Autoselect = no
In diesem Fall wird Bacula das Laufwerk nicht mehr automatisch auswählen, wenn es auf den Autochanger zugreift. Sie können das Laufwerk weiterhin benutzen, indem Sie direkt den Device-Namen ansprechen, anstatt des Autochangers. Ein Beispiel einer solchen Konfiguration sehen Sie oben bei dem Device-Eintrag DDS-4-3. Diese Laufwerk wird nicht benutzt werden, wenn der Autochanger-Name DDS-4-changer als Storage-Definition genutzt wird, es lässt sich aber direkt, mit entsprechenden Storage-Konfigurations-Eintrag im Director-Dienst, als Storage DDS-4-3 ansprechen.
Die folgenden beiden Konfigurations-Einträge realisieren einen Autochanger:
Autochanger {
Name = "Autochanger"
Device = DDS-4
Changer Device = /dev/sg0
Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d"
}
Device {
Name = DDS-4
Media Type = DDS-4
Archive Device = /dev/nst0 # Normal archive device
Autochanger = yes
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
}
Wobei Sie Archive Device, Changer Device und den Pfad zum Changer Command Ihrem System entsprechend anpassen müssen.
Die folgenden Konfigurations-Einträge realisieren einen Autochanger mit mehreren Laufwerken:
Autochanger {
Name = "Autochanger"
Device = Drive-1, Drive-2
Changer Device = /dev/sg0
Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d"
}
Device {
Name = Drive-1
Drive Index = 0
Media Type = DDS-4
Archive Device = /dev/nst0 # Normal archive device
Autochanger = yes
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
}
Device {
Name = Drive-2
Drive Index = 1
Media Type = DDS-4
Archive Device = /dev/nst1 # Normal archive device
Autochanger = yes
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
}
Wobei Sie Archive Device, Changer Device und den Pfad zum Changer Command Ihrem System entsprechend anpassen müssen.
Wenn Sie einen Autochanger = yes Eintrag in Ihrer Storage-Konfiguration des Director-Dienstes hinzugefügt haben, wird die Bacula Console Sie bei diesen beiden Kommandos add und label automatisch nach einem Slot für die jeweilige Aktion fragen. Beim label Kommando wird Bacula automatisch das richtige Volume in ein Laufwerk laden.
Außerdem muss, wie oben beschrieben, der Parameter Autochanger = yes in der Geräte-Konfiguration des Storage-Dienstes vorhanden sein, damit der Autochanger benutzt werden kann. Nähere Informationen zu diesen Parametern finden Sie in der Storage Konfiguration des Director-Kapitels und in Device Konfiguration des Storage-Kapitels.
Somit können alle Aktionen mit dem Autochanger komplett automatisiert werden. Zudem ist es möglich mit dem Menüpunkt Volume Parameters des Consolen-Kommandos update den Slot zu setzen und zu ändern.
Selbst wenn alle oben genannten Konfigurationen und Parameter richtig angegeben sind, wird Bacula nur dann korrekt mit den Volumes im Autochanger arbeiten, wenn den Volume-Einträge im Katalog, die den Tapes im Autochanger entsprechenden, auch eine slot-Nummer zugewiesen ist.
Wenn Ihr Autochanger Barcodes unterstützt, können Sie alle Volumes im Autochanger, eins nach dem anderen, labeln indem Sie das Console-Kommando label barcodes verwenden. Jedes Tape mit Barcode, wird von Bacula in ein Laufwerk geladen und dann mit dem selben Namen gelabelt, der auch auf dem Barcode steht. Gleichzeitig wird ein Katalog-Eintrag für das Volume angelegt. Wenn der Barcode mit der Zeichenkette beginnt, die als CleaningPrefix= konfiguriert ist, wird Bacula das Tape für ein Reinigungsband halten und es wird nicht versucht das Tape zu labeln. Ein Beispiel:
Pool {
Name ...
Cleaning Prefix = "CLN"
}
Jedes Volume mit einem Barcode wie CLNxxxxx wird als Reinigungsband behandelt und nicht gelabelt.
Bitte bedenken Sie, dass jedes Volume, dass der Autochanger automatisch benutzen soll, bereits vor-gelabelt sein muss. Wenn Sie keinen Barcode-Leser haben, muss das von Hand geschehen (oder durch ein Script).
unmount
(wechseln der Tapes und/oder mtx ausf\"{u}hren
mount
Wenn Sie den Autochanger nicht freigeben, weiß Bacula nach dem Tapewechsel nicht mehr, welches Volume in welchen Slot des Autochanger ist und wird nicht mehr korrekt mit dem Autochanger arbeiten können. Bacula geht immer davon aus, dass es exklusiven Zugriff auf den Autochanger hat, solange ein Laufwerk gemountet ist.
Wenn Sie mehrere Magazine haben, oder wenn Sie Tapes in den Magazinen tauschen, müssen Sie Bacula darüber informieren. Bacula wird immer die Tapes im Autochanger bevorzugt vor anderen Tapes benutzen, somit werden Bedienereingriffe minimiert.
Wenn Ihr Autochanger mit Barcodes (maschinenlesbare Tape Labels) arbeitet, ist der Schritt, Bacula über die im Autochanger verfügbaren Tapes zu informieren, sehr einfach. Jedes mal wenn Sie ein Magazin wechseln, oder Tapes aus dem Magazine entfernen bzw. hinzufügen, führen Sie einfach:
unmount (Magazin/Tapes wechseln) update slots mount
im Console-Programm aus. Daraufhin wird Bacula den Autochanger nach einer aktuellen Liste der in den Magazinen verfügbaren Tapes fragen. Bei diesem Vorgang werden keine Tapes gelesen, diese Informationen werden vom Autochanger während des Inventory ermittelt. Bacula aktualisiert die Volume-Einträge im Katalog, so dass bei allen in den Magazinen vorhandenen Tapes das InChanger Flag und auch die Slot-Nummern richtig gesetzt werden.
Falls Sie keinen Barcode-Leser im Autochanger haben, gibt es mehrere andere Möglichkeiten.
update slots scan
Consolen-Kommando ausführen. Daraufhin wird Bacula jedes Tape nacheinander in ein Laufwerk laden, das Tape Label lesen und den Katalog (Slot, InChanger-Flag) aktualisieren. Dieses Vorgehen ist zwar wirkungsvoll, aber auch sehr langsam.
Sie können die Barcodes im Autochanger simulieren, indem Sie das mtx-changer Script so anpassen, dass es die selben Informationen zurückgibt, die ein Autochanger mit Barcodes liefert. Dazu wird die folgende Zeile im mtx-changer Script:
${MTX} -f $ctl status |
grep " *Storage Element [0-9]*:.*Full" |
awk "{print \$3 \$4}" | sed "s/Full *\(:VolumeTag=\)*//"
(Der Zeilenumbruch dient hier nur der Darstellung, im mtx-changer Script ist es eine Zeile)
durch ein # auskommentiert oder einfach gelöscht (Zeilennummer ist ungefähr 99). An ihrer Stelle wird eine neue Zeile erstellt, die den Inhalt einer Datei ausgibt. Zum Beispiel:
cat /etc/bacula/changer.volumes
Stellen Sie sicher, dass Sie den kompletten Pfad zur Datei angeben, Ort und Name der Datei sind egal. Die Inhalt der Datei muss folgenden Beispiel entsprechen:
1:Volume1 2:Volume2 3:Volume3 ...
Wobei die 1, 2 und 3 die Slot-Nummern und Volume1, Volume2 und Volume3 die Namen (bzw. Barcodes) sind. Sie kö]nnen mehrere Datei erstellen, die den Tapes in verschiedenen Magazinen entsprechen und beim Wechsel der Magazine einfach die für das Magazine gültige Datei in die /etc/bacula/changer.volumes kopieren. Sie brauchen Bacula nicht neu zu starten, wenn Sie Magazine wechseln, nur die Datei muss den richtigen Inhalt haben. Wenn Sie dann das Console-Kommando update slots ausführen, wird Ihr Autochanger für Bacula so erscheinen, als ob er Barcodes unterstützen würde.
Wenn Sie ncht alle Slots überprüfen lassen wollen, nur weil Sie ein Tape im Magazin getauscht haben, können Sie das Consolen-Kommando update slots, genauso wie das Kommando update slots scan, mit zusätzlichen Parametern aufrufen:
update slots=n1,n2,n3-n4, ...
wobei der Parameter scan optional ist. Die Parameter n1, n2, n3-n7... geben die Slots an, wobei n1, n2 für einzelne Slots und n3-n7 für einen Bereich von Slots steht (n3 bis n7).
Diese Parameter sind nützlich, wenn Sie update slots scan (sehr langsam) ausführen und dabei die Slots auf die mit gewechselten Tapes begrenzen können.
Als Beispiel, das Console-Kommando :
update slots=1,6 scan
veranlasst Bacula, das Tape im ersten Slot des Autochangers in ein Laufwerk zu laden, das Label zu lesen und den Katalog entsprechend zu aktualisieren. Danach passiert dasselbe mit dem Tape im sechsten Slot. Das Console-Kommando:
update slots=1-3,6
liest die Barcodes der Tapes in den Slots 1, 2, 3 und 6 und aktualisiert den Katalog. Wenn Ihr Autochanger keinen Barcode-Leser hat und Sie das mtx changer Script nicht, wie oben beschrieben, angepasst haben, wird dieses Console-Kommando keine Tapes finden und folglich nichts tun.
Falls unter FreeBSD Probleme auftreten, wenn Bacula versucht auf ein Laufwerk zuzugreifen und folgende Fehlermeldung erscheint: Device not configured, passiert dass weil FreeBSD den Geräte-Eintrag /dev/nsa1 entfernt, wenn kein Tape im Laufwerk ist. Das hat zur Folge, dass Bacula das Gerät nicht öffnen kann. Die Lösung für dieses Problem ist es, sicherzustellen, dass immer ein Tape im Laufwerk ist, wenn Bacula gestartet wird. Diese Problem ist in den Bacula-Versionen 1.32f-5 und später behoben.
Beachten Sie bitte das Kapitel Laufwerk-Tests bevor Sie den Autochanger testen, dort finden Sie weitere wichtige Informationen die Laufwerke betreffend.
Bevor Sie den Autochanger gleich mit Bacula ausprobieren, ist es vorzuziehen, zuerst von Hand zu testen ob er richtig funktioniert. Um das zu tun, empfehlen wir, dass Sie die folgenden Kommandos ausführen (wobei angenommen wird, dass das mtx-changer Script unter /etc/bacula/mtx-changer liegt):
Das Kommando sollte diese Ausgabe erzeugen:
1: 2: 3: ...
eine oder mehrere Zeilen für jeden belegten Slot im Autochanger, wobei hinter jeder Zahl ein Doppelpunkt (:) stehen muss. Wenn Ihr Autochanger Barcodes unterstützt, steht hinter dem Doppelpunkt der Barcode. Falls ein Fehler auftritt, muss die Ursache gefunden werden (versuchen Sie z.B. ein anderes Kontroll-Device zu verwenden, falls /dev/sg0 falsch ist). Unter FreeBSD z.B. liegt das Kontroll-Device gewöhnlich auf /dev/pass2.
Das Kommando sollte die Anzahl der Slots im Autochanger anzeigen.
Falls das Tape aus Slot 1 in einem Laufwerk geladen ist, sollte es jetzt entladen werden.
Angenommen in Slot 3 ist ein Tape, dann wird es jetzt in das erste Laufwerk geladen (Drive Index = 0)
Dieses Kommando sollte jetzt 3 ausgeben (Die Slot-Nummer des in Laufwerk 0 geladenen Tapes.). Beachten Sie, dass wir im Kommando eine ungültige Slotnummer 0 verwendet haben. In diesem Fall, wird sie einfach ignoriert, weil sie nicht benötigt wird. Allerdings musste eine Slot-Nummer angegeben werden, weil der Laufwerksparameter am Ende des Kommandos erforderlich war, um das richtige Laufwerk zu wählen.
wird das Laufwerk mit Drive Index = 0 in Slot 3 entladen.
Nachdem alle oben genannten Kommandos funktionieren und in der Storage-Dienst-Konfiguration auch das richtige Changer Command angegeben ist, sollte Bacula jetzt mit Ihrem Autochanger arbeiten können. Das letzte verbleibende Problem ist, dass der Autochanger einige Zeit benötigt, das Tape zu laden, nachdem das entsprechende Kommando abgesetzt wurde. Wenn sich das mtx-changer Script nach dem load-Kommando beendet, wird Bacula sofort versuchen das Tape zurückzuspulen und zu lesen. Wenn Bacula Ein-/Ausgabe-Fehler nach dem Laden des Tapes meldet, werden Sie eventuell eine Verzögerungszeit (z.B. sleep 20) im mtx changer Script nach dem mtx Kommando einfügen müssen. Bitte bedenken Sie, dass egal was Sie dem mtx changer Script an Kommandos hinzufügen, sich das Script immer mit exit 0 beendet. Bacula überprüft den Rückgabewert des Script nach jedem Aufruf und er muss immer 0 sein, wenn alles geklappt hat.
Ob Sie eine sleep-Zeit im Script angeben müssen, können Sie mit folgenden Kommandos überprüfen, indem Sie sie in ein Script schreiben und ausführen.
#!/bin/sh /etc/bacula/mtx-changer /dev/sg0 unload 1 /dev/nst0 0 /etc/bacula/mtx-changer /dev/sg0 load 3 /dev/nst0 0 mt -f /dev/st0 rewind mt -f /dev/st0 weof
Wenn das Script funktioniert, haben Sie wahrscheinlich keine zeitlichen Probleme. Wenn es nicht funktioniert, tragen Sie, direkt hinter dem mtx-changer load Kommando, sleep 30 oder auch sleep 60 ein. Wenn es damit funktioniert, übernehmen Sie den passenden sleep-Eintrag in das mtx-changer Script, so wird diese Verzögerungszeit jedes mal angewendet, wenn Bacula das Script aufruft.
Ein zweites Problem, dass einige Autochanger betrifft, ist dass die Laufwerke diese Autochanger das Tape auswerfen müssen, bevor es aus dem Laufwerk entfernt werden kann. Falls das zutrifft, wird das Kommando load 3 niemals erfolgreich beendet werden, egal wie lange Sie warten. In diesem Fall, können Sie ein Auswurf-Kommando direkt hinter das unload setzen, so dass das Script dann so aussieht:
#!/bin/sh /etc/bacula/mtx-changer /dev/sg0 unload 1 /dev/nst0 0 mt -f /dev/st0 offline /etc/bacula/mtx-changer /dev/sg0 load 3 /dev/nst0 0 mt -f /dev/st0 rewind mt -f /dev/st0 weof
Natürlich müssen Sie das offline Kommando in das mtx changer Script übernehmen, falls es das Problem behebt. Da Bacula den Rückgabewert des mtx changer Scripts überprüft, stellen sie wiederum sicher, dass er immer 0 ist, bzw. das der Rückgabewert des mtx Kommandos an Bacula übergeben wird.
Wie vorher schon angemerkt, sind im Verzeichnis <bacula-source>/examples/devices mehrere Scripte, die die oben genannten Kommandos bereits enthalten. Sie können eine Hilfe sein, um Ihr Script zum laufen zu bringen.
Wenn Bacula den Fehler Rewind error on /dev/nst0. ERR=Input/output error. ausgibt, werden Sie in den meisten Fällen eine längere sleep-Zeit in Ihrem mtx-changer Script hinzufügen müssen, bevor es nach dem load Kommando beendet wird.
Angenommen, Sie haben alle notwendigen Storage-Dienst-Device-Einträge richtig konfiguriert und Sie haben einen Autochanger = yes Eintrag zu der Storage-Konfiguration im Director-Dienst hinzugeügt.
Jetzt füllen Sie Ihren Autochanger mit, zum Beispiel, 6 leeren Tapes.
Was muss passieren, damit Bacula auf diese Tapes zugreifen kann?
Eine Möglichkeit ist, dass jedes Tape vorgelabelt wird. Starten Sie Bacula und führen Sie das Console-Programm aus, innerhalb des Console-Programms verwenden Sie das Kommando label:
./bconsole Connecting to Director rufus:8101 1000 OK: rufus-dir Version: 1.26 (4 October 2002) *label
wird etwas ähnliches wie hier ausgeben:
Using default Catalog name=BackupDB DB=bacula
The defined Storage resources are:
1: Autochanger
2: File
Select Storage resource (1-2): 1
Wählen Sie den Autochanger und es erscheint:
Enter new Volume name: TestVolume1 Enter slot (0 for none): 1
geben Sie Testvolume1 für den Tape-Namen ein und 1 für den Slot. Bacula fragt:
Defined Pools:
1: Default
2: File
Select the Pool (1-2): 1
Wählen Sie den Default Pool. Das wird automatisch gemacht, wenn Sie nur einen Pool haben. Nun wird Bacula damit beginnen, das benötigte Laufwerk zu entladen und das Tape aus Slot 1 in das Laufwerk zu laden und als Testvolume1 zu labeln. In diesem Beispiel war kein Tape im Laufwerk, die Ausgabe sieht dann so aus:
Connecting to Storage daemon Autochanger at localhost:9103 ... Sending label command ... 3903 Issuing autochanger "load slot 1" command. 3000 OK label. Volume=TestVolume1 Device=/dev/nst0 Media record for Volume=TestVolume1 successfully created. Requesting mount Autochanger ... 3001 Device /dev/nst0 is mounted with Volume TestVolume1 You have messages. *
Sie können dann damit fortfahren, die andern Tapes zu labeln. Die Ausgaben werden etwas anders aussehen, weil Bacula dann erst das vorherige, gerade gelabelte Tape, aus dem Laufwerk entladen muss, bevor das neue Tape geladen werden kann.
Wenn Sie alle Tapes gelabelt haben, wird Bacula sie automatisch verwenden, wenn sie benötigt werden.
Um nachzusehen, wie die Tapes gelabelt sind, geben Sie einfach das Console-Kommando list volumes ein, das wird eine Liste, wie die folgende ausgeben:
*{\bf list volumes}
Using default Catalog name=BackupDB DB=bacula
Defined Pools:
1: Default
2: File
Select the Pool (1-2): 1
+-------+----------+--------+---------+-------+--------+----------+-------+------+
| MedId | VolName | MedTyp | VolStat | Bites | LstWrt | VolReten | Recyc | Slot |
+-------+----------+--------+---------+-------+--------+----------+-------+------+
| 1 | TestVol1 | DDS-4 | Append | 0 | 0 | 30672000 | 0 | 1 |
| 2 | TestVol2 | DDS-4 | Append | 0 | 0 | 30672000 | 0 | 2 |
| 3 | TestVol3 | DDS-4 | Append | 0 | 0 | 30672000 | 0 | 3 |
| ... |
+-------+----------+--------+---------+-------+--------+----------+-------+------+
Bacula unterstützt Barcodes mit zwei Console-Kommandos: label barcodes und update slots.
Das Kommando label barcodes bewirkt, dass Bacula mittels des mtx-changer list Kommandos die Barcodes der Tapes in allen Slots einliest. Danach wird jedes Tape, eins nach dem anderen, mit dem Namen gelabelt, den der Barcode enthält.
Das update slots Kommando holt, über das mtx-changer Script, zuerst eine Liste aller Tapes und deren Barcodes. Dann versucht es im Katalog die entsprechenden Tapes zu finden und aktualisiert den Slot und das InChanger Flag. Falls das Tape nicht im Katalog gelistet ist, passiert nichts. Diese Kommando wird benötigt, um die Volume-Einträge im Katalog mit den tatsächlich im Autochanger zur Verfügung stehenden Tapes abzugleichen, nachdem Tapes gewechselt oder in andere Slots verschoben wurden.
Die Angabe des Cleaning Prefix kann in der Pool-Konfiguration benutzt werden, um anzugeben welche Tapes (Barcodes) im Katalog mit dem VolStatus Cleaning gekennzeichnet werden sollen. Das verhindert, dass Bacula versucht auf dem Tape zu schreiben.
Bacula ruft das Autochanger-Script auf, dass Sie als Changer Command angegeben haben. Normalerweise ist es das von Bacula mitgelieferte mtx-changer Script, aber tatsächlich kann es auch jedes andere Programm sein. Die einzige Anforderung ist, dass es die Kommandos die Bacula benutzt, loaded, load, unload, list und slots, unterstützt. Ausserdem muss jedes dieser Kommandos genau diese Rückgabewerte liefern:
- Die momentan benutzten Autochanger-Kommandos sind:
loaded -- gibt, ab 1 beginnend, die Nummer des im Laufwerk geladenen Slot zur\"{u}ck,
bzw. 0 wenn das Laufwerk leer ist.
load -- l\"{a}dt das Tape aus dem angegebenen Slot in das Laufwerk (einige Autochanger
ben\"{o}tigen eine 30-sek\"{u}ndige Pause nach diesem Kommando)
unload -- entl\"{a}dt das Tape aus dem Laufwerk zur\"{u}ck in den Slot
list -- gibt eine Zeile pro Tape im Autochanger aus.
Das Format ist: <Slot>:<Barcode>. Wobei
der {\bf Slot} eine Zahl (nicht null) ist, die der Slot-Nummer entspricht,
und {\bf Barcode} ist, falls vorhanden, der Barcode des Tapes,
ansonsten ist {\bf Barcode} leer.
slots -- gibt die absolute Anzahl der Slots im Autochanger zur\"{u}ck.
Bacula überprüft den Rückgabewert des aufgerufenen Programms, wenn er Null ist, werden die gelieferten Daten akzeptiert. Wenn der Rückgabewert nicht Null ist, wird eine entsprechende Fehlermeldung ausgegeben und Bacula wird ein manuelles laden des Tapes in das Laufwerk erwarten.
I hesitate to call these "supported" autochangers because the only autochangers that I have in my possession and am able to test are the HP SureStore DAT40X6 and the Overland PowerLoader LTO-2. All the other autochangers have been reported to work by Bacula users. Note, in the Capacity/Slot column below, I quote the Compressed capacity per tape (or Slot).
| OS | Man. | Media | Model | Slots | Cap/Slot |
| Linux | Adic | DDS-3 | Adic 1200G | 12 | - |
| Linux | Adic | DLT | FastStore 4000 | 7 | 20GB |
| Linux | Adic | LTO-1/2, SDLT 320 | Adic Scalar 24 | 24 | 100GB |
| Linux | Adic | LTO-2 | Adic FastStor 2, Sun Storedge L8 | 8 | 200GB |
| - | CA-VM | ?? | Tape | ?? | ?? |
| Linux Gentoo | Dell | DLT VI,LTO-2 | PowerVault 122T/132T/136T | - | 100GB |
| - | DFSMS | ?? | VM RMM | - | ?? |
| z/VM | IBM | ?? | IBM Tape Manager | - | ?? |
| z/VM | IBM | ?? | native tape | - | ?? |
| Linux | Exabyte | VXA2 | VXA PacketLoader 1x10 2U | 10 | 80/160GB |
| - | Exabyte | LTO | Magnum 1x7 LTO Tape Auotloader | 7 | 200/400GB |
| Linux Gentoo 1.4 | Exabyte | AIT-2 | 215A | 15 (2 drives) | 50GB |
| Linux | HP | DDS-4 | SureStore DAT-40X6 | 6 | 40GB |
| Linux | HP | Ultrium-2/LTO | MSL 6000/ 60030/ 5052 | 28 | 200/400GB |
| - | HP | DLT | A4853 DLT | 30 | 40/70GB |
| Linux | HP (Compaq) | DLT VI | Compaq TL-895 | 96+4 import export | 35/70GB |
| SuSE 9.0 | IBM | LTO | IBM 3581 Ultrium Tape Loader | 7 | 200/400GB |
| FreeBSD 5.4 | IBM | DLT | IBM 3502-R14 -- rebranded ATL L-500 | 14 | 35/70GB |
| Debian | Overland | LTO | Overland LoaderXpress LTO/DLT8000 | 10-19 | 40-100GB |
| Fedora | Overland | LTO | Overland PowerLoader LTO-2 | 10-19 | 200/400GB |
| FreeBSD 5.4-Stable | Overland | LTO-2 | Overland Powerloader tape | 17 | 100GB |
| - | Overland | LTO | Overland Neo2000 LTO | 26-30 | 100GB |
| - | Quantum | ?? | Super Loader | ?? | ?? |
| FreeBSD 4.9 | QUALSTAR TLS-4210 (Qualstar) | AIT1: 36GB, AIT2: 50GB all uncomp | QUALSTAR TLS-4210 | 12 | AIT1: 36GB, AIT2: 50GB all uncomp |
| Linux | Skydata | DLT | ATL-L200 | 8 | 40/80 |
| - | Sony | DDS-4 | TSL-11000 | 8 | 40GB |
| Linux | Sony | AIT-2 | LIB-304(SDX-500C) | ? | 200GB |
| Linux | Sony | AIT-3 | LIB-D81) | ? | 200GB |
| FreeBSD 4.9-STABLE | Sony | AIT-1 | TSL-SA300C | 4 | 45/70GB |
| - | Storagetek | DLT | Timberwolf DLT | 6 | 40/70 |
| - | Storagetek | ?? | ACSLS | ?? | ?? |
| Solaris | Sun | 4mm DLT | Sun Desktop Archive Python 29279 | 4 | 20GB |
| Linux | Tandberg | DLT VI | VS 640 | 8? | 35/70GB |
| Linux 2.6.x | Tandberg Data | SLR100 | SLR100 Autoloader | 8 | 50/100GB |
Bacula allows you to specify that you want the Storage daemon to initially write your data to disk and then subsequently to tape. This serves several important purposes.
Data spooling is exactly that "spooling". It is not a way to first write a "backup" to a disk file and then to a tape. When the backup has only been spooled to disk, it is not complete yet and cannot be restored until it is written to tape. In a future version, Bacula will support writing a backup to disk then later Migrating or Copying it to a tape.
The remainder of this chapter explains the various directives that you can use in the spooling process.
The following directives can be used to control data spooling.
SpoolData = yes|no
SpoolData = yes|no
Maximum Spool Size = size Where size is a the maximum spool size for all jobs specified in bytes.
Maximum Job Spool Size = size Where size is the maximum spool file size for a single job specified in bytes.
Spool Directory = directory
Please be very careful to exclude the spool directory from any backup, otherwise, your job will write enormous amounts of data to the Volume, and most probably terminate in error. This is because in attempting to backup the spool file, the backup data will be written a second time to the spool file, and so on ad infinitum.
Another advice is to always specify the maximum spool size so that your disk doesn't completely fill up. In principle, data spooling will properly detect a full disk, and despool data allowing the job to continue. However, attribute spooling is not so kind to the user. If the disk on which attributes are being spooled fills, the job will be canceled. In addition, if your working directory is on the same partition as the spool directory, then Bacula jobs will fail possibly in bizarre ways when the spool fills.
You may be asking what Python is and why a scripting language is needed in Bacula. The answer to the first question is that Python is an Object Oriented scripting language with features similar to those found in Perl, but the syntax of the language is much cleaner and simpler. The answer to why have scripting in Bacula is to give the user more control over the whole backup process. Probably the simplest example is when Bacula needs a new Volume name, with a scripting language such as Python, you can generate any name you want, based on the current state of Bacula.
Python must be enabled during the configuration process by adding
a --with-python, and possibly specifying an alternate
directory if your Python is not installed in a standard system
location. If you are using RPMs you will need the python-devel package
installed.
When Python is configured, it becomes an integral part of Bacula and runs in Bacula's address space, so even though it is an interpreted language, it is very efficient.
When the Director starts, it looks to see if you have a Scripts Directory Directive defined, if so, it looks in that directory for a file named DirStartUp.py. If it is found, Bacula will pass this file to Python for execution. The Scripts Directory is a new directive that you add to the Director resource of your bacula-dir.conf file.
There are four Python objects that you will need to work with:
The first thing the startup script must do is to define what global Bacula events (daemon events), it wants to see. This is done by creating a Bacula Events class, instantiating it, then passing it to the set_events method. There are three possible events.
Access to the Bacula variables and methods is done with:
import bacula
The following are the read-only attributes provided by the bacula object.
A simple definition of the Bacula Events Class might be the following:
import sys, bacula
class BaculaEvents:
def JobStart(self, job):
...
Then to instantiate the class and pass it to Bacula, you would do:
bacula.set_events(BaculaEvents()) # register Bacula Events wanted
And at that point, each time a Job is started, your BaculaEvents JobStart method will be called.
Now to actually do anything with a Job, you must define which Job events you want to see, and this is done by defining a JobEvents class containing the methods you want called. Each method name corresponds to one of the Job Events that Bacula will generate.
A simple Job Events class might look like the following:
class JobEvents:
def NewVolume(self, job):
...
Here, your JobEvents class method NewVolume will be called each time the Job needs a new Volume name. To actually register the events defined in your class with the Job, you must instantiate the JobEvents class and set it in the Job set_events variable. Note, this is a bit different from how you registered the Bacula events. The registration process must be done in the Bacula JobStart event (your method). So, you would modify Bacula Events (not the Job events) as follows:
import sys, bacula
class BaculaEvents:
def JobStart(self, job):
events = JobEvents() # create instance of Job class
job.set_events(events) # register Job events desired
...
When a job event is triggered, the appropriate event definition is called in the JobEvents class. This is the means by which your Python script or code gets control. Once it has control, it may read job attributes, or set them. See below for a list of read-only attributes, and those that are writable.
In addition, the Bacula job obbject in the Director has a number of methods (subroutines) that can be called. They are:
The following attributes are read/write within the Director for the job object.
The following read-only attributes are available within the Director for the job object.
The following write-only attributes are available within the Director:
There is a new Console command named python. It takes a single argument restart. Example:
python restart
This command restarts the Python interpreter in the Director. This can be useful when you are modifying the DirStartUp script, because normally Python will cache it, and thus the script will be read one time.
An example script for the Director startup file is provided in examples/python/DirStartup.py as follows:
#
# Bacula Python interface script for the Director
#
# You must import both sys and bacula
import sys, bacula
# This is the list of Bacula daemon events that you
# can receive.
class BaculaEvents:
def __init__(self):
# Called here when a new Bacula Events class is
# is created. Normally not used
noop = 1
def JobStart(self, job):
"""
Called here when a new job is started. If you want
to do anything with the Job, you must register
events you want to receive.
"""
events = JobEvents() # create instance of Job class
events.job = job # save Bacula's job pointer
job.set_events(events) # register events desired
sys.stderr = events # send error output to Bacula
sys.stdout = events # send stdout to Bacula
jobid = job.JobId; client = job.Client
numvols = job.NumVols
job.JobReport="Python Dir JobStart: JobId=%d Client=%s NumVols=%d\n" % (jobid,client,numvols)
# Bacula Job is going to terminate
def JobEnd(self, job):
jobid = job.JobId
client = job.Client
job.JobReport="Python Dir JobEnd output: JobId=%d Client=%s.\n" % (jobid, client)
# Called here when the Bacula daemon is going to exit
def Exit(self, job):
print "Daemon exiting."
bacula.set_events(BaculaEvents()) # register daemon events desired
"""
These are the Job events that you can receive.
"""
class JobEvents:
def __init__(self):
# Called here when you instantiate the Job. Not
# normally used
noop = 1
def JobInit:
# Called when the job is first scheduled
noop = 1
def JobRun:
# Called just before running the job after initializing
# This is the point to change most Job parameters.
# It is equivalent to the JobRunBefore point.
noop = 1
def NewVolume(self, job):
# Called when Bacula wants a new Volume name. The Volume
# name returned, if any, must be stored in job.VolumeName
jobid = job.JobId
client = job.Client
numvol = job.NumVols
volname = "TestA-001"
job.JobReport = "JobId=%d Client=%s NumVols=%d VolumeName=%s" % (jobid, client, numvol,volname)
job.JobReport="Python before New Volume set for Job.\n"
job.VolumeName=volname
def VolumePurged(self, job):
# Called when a Volume is purged. The Volume name can be referenced
# with job.VolumeName
noop = 1
Kern Sibbald 2008-01-31