Ausgangslage und Ziel

Teil 1 hat den Bareos-Server mit Director, Storage Daemon, PostgreSQL-Katalog, bconsole und WebUI aufgebaut. Jetzt wird client01.example.test als getrenntes Debian-13-System angebunden. Der Client soll nur die ausdrücklich ausgewählten Testdaten liefern und über das private Lab-Netz mit Director und Storage kommunizieren.

Ein installierter File Daemon ist noch kein erfolgreich angebundener Client. Erst übereinstimmende Ressourcennamen und Secrets, eine erreichbare private Adresse, eine gültige Director-Konfiguration sowie ein ausgeführter Backup-Job ergeben einen belastbaren Nachweis.

  • Bareos-Server: bareos01.example.test, private Adresse 192.168.77.10.
  • Client: client01.example.test, private Adresse 192.168.77.11.
  • Bareos: Community-Build 25.1.2~pre49.d5742f640 aus dem offiziellen Debian-13-Repository.
  • Administrativer SSH-Benutzer im Lab: fone-rumboldm mit fone-admins.
  • Testumfang: Verbindung, Schätzung und Full-Backup eines isolierten Testverzeichnisses.

1. Repository einbinden und File Daemon installieren

Client und Server sollten aus einem zueinander passenden Bareos-Kanal stammen. Das Lab verwendet deshalb auf beiden Hosts dasselbe offizielle current-Repository. Prüfen Sie das Installationsskript vor der Ausführung und dokumentieren Sie den tatsächlich installierten Paketstand.

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
curl -fsSLo /tmp/add_bareos_repositories.sh https://download.bareos.org/current/Debian_13/add_bareos_repositories.sh
less /tmp/add_bareos_repositories.sh
sudo sh /tmp/add_bareos_repositories.sh
sudo apt-get update
sudo apt-get install -y bareos-filedaemon
dpkg-query -W bareos-filedaemon bareos-common

2. Client-Identität und Director-Zugriff konfigurieren

Die Client-Ressource des File Daemons erhält einen eindeutigen Namen und bindet im Lab ausschließlich an die private Adresse. Plugin Names bleibt bewusst leer, weil dieser Test keine Plugins benötigt. Damit wird kontrolliert, welche Erweiterungen der File Daemon laden darf.

Die Director-Ressource autorisiert bareos-dir mit einem eigenen zufälligen Secret. Dasselbe Secret muss in der Client-Ressource auf dem Director hinterlegt sein. Es gehört in eine Secret-Verwaltung und wird hier nur als Platzhalter gezeigt. Aktuelle Bareos-Versionen verwenden bei dieser Konstellation TLS-PSK; der reale Lauf handelte TLS 1.3 mit CHACHA20-POLY1305 aus.

sudoedit /etc/bareos/bareos-fd.d/client/myself.conf


Client {
  Name = client01-fd
  FD Address = 192.168.77.11
  Plugin Names = ""
}


sudoedit /etc/bareos/bareos-fd.d/director/bareos-dir.conf


Director {
  Name = bareos-dir
  Password = "<SECRET_FROM_SECRET_MANAGEMENT>"
}

3. Client-Ressource auf dem Director anlegen

Der Director benötigt das Gegenstück zur File-Daemon-Konfiguration. Name, Adresse und Secret müssen exakt zusammenpassen. Verwenden Sie eine auflösbare interne Adresse oder eine feste private IP und vermeiden Sie localhost für entfernte Clients.

sudoedit /etc/bareos/bareos-dir.d/client/client01-fd.conf


Client {
  Name = client01-fd
  Address = 192.168.77.11
  Password = "<SAME_SECRET_AS_ON_CLIENT>"
  Maximum Concurrent Jobs = 5
}

4. Ein begrenztes FileSet definieren

Für die erste Abnahme wird nicht sofort das gesamte System gesichert. Ein kleines, kontrolliertes Verzeichnis macht sichtbar, welche Dateien erwartet werden, und reduziert das Risiko eines falsch gesetzten Include-Pfads. ACL- und Extended-Attribute-Unterstützung werden ausdrücklich aktiviert.

sudo install -d -m 0755 /srv/bareos-test/subdirectory
printf "%s\n" "ForgeOne Bareos client onboarding test" | sudo tee /srv/bareos-test/README.txt


sudoedit /etc/bareos/bareos-dir.d/fileset/client01-test.conf


FileSet {
  Name = "client01-test"
  Include {
    Options {
      Signature = XXH128
      Acl Support = yes
      Xattr Support = yes
    }
    File = /srv/bareos-test
  }
}

5. Backup-Job mit bestehendem JobDefs verbinden

Der Job verwendet die geprüfte Paketressource DefaultJob und überschreibt Client, FileSet und Full-Pool. Dadurch bleiben gemeinsame Einstellungen an einer Stelle, während der konkrete Schutzumfang lesbar bleibt. Ein produktiver Zeitplan wird erst nach Festlegung von RPO, Wartungsfenster und Retention aktiviert.

sudoedit /etc/bareos/bareos-dir.d/job/backup-client01.conf


Job {
  Name = "backup-client01"
  JobDefs = "DefaultJob"
  Client = "client01-fd"
  FileSet = "client01-test"
  Pool = "Full"
}

6. Beide Konfigurationen vor dem Neustart prüfen

Prüfen Sie zuerst den File Daemon und anschließend den Director. Ein Dienst darf nur mit fehlerfreier Konfiguration neu gestartet oder geladen werden. Deprecated-Warnungen sind ebenfalls zu bereinigen; im Lab wurde eine veraltete File-Daemon-Direktive entfernt, bevor die Abnahme fortgesetzt wurde.

sudo bareos-fd -t
sudo systemctl restart bareos-filedaemon
systemctl is-active bareos-filedaemon


# Auf dem Director
sudo -u bareos bareos-dir -t
sudo systemctl reload bareos-director

7. Verbindung und Auswahl mit bconsole prüfen

status client beweist Authentifizierung, Protokoll und Erreichbarkeit. estimate lässt den Client das FileSet auswerten, ohne bereits einen Backup-Job zu schreiben. Im Lab meldete der Client Bareos 25.1.2 auf Debian 13; die Verbindung nutzte Immediate TLS mit TLS 1.3. Die Schätzung ergab fünf Dateisystemeinträge und 135 Byte Nutzdaten.

sudo -u bareos bconsole
status client=client01-fd
estimate job=backup-client01 level=Full
quit

8. Full-Backup ausführen und Ergebnis lesen

Der erste Full-Job wurde interaktiv und ohne produktive Daten gestartet. Bareos legte das Volume Full-0001 an, schrieb fünf Einträge und beendete File Daemon und Storage Daemon jeweils mit Status OK. Die Jobtabelle zeigt Status T für Terminated successfully.

Ein erfolgreicher Backup-Job beweist noch keine Wiederherstellbarkeit. Er bestätigt aber den vollständigen Pfad Director zu Client, Client zu Storage und Storage zum Catalog. Der nächste Serienteil führt deshalb einen isolierten Restore mit Inhalts- und Metadatenvergleich durch.

sudo -u bareos bconsole
run job=backup-client01 level=Full yes
wait
messages
list jobs client=client01-fd last
quit

Typische Fehler systematisch eingrenzen

Authentication failed weist meist auf abweichende Ressourcennamen oder Secrets hin. Connection refused spricht eher für einen inaktiven File Daemon, eine falsche Bind-Adresse oder eine Firewall-Regel. Ein erfolgreicher Director-Kontakt bei scheiterndem Job kann auf den separaten Datenpfad zum Storage Daemon hinweisen.

  • Name und Password in Director- und File-Daemon-Ressource zeichengetreu vergleichen.
  • Mit ss prüfen, ob der File Daemon auf der erwarteten privaten Adresse und Port 9102 lauscht.
  • Namensauflösung und Routing von Director zum Client sowie vom Client zum Storage getrennt testen.
  • bareos-fd -t und bareos-dir -t ausführen, bevor Logs interpretiert werden.
  • Director-, File-Daemon- und Storage-Meldungen anhand derselben Job-ID zusammenführen.
  • Keine TLS-Warnung durch Abschalten der Verschlüsselung umgehen; Vertrauens- und Namensproblem beheben.
https://bareos01.example.test/bareos-webui/client/details?client=client01-fd
https://bareos01.example.test/bareos-webui/job/details/2
https://bareos01.example.test/bareos-webui/job/details/2
bareos01.example.test

Technische Abnahme des Client-Onboardings

Diese Abnahme bestätigt Installation, Authentifizierung und einen real ausgeführten Full-Backup-Job. Ein Restore wird bewusst erst nach seinem eigenen Test als bestanden markiert.

  • File Daemon und Director verwenden eindeutige, übereinstimmende Ressourcennamen.
  • Das Client-Secret liegt nicht im Artikel oder Repository und ist auf beiden Seiten identisch.
  • Der File Daemon bindet an die dokumentierte private Adresse 192.168.77.11:9102.
  • bareos-fd -t und bareos-dir -t laufen ohne Fehler oder Deprecated-Warnungen.
  • status client bestätigt Immediate TLS und TLS 1.3.
  • estimate bestätigt fünf ausgewählte Einträge und 135 Byte im Test-FileSet.
  • Full-Job 2 endet mit Status Success beziehungsweise T, null Fehlern und Volume Full-0001.
  • Desktop- und Mobile-Ansicht der realen WebUI wurden mit Playwright ohne Console-Fehler geprüft.
  • Noch offen und nicht behauptet: Restore, produktiver Zeitplan, Retention, Offsite und Disaster Recovery.