Why architecture must be clarified before installation

Bareos is not a single backup application but a set of clearly separated services. The Director controls jobs, the File Daemon reads or writes data on a client, the Storage Daemon manages backup media, and the PostgreSQL catalog stores metadata about jobs, volumes and protected files.

This separation supports distributed and heterogeneous environments. It also means that names, network paths, permissions, storage and recovery objectives must fit together before packages are installed. This first part therefore connects the system model with an installation executed in a real lab.

Tested lab environment and goal of this part

The following steps were executed in an isolated lab on 17 October 2026. bareos01.example.test runs Debian 13.4 and hosts the Director, Storage Daemon, local File Daemon, PostgreSQL catalog, bconsole and WebUI. client01.example.test remains available as a separate Debian host for the next part. Both systems communicate over a private lab network.

The lab installed community build 25.1.2~pre49.d5742f640 from the official current repository for Debian 13. The current channel can change. Before a production rollout, verify the offered version, the required support channel and target-platform approval.

  • bareos01.example.test: Debian 13.4, 4 vCPU, 6 GB RAM, Director, Storage, File Daemon, catalog and WebUI.
  • client01.example.test: Debian 13.4, 2 vCPU, 3 GB RAM, retained for later client integration.
  • Private lab network: 192.168.77.0/24; no production systems or data.
  • Evidence: package versions, daemon configuration tests, systemd state, bconsole and WebUI were actually checked.

Supported platforms and transparent validation status

Bareos provides distribution-specific packages. The repository name must match the distribution and major release. Community packages from the rolling current channel are not equivalent to a maintained subscription repository; production environments require an explicit support model, release policy and upgrade path.

Only Debian 13.4 was practically tested for this guide. The other paths were reviewed on 17 October 2026 against official Bareos documentation and the current repository index. They guide controlled testing but do not claim production validation.

  • Debian 13.4: Bareos Community current / Debian_13; tested in the ForgeOne lab. Server, PostgreSQL catalog, WebUI, daemons and configuration checks executed in the ForgeOne lab.
  • Ubuntu 24.04 LTS: Bareos Community current / xUbuntu_24.04; reviewed against official documentation. Official repository and package path available; not practically validated in the ForgeOne lab.
  • RHEL 9: Matching RHEL subscription repository; reviewed against official documentation. Do not treat RHEL and EL repositories as interchangeable; verify access and target release before rollout.
  • Rocky Linux 9 / AlmaLinux 9: Bareos Community current / EL_9; reviewed against official documentation. Official EL package path documented; not practically validated in the ForgeOne lab.
  • SLES 15 / openSUSE Leap 15: Bareos Community current / SUSE_15 or matching subscription repository; reviewed against official documentation. Official repository and zypper path documented; validate distribution-specific WebUI/PHP-FPM integration.

Select and inspect the repository safely

First choose Community current, a pinned subscription release, or next for an isolated lab only. next does not belong in production. Download the add_bareos_repositories.sh file matching the target without root privileges, inspect it, and only then execute the approved local copy.

The script configures signed package sources. Subscription credentials may be stored in package-manager configuration; keep those files out of logs, screenshots and repositories. Record the repository URL, resolved Bareos package version and signature verification in the technical acceptance record.

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

Install on Debian and Ubuntu

Debian and Ubuntu use APT but different repository paths. Debian 13 uses Debian_13, while Ubuntu 24.04 uses xUbuntu_24.04. Check the live index before each installation because current is continuously updated.

The bareos metapackage installs the central components. On distributed systems, install only the Director, Storage Daemon, File Daemon, bconsole and PostgreSQL integration assigned to each host. The WebUI also requires a working web-server and PHP-FPM path.

DIST_REPO=Debian_13 # for 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

Install on RHEL

Bareos documentation distinguishes RHEL repositories from EL repositories for compatible derivatives. A genuine RHEL host requires the matching approved RHEL repository; an EL_ path must not be treated as evidence of RHEL support merely because the packages may be technically similar.

Confirm subscription access, the RHEL major release, SELinux policy and PHP-FPM before rollout. After repository setup, DNF installs either the metapackage or deliberately selected components. This path was not practically executed for this guide.

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

Install on Rocky Linux and AlmaLinux

Rocky Linux and AlmaLinux use the official EL_ package path. EL_9 is the matching family for release 9; do not mix major releases. Initialize and start PostgreSQL according to the distribution before running the Bareos catalog scripts.

Also validate Firewalld, SELinux and the RPM service names bareos-dir, bareos-sd and bareos-fd. The commands follow the official installation model but are not presented as a successful ForgeOne lab run.

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

Install on SLES and openSUSE

Bareos groups SLES and openSUSE in SUSE_ repositories. SUSE_15 covers the version 15 family; inspect the current repository index for other major releases. In subscription deployments, credentials and release pinning must be handled separately from the public Community channel.

Install with Zypper, then verify PostgreSQL, Apache or PHP-FPM and the RPM service names. AppArmor, file permissions and WebUI configuration belong in acceptance testing. This path was documentation-reviewed but not executed in the ForgeOne lab.

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

Initialize the catalog and start distribution-specific services

The PostgreSQL catalog is mandatory on every platform. Debian can use dbconfig-common; other platforms prepare the database, tables and privileges with the Bareos scripts. Never run initialization scripts blindly against a catalog already in use.

Debian-family packages typically use bareos-director, bareos-storage and bareos-filedaemon. RPM-family packages use bareos-dir, bareos-sd and bareos-fd. This difference matters for systemd, monitoring and runbooks.

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

Accept the first backup and restore run

Running services do not prove that backups work. Use an approved test path, start a full job, verify job and volume state, and restore into a separate destination. Compare content, ownership, permissions, timestamps and, where applicable, ACLs and extended attributes.

The external full backup on Debian 13 is practically evidenced in part two. A complete restore run and the RPM/SUSE paths have not yet been practically validated for this expanded candidate. The cross-distribution guide must therefore not be called fully tested until that evidence exists.

sudo -u bareos bconsole
run job=<TEST_JOB> level=Full yes
wait
list jobs job=<TEST_JOB> last
restore
# Select the test backup and set a separate Where destination
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, permissions and hardening

Use unambiguous resource names, separate secrets and only the required network paths. Protect Director, Storage and File Daemon communication according to the deployed Bareos version. Console profiles and WebUI accounts receive minimum privileges; repository credentials and daemon secrets stay out of public configuration.

Harden operations with distribution-appropriate SELinux or AppArmor policy, restrictive file permissions, firewall rules, documented secret rotation and protected catalog/configuration data. Encryption does not replace restore testing or a separate offsite design.

Monitoring, troubleshooting and Ansible automation

Monitor job state, runtime, data volume, last successful backup, failed restores, catalog growth, volume state and free storage capacity. Daemon logs, bconsole messages and PostgreSQL must be time-correlatable. Alert on missing jobs, not only stopped processes.

Ansible automation should cover repository selection, packages, resources, secrets, configuration checks and controlled reloads. Keep distribution variables separate from shared Bareos resources and run handlers only after successful syntax validation. A dedicated, practically validated Ansible part remains open and is not pre-empted here.

1. Prepare the operating system and add the official repository

Start with an updated Debian host, working name resolution and a stable system identity. The repository installer requires CA certificates, curl and GnuPG. Save the download under a fixed filename and inspect it before running it with root privileges.

The commands below match the successful lab run. In controlled environments, review the downloaded script and the generated source definition before continuing.

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. Install Bareos, WebUI and PostgreSQL

The bareos metapackage installs the central daemons and command-line tools. bareos-webui adds browser-based administration, while PostgreSQL provides the catalog. The lab validated every relevant service after package installation instead of treating a successful package transaction as sufficient evidence.

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. Initialize the PostgreSQL catalog

The catalog is not an optional convenience. It connects jobs, volumes and file metadata and must be included in backup and recovery planning. The packaged scripts create the database, tables and permissions. Run them only when the database has not already been initialized.

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. Understand configuration paths and ownership

Packaged configuration lives below /etc/bareos. Director resources are stored in /etc/bareos/bareos-dir.d, Storage resources in /etc/bareos/bareos-sd.d and File Daemon resources in /etc/bareos/bareos-fd.d. Console connectivity is configured through /etc/bareos/bconsole.conf and matching Director console resources.

WebUI configuration is below /etc/bareos-webui; Apache and PHP-FPM integration use their package paths below /etc/apache2 and /etc/php. Add custom resources in the intended directories, keep names unambiguous and validate each daemon before restart.

  • /etc/bareos/bareos-dir.d: clients, jobs, FileSets, schedules, pools, storage and console resources.
  • /etc/bareos/bareos-sd.d: Storage Daemon, devices and messages.
  • /etc/bareos/bareos-fd.d: local File Daemon and Director permissions.
  • /etc/bareos/bconsole.conf: text-console connection to the Director.
  • /etc/bareos-webui: WebUI-specific Director and application parameters.
  • /var/lib/bareos: runtime and working data; backup volumes require deliberately planned storage.

5. Configure WebUI access and start services

The WebUI does not authenticate directly against PostgreSQL. It uses a named Director console resource. Use a dedicated strong password from secret management and a matching WebUI profile. The value used in the lab is not published.

After enabling Apache, PHP-FPM and the Bareos services, the WebUI was reachable. Login and the authenticated dashboard were also verified with Playwright at desktop and mobile viewports.

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

The central Bareos components

The Director is the control plane. It knows clients, jobs, FileSets, schedules, pools and storage resources. It schedules backups and restores but does not store the backup payload itself.

The File Daemon runs on the protected system. During backup it reads the data selected by the FileSet and sends it to the Storage Daemon. During restore it receives the data and writes it to the approved destination.

The Storage Daemon accepts data streams, writes them to volumes on disk, tape or appropriately integrated storage targets and reads them for restores. The PostgreSQL catalog stores the metadata required to find them. bconsole and the optional WebUI are interfaces to the Director.

  • Director: schedule jobs, connect resources and coordinate backup and restore operations.
  • File Daemon: read data and file attributes on the protected system or restore them.
  • Storage Daemon: write backup data to volumes and provide it for restores.
  • PostgreSQL catalog: keep jobs, files, volumes and run history searchable.
  • bconsole and WebUI: operate the Director; they replace neither catalog nor storage.

How control and payload data flow

The Director starts a job and provides the participating services with the required job information. Backup payload flows from the File Daemon to the Storage Daemon. Status and file metadata are recorded in the catalog. During recovery, the Director uses the catalog to locate the required volumes and coordinates the reverse data path.

This distinction matters for firewall rules and troubleshooting: a reachable Director does not prove that File Daemon and Storage Daemon can communicate. Likewise, a volume without an intact and protected catalog has limited operational value.

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

Five decisions before the first production job

Do not begin with an arbitrary example job. First document the systems to protect, the relevant data classes and the recovery objectives. Architecture and capacity follow from these facts more reliably than from one generic retention value.

  • Protection scope: inventory hosts, file systems, databases and applications with accountable owners.
  • RPO and RTO: define tolerable data loss and recovery duration for each data class.
  • Storage and offsite: plan capacity, growth, media, a separate failure domain and immutable copies.
  • Retention: derive full, differential and incremental cycles from business requirements.
  • Restore evidence: define test objects, target systems, frequency and acceptance records before go-live.

Network, identities and encryption

Bareos resources authenticate using matching names and credentials. Store these values in managed secret storage, never in public repositories. The official documentation describes TLS for Director, File Daemon, Storage Daemon and Console; current directives and peer verification must match the deployed Bareos version.

Permit only the communication paths that are actually required. Well-known default ports are a starting point, not a complete firewall specification for every topology. In particular, verify the payload path between File Daemon and Storage Daemon and administrative access to console and WebUI.

Keep configuration reviewable and repeatable

Bareos uses separate resources for Director, Storage Daemon, File Daemon and Console. Current installations commonly organize configuration in subdirectories and individual resource files. Treat them as infrastructure code: versioned, reviewed, generated from templates and free of plaintext secrets.

Before reload or restart, let each daemon validate its configuration. The commands below were executed successfully in the lab.

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

Technical acceptance of the base installation

This acceptance confirms a working base but not yet an external client backup or restore. Those tests follow on the same lab systems in later parts.

  • Director, catalog, Storage Daemon and File Daemons are assigned to hosts or operating zones.
  • Control and payload paths document source, destination, port and ownership.
  • Backup capacity, growth, retention and offsite copies have a traceable sizing basis.
  • RPO, RTO and restore test cases are defined for each relevant data class.
  • Secrets, TLS trust and administrative access have defined storage and rotation processes.
  • Catalog, configuration and key material are included in the backup and recovery concept.
  • Director, Storage Daemon, File Daemon, PostgreSQL and Apache are active; the WebUI returns HTTP 200.
  • All four configuration tests and status director through bconsole completed successfully.
  • Desktop login, dashboard and mobile rendering passed Playwright without JavaScript console errors.
  • Deliberately still open: external client, real backup job, restore, retention, offsite and Proxmox disaster recovery.

Where the series goes next

Part 2 connects client01.example.test as a separate File Daemon. Later parts add FileSets and backup jobs, perform a traceable restore, cover retention and storage, monitoring and hardening, and finish with catalog recovery and Proxmox disaster recovery. Every part builds on this retained lab and is called tested only after the procedure was executed with authentic evidence.