Holger Müller holger.mueller@dass-it.de arbeitet als Consultant für die dass IT GmbH.

Aufgaben:

• Datensicherung / Monitoring und HA-Thematiken
• Fehleranalysen bis auf Quellcode-Ebene.

Lieblingssprache:

• Python

In diesem Vortrag wird gezeigt wie Bacula zum Erstellen „sicherer“ Backups verwendet werden kann. Hierbei steht nicht der Schutz vor Datenverlust, welcher bei einem guten Backup-Programm gegeben sein sollte, im Vordergrund, sondern wie die Daten vor unbefugtem Zugriff und Manipulation geschützt werden können.

• Bezug von Bacula (Git-Repo) und wichtige Mailinglisten.
• Übersicht über die Softwarearchitektur
• Unterschiede der Datenbank-Backends
• Verschlüsseltes Backup der Daten mittels AES
• Tests auf Datenmanipulation mittels Prüfsummenchecks
• ACLs zur Zugriffsbeschränkung der Consolen

Erste und wichtigste Anlaufstelle für Bacula ist natürlich die Bacula.org-Website!

Weiter Informationen und Anwendungsbeispiele findet man auch der Bacula Konferenz-Site. Hier kann man einige der dort gehaltenen Vorträge herunterladen.

Der Quellcode kann über folgende Git-Repositories bezogen werden:

• bacula – Bacula Community Source http://www.bacula.org/git/cgit.cgi/bacula/
• doc – Bacula Community Manual http://www.bacula.org/git/cgit.cgi/docs/

Binaries gibt es entweder schon in der Distribution (z.B. bei Debian) oder Communuty-Repositories.

• https://build.opensuse.org/project/repositories?project=Archiving%3ABackup%3AFactory
• http://download.opensuse.org/repositories/Archiving:/Backup:/Factory/

• https://build.opensuse.org/project/repositories?project=home%3Apstorz%3Abacula-buch
• https://build.opensuse.org/package/repositories?package=bacula&project=home%3Adassit%3Abacula

• http://sourceforge.net/projects/bacula/files/Win32_64/ – Windows Binaries

http://www.baculasystems.com

Liste der Unterstützten Plattformen

Die beiden wichtigsten Mailinglisten:

• Bacula-Users – Für Einsteiger und Allgemeine Fragen und Ankündigungen
• Bacula-Devel – Für alle die auch mal am Code schrauben

Am einfachsten über die Development-Mailingliste.

Bestehende Bugs können im Mantis Bug Tracking eingesehen werden.

Für den Vortrag verwende ich die Pakete aus dem Bacula-Buch Repository:

zypper ar 'http://download.opensuse.org/repositories/home:/pstorz:/bacula-buch/openSUSE_11.4/' 'Bacula Buch'
groupadd -r bacula
useradd -g bacula -r bacula
zypper install postgresql-server
zypper install bacula-postgresql

Leider haben die Pakete noch ein paar Probleme mit den Datei- und Verzeichnisrechten, so diese noch etwas angefasst werden müssen.

chgrp bacula /usr/lib64/bacula/*
chmod  g+rx /usr/lib64/bacula/*
chown bacula:bacula /var/lib/bacula/
chmod  g+w /var/lib/bacula/
chgrp bacula /usr/sbin/bscan /usr/sbin/dbcheck
chmod g+rx /usr/sbin/bscan /usr/sbin/dbcheck
rcpostgresql start
su - postgres
createuser bacula
# Shall the new role be a superuser? (y/n) y
usermod -s /bin/bash bacula
su - bacula -c /usr/lib64/bacula/create_bacula_database
su - bacula -c /usr/lib64/bacula/make_bacula_tables
usermod -s /sbin/nologin bacula

/etc/init.d/bacula-dir

...
# Required-Start:               $local_fs $network postgresql
# Required-Stop:                $local_fs $network postgresql
...

rcbacula-dir start
chkconfig -e

Um Daten sichern zu können brauchen wir ein wenig Platz im Dateisystem:

mkdir -p /srv/backup/
chown bacula:disk /srv/backup/
chmod 770 /srv/backup/

/etc/bacula/bacula-fd.conf

...
Device {
  Name = FileStorage
  Media Type = File
  Archive Device = /srv/backup
  LabelMedia = yes;                   # 
...

Wiki Anleitung

git clone http://git.bacula.org/bacula
cd bacula
git tag -l
git checkout -b Release-5.2.1
cd bacula
./configure --enable-client-only

• Der Director – Steuert und Verwaltet alle Backupaufträge
• Die Console – Spricht mit dem Director um Aufträge anzustossen
• Der Catalog – Speichert die Metadaten der gesicherten Dateien, Job- und Medieninformationen
• Der Storage Daemon – Schreibt die vom File Daemon gelieferten Daten auf die Medien
• Der File Daemon – Sendet Dateien an den Storage Daemon

Zur Zeit existieren drei Datenbank-Backends für den Catalog:

1. Sqlite – nur für nichtproduktive Systeme geeignet kein bweb etc. möglich
2. MySQL – Geignet, aber Abfragen sind bei großen Datenbeständen langsamer als bei PostgreSQL
3. PostgreSQL – Primäres Entwicklungsbackend → beste Unterstützung und Performance

Weitere Backends sind in Planung, die Catalog-Abfragen werden seit der Version 5 in einer eigenen Library (libbaccats) gekapselt.

Üblicherweise erfolgt die Netzwerkanbindung an die Clients über die von Bacula vorgegebenen TCP/IP-Ports.

Bei der IANA registrierte Netzwerkports für Bacula:

Die Ports sind sowohl für tcp als auch für udp spezifiziert, Bacula nutzt jedoch lediglich tcp.

Die Backup-Daten werden auf der zwischen den einzelnen Daemons im Klartext übertragen, die Authentisierung der Daemons ist jedoch kryptografisch mittels hmac_md5 und symetrischen Schlüsseln gesichert.

Soll auch der Netzwerkverkehr der Daten abgesichert werden, so kann auch TLS eingesetzt werden. Ebenso ist es möglich SSH-Verbindungen (autossh) zum Beispiel in DMZs anzulegen oder aber einfach die Verbindung über IPSEC oder OpenVPN herzustellen.

Beispiele zum Einsatz von autossh findet man im Bacula-Repository unter dem Pfad /bacula/bacula/examples/

Ausführliches Diagramm im Wiki

• Verschlüsselung und Signierung von Daten ausschließlich auf dem Filedaemon
• RSA Schlüssel mit selbstsignierten x509 Zertifikaten.
• Verschlüssungsalgorhythmus AES-CBC 128 Bit.
• Metadaten (Dateinamen, Berechtigungen, Größen etc.) nicht verschlüsselt

• Masterkey – Kann global als Notfallschlüssel hinterlegt werden
• Clientkeys
• Dateirechte beachten - Masterkey „wegschließen“

• Beispiel im Wiki

/etc/bacula/bacula-fd.conf

..
  PKI Signatures = Yes                            # Daten werden signiert
  PKI Encryption = Yes                            # Daten werden verschluesselt
  PKI Keypair = "/etc/bacula/keys/bacula-fd.pem"  # Eigener oeffentlicher und privater Schluessel
  PKI Master Key = "/etc/bacula/keys/master.cert" # NUR der oeffentliche Schluessel
..

1. Datenverschlüsselung ist rechenintensiv
2. Schlüsselverlust vernichtet die Sicherung
3. Filedaemon kann unverschlüsselten Daten annehmen
4. Masterkey ist in der Regel sinnvoll
5. Rücksicherungen regelmäßig testen (Ist bei jedem Backupsystem sinnvoll)

Sollte die Schlüsseldatei des Clients verloren gegangen sein, so ist beim Restore der private Masterschlüssel master.key notwendig.

FD-Einrichtung - Analog des Client-Schlüsselpäärchens.

Auf diesem Filedaemon können sämtliche mittels Masterkey verschlüsselte Sicherungen zurückgesichert werden.

Mit Bacula ist es möglich Verify Jobs anzulegen. Diese Jobs sichern allerdings keine Dateien, sondern ermöglichen es die in den Filesets dieser Jobs erfassten Dateien und Verzeichnisse auf Manipulationen hin zu überwachen.

Ausführliche Konfiguration im Wiki

/etc/bacula/bacula-dir.conf

Job {
  Name = "VerifyClient1"
  JobDefs = "DefaultJob"
  Client = bacula-fd
  FileSet = "Verify Set"
  Type = Verify
  Schedule = "VerifyCycle"
  Level = InitCatalog
}

Anhand der Verify Option wird festgelegt, welche Veränderungen erkannt und gemeldet werden sollen:

• i vergleiche Inodes
• p vergleiche Berechtigungen (permission bits)
• n vergleiche Anzahl der Links
• u vergleiche Benutzer ID (user id)
• g vergleiche Gruppen ID (group id)
• s vergleiche Dateigröße (size)

• a vergleiche letzte Zugriffszeit (access time)
• m vergleiche letzte Änderung in der Datei (modification time / st_mtime)
• c vergleiche letzte Änderung der Dateieigenschaften (change time / st_ctime)
• s vergleiche Größenänderungen
• 5 vergleicht MD5 Prüfsummen
• 1 vergleicht SHA1 Prüfsummen

Bacula bietet die Möglichkeit den Funktionsumfang der konnektierenden Consolen einzuschränken.

• JobACL = Namensliste – Beschränkt den Zugriff auf einzelne Job Resourcen.
• ClientACL = Namensliste – Limitiert die auswählbaren Clients (File Daemons)
• StorageACL = Namensliste – Limitiert die auswählbaren Storages
• ScheduleACL = Namensliste – Bestimmt die nutzbaren Zeitpläne
• PoolACL = Namensliste – Limitiert die auswählbaren Medienpools

• FileSetACL = Namensliste – Limitiert die auswählbaren Filesets
• CatalogACL = Namensliste – Catalogdatenbanken auf die die Console zugreifen kann
• CommandACL = Namensliste – Bestimmt die möglichen Befehle
• WhereACL = Pfadangabe – Bestimmt in welchen Pfad zurückgesichert werden kann (noch nicht ausgiebig getestet)

Es dürfen Fragen gestellt werden!