theHacker's Blog
– It's just a glitch in the Matrix –
2

Bareos – Einrichtung einer neuen Backup-Lösung

Meine bisherige Backup-Lösung ging immer davon aus, dass alle wichtigen Daten auf einem zentralen Storage liegen, den man nur backupen muss – ein Hoch auf Synology-NAS-Systeme.

Seit ich nun einen VMware ESXi-Host betreibe und mit diesem zusätzliche Maschinen mit Daten kommen, funktioniert dieser Backup-Ansatz nicht mehr. Es musste somit eine neue Lösung her, die auch von mehreren Maschinen automatisch Backups macht.

In diesem Blog-Eintrag habe ich schrittweise notiert, wie die Einrichtung vorwärts ging. 

Vorab für Nachmacher: Nicht alles, was hier steht, ist in Stein gemeißelt. Ich hab nach dem Blog-Eintrag sicherlich noch einige Einstellungen geändert und weiterprobiert 😉

Backup-Software

Bacula

Die Nummer 1 an open-source Backup-Lösungen, die man hier kennt, ist Bacula.

Zuerst ein paar Worte zu Bacula, wer es nicht kennt. Bacula arbeitet mit einer Server/Client-Architektur. Die zu sichernden Rechner sind die Clients. Auf Server-Seite gibt es den Storage-Daemon, dessen Aufgabe es ist, Daten abzuspeichern bzw. wiederherzustellen. Und da gibt es noch den Director-Daemon, der alle Fäden hält; er kümmert sich um die Zeitplanung der Aufgaben, leitet Backups und Wiederherstellung ein und vermittelt Storage-Daemon und File-Daemon. Letzterer ist der Prozess, der auf den Clients läuft und somit die zu sicherenden Daten an den Storage-Daemon übermittelt.

Grundsätzlich schreibt Bacula die Backups auf Bandlaufwerke, man kann ihn aber auch so konfigurieren, dass er „einfache“ Dateien schreibt. Bandlaufwerke können nur sequentiell gelesen/geschrieben werden, also nicht so wie eine Festplatte, wo man einfach eine x-beliebige Datei rauspicken kann. Um einen Überblick zu haben, welche Datei von welchem Backup sich wo auf welchem Band befindet, hält Bacula den sogenannten „Katalog“. Das ist eine relationalle Datenbank, die diese Informationen alle enthält.

Bareos

Ich hatte einige Zeit mit Bacula rumprobiert, als ich dann später gesehen hab, dass es einen Fork des Projekts gibt: Bareos.

Wie üblich bei Open-Source-Software, wenn ein Projekt einen Weg geht, den andere – warum auch immer – nicht mögen, entstehen Forks. Diese Freiheit gibt uns Open-Source und genau deshalb funktioniert das Ganze so gut. So ist es auch mit Bacula passiert: Die Entwickler von Bacula haben immer mehr Funktionalität nur noch in die proprietäre Enterprise-Version gepackt. Patches aus der Community wurden sogar aus diesem Grund komplett abgewiesen. Die freie Version verwaiste langsam.

So entstand 2010 das Projekt Bareos, ein 100%iger Open-Source-Fork von Bacula mit inzwischen sehr vielen neuen Features. Die Entwickler von Bareos verdienen ihre Brötchen mit Support, Backup als Service und Consulting – die Backup-Software ist hingegen absolut frei!

Das war mein Cue, mir Bareos intensiver anzusehen. Da Bareos ein Fork von Bacula ist, ist sämtliche Konfiguration kompatibel. Im Grunde funktioniert alles, was mit Bacula funktioniert hat, auch mit Bareos. Es ist selbst möglich Bacula- und Bareos Server-/Client-Komponenten zu mischen, wenn man nicht die neuen Features von Bareos verwendet.

Installation von Bareos

Installation von Ubuntu

Als Basis für die Bareos-Installation verwende ich ein Ubuntu 16.10 (Server-Edition). ISO-Image herunterladen und booten.

Bei der Einrichtung des Netzwerks verwende ich den Rechnername „bareos“ (sollte gut beschreiben, was die Maschine macht 😉 ).
Der Installer konfiguriert das Netzwerk standardmäßig mittels DHCP. In meinem Fall will ich das nicht, da ich alle meine Server mit statischen IPs versehe. Im Netzwerk ist allerdings ein DHCP-Server da, drum werde ich gar nicht gefragt. Nach der Installation muss die Netzwerk-Konfiguration deshalb von Hand nachträglich noch angepasst werden.

Bei der Festplatten-Partitionierung einfach „gesamte Platte verwenden“ wählen. LVM kostet nix. In meinem Setup wird auf der Bareos-Maschine selber sowieso nix gespeichert, d. h. die einzigen Komponenten, die Speicher brauchen, sind Ubuntu und Bareos, sonst brauchen wir nix.

Bei der Frage, welche Software-Pakete installiert werden sollen, wähle ich „Open-SSH-Server“ und „Standard-Systemwerkzeuge“. Ersteres erlaubt mir, bequem mit SSH zu arbeiten. Letzteres is nie verkehrt, um ein wenig Bequemlichkeit auf die Konsole zu bringen (z. B. noch intelligentere Auto-Completion auf der Bash, um nur einen Pluspunkt zu nennen).

Nachdem die Installation abgeschlossen ist, wie obig erwähnt, hab ich die Netzwerkkonfiguration geändert: Hierzu in der /etc/network/interfaces das dhcp streichen und durch static und die entsprechenden Angaben (siehe Screenshot) ergänzen. Außerdem hab ich in der /etc/resolvconf/resolv.conf.d/base noch die Angabe search thehacker.local gemacht, um das DNS-Suffix einzustellen.

Am Ende einmal rebooten und gucken, ob alles soweit geht. Ab sofort geht es dann per SSH weiter.

Installation der Datenbank

Wie eingangs erwähnt, benötigt Bareos einen Katalog, den er in einer relationallen Datenbank abspeichert. Wir können hierfür eine PostgreSQL-, eine SQLite- oder eine MySQL-Datenbank nehmen. Ich verwende eine MariaDB. (Die is doch gar nicht gelistet!?) MariaDB ist ein Fork von MySQL und wird von Bareos sogar gegenüber der MySQL empfohlen. Hintergrund: In MySQL 5.7 gab es inkompatible Änderungen, weswegen es sowieso nicht funktioniert (Quelle).

apt install mariadb-server

Wir installieren die Datenbank bevor wir Bareos installieren. Das hat den Vorteil, dass das Installations-Script von Bareos bereits eine laufende MariaDB vorfindet und uns damit Arbeit abnimmt.

Installation von Bareos

Bareos ist in den offiziellen Paketen von Ubuntu bereits enthalten. Ich verwende aber bewusst die Bareos-Quellen, um

  • aktuellere Versionen zu haben und
  • die Web-Oberfläche zu kriegen (die fehlt in der Ubuntu-Distribution).
echo "deb http://download.bareos.org/bareos/release/latest/xUbuntu_16.04/ /" > /etc/apt/sources.list.d/bareos.list
wget http://download.bareos.org/bareos/release/latest/xUbuntu_16.04/Release.key -O - | apt-key add -

Anmerkung: Wie man sieht, sind die Bareos-Quellen für ein Ubuntu 16.04, ich hab aber ein 16.10 – geht trotzdem ohne Probleme.

Nicht vergessen, den Schlüssel herunterzuladen und einzuspielen, sonst weigert sich apt von der Bareos-Quelle zu installieren.

So, nun kommt die eigentliche Installation:

apt update
apt install bareos-director bareos-storage bareos-filedaemon bareos-database-mysql bareos-bconsole bareos-webui

Es gibt auch Meta-Packages, die Director, Storage und Client enthalten. Problem hierbei, dass das Meta-Package den Tray-Monitor installiert, den ich nicht haben will. Der Tray-Monitor ist für Client-Systeme da, damit man per System-Tray-Symbol den Backup-Status sieht. Das brauch ich nicht und auf der Server-Maschine schon gar nicht, weil es dort keine grafische Oberfläche gibt, die irgendwer bedient.

Mit den obigen Installationskandidaten installiert uns apt mittels der Abhängigkeiten automatisch einen Apache2-HTTP-Server mit PHP (für die Web-Oberfläche) und einen Postfix-SMTP-Server (um Rückmeldungen von Bareos per Mail verschicken zu können). Bei der Postfix-Installation wird man einige Sachen gefragt. Bei der Frage nach der Verwendung wählen wir „nur lokal“ aus. Der System-E-Mail-Name sollte schon korrekt vorausgefüllt sein.

Bei der Einrichtung der Datenbank kommt es uns jetzt gelegen, dass die MariaDB schon läuft. Mit der Antwort „Ja“, ob bareos-database-common mit dbconfig-common konfiguriert werden soll, funktioniert nun alles. (Ohne das hätten wir die DB selber von Hand einrichten müssen.) Zum Schluss noch ein Datenbank-Passwort ausdenken. Der Installer legt einen MariaDB-User bareos mit diesem Passwort an.

So, nun haben wir bereits alles, was wir brauchen. Unter http://bareos/bareos-webui/ ist bereits die Web-Oberfläche zu sehen (auch wenn man noch nicht reinkommt).

Einrichtung von Bareos

Im Gegensatz zu Bacula hat Bareos nicht nur eine Konfigurationsdatei pro Service, sondern erlaubt beliebig viele Konfigurationsdateien mit flexibler Verzeichnisstruktur. In der Default-Konfiguration befinden sich alle Konfigurationselemente einzeln im jeweiligen Unterordner (s. Screenshot).

Verzeichnisstruktur der Bareos-Konfigurationsdateien

Diese Anordnung ist zwar wesentlich besser, als die Bacula-Anordnung, allerdings möchte ich nicht jedes Konfigurationslement einzeln haben, sondern Elemente, die zum selben Client gehören, auch zusammen in einer Datei stehen haben. Mit der Default-Anordnung hätte man die Informationen „Wer ist zu sichern?“ (Client), „Was ist zu sichern?“ (FileSet) und „Wann ist zu sichern?“ (Job bzw. Schedule) in lauter einzelnen Dateien in unterschiedlichen Verzeichnissen rumliegen.

Ich möchte pro Client eine Datei haben, die alle diese Informationen enthält. Nur gemeinsame Elemente, wie gemeinsame FileSets oder Zeitpläne in den vorgegebenen Ordnern.

Einrichtung des Directors

Anmerkung: Ich erkläre im Folgenden nicht, wie die Konfiguration funktioniert und was die Direktiven bedeuten. Infos hierzu im fickenden Handbuch von Bareos. (Vielleicht mach ich ja mal einen extra Beitrag hierzu)

Pools

Standardmäßig sind verschiedene Pools für Increment-, Differential- und Full-Backups festgelegt. Ich will aber nur einen Pool, also leg ich mir einen „Standard“-Pool an und lösch die anderen.

Info: Irgendwo hab ich ne Warnung gelesen, dass man besser Leerdateien zurücklassen soll, weil bei einem Update von Baroes gelöschte Dateien sonst wiederkommen. Da ich keine „toten“ Dateien mag, probier ich das mit dem Weglöschen einfach mal aus und guck, was passiert.

Vorsicht, wenn man als root neue Dateien anlegt, dass man sie dem bareos-Nutzer zuordnet, sondern gibts „Zugriff verweigert“-Fehler.

chown bareos: TäglichNachts.conf

FileSets

Die Defaults gefallen mir so gar nicht, deshalb hab ich den ganzen Ordner entfernt. Im Moment gehe ich davon aus, dass jeder Client sein eigenes FileSet bekommt.

Jobs

Jobs gehen auch in den entsprechenden Client-Eintrag. Der Default-Eintrag für Bareos selber geht also mit dem Catalog-Job und seinem FileSet in den Client-Eintrag. In den Defaults sind zwei Jobs vorgesehen (einer für /etc/bareos und einer für den Katalog), die ich aber zu einem zusammengeführt hab.*)

Den RestoreFiles-Job lass ich in dem Ordner, weil er (eigentlich – steht zwar auch bareos-fd drin, aber who cares) client-los ist.

Den Default-JobDef schiebe ich in den Jobs-Ordner und eliminiere den jobdef-Ordner.

*) Während ich grade an diesem Blog-Eintrag schreibe, fällt mir auf, dass es eigentlich besser ist, den Katalog immer separat zu speichern. Der Katalog wird standardmäßig immer am Ende der Backups gesichert. Es ist sinnvoll, dass die Katalog-Daten für eine Sicherung von /etc/bareos bei einer Sicherung des Katalogs mit dabei sind. – muss ich später gleich mal ändern 🙂

Bezeichner

Ein allgemeines Wort zu den Bezeichnern: Ich persönlich mag es einheitlich. Im Default ist ein Misch-Masch von Kleinbuchstaben+Minus (xxxx-xxxx) und Camel-Case (XxxxXxxx) vertreten. Das Handbuch empfiehlt, die Suffixe -dir, -sd und -fd zu haben (Quelle). Die Elemente Schedules, FileSets und Jobs sind aber mit Camel-Case benannt.

Ich hab mich deshalb dazu entschieden, einheitlich Kleinbuchstaben+Minus zu verwenden. Bestehende Defaults in Camel-Case-Benennung benenne ich alle um.

Monitor-Zugänge entfernen

Im Default sind Monitor-Zugänge für alle Daemons enthalten. Diese verwendet der Tray-Monitor, damit der Benutzer bequem per Klicki-Bunti nur-lesend sich über den Status von Bareos informieren kann. Ich brauche diese Zusatzzugänge nicht und entferne deshalb die entsprechenden Konfigurationsdateien.

Einrichtung des Storage-Daemons

Standardmäßig verwendet der Storage-Deamon den lokalen Pfad /var/lib/bareos/storage. Wie eingangs erwähnt, ist die Festplatte der Bareos-Maschine nicht für die Speicherung der Backups vorgesehen. Der Platz reicht nicht mal, um einen Rechner zu sichern. Ich will über Mount auf den Backup-Storage meiner Synology-NAS schreiben.

Hierzu erstmal NFS-Support installieren:

apt install nfs-common

Danach wird die Device-Direktive in der Konfiguration des Storage-Daemons angepasst.

Das Feld Archive Device ist ein Pflichtfeld und stehtmittels der Variable %a für den Mountbefehl zur Verfügung. Mein erster Versuch war deshalb als Mountbefehl /bin/mount -t nfs %a %m zu hinterlegen. Allerdings funktioniert das so nicht, da nur Root den Mountbefehl mit Optionen nutzen kann. Ich musste deshalb einen zusätzlichen Eintrag in die /etc/fstab machen und dabei die Option user nutzen, damit der bareos-User den Mount ausführen darf.

Arbeiten tut Bareos mit dem Archive Device, also muss dieser Wert am Ende mit dem Mount-Point übereinstimmen.

Die überarbeitete Device-Direktive sieht dann so aus:

Device {
  Name = mount-athena
  Media Type = file-on-athena
  Device Type = file
  Archive Device = /mnt/athena-backup

  LabelMedia = yes;
  Random Access = yes;
  AutomaticMount = yes;
  RemovableMedia = no;

  Requires Mount = yes
  Mount Point = /mnt/athena-backup
  Mount Command = "/bin/mount %m"
  Unmount Command = "/bin/umount %m"
}

Am Director müssen die geänderten Werte für Media Type und Device Type übernommen werden:

Storage {
  Name = bareos-sd
  ...
  Device = mount-athena
  Media Type = file-on-athena
}

Damit wär die Einrichtung fertig.

Konfiguration testen

Bevor’s los geht kann man die Konfiguration testen, ohne die Dienste zu starten. Hierzu haben alle Daemons die Option -t.

su bareos -s /bin/sh -c "bareos-dir -t"
su bareos -s /bin/sh -c "bareos-sd -t"
bareos-fd -t
bconsole -t

Der File-Daemon und die Konsole werden als root getestet, der Director und der Storage als der bareos-User. Funktioniert zu diesem Zeitpunkt was nicht, wird man informiert. Typische Fehler sind Syntaxfehler in der Konfiguration oder Verweise zu Elementen, die nicht existieren/falsch geschrieben sind.

Ist alles ok, fahren wir die Dienste hoch bzw. restarten sie:

service bareos-storage start
service bareos-director start
service bareos-filedaemon restart

Erstes Backup anstoßen

Über die Konsole überprüfen wir, dass wir Verbindung zum Director erhalten und stoßen ein Backup an.

root@bareos:~# bconsole
Connecting to Director localhost:9101
1000 OK: bareos-dir Version: 16.2.4 (01 July 2016)
Enter a period to cancel a command.
*run job=backup-bareos-fd
Using Catalog "catalog-bareos"
Run Backup job
JobName:  backup-bareos-fd
Level:    Full
Client:   bareos-fd
Format:   Native
FileSet:  fileset-bareos-fd
Pool:     pool-default (From Job FullPool override)
Storage:  file (From Job resource)
When:     2017-04-08 18:24:45
Priority: 11
OK to run? (yes/mod/no): yes
Job queued. JobId=2
*messages
08-Apr 18:24 bareos-dir JobId 2: shell command: run BeforeJob "/usr/lib/bareos/scripts/make_catalog_backup.pl catalog-bareos"
08-Apr 18:24 bareos-dir JobId 2: Start Backup JobId 2, Job=backup-bareos-fd.2017-04-08_18.24.47_04
08-Apr 18:24 bareos-dir JobId 2: Created new Volume "Standard-Backup-0001" in catalog.
08-Apr 18:24 bareos-dir JobId 2: Using Device "local-file-storage" to write.
08-Apr 18:24 bareos-sd JobId 2: Labeled new Volume "Standard-Backup-0001" on device "local-file-storage" (/var/lib/bareos/storage).
08-Apr 18:24 bareos-sd JobId 2: Wrote label to prelabeled Volume "Standard-Backup-0001" on device "local-file-storage" (/var/lib/bareos/storage)
08-Apr 18:24 bareos-sd JobId 2: Elapsed time=00:00:01, Transfer rate=48.54 K Bytes/second
08-Apr 18:24 bareos-dir JobId 2: Bareos bareos-dir 16.2.4 (01Jul16):
  Build OS:               x86_64-pc-linux-gnu ubuntu Ubuntu 16.04 LTS
  JobId:                  2
  Job:                    backup-bareos-fd.2017-04-08_18.24.47_04
  Backup Level:           Full
  Client:                 "bareos-fd" 16.2.4 (01Jul16) x86_64-pc-linux-gnu,ubuntu,Ubuntu 16.04 LTS,xUbuntu_16.04,x86_64
  FileSet:                "fileset-bareos-fd" 2017-04-08 18:22:12
  Pool:                   "pool-default" (From Job FullPool override)
  Catalog:                "catalog-bareos" (From Client resource)
  Storage:                "file" (From Job resource)
  Scheduled time:         08-Apr-2017 18:24:45
  Start time:             08-Apr-2017 18:24:49
  End time:               08-Apr-2017 18:24:49
  Elapsed time:           0 secs
  Priority:               11
  FD Files Written:       52
  SD Files Written:       52
  FD Bytes Written:       42,568 (42.56 KB)
  SD Bytes Written:       48,542 (48.54 KB)
  Rate:                   0.0 KB/s
  Software Compression:   None
  VSS:                    no
  Encryption:             no
  Accurate:               no
  Volume name(s):         Standard-Backup-0001
  Volume Session Id:      1
  Volume Session Time:    1491668315
  Last Volume Bytes:      50,445 (50.44 KB)
  Non-fatal FD errors:    0
  SD Errors:              0
  FD termination status:  OK
  SD termination status:  OK
  Termination:            Backup OK

08-Apr 18:24 bareos-dir JobId 2: shell command: run AfterJob "/usr/lib/bareos/scripts/delete_catalog_backup"

„Backup OK“. Sehr gut.

(Anmerkung: Dieser Blog-Beitrag vereinfacht meine Versuche etwas. Die obige Ausgabe stammt noch aus der Zeit, wo ich kein Netzwerk-Mount da war. Beim Lesen also bitte nicht wundern, wenn als Zielpfad da was von /var/lib/bareos/storage steht.)

Steuerung von einem externen Rechner

Da die Steuerung über die Konsole nicht besonders konfortabel ist, installieren wir uns auf einem Desktop-Rechner das Paket bareos-bat. Alles, was wir tun müssen, ist die IP-Adresse und das Passwort des Directors in die Konfiguration einzutragen:

#
# Bareos Administration Tool (bat) configuration file
#
Director {
  Name = bareos-dir
  DIRport = 9101
  address = bareos.thehacker.local
  Password = "..."
}

Starten wir die Anwendung, verbindet sich das Bareos-Admin-Tool („BAT“) zum Director und wir können alle Informationen einsehen bzw. Aufträge anstoßen. Im Screenshot ist das zuvor durchgeführte Backup zu sehen.

bat – Ansicht eines Mediums

Web-Admin gangbar machen

Wir erinnern uns an den Screenshot mit dem Bareos-Web-UI direkt nach der Installation. Nun machen wir diese Benutzeroberfläche gangbar. Vorteil gegenüber BAT ist, dass hierfür nix installiert werden muss, sondern dass diese UI direkt auf dem Bareos-Server läuft.

Zugang einrichten

Damit wir uns in die Bareos-WebUI einloggen können, müssen wir noch einen Zugang einrichten. Die Dummy-Datei bareos-dir.d/console/admin.conf.example muss hierzu ausgefüllt werden. Wichtig ist, die Dateiendung umbenennen, da .example ignoriert wird; Dateien müssen auf .conf enden!

service bareos-dir reload

Interessant: Bash completiert die Dienste jeweils als bareos-dir und bareos-director. Ein Start geht mit beiden Formen, ein Reload nur mit der (eigentlich korrekten) Kurzform.

URL anpassen

Unter der Root-URL erreichen wir aktuell die Dummy-Seite vom Apache. Das Bareos-UI ist unter /bareos-webui zu erreichen. Um das zu beheben, verändern wir die Konfigurationsdatei /etc/apache2/conf-available/bareos-webui.conf, die Bareos installiert hat.

  • DocumentRoot statt Alias
  • RewriteBase weg

Default-Site deaktivieren und Konfiguration neu einlesen:

a2dissite 000-default
service apache2 reload

… und fertig!

Einen weiteren Client hinzufügen

Zum Schluss nun einen weiteren Client konfigurieren. Hierzu auf dem zu sicherenden Rechner das Paket bareos-filedaemon installieren und die Konfiguration anpassen.

Hier mach ich mir nicht die Mühe mit den Bareos-Quellen, sondern installier einfach nur die Distibutionsquelle. Entsprechend gibts hier auch nun keinen bareos-fd.d/-Ordner, sondern nur eine einfache bareos-fd.conf (weil die Distribution von der Version hinterherhinkt).

Wie auf dem Server auch schon, entfern ich die Konfiguration für den Monitor. Ich hab BAT und Web-UI, da brauch ich kein Tray-Symbol.

Info: Bareos hat keine Probleme mit verschiedenen Client-Versionen. Wichtig ist nur, dass Director und Storage von der Version immer zusammenpassen.

Hilfsmittel: Datenbank bereinigen

Am Anfang läuft natürlich nicht alles wie am Schnürchen läuft und der Katalog wird durch fehlerhafte Backups und gelöschte Objekte vermüllt. Wenn am Ende alles läuft, möchte man diesen Müll loswerden und frisch starten.

Das nachfolgende Script entfernt alle Spuren von unseren Versuchen; löscht lokal-gemachte Backups (also bevor NFS-Storage eingerichtet war), löscht die gesamte Datenbank und baut einen neuen leeren Katalog auf.

service bareos-dir stop
service bareos-sd stop
service bareos-fd stop
rm -r /var/lib/bareos/storage
rm /var/lib/bareos/*
/usr/lib/bareos/scripts/drop_bareos_database
/usr/lib/bareos/scripts/create_bareos_database
/usr/lib/bareos/scripts/make_bareos_tables
/usr/lib/bareos/scripts/grant_bareos_privileges
service bareos-dir start
service bareos-sd start
service bareos-fd start

Info: grant_bareos_privileges is bei mir gescheitert, es scheint aber trotzdem alles zu funktionieren.

Um auf den Clients jeglichen gespeicherten Zustand zu entfernen:

sudo service bareos-fd stop
sudo rm -r /var/lib/bareos/*.state
sudo service bareos-fd start

Soviel von meiner Bareos-Einrichtung.

Wenn du es bis hierhin durchgehalten hat, danke für Lesen. Gerne auch einen Kommentar hinterlassen, wenn dir dieser Beitrag geholfen hat 🙂

17. April 2017

Kommentare zu diesem Artikel

  • Gerne lasse ich einen Kommentar 🙂 erst mal vielen vielen dank 🙂 wäre schön wenn du zeigen könntest wie man externe clients sichert ? oder habe ich da was falsch verstanden..

    als test habe ich bareos auf einen VM und ich möchte den
    server sichern mit der VM sichern wie könnte ich das realisieren ?

    ich bin absolut einen Anfänger .

    • (Sorry, für die späte Antwort)

      Normalerweise baut der File-Daemon (= zu sichernden Client) eine Verbindung zum Storage-Daemon auf.
      Wenn dein Client im Internet liegt, kommt er natürlich nicht so einfach durch die heimische Firewall (Fritz!Box etc.) durch.
      Bareos hat hierzu ein Passive-Flag, was du in deiner Konfiguration des Clients einfach auf yes setzen kannst, um die Verbindungsrichtung umzudrehen.

      Client {
        ...
        Passive = yes
      }
      

      Du findest mehr Infos dazu im Bareos-Handbuch unter „29.2 Passive Client“. (Ein bisschen Geduld mit dem Link, das Handbuch braucht immer ne Weile, um komplett zu laden)

Schreib einen Kommentar hierzu

Deine eMail-Adresse wird nicht veröffentlicht.