Bacula unter FreeBSD & Linux
06.07.2010
Bacula wird installiert auf nanako einer übrigebliebenen Maschiene (PIII866) mit einer HVD-SCSI Karte um die Timberwolf 9740 zu steuern. Die Konfiguration von Bacula wird über diverse Konfigurationskripte gesteurert:
27.07.2010
Jetzt wirds ernst. Ich haben den Direktor mit /usr/local/etc/bacula-dir.conf und den Storage Daemon mit /usr/local/etc/bacula-sd.conf konfiguriert und teste das ganze nun nach folgender Anleitung: http://www.lllf.uam.es/~antonio/documentos/bacula/dev-manual/Getting_Started_with_Bacula.html
Ich bekomme Folgendes:
nanako# bacula-dir -t -c bacula-dir.conf bacula-dir: dird.c:950 Could not open Catalog "MyCatalog", database "bacula". bacula-dir: dird.c:955 sqlite.c:178 Database /var/db/bacula/bacula.db does not exist, please create it. 27-Jul 16:24 bacula-dir ERROR TERMINATION Please correct configuration file: bacula-dir.conf
Offensichtlich ist die sqLite-Datenbank nicht gestartet bzw. die Datenbank MyCatalog nicht vorhanden. Man kann allerdings die von Bacula benötigen Tabellen per Skript nachbauen lassen zb. mit /usr/local/share/bacula/create_sqlite3_database.
Jetzt muss ich erst mal rauskriegen warum sqlite nicht läuft.
29.07.2010
Laut Wikipedia handelt es sich bei SQlite nur um eine Softwarelibrary. Da ps keinen Thread sqlite oder ähnliches anzeigt versuche ich mein Glück und setzte folgendes Kommando ab :
nanako# sh /usr/local/share/bacula/make_sqlite3_tables und nun
nanako# bacula-dir -t -c bacula-dir.conf
scheint zu klappen. Jetzt starte ich zu Testzwecken den Direktor und den Storage-Daemon per Hand mit:
nanako# /usr/local/etc/rc.d/bacula-dir onestart nanako# /usr/local/etc/rc.d/bacula-sd onestart
nun eine Übersicht mit der bconsole
nanako# bconsole
Connecting to Director nanako:9101
1000 OK: nanako.brainwash.com -dir Version: 5.0.0 (26 January 2010)
Enter a period to cancel a command.
*status
Status available for:
1: Director
2: Storage
3: Client
4: All
Select daemon type for status (1-4): 1
nanako.brainwash.com -dir Version: 5.0.0 (26 January 2010) i386-portbld-freebsd8.0 freebsd 8.0-RELEASE-p3
Daemon started 29-Jul-10 15:28, 0 Jobs run since started.
Heap: heap=0 smbytes=56,848 max_bytes=57,577 bufs=231 max_bufs=241
Scheduled Jobs:
Level Type Pri Scheduled Name Volume
===================================================================================
Incremental Backup 10 29-Jul-10 23:05 BackupClient1 *unknown*
Full Backup 11 29-Jul-10 23:10 BackupCatalog *unknown*
====
Running Jobs:
Console connected at 29-Jul-10 15:35
No Jobs running.
====
No Terminated Jobs.
====
You have messages.
*2
2: is an invalid command.
*status
Status available for:
1: Director
2: Storage
3: Client
4: All
Select daemon type for status (1-4): 2
The defined Storage resources are:
1: File
2: DLT-0
3: DLT-1
4: DLT-2
5: DLT-3
Select Storage resource (1-5): 1
Connecting to Storage daemon File at nanako:9103Aber aber ich bekomme keine Rückmeldung vom Storage Daemon. Stattdessen folgende Bacula Fehlermeldung Nun bringt ein erneutes messages-Kommndo in bconsole folgende Bacula Fahlermeldung Teil 2
In /var/db/bacula sind einige Dateien wie z.B bacula.db die als Eigentümer root haben (/var/db/bacula alt) Damit kann aber der Director nicht auf die Datei schreiben. Nachfolgendes Kommando wird in /var/db/bacula/ ausgeführt.
chown bacula:bacula *
Und noch ein Restart des Direktors bringt Bacula Fehlermeldung Teil 3
30.07.2010
Also tausche ich die Passwörter zwischen Direktor und Storage Daemon aus und vola nun scheints zu funktionieren. Nun versuche ich mein erstes Band zu labeln und bekomme Bacula Fehlermeldung Teil 4. Anscheinend hat der Storage Daemon keine Rechte um auf deb Wechsler (dev/pass4) zuzugreifen.
Auch hier bring ein Anpassen der rechte Abhilfe.
chown bacula:bacula /dev/pass*
Nun muss noch der File-Daemon konfiguriert werden. Auf dem Server selbst ist das kein Problem, man übernimmt einfach die begelegte Beispieldatei und bennet sie nach bacula-df.conf um. Und schon kanns losgehen. Möchte man jetzt ein Testbackup durchführen,dann starten man bconsole und gibt das Komando run ein.
*run
A job name must be specified.
The defined Job resources are:
1: BackupClient1
2: Hotarubi
3: BackupCatalog
4: RestoreFiles
Select Job resource (1-4): 2
Run Backup job
JobName: Hotarubi
Level: Incremental
Client: hotarubi.brainwash.com -fd
FileSet: Hotarubi Set
Pool: File (From Job resource)
Storage: File (From Job resource)
When: 2010-07-30 15:14:50
Priority: 10
OK to run? (yes/mod/no): mod
Wie man hier sieht hat der Job noch keinen zugewiesenen Pool und keine Storage Einheit. Beides kann man über die Eingabe von mod per Hand ändern. Das ganze sieht dann so aus:
Run Backup job
JobName: Hotarubi
Level: Full
Client: hotarubi.brainwash.com -fd
FileSet: Hotarubi Set
Pool: Default (From User input)
Storage: DLT-3 (From user selection)
When: 2010-07-30 15:14:50
Priority: 10
OK to run? (yes/mod/no): yes
Job queued. JobId=4
*status
Status available for:
1: Director
2: Storage
3: Client
4: All
Select daemon type for status (1-4): 1
nanako.brainwash.com -dir Version: 5.0.0 (26 January 2010) i386-portbld-freebsd8.0 freebsd 8.0-RELEASE-p3
Daemon started 30-Jul-10 14:30, 1 Job run since started.
Heap: heap=0 smbytes=82,489 max_bytes=117,452 bufs=314 max_bufs=328
Scheduled Jobs:
Level Type Pri Scheduled Name Volume
===================================================================================
Incremental Backup 10 30-Jul-10 23:05 BackupClient1 *unknown*
Incremental Backup 10 30-Jul-10 23:05 Hotarubi *unknown*
Full Backup 11 30-Jul-10 23:10 BackupCatalog *unknown*
====
Running Jobs:
Console connected at 30-Jul-10 15:11
JobId Level Name Status
======================================================================
4 Full Hotarubi.2010-07-30_15.15.28_09 is running
====
Terminated Jobs:
JobId Level Files Bytes Status Finished Name
====================================================================
1 Full 0 0 Error 30-Jul-10 10:54 BackupClient1
2 Full 23 2.891 M OK 30-Jul-10 11:00 BackupClient1
3 Full 0 0 Cancel 30-Jul-10 15:13 Hotarubi
====Nun wird schwieriger. Einrichtung eines File-Daemons auf einem externen Rechner mit Linux. Dazu wird erst mal unter Ubuntu 10.04 der File-Daemon instaliert mit
apt-get install bacula-client
Und nun muss noch dess Konfigurationsdatei angepasst werden. Diese liegen unter /etc/bacula. Hier die fertige hotarubi.bacula-fd.conf . Die Besonderheit: der Eintrag FDAdress = 127.0.0.1 muss auskommentiert werden.
Und hier nun die fertigen nanako.bacula-dir.conf und die fertige nanako.bacula-sd.conf.
Und hier noch eine Bacula Link Seite
14.09.2010
Bacula unter Linux (Xubuntu 10.04 LTS)
Um z.B ein Band manuell zu löschen bzw wieder zu verwenden setzt man folgende Kommandos in der bconsole ab.
purge jobs volume
03.10.2010
Ich möchte auf einige Tapes die ich schon mal mit einem Bacula-Label versehen haben, ein neues Label schreiben. Dazu könnte man in der bconsole das Kommando relabel oder label verwenden, aber bacula schreibt nur dann ein label auf das Band wenn nicht schon eines existiert. Mann muss das alte Label quasi per Hand löschen. Im folgenden Beispiel habe ich den Bacula-Director gestoppt und möchte nun das Band im Slot 10 mit dem 4. Laufwerk (nst3) löschen.
sudo mtx -f /dev/sg6 load 10 3 # Lädt das Laufwerk /dev/nst3 mit dem band aus Slot 10 sudo mt -f /dev/nst3 rewind # Band zurückspulen sudo mt -f /dev/nst3 weof # End of Line schreiben - das alte Label ist jetzt für Bacula unsichtbar sudo mt -f /dev/nst3 offline # Laufwerk offline - sonst kann man es nicht mehr auswerfen sudo mtx -f /dev/sg6 unload 10 3 # Band wieder in Slot 10 legen
Und hier noch ein netter Gag. Wenn man Barcodes verwendet kann man z.B die Tape vollautomatisch labeln lassen mit:
label barcodes slots=100-110 pool=Default
nimmt dann di Bänder 100 -110 und labelt sie automatisch auf den Namen der Barcodes.
10.11.2010
Ich hänge den Timberwolf vom Interen Anbschluss des SCSI-Controllers an den Externen Anschluss und prompt findet er den Wechlser nicht mehr. Ich schau mal unter var/log/messages nach und Prompt:
root@tomoko:/etc/bacula# less /var/log/messages | fgrep "scsi tape" Nov 10 08:37:25 tomoko kernel: [ 24.150386] st 4:0:0:0: Attached scsi tape st0 Nov 10 08:37:25 tomoko kernel: [ 24.152650] st 4:0:1:0: Attached scsi tape st1 Nov 10 08:37:25 tomoko kernel: [ 24.169553] st 4:0:2:0: Attached scsi tape st2 Nov 10 08:37:25 tomoko kernel: [ 24.171336] st 4:0:3:0: Attached scsi tape st3 Nov 10 09:13:52 tomoko kernel: [ 24.209613] st 5:0:0:0: Attached scsi tape st0 Nov 10 09:13:52 tomoko kernel: [ 24.211263] st 5:0:1:0: Attached scsi tape st1 Nov 10 09:13:52 tomoko kernel: [ 24.213944] st 5:0:2:0: Attached scsi tape st2 Nov 10 09:13:52 tomoko kernel: [ 24.215636] st 5:0:3:0: Attached scsi tape st3 root@tomoko:/etc/bacula#
Um sicher zu gehen kann man die einzellnen Devices befragen wer sie denn sind:
bic@tomoko:~$ sudo mtx -f /dev/sg7 inquiry Product Type: Medium Changer Vendor ID: 'STK ' Product ID: '9740 ' Revision: '1952' Attached Changer API: No
Ich stecken den Stecker auf den ersten externen Bus und nun bekomme ich
Nov 10 10:46:12 tomoko kernel: [ 18.289644] st 3:0:1:0: Attached scsi tape st1 Nov 10 10:46:12 tomoko kernel: [ 18.294469] st 3:0:2:0: Attached scsi tape st2 Nov 10 10:46:12 tomoko kernel: [ 18.303489] st 3:0:3:0: Attached scsi tape st3
Jetzt liegt der Changer wieder auf sg6.