Bacula: Backup von Linux-Servern

Bacula ist ein Open-Source-Backup-System der Enterprise-Klasse für die Verwaltung von Backups sowie die Wiederherstellung und Verifizierung von Daten im gesamten Netzwerk. Das System ist modular aufgebaut und besteht aus mehreren Komponenten:

• Director - die zentrale Steuerkomponente, die alle Backup-Vorgänge koordiniert
• Storage Daemon - verwaltet den Backup-Speicher (Festplatten, Bänder)
• File Daemon - läuft auf den zu sichernden Clients und sendet die Daten
• Console - Oberfläche für Verwaltung und Monitoring
• Catalog - Datenbank (MySQL/PostgreSQL), in der die Metadaten der Backups gespeichert werden

Installation unter Debian/Ubuntu

Installation von Director und Storage Daemon (Backup-Server)

apt update
apt install bacula-director-mysql bacula-sd bacula-console

Während der Installation werden Sie nach der Datenbankkonfiguration gefragt. Wählen Sie die automatische Konfiguration mit dbconfig-common.

Installation des File Daemon (zu sichernder Client)

apt install bacula-fd

Installation überprüfen

# Konfigurationssyntax prüfen
bacula-dir -t -c /etc/bacula/bacula-dir.conf

# Dienste starten
systemctl enable --now bacula-director bacula-sd bacula-fd

Beispielkonfiguration

Die folgende Konfiguration sichert einen einzelnen Server mit diesen Eigenschaften:

• Tägliche inkrementelle Backups um 01:00 Uhr
• Virtual-Full-Backups zweimal pro Woche (Mittwoch und Sonntag) um 02:00 Uhr
• Automatische Freigabe von Speicherplatz
• 7 Tage Aufbewahrung der Daten auf der Festplatte
• 14 Tage Aufbewahrung der Metadaten im Katalog

Konfiguration des File Daemon (Client)

Diese Konfiguration läuft auf jedem zu sichernden Server und ist in der Datei /etc/bacula/bacula-fd.conf gespeichert.

#
# Bacula File Daemon Configuration
#

FileDaemon {
  Name = server-fd
  FDport = 9102
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /run/bacula
  Maximum Concurrent Jobs = 10
  # Adresse, auf der der FD lauscht (0.0.0.0 = alle)
  FDAddress = 0.0.0.0
}

# Verbindung vom Director
Director {
  Name = backup-dir
  Password = "heslo-pro-file-daemon"
}

# Lokales Monitoring (optional)
Director {
  Name = backup-mon
  Password = "heslo-pro-monitoring"
  Monitor = yes
}

Messages {
  Name = Standard
  director = backup-dir = all, !skipped, !restored
}

Konfiguration des Storage Daemon

Diese Konfiguration läuft auf dem Backup-Server, auf dem die Daten gespeichert werden, und liegt in der Datei /etc/bacula/bacula-sd.conf.

#
# Bacula Storage Daemon Configuration
#

Storage {
  Name = backup-sd
  SDPort = 9103
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /run/bacula
  Maximum Concurrent Jobs = 20
  SDAddress = 0.0.0.0
}

# Verbindung vom Director
Director {
  Name = backup-dir
  Password = "heslo-pro-storage-daemon"
}

# Lokales Monitoring (optional)
Director {
  Name = backup-mon
  Password = "heslo-pro-monitoring"
  Monitor = yes
}

# Autochanger - ein virtueller "Bandwechsler" für Festplattenspeicher
Autochanger {
  Name = FileChgr1
  Device = FileChgr1-Dev1
  Device = FileChgr1-Dev2
  Device = FileChgr1-Dev3
  Changer Command = ""
  Changer Device = /dev/null
}

# Gerät zum Speichern der Backups
Device {
  Name = FileChgr1-Dev1
  Media Type = File
  Archive Device = /home/backupdb/bacula/backup
  LabelMedia = yes
  Random Access = yes
  AutomaticMount = yes
  RemovableMedia = no
  AlwaysOpen = no
  Maximum Concurrent Jobs = 5
}

Device {
  Name = FileChgr1-Dev2
  Media Type = File
  Archive Device = /home/backupdb/bacula/backup
  LabelMedia = yes
  Random Access = yes
  AutomaticMount = yes
  RemovableMedia = no
  AlwaysOpen = no
  Maximum Concurrent Jobs = 5
}

Device {
  Name = FileChgr1-Dev3
  Media Type = File
  Archive Device = /home/backupdb/bacula/backup
  LabelMedia = yes
  Random Access = yes
  AutomaticMount = yes
  RemovableMedia = no
  AlwaysOpen = no
  Maximum Concurrent Jobs = 5
}

Messages {
  Name = Standard
  director = backup-dir = all
}

Warum 3 Geräte (Device)? Ein Autochanger mit mehreren Geräten ermöglicht parallele Vorgänge. Jedes Gerät kann gleichzeitig ein Volume bedienen, was entscheidend ist für:

1. Virtual-Full-Backups - bei der Konsolidierung liest Bacula gleichzeitig aus den Quell-Volumes (Dev2) und schreibt in das Ziel-Volume (Dev1). Mit nur einem Gerät wäre das nicht möglich.
2. Paralleles Backup mehrerer Clients - wenn Sie mehrere Server gleichzeitig sichern, kann jeder über ein eigenes Gerät in ein eigenes Volume schreiben.
3. Restore während eines Backups - Sie können Daten wiederherstellen (Lesen), während ein anderer Client gesichert wird (Schreiben).

Alle Geräte verweisen auf dasselbe Verzeichnis (Archive Device), Bacula verwendet sie jedoch als unabhängige "Laufwerke" für den Zugriff auf verschiedene Volumes. Für ein übliches Setup empfehlen wir 2-3 Geräte, bei größeren Infrastrukturen mit vielen Clients können es mehr sein.

Hinweis: Das Verzeichnis /home/backupdb/bacula/backup muss existieren und für den Benutzer bacula beschreibbar sein:

Hauptkonfigurationsdatei

Sie ist in der Datei /etc/bacula/bacula-dir.conf gespeichert.

Director {
  Name = backup-dir
  QueryFile = "/etc/bacula/scripts/query.sql"
  WorkingDirectory = "/var/lib/bacula"
  PidDirectory = "/run/bacula"
  Maximum Concurrent Jobs = 10
  Password = "silne-heslo-pro-console"
  Messages = Daemon
}

# Standardeinstellungen für alle Backup-Jobs
JobDefs {
  Name = "DefaultJob"
  Type = Backup
  Level = Incremental
  Schedule = "WeeklyCycle"
  Messages = Standard
  SpoolAttributes = yes
  Priority = 10
  Write Bootstrap = "/var/lib/bacula/%c.bsr"
  # Automatisches Hochstufen auf VirtualFull nach 30 Tagen ohne Full
  Max Virtual Full Interval = 30 days
  Allow Mixed Priority = yes
  Cancel Lower Level Duplicates = yes
  Cancel Queued Duplicates = yes
}

# Backup-Job für den Server
Job {
  Name = "BackupServer"
  JobDefs = "DefaultJob"
  FileSet = "ServerFileSet"
  Pool = ServerPool
  Client = "server-fd"
  Storage = BackupStorage
  # Nur das letzte nicht konsolidierte Incremental behalten
  Backups To Keep = 1
  Delete Consolidated Jobs = Yes
  Accurate = Yes
  # Maximale Wartezeit auf den Jobstart
  Max Start Delay = 10h
  # Wiederholung bei Fehler
  Reschedule On Error = yes
  Reschedule Times = 3
  Reschedule Interval = 30 min
}

# Restore job
Job {
  Name = "RestoreFiles"
  Type = Restore
  Client = server-fd
  Storage = BackupStorage
  FileSet = "ServerFileSet"
  Pool = ServerPool
  Messages = Standard
  Where = /tmp/bacula-restore
}

# Definition der zu sichernden Dateien
FileSet {
  Name = "ServerFileSet"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    # Unnötige Verzeichnisse ausschließen
    Options {
      exclude = yes
      wild = "*/logs/*"
      wild = "*/var/log/*"
      wild = "*/var/cache/*"
      wild = "*/tmp/*"
      wild = "*/node_modules/*"
      wild = "*/.cache/*"
      wild = "*/media/cache/*"
    }
    File = /root
    File = /home
    File = /etc
  }
}

# Backup-Zeitplan
Schedule {
  Name = "WeeklyCycle"
  # Tägliche inkrementelle Backups
  Run = Level=Incremental Priority=10 mon-sun at 01:00
  # Virtual Full zweimal pro Woche (Mittwoch und Sonntag)
  Run = Level=VirtualFull Priority=5 wed,sun at 02:00
}

# Client
Client {
  Name = server-fd
  Address = server.example.com
  FDPort = 9102
  Catalog = MyCatalog
  Password = "heslo-pro-file-daemon"
  File Retention = 14 days
  Job Retention = 14 days
  AutoPrune = yes
  Maximum Concurrent Jobs = 10
}

# Speicher mit Autochanger
Autochanger {
  Name = BackupStorage
  Address = backup.example.com
  SDPort = 9103
  Password = "heslo-pro-storage-daemon"
  Device = FileChgr1
  Media Type = File
  Maximum Concurrent Jobs = 10
  Autochanger = BackupStorage
}

# Katalog (Datenbank)
Catalog {
  Name = MyCatalog
  dbname = "bacula"
  DB Address = "127.0.0.1"
  DB Port = "3306"
  dbuser = "bacula"
  dbpassword = "heslo-databaze"
}

# Pool für reguläre Backups
Pool {
  Name = ServerPool
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  # Aufbewahrung der Daten auf der Festplatte
  Volume Retention = 7 days
  # Speicherplatz nach Purge automatisch freigeben
  Action On Purge = Truncate
  Recycle Oldest Volume = yes
  Maximum Volume Bytes = 20G
  Maximum Volumes = 50
  Label Format = "ServerVol-"
  # Ziel-Pool für Virtual Full
  Next Pool = VFServerPool
}

# Pool für Virtual-Full-Backups
Pool {
  Name = VFServerPool
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 7 days
  Maximum Volume Bytes = 20G
  Maximum Volumes = 70
  Action On Purge = Truncate
  Recycle Oldest Volume = yes
  Label Format = "VFServerVol-"
  Storage = BackupStorage
}

# Meldungen
Messages {
  Name = Standard
  mailcommand = "/usr/sbin/bsmtp -h localhost -f \"Bacula\" -s \"Bacula: %t %e of %c %l\" %r"
  mail = admin@example.com = all, !skipped
  console = all, !skipped, !saved
  append = "/var/log/bacula/bacula.log" = all, !skipped
  catalog = all
}

Messages {
  Name = Daemon
  mailcommand = "/usr/sbin/bsmtp -h localhost -f \"Bacula\" -s \"Bacula daemon message\" %r"
  mail = admin@example.com = all, !skipped
  console = all, !skipped, !saved
  append = "/var/log/bacula/bacula.log" = all, !skipped
}

# Wartungsjob für die automatische Bereinigung
Schedule {
  Name = "MaintenanceNightly"
  Run = mon-sun at 09:00
}

Job {
  Name = "MaintenancePrune"
  Type = Admin
  Client = server-fd
  FileSet = "ServerFileSet"
  Schedule = "MaintenanceNightly"
  Priority = 50
  Messages = Standard
  Pool = ServerPool
  Storage = BackupStorage

  # Abgelaufene Jobs bereinigen
  RunScript {
    Console = "prune jobs client=server-fd yes"
    RunsOnClient = no
    RunsWhen = Before
  }

  # Abgelaufene Volumes bereinigen
  RunScript {
    Console = "prune expired volume pool=ServerPool yes"
    RunsOnClient = no
    RunsWhen = Before
  }
  RunScript {
    Console = "prune expired volume pool=VFServerPool yes"
    RunsOnClient = no
    RunsWhen = Before
  }

  # Truncate - Speicherplatz auf der Festplatte freigeben
  RunScript {
    Console = "truncate volume pool=ServerPool allpools storage=BackupStorage yes"
    RunsOnClient = no
    RunsWhen = Before
  }
  RunScript {
    Console = "truncate volume pool=VFServerPool allpools storage=BackupStorage yes"
    RunsOnClient = no
    RunsWhen = Before
  }
}

Console {
  Name = backup-mon
  Password = "heslo-pro-monitoring"
  CommandACL = status, .status
}

Die wichtigsten Parameter erklärt

Aufbewahrung der Daten

• Volume Retention - wie lange die Daten auf der Festplatte aufbewahrt werden. Empfehlung: mindestens die Dauer des längsten Backups plus Reserve.
• Job Retention - wie lange die Job-Einträge in der DB aufbewahrt werden. Empfehlung: ≥ Volume Retention.
• File Retention - wie lange die Dateilisten in der DB aufbewahrt werden. Empfehlung: ≤ Job Retention.

Warum File/Job Retention länger als Volume Retention halten?

File Retention und Job Retention betreffen nur die Metadaten in der Datenbank (Katalog), nicht die Backup-Dateien auf der Festplatte selbst. Eine längere Aufbewahrung der Metadaten bringt mehrere Vorteile:

1. Schutz vor dem Verlust der Basis für inkrementelle Backups

Bacula benötigt im Katalog einen Eintrag über das letzte Full- oder Virtual-Full-Backup, um ein Incremental korrekt durchführen zu können. Läuft die Job Retention ab und verschwindet der Eintrag über das Full-Backup, stuft Bacula das nächste Incremental automatisch zu einem Full hoch - das bedeutet die Übertragung aller Daten statt nur der Änderungen.

Ein Beispiel für das Problem bei kurzer Aufbewahrung:

• Montag: Full-Backup (1 TB, dauert 4 Tage)
• Freitag: Full abgeschlossen, Job Retention = 4 Tage
• Dienstag der Folgewoche: Der Eintrag über das Full-Backup läuft ab
• Mittwoch: Das geplante Incremental wird zu einem Full hochgestuft (weitere 4 Tage, 1 TB)

2. Schnellere und genauere Wiederherstellung von Dateien

Die File Retention bestimmt, wie lange in der Datenbank eine Liste aller gesicherten Dateien mit ihren Pfaden, Größen und Prüfsummen vorliegt. Mit längerer Aufbewahrung:

• Können Sie gezielt nach Dateien über die gesamte Backup-Historie suchen
• Bietet der Restore-Assistent eine vollständige Liste der wiederherstellbaren Dateien an
• Müssen Sie die Volumes nicht manuell durchsuchen und raten, was sie enthalten

Ohne Metadaten im Katalog ist eine Wiederherstellung zwar weiterhin möglich, Sie müssen dann aber die genaue JobId kennen oder die Volumes manuell mit dem Tool bls durchsuchen.

3. Besserer Überblick und Debugging

Eine längere Job Retention ermöglicht es:

• Trends bei der Größe der Backups im Zeitverlauf zu analysieren
• Problematische Jobs und Fehlermuster zu erkennen
• Die Speicherkapazität anhand historischer Daten zu planen

Auswirkung auf den Speicherplatz

• Volume Retention - wirkt sich direkt auf die Festplatte aus und bestimmt, wie lange die Backup-Dateien aufbewahrt werden. Auf die Datenbank hat sie keinen Einfluss.
• Job Retention - hat keinen Einfluss auf die Festplatte. In der Datenbank belegt sie nur minimalen Platz (einige KB pro Job).
• File Retention - hat keinen Einfluss auf die Festplatte. In der Datenbank wirkt sie sich deutlich aus, da sie die vollständige Liste aller gesicherten Dateien mit ihren Metadaten speichert.

File Retention und Datenbankgröße

Bei einem Server mit 4 Millionen Dateien kann die File Retention Folgendes ausmachen:

• 4 Tage Aufbewahrung: ~200 MB in der Datenbank
• 14 Tage Aufbewahrung: ~700 MB in der Datenbank
• 30 Tage Aufbewahrung: ~1.5 GB in der Datenbank

Das ist im Vergleich zur Größe der Backups selbst (Hunderte GB bis TB) vernachlässigbar, kann aber die Performance der Datenbankabfragen beeinflussen. Bei sehr großen Installationen sollten Sie eine Optimierung von MySQL/PostgreSQL in Betracht ziehen.

Empfohlene Einstellungen

# In der Client-Konfiguration
File Retention = 14 days   # Dateien lassen sich bis zu 2 Wochen zurück finden
Job Retention  = 14 days   # Schützt die Baseline für Incrementals
Volume Retention = 7 days  # Tatsächliche Daten auf der Festplatte

Diese Einstellungen stellen sicher, dass:

• Backup-Dateien nach 7 Tagen recycelt werden (spart Speicherplatz)
• Metadaten 14 Tage erhalten bleiben (Schutz vor dem Hochstufen auf Full)
• Ihnen eine zweiwöchige Historie für die Dateisuche zur Verfügung steht

Virtual-Full-Backups

Ein Virtual Full ist die Zusammenführung des vorherigen Full-Backups und aller nachfolgenden Incrementals zu einem neuen "virtuellen" Full-Backup. Vorteile:

• Keine Datenübertragung vom Client
• Schnellere Wiederherstellung (Inkremente müssen nicht angewendet werden)
• Effizientere Nutzung des Speichers

Parameter:

• Backups To Keep = 1 - löscht nach der Konsolidierung die alten Inkremente
• Delete Consolidated Jobs = Yes - löscht die Einträge der konsolidierten Jobs
• Next Pool - Ziel-Pool für Virtual-Full-Backups

Wartungsjob

Der Wartungsjob MaintenanceNightly führt eine automatische Bereinigung durch - er entfernt abgelaufene Einträge aus dem Katalog und gibt Speicherplatz frei, indem er leere Volumes kürzt (Truncate).

Wann die Wartung laufen sollte: Der Wartungsjob sollte erst nach Abschluss aller Backup-Jobs laufen. Würde er vor oder während der Backups laufen, könnte er Metadaten löschen, die für die Virtual-Full-Konsolidierung benötigt werden, oder Volumes freigeben, die noch in Gebrauch sind. Bei nächtlichen Backups mit Start um 01:00-02:00 Uhr empfehlen wir, die Wartung morgens laufen zu lassen, z. B. um 09:00 Uhr.

Schedule {
  Name = "MaintenanceNightly"
  Run = mon-sun at 09:00
}

Verwaltung des Speicherplatzes

• Action On Purge = Truncate - kürzt ein Volume nach dem Purge auf null und gibt so sofort Speicherplatz frei
• Recycle Oldest Volume = yes - recycelt automatisch das älteste verfügbare Volume, wenn ein neues benötigt wird
• Maximum Volume Bytes - maximale Größe einer einzelnen Volume-Datei (z. B. 20G)
• Maximum Volumes - maximale Anzahl von Volumes im Pool, begrenzt die Gesamtkapazität

Reihenfolge und Prioritäten der Jobs

Bacula startet Jobs nach ihrer Priorität - niedrigere Zahl = höhere Priorität. Das ist wichtig, damit Virtual-Full-Backups korrekt funktionieren.

Warum die Reihenfolge wichtig ist:

Ein Virtual Full konsolidiert das vorherige Full/VirtualFull und alle nachfolgenden Incrementals zu einem neuen Ganzen. Würde der VirtualFull früher starten als ein für denselben Tag geplantes Incremental, wäre dieses Incremental nicht in der Konsolidierung enthalten.

Empfohlene Prioritäten:

• Priority = 5 - Virtual-Full-Backups (höhere Priorität)
• Priority = 10 - Incremental- und Full-Backups (Standardpriorität)
• Priority = 50 - Wartungsjobs (niedrigste Priorität)

Schedule {
  Name = "WeeklyCycle"
  Run = Level=Incremental Priority=10 mon-sun at 01:00
  Run = Level=VirtualFull Priority=5 wed,sun at 02:00
}

Wie funktioniert das? Die richtige Reihenfolge wird durch den zeitlichen Abstand im Schedule sichergestellt - die Incrementals starten um 01:00 Uhr, der VirtualFull erst um 02:00 Uhr. Entscheidend ist, dass die Incrementals zuerst starten.

Der VirtualFull konsolidiert alle abgeschlossenen Jobs im Katalog. Läuft ein Incremental beim Start des VirtualFull noch, wird es nicht in diese Konsolidierung einbezogen, sondern erst in den nächsten VirtualFull. Das ist erwartetes Verhalten und kein Problem, da die Daten des laufenden Incrementals weiterhin separat verfügbar sind.

Der Virtual Full hat eine höhere Priorität (niedrigere Zahl), damit er beim Warten in der Queue weniger wichtige Jobs überholen kann. Die Priorität entscheidet nur bei Jobs, die gleichzeitig in der Queue warten.

Der Parameter Allow Mixed Priority in den JobDefs erlaubt es, Jobs mit unterschiedlicher Priorität gleichzeitig auszuführen. Ohne ihn würde Bacula warten, bis alle Jobs mit höherer Priorität abgeschlossen sind, bevor Jobs mit niedrigerer Priorität starten.

Allow Mixed Priority = yes

Umgang mit großen Backups

Wenn das Backup eines Servers mehrere Tage dauert (z. B. 1 TB Daten über ein langsames Netzwerk oder HDD), muss die Konfiguration angepasst werden:

1. Volume Retention erhöhen

Volume Retention = 14 days  # Mindestens 2× der Sicherungszeitraum

2. Job/File Retention erhöhen

Job Retention = 21 days
File Retention = 21 days

3. Job während der Ausführung vorübergehend deaktivieren

# Geplante Ausführung deaktivieren
bconsole <<< "disable job=BackupServer"

# Nach Abschluss wieder aktivieren
bconsole <<< "enable job=BackupServer"

4. FileSet optimieren

Das Ausschließen großer, nicht benötigter Verzeichnisse beschleunigt das Backup deutlich:

Options {
  exclude = yes
  wild = "*/vendor/*"
  wild = "*/node_modules/*"
  wild = "*.log"
  wild = "*.tmp"
  wild = "/var/lib/docker/*"
}

Grafische Oberfläche BAT

Für Benutzer, die eine grafische Umgebung der Kommandozeile vorziehen, bietet Bacula die Anwendung BAT (Bacula Administration Tool). Es handelt sich um eine Qt-Anwendung mit einer übersichtlichen GUI für die Verwaltung und das Monitoring von Backups.

Der Hauptvorteil von BAT ist, dass Sie es auf Ihrem lokalen Rechner starten und den Backup-Status der Server aus der Ferne überwachen können - eine Anmeldung per SSH auf dem Backup-Server ist nicht nötig.

Installation

# Debian/Ubuntu - auf Ihrem Rechner
apt install bacula-console-qt

Verbindung konfigurieren

BAT benötigt eine Konfigurationsdatei mit den Verbindungsdaten zum Director. Legen Sie zum Beispiel die Datei ~/.bacula/bat.conf an:

Director {
  Name = backup-dir
  DIRport = 9101
  address = backup.example.com
  Password = "silne-heslo-pro-console"
}

Wichtig: Das Passwort muss mit dem Passwort übereinstimmen, das in der Console-Ressource auf der Seite des Directors definiert ist.

Start mit eigener Konfiguration

# Start mit explizitem Pfad zur Konfiguration
bat -c ~/.bacula/bat.conf

Für einen bequemeren Start können Sie in ~/.bashrc einen Alias anlegen:

alias bat='bat -c ~/.bacula/bat.conf'

Firewall und Netzwerkzugriff

Für eine Remote-Verbindung muss auf dem Backup-Server der Zugriff auf den Port des Directors erlaubt sein:

# Auf dem Backup-Server
ufw allow from 192.168.1.0/24 to any port 9101 proto tcp

Alternativ können Sie in der Konfiguration des Directors einschränken, auf welchen Adressen er lauscht:

Director {
  Name = backup-dir
  DirAddresses = {
    ip = { addr = 127.0.0.1 }
    ip = { addr = 192.168.1.10 }  # LAN-Adresse
  }
  ...
}

Grundlegende bconsole-Befehle

Verbindung zur Konsole

bconsole

Status überwachen

# Status des Directors - Übersicht geplanter und laufender Jobs
status dir

# Detaillierter Status eines bestimmten Jobs
status jobid=1234

# Status des Clients
status client=server-fd

# Status des Speichers
status storage=BackupStorage

Jobs verwalten

# Backup manuell starten
run job=BackupServer level=Incremental yes

# Laufenden Job abbrechen
cancel jobid=1234

# Letzte Jobs auflisten
list jobs client=server-fd

# Job-Details
list jobid=1234

Volumes verwalten

# Volumes im Pool auflisten
list volumes pool=ServerPool

# Volume-Details
list volume=ServerVol-0001

# Volume manuell purgen
purge volume=ServerVol-0001 yes

# Truncate - Speicherplatz freigeben
truncate volume pool=ServerPool allpools storage=BackupStorage yes

Konfiguration überprüfen

# Syntax prüfen (ohne Start)
bacula-dir -t -c /etc/bacula/bacula-dir.conf

# Konfiguration im laufenden Betrieb neu laden
bconsole <<< "reload"

# Konfiguration anzeigen
show job=BackupServer
show pool=ServerPool
show schedule=WeeklyCycle

Fehlersuche

# Meldungen anzeigen
bconsole <<< "messages"

# Logdatei
tail -f /var/log/bacula/bacula.log

# Verbindung zum Client prüfen
bconsole <<< "status client=server-fd"

# Speicher prüfen
bconsole <<< "status storage=BackupStorage"

Dateien aus einem Backup wiederherstellen

Interaktive Wiederherstellung

bconsole

# Restore-Assistenten starten
restore

# Client auswählen
> 5 (Select the Client)
> server-fd

# Art der Dateiauswahl wählen
> 5 (Select the most recent backup for a client)

# Navigation und Dateiauswahl
cd /home/user/documents
mark important-file.txt
mark another-file.pdf
cd /etc
mark nginx

# Auswahl abschließen
done

# Wiederherstellung bestätigen
yes

Schnelle Wiederherstellung des letzten Jobs

bconsole << 'EOF'
restore client=server-fd where=/tmp/bacula-restore all
5
server-fd
done
yes
EOF

Wiederherstellung eines bestimmten Verzeichnisses

bconsole << 'EOF'
restore client=server-fd where=/tmp/bacula-restore
5
server-fd
cd /home/user
mark documents
done
yes
EOF

Wiederherstellung aus einem bestimmten Job/Datum

bconsole << 'EOF'
restore client=server-fd where=/tmp/bacula-restore
# Option 3 - Enter list of comma separated JobIds to select
3
6789,6790
cd /etc
mark nginx
done
yes
EOF

Parameter der Wiederherstellung

• where= Zielverzeichnis für die Wiederherstellung
• replace= Umgang mit vorhandenen Dateien: always, ifnewer, ifolder, never
• client= Ziel-Client (kann sich vom ursprünglichen unterscheiden)

Wiederherstellung auf einem anderen Server

restore client=original-fd restoreclient=new-fd where=/tmp/restore

Lösung häufiger Probleme

"Cannot find any appendable volumes"

Der Pool hat das Limit an Volumes erreicht. Lösung:

# Limit erhöhen
bconsole <<< "update pool=ServerPool MaxVols=100"

# Oder ein neues Volume manuell anlegen
bconsole <<< "label storage=BackupStorage pool=ServerPool"

"Only one Job found. Consolidation not needed"

Der Virtual Full hat nichts zu konsolidieren - es fehlt ein vorheriges Full oder es fehlen Incrementals. Stellen Sie sicher, dass der Schedule richtig eingestellt ist und mindestens ein Full + Incremental existiert.

Die Festplatte läuft voll

# Manuelles Truncate
bconsole << 'EOF'
truncate volume pool=ServerPool allpools storage=BackupStorage yes
truncate volume pool=VFServerPool allpools storage=BackupStorage yes
EOF

# Status der Volumes prüfen
bconsole <<< "list volumes pool=ServerPool"

Job wartet in der Queue

# Wartende Jobs anzeigen
bconsole <<< "status dir"

# Alle wartenden Jobs abbrechen
bconsole <<< "cancel all yes"

Dokumentation

Weitere Informationen finden Sie in der offiziellen Bacula-Dokumentation.