Bareos unter Linux installieren und konfigurieren: Debian, Ubuntu, RHEL, Rocky, AlmaLinux und SUSE

Warum die Architektur vor der Installation geklärt werden muss

Bareos ist keine einzelne Backup-Anwendung, sondern ein Zusammenspiel klar getrennter Dienste. Der Director steuert Jobs, der File Daemon liest oder schreibt Daten auf einem Client, der Storage Daemon verwaltet die Backup-Medien und der PostgreSQL-Katalog hält Metadaten zu Jobs, Volumes und gesicherten Dateien vor.

Diese Trennung macht verteilte und heterogene Umgebungen möglich. Sie bedeutet aber auch, dass Namen, Netzwerkpfade, Berechtigungen, Speicher und Wiederherstellungsziele vor der Paketinstallation zusammenpassen müssen. Dieser erste Serienteil verbindet deshalb das Systemmodell direkt mit einer real ausgeführten Basisinstallation.

Getestete Lab-Umgebung und Ziel dieses Teils

Die folgenden Schritte wurden am 17. Oktober 2026 in einem isolierten Lab ausgeführt. bareos01.example.test läuft mit Debian 13.4 und übernimmt Director, Storage Daemon, lokalen File Daemon, PostgreSQL-Katalog, bconsole und WebUI. client01.example.test bleibt als getrenntes Debian-System für den nächsten Teil erhalten. Beide Hosts kommunizieren über ein privates Lab-Netz.

Installiert wurde der Community-Build 25.1.2~pre49.d5742f640 aus dem offiziellen current-Repository für Debian 13. Der current-Kanal kann sich ändern. Prüfen Sie deshalb vor einem produktiven Rollout die angebotene Version, den gewünschten Supportkanal und die Freigabe Ihrer Zielplattform.

bareos01.example.test: Debian 13.4, 4 vCPU, 6 GB RAM, Director, Storage, File Daemon, Catalog und WebUI.
client01.example.test: Debian 13.4, 2 vCPU, 3 GB RAM, vorbereitet für die spätere Client-Anbindung.
Privates Lab-Netz: 192.168.77.0/24; keine produktiven Systeme oder Daten.
Nachweis: Paketstände, Daemon-Konfigurationstests, systemd-Status, bconsole und WebUI wurden tatsächlich geprüft.

Unterstuetzte Plattformen und transparenter Teststatus

Bareos stellt distributionsspezifische Pakete bereit. Der Repository-Name muss zur Distribution und Hauptversion passen. Community-Pakete aus dem current-Kanal sind nicht mit einem gewarteten Subscription-Repository gleichzusetzen; fuer produktive Umgebungen muessen Supportmodell, Releasebindung und Upgradepfad bewusst festgelegt werden.

Nur Debian 13.4 wurde fuer diesen Beitrag praktisch getestet. Die weiteren Wege wurden am 17. Oktober 2026 gegen die offizielle Bareos-Dokumentation und das aktuelle Repository-Verzeichnis geprueft. Sie sind deshalb Orientierung fuer einen kontrollierten Testlauf, aber kein behaupteter Produktionsnachweis.

Debian 13.4: Bareos Community current / Debian_13; im ForgeOne-Lab getestet. Server, PostgreSQL-Katalog, WebUI, Daemons und Konfigurationstests im ForgeOne-Lab ausgefuehrt.
Ubuntu 24.04 LTS: Bareos Community current / xUbuntu_24.04; anhand offizieller Dokumentation geprueft. Repository und Paketweg offiziell vorhanden; nicht im ForgeOne-Lab praktisch validiert.
RHEL 9: Passendes RHEL-Subscription-Repository; anhand offizieller Dokumentation geprueft. RHEL- und EL-Repositories nicht gleichsetzen; Zugang und Zielrelease vor dem Rollout pruefen.
Rocky Linux 9 / AlmaLinux 9: Bareos Community current / EL_9; anhand offizieller Dokumentation geprueft. Offizieller EL-Paketweg dokumentiert; nicht im ForgeOne-Lab praktisch validiert.
SLES 15 / openSUSE Leap 15: Bareos Community current / SUSE_15 oder passendes Subscription-Repository; anhand offizieller Dokumentation geprueft. Repository und zypper-Paketweg offiziell dokumentiert; WebUI/PHP-FPM distributionstypisch pruefen.

Repository sicher auswaehlen und pruefen

Waehlen Sie zuerst Community current, einen fest gebundenen Subscription-Release oder next fuer ein reines Lab. next gehoert nicht in produktive Systeme. Laden Sie das zum Zielsystem passende add_bareos_repositories.sh ohne Root-Rechte, lesen Sie es und fuehren Sie erst danach die freigegebene lokale Kopie aus.

Das Skript richtet signierte Paketquellen ein. Bei Subscription-Repositories koennen Zugangsdaten in Paketmanager-Konfigurationen landen; diese Dateien duerfen nicht in Logs, Screenshots oder Repositories gelangen. Dokumentieren Sie Repository-URL, Bareos-Paketversion und Fingerprint beziehungsweise Signaturpruefung in der technischen Abnahme.

curl -fsSLo /tmp/add_bareos_repositories.sh "<OFFICIAL_REPOSITORY_URL>/add_bareos_repositories.sh"
less /tmp/add_bareos_repositories.sh
sha256sum /tmp/add_bareos_repositories.sh
sudo sh /tmp/add_bareos_repositories.sh

Installation unter Debian und Ubuntu

Debian und Ubuntu verwenden APT, aber unterschiedliche Repository-Pfade. Fuer Debian 13 lautet der Community-Pfad Debian_13; Ubuntu 24.04 verwendet xUbuntu_24.04. Pruefen Sie das aktuelle Verzeichnis vor jeder Installation, weil current fortlaufend aktualisiert wird.

Das Metapaket bareos zieht die zentralen Komponenten ein. Auf verteilten Systemen installieren Sie stattdessen nur Director, Storage Daemon, File Daemon, bconsole und PostgreSQL-Integration auf den jeweils vorgesehenen Hosts. Die WebUI benoetigt ausserdem einen funktionierenden Webserver- und PHP-FPM-Pfad.

DIST_REPO=Debian_13 # fuer Ubuntu 24.04: xUbuntu_24.04
curl -fsSLo /tmp/add_bareos_repositories.sh "https://download.bareos.org/current/${DIST_REPO}/add_bareos_repositories.sh"
less /tmp/add_bareos_repositories.sh
sudo sh /tmp/add_bareos_repositories.sh
sudo apt update
sudo apt install bareos bareos-webui postgresql

Installation unter RHEL

Die Bareos-Dokumentation unterscheidet RHEL-Repositories von EL-Repositories fuer kompatible Derivate. Fuer ein echtes RHEL-System ist das passende, freigegebene RHEL-Repository zu verwenden; ein EL_-Pfad darf nicht allein aufgrund technischer Aehnlichkeit als RHEL-Supportnachweis behandelt werden.

Klaeren Sie Subscription-Zugang, RHEL-Hauptversion, SELinux-Policy und PHP-FPM vor dem Rollout. Nach der Repository-Einrichtung installiert DNF das Metapaket oder die bewusst ausgewaehlten Einzelkomponenten. Dieser Pfad wurde fuer den vorliegenden Beitrag nicht praktisch ausgefuehrt.

curl -fsSLo /tmp/add_bareos_repositories.sh "<MATCHING_RHEL_REPOSITORY>/add_bareos_repositories.sh"
less /tmp/add_bareos_repositories.sh
sudo sh /tmp/add_bareos_repositories.sh
sudo dnf install bareos bareos-webui postgresql-server

Installation unter Rocky Linux und AlmaLinux

Rocky Linux und AlmaLinux verwenden den offiziellen EL_-Paketpfad. Fuer Release 9 ist EL_9 die passende Familie; mischen Sie keine Hauptversionen. Initialisieren und starten Sie PostgreSQL nach den Vorgaben der Distribution, bevor Sie die Bareos-Katalogskripte ausfuehren.

Pruefen Sie zusaetzlich Firewalld, SELinux und die RPM-spezifischen Dienstnamen bareos-dir, bareos-sd und bareos-fd. Die folgenden Befehle sind aus der offiziellen Installationslogik abgeleitet, wurden hier aber nicht als erfolgreicher Lab-Lauf ausgegeben.

curl -fsSLo /tmp/add_bareos_repositories.sh https://download.bareos.org/current/EL_9/add_bareos_repositories.sh
less /tmp/add_bareos_repositories.sh
sudo sh /tmp/add_bareos_repositories.sh
sudo dnf install bareos bareos-webui postgresql-server
sudo postgresql-setup --initdb
sudo systemctl enable --now postgresql

Installation unter SLES und openSUSE

Bareos fasst SLES und openSUSE in SUSE_-Repositories zusammen. SUSE_15 deckt die 15er-Familie ab; fuer andere Hauptversionen muss das aktuelle Repository-Verzeichnis geprueft werden. Bei einem Subscription-Einsatz sind Zugangsdaten und Releasebindung getrennt vom oeffentlichen Community-Kanal zu behandeln.

Installieren Sie mit Zypper und pruefen Sie anschliessend PostgreSQL, Apache beziehungsweise PHP-FPM und die RPM-Dienstnamen. AppArmor, Dateirechte und WebUI-Konfiguration sind Teil der Abnahme. Dieser Pfad ist dokumentationsgeprueft, aber noch nicht im ForgeOne-Lab ausgefuehrt.

curl -fsSLo /tmp/add_bareos_repositories.sh https://download.bareos.org/current/SUSE_15/add_bareos_repositories.sh
less /tmp/add_bareos_repositories.sh
sudo sh /tmp/add_bareos_repositories.sh
sudo zypper refresh
sudo zypper install bareos bareos-webui postgresql-server

Katalog und Dienste distributionsspezifisch starten

Der PostgreSQL-Katalog bleibt auf allen Plattformen verpflichtend. Debian kann dbconfig-common nutzen; auf anderen Plattformen werden Datenbank, Tabellen und Rechte mit den Bareos-Skripten vorbereitet. Fuehren Sie Initialisierungsskripte nie blind gegen einen bereits verwendeten Katalog aus.

Debian-basierte Pakete verwenden typischerweise bareos-director, bareos-storage und bareos-filedaemon. RPM-basierte Pakete verwenden bareos-dir, bareos-sd und bareos-fd. Diese Differenz ist fuer systemd, Monitoring und Runbooks relevant.

sudo -u postgres /usr/lib/bareos/scripts/create_bareos_database
sudo -u postgres /usr/lib/bareos/scripts/make_bareos_tables
sudo -u postgres /usr/lib/bareos/scripts/grant_bareos_privileges

# Debian/Ubuntu
sudo systemctl enable --now bareos-director bareos-storage bareos-filedaemon

# RHEL/EL/SUSE
sudo systemctl enable --now bareos-dir bareos-sd bareos-fd

Ersten Backup- und Restore-Lauf kontrolliert abnehmen

Ein erfolgreicher Dienststart ist noch kein Backup-Nachweis. Verwenden Sie einen freigegebenen Testpfad, starten Sie einen Full-Job, pruefen Sie Jobstatus und Volume und stellen Sie die Daten in ein getrenntes Restore-Ziel wieder her. Vergleichen Sie danach Inhalt, Eigentum, Rechte, Zeitstempel sowie gegebenenfalls ACLs und Extended Attributes.

Der externe Full-Backup-Job auf Debian 13 ist im zweiten Serienteil praktisch nachgewiesen. Ein vollstaendiger Restore-Lauf und die RPM-/SUSE-Pfade sind fuer diesen erweiterten Kandidaten noch nicht praktisch validiert. Deshalb darf der distributionsuebergreifende Artikel erst nach diesem Nachweis als vollstaendig getestet bezeichnet werden.

sudo -u bareos bconsole
run job=<TEST_JOB> level=Full yes
wait
list jobs job=<TEST_JOB> last
restore
# Test-Backup auswaehlen und getrenntes Where-Ziel festlegen
run
wait
messages
quit

find <RESTORE_TARGET> -printf "%M %u:%g %TY-%Tm-%TdT%TH:%TM:%TS %p\n"
getfacl -R <RESTORE_TARGET>
getfattr -R -d <RESTORE_TARGET>

TLS, Berechtigungen und Hardening

Verwenden Sie eindeutige Ressourcennamen, getrennte Secrets und nur die notwendigen Netzwerkpfade. Schuetzen Sie Director-, Storage- und File-Daemon-Kommunikation gemaess der eingesetzten Bareos-Version. Console-Profile und WebUI-Zugaenge erhalten minimale Rechte; Repository-Zugangsdaten und Daemon-Secrets bleiben ausserhalb oeffentlicher Konfigurationen.

Haerten Sie den Betrieb distributionsgerecht mit SELinux oder AppArmor, restriktiven Dateirechten, Firewall-Regeln, protokollierter Secret-Rotation und gesicherten Katalog-/Konfigurationsdaten. Verschluesselung ersetzt keinen Restore-Test und kein getrenntes Offsite-Konzept.

Monitoring, Fehleranalyse und Automatisierung mit Ansible

Ueberwachen Sie Jobstatus, Laufzeit, Datenmenge, letzte erfolgreiche Sicherung, fehlgeschlagene Restores, Catalog-Wachstum, Volume-Zustand und freie Storage-Kapazitaet. Daemon-Logs, bconsole-Meldungen und PostgreSQL muessen zeitlich korrelierbar sein. Alarmieren Sie auf ausbleibende Jobs statt nur auf gestoppte Prozesse.

Automatisierung mit Ansible sollte Repository-Auswahl, Pakete, Ressourcen, Secrets, Konfigurationstests und kontrollierte Reloads abbilden. Trennen Sie Distributionsvariablen von gemeinsamen Bareos-Ressourcen und lassen Sie Handler nur nach erfolgreicher Syntaxpruefung laufen. Ein eigener, praktisch validierter Ansible-Teil ist noch offen und wird hier nicht vorweggenommen.

1. Betriebssystem vorbereiten und offizielles Repository einbinden

Starten Sie mit einem aktualisierten Debian-System, funktionierender Namensauflösung und einer festen Systemidentität. Für den Repository-Installer werden CA-Zertifikate, curl und GnuPG benötigt. Der Download wird bewusst unter einem festen Dateinamen gespeichert, bevor das Skript mit Root-Rechten ausgeführt wird.

Prüfen Sie das heruntergeladene Skript und die erzeugte Source-Datei in kontrollierten Umgebungen vor der Ausführung. Die folgenden Befehle entsprechen dem erfolgreich ausgeführten Lab-Lauf.

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
grep -ER '^URIs|^Suites|^Components' /etc/apt/sources.list.d/bareos.sources

2. Bareos, WebUI und PostgreSQL installieren

Das Metapaket bareos installiert die zentralen Daemons und Werkzeuge. bareos-webui ergänzt die browserbasierte Bedienung; PostgreSQL stellt den Katalog bereit. Im Lab wurde nicht nur auf erfolgreiche Paketinstallation geprüft, sondern anschließend jeder relevante Dienst separat validiert.

sudo apt-get update
sudo env DEBIAN_FRONTEND=noninteractive apt-get install -y bareos bareos-webui postgresql
dpkg-query -W 'bareos*' 'postgresql*' 'apache2*' 'php*-fpm' | sort

3. PostgreSQL-Katalog initialisieren

Der Catalog ist kein optionales Komfortmerkmal. Er verbindet Jobs, Volumes und Dateimetadaten und muss selbst in Backup- und Recovery-Pläne aufgenommen werden. Die mitgelieferten Skripte erzeugen Datenbank, Tabellen und Berechtigungen. Führen Sie sie nur bei einer noch nicht initialisierten Datenbank aus.

sudo -u postgres /usr/lib/bareos/scripts/create_bareos_database
sudo -u postgres /usr/lib/bareos/scripts/make_bareos_tables
sudo -u postgres /usr/lib/bareos/scripts/grant_bareos_privileges
sudo -u postgres psql -d bareos -c "SELECT count(*) FROM information_schema.tables WHERE table_schema = 'public';"

4. Konfigurationspfade und Zuständigkeiten verstehen

Die paketierte Konfiguration liegt unter /etc/bareos. Director-Ressourcen befinden sich in /etc/bareos/bareos-dir.d, Storage-Ressourcen in /etc/bareos/bareos-sd.d und die File-Daemon-Konfiguration in /etc/bareos/bareos-fd.d. Console-Zugänge liegen unter /etc/bareos/bconsole.conf beziehungsweise in passenden Console-Ressourcen des Directors.

Die WebUI-Konfiguration liegt unter /etc/bareos-webui; Apache- und PHP-FPM-Einbindung kommen aus den jeweiligen Paketpfaden unter /etc/apache2 und /etc/php. Ändern Sie nicht wahllos generierte oder paketverwaltete Dateien. Legen Sie eigene Ressourcen in den vorgesehenen Unterverzeichnissen ab, halten Sie Namen eindeutig und validieren Sie vor jedem Neustart.

/etc/bareos/bareos-dir.d: Clients, Jobs, FileSets, Schedules, Pools, Storage- und Console-Ressourcen.
/etc/bareos/bareos-sd.d: Storage Daemon, Devices und Messages.
/etc/bareos/bareos-fd.d: lokaler File Daemon und Director-Berechtigungen.
/etc/bareos/bconsole.conf: Verbindung der Textkonsole zum Director.
/etc/bareos-webui: WebUI-spezifische Director- und Anwendungsparameter.
/var/lib/bareos: Laufzeit- und Arbeitsdaten; Backup-Volumes gehören auf bewusst geplanten Storage.

5. WebUI-Zugang einrichten und Dienste starten

Die WebUI meldet sich nicht direkt an PostgreSQL an, sondern verwendet eine benannte Console-Ressource des Directors. Verwenden Sie ein eigenes starkes Passwort aus einer Secret-Verwaltung und ein passendes WebUI-Profil. Der im Lab verwendete Wert wird nicht veröffentlicht.

Nach dem Aktivieren von Apache, PHP-FPM und den Bareos-Diensten war die WebUI erreichbar. Der Login und das authentifizierte Dashboard wurden zusätzlich mit Playwright auf Desktop- und Mobile-Viewport geprüft.

sudo systemctl enable --now postgresql bareos-director bareos-storage bareos-filedaemon apache2
sudo systemctl restart bareos-director apache2
systemctl --no-pager --full status bareos-director bareos-storage bareos-filedaemon postgresql apache2

Die zentralen Bareos-Komponenten

Der Director ist die Steuerungsebene. Er kennt Clients, Jobs, FileSets, Schedules, Pools und Storage-Ressourcen. Er plant Sicherungen und Wiederherstellungen, speichert die Nutzdaten aber nicht selbst.

Der File Daemon läuft auf dem zu sichernden System. Bei einem Backup liest er die im FileSet ausgewählten Daten und überträgt sie zum Storage Daemon. Beim Restore nimmt er die Daten wieder entgegen und schreibt sie an das freigegebene Ziel.

Der Storage Daemon nimmt Datenströme an, schreibt sie in Volumes auf Disk, Tape oder passend angebundene Storage-Ziele und liest sie für Restores wieder aus. Der Catalog in PostgreSQL speichert die dafür benötigten Metadaten. bconsole und optional die WebUI dienen als Bedienoberflächen zum Director.

Director: Jobs planen, Ressourcen verbinden und Backup- sowie Restore-Abläufe koordinieren.
File Daemon: Daten und Dateiattribute auf dem geschützten System lesen beziehungsweise wiederherstellen.
Storage Daemon: Backup-Daten auf Volumes schreiben und für Restores bereitstellen.
PostgreSQL Catalog: Jobs, Dateien, Volumes und Laufhistorie auffindbar halten.
bconsole und WebUI: den Director bedienen; sie ersetzen weder Catalog noch Storage.

So fließen Steuerung und Nutzdaten

Der Director startet einen Job und übermittelt den beteiligten Diensten die notwendigen Jobinformationen. Die eigentlichen Backup-Daten fließen vom File Daemon zum Storage Daemon. Status und Dateimetadaten landen im Catalog. Bei einer Wiederherstellung ermittelt der Director über den Catalog die benötigten Volumes und koordiniert den umgekehrten Datenweg.

Diese Unterscheidung ist für Firewall-Regeln und Fehleranalysen wichtig: Ein erreichbarer Director beweist noch nicht, dass File Daemon und Storage Daemon miteinander arbeiten können. Ebenso ist ein vorhandenes Volume ohne intakten und gesicherten Catalog betrieblich nur eingeschränkt nutzbar.

Administrator -> bconsole/WebUI -> Director
Director <-> PostgreSQL Catalog
Director -> File Daemon
Director -> Storage Daemon
File Daemon ===== backup/restore data ===== Storage Daemon

Fünf Entscheidungen vor dem ersten produktiven Job

Beginnen Sie nicht mit einem zufälligen Beispieljob. Dokumentieren Sie zuerst, welche Systeme geschützt werden, welche Datenklassen existieren und welche Wiederanlaufziele gelten. Daraus folgen Architektur und Kapazität deutlich zuverlässiger als aus einer pauschalen Aufbewahrungszahl.

Schutzumfang: Hosts, Dateisysteme, Datenbanken und Anwendungen mit verantwortlichen Ownern erfassen.
RPO und RTO: maximalen Datenverlust und akzeptable Wiederherstellungsdauer je Datenklasse festlegen.
Storage und Offsite: Kapazität, Wachstum, Medien, getrennte Fehlerdomäne und unveränderbare Kopien planen.
Retention: Full-, Differential- und Incremental-Zyklen sowie Aufbewahrung aus fachlichen Vorgaben ableiten.
Restore-Nachweis: Testobjekte, Zielsystem, Frequenz und dokumentierte Abnahme bereits vor dem Go-live bestimmen.

Netzwerk, Identitäten und Verschlüsselung

Bareos-Ressourcen authentifizieren sich über zueinander passende Namen und Zugangsdaten. Diese Werte gehören in eine verwaltete Secret-Ablage und nicht in öffentliche Repositories. Die offiziellen Unterlagen beschreiben TLS für Director, File Daemon, Storage Daemon und Console; aktuelle Vorgaben und Peer-Prüfung müssen zur eingesetzten Bareos-Version passen.

Erlauben Sie nur die tatsächlich benötigten Kommunikationspfade. Die bekannten Standardports sind ein Ausgangspunkt, aber keine vollständige Firewall-Spezifikation für jede Topologie. Prüfen Sie insbesondere den Datenpfad zwischen File Daemon und Storage Daemon sowie administrative Zugriffe auf Console und WebUI.

Konfiguration prüfbar und wiederholbar halten

Bareos verwendet getrennte Ressourcen für Director, Storage Daemon, File Daemon und Console. In aktuellen Installationen wird die Konfiguration typischerweise in Unterverzeichnisse und einzelne Ressourcendateien gegliedert. Behandeln Sie diese Dateien wie Infrastrukturcode: versioniert, reviewed, aus Templates erzeugt und ohne Klartext-Secrets.

Vor einem Reload oder Neustart sollten die jeweiligen Daemons ihre Konfiguration syntaktisch prüfen. Die folgenden Befehle wurden im Lab erfolgreich ausgeführt.

sudo -u bareos /usr/sbin/bareos-dir -t
sudo -u bareos /usr/sbin/bareos-sd -t
sudo /usr/sbin/bareos-fd -t
sudo -u bareos bconsole -t

Technische Abnahme der Basisinstallation

Diese Abnahme bestätigt die lauffähige Basis, aber noch keinen erfolgreichen Client-Backup- oder Restore-Lauf. Diese Nachweise folgen in den nächsten Teilen auf denselben Lab-Systemen.

Director, Catalog, Storage Daemon und File Daemons sind Hosts oder Betriebszonen zugeordnet.
Steuerungs- und Datenpfade sind mit Quelle, Ziel, Port und Verantwortlichkeit dokumentiert.
Backup-Kapazität, Wachstum, Retention und Offsite-Kopie sind nachvollziehbar dimensioniert.
RPO, RTO und Restore-Testfälle sind pro relevanter Datenklasse festgelegt.
Secrets, TLS-Vertrauen und administrative Zugriffe haben definierte Ablage- und Rotationsprozesse.
Catalog, Konfiguration und Schlüsselmaterial sind Teil des eigenen Sicherungs- und Recovery-Konzepts.
Director, Storage Daemon, File Daemon, PostgreSQL und Apache sind aktiv; die WebUI liefert HTTP 200.
Die vier Konfigurationsprüfungen und status director über bconsole wurden erfolgreich ausgeführt.
Desktop-Login, Dashboard und mobile Darstellung wurden mit Playwright ohne JavaScript-Console-Fehler geprüft.
Noch offen und bewusst nicht behauptet: externer Client, echter Backup-Job, Restore, Retention, Offsite und Proxmox-Disaster-Recovery.

Wie die Serie weitergeht

Teil 2 bindet client01.example.test als getrennten File Daemon ein. Danach folgen FileSets und Backup-Jobs, ein nachvollziehbarer Restore-Test, Retention und Storage, Monitoring und Hardening sowie Catalog-Recovery und eine Disaster-Recovery-Integration mit Proxmox. Alle Teile bauen auf dieser erhaltenen Lab-Umgebung auf und gelten nur mit tatsächlich ausgeführten Tests und authentischer Evidenz als geprüft.