ubuntuusers.de

Heyho Leute,

vielleicht kann mir hier einer helfen, bzw. hat eine Idee. Ich bin im Moment dran Bareos (Fork von Bacula) in einer Dockerumgebung ans Laufen zu bringen. Habe aber leider mit beidem noch nicht sooo viel gearbeitet (mit Bareos gar nicht, mit Docker ist's schon etwas her...).

Folgender Aufbau: Da mein Testgerät (mein Win Tower @ home) hinter NAT liegt und sich meine öffentliche IP ständig ändert, habe ich auf dem Zielserver einen VPN Server im Container installiert und verbinde mich mit diesem. Hierzu habe ich einfach dieses Dockerimage genommen: https://hub.docker.com/r/hwdsl2/ipsec-vpn-server/ Die Verbindung klappt super. Für den Bareos-FD auf dem Client habe ich dem Container noch die Option --expose=9102 hinzugefügt.

Für die eigentliche Bareos-Infrastruktur nahm ich einfachheitshalber dieses Image: https://hub.docker.com/r/barcus/bareos-director/. Nach kleinen Zickereien, klappt auch dieses. Nur wenn ich versuche das Backup initial einmal zu starten, passiert -fast- nix. Wieso fast? Nun, warum auch immer geht auf dem Client nach dem Ausführen von run in der bconsole die GPU-Last auf gut 15%. Sobald der Backupversuch als "Fehlgeschlagen" betitelt wird, geht diese wieder herunter auf 0-3%.

Die Directormeldungen:

2018-06-07 17:58:22 bareos-dir JobId 12: Error: Bareos bareos-dir 17.2.4 (21Sep17):
  Build OS:               x86_64-pc-linux-gnu ubuntu Ubuntu 16.04 LTS
  JobId:                  12
  Job:                    backup-flos-desktop.2018-06-07_17.55.08_50
  Backup Level:           Full (upgraded from Incremental)
  Client:                 "flos-desktop-fd" 
  FileSet:                "windows" 2018-06-07 14:16:08
  Pool:                   "Full" (From Job FullPool override)
  Catalog:                "MyCatalog" (From Client resource)
  Storage:                "File" (From Job resource)
  Scheduled time:         07-Jun-2018 17:55:05
  Start time:             07-Jun-2018 17:55:10
  End time:               07-Jun-2018 17:58:22
  Elapsed time:           3 mins 12 secs
  Priority:               10
  FD Files Written:       0
  SD Files Written:       0
  FD Bytes Written:       0 (0 B)
  SD Bytes Written:       0 (0 B)
  Rate:                   0.0 KB/s
  Software Compression:   None
  VSS:                    no
  Encryption:             no
  Accurate:               no
  Volume name(s):         
  Volume Session Id:      12
  Volume Session Time:    1528374789
  Last Volume Bytes:      0 (0 B)
  Non-fatal FD errors:    1
  SD Errors:              0
  FD termination status:  Error
  SD termination status:  Waiting on FD
  FD  Secure Erase Cmd:   
  Termination:            *** Backup Error ***

2018-06-07 17:58:22 bareos-dir JobId 12: Fatal error: No Job status returned from FD.
2018-06-07 17:58:21 bareos-dir JobId 12: Fatal error: Failed to connect to client "flos-desktop-fd".
2018-06-07 17:58:21 bareos-dir JobId 12: Fatal error: bsock_tcp.c:134 Unable to connect to Client: flos-desktop-fd on 192.168.42.10:9102. ERR=Interrupted system call
2018-06-07 17:58:11 bareos-dir JobId 12: Warning: bsock_tcp.c:128 Could not connect to Client: flos-desktop-fd on 192.168.42.10:9102. ERR=Interrupted system call
Retrying ...
2018-06-07 17:55:11 bareos-dir JobId 12: Using Device "FileStorage" to write.
2018-06-07 17:55:10 bareos-dir JobId 12: Start Backup JobId 12, Job=backup-flos-desktop.2018-06-07_17.55.08_50
2018-06-07 17:55:08 bareos-dir JobId 12: No prior or suitable Full backup found in catalog. Doing FULL backup.
2018-06-07 17:55:08 bareos-dir JobId 12: No prior Full backup Job record found.

client.conf

Client {
 Name = flos-desktop-fd
 Description = "Mein Rechner zu Hause."
 Address = 192.168.42.10
 Password = "PASSWORT"
}

job.conf

Job {
  Name = "backup-flos-desktop"
  JobDefs = "windows"
  FileSet = "windows"
  Client = "flos-desktop-fd"
}

jobdefs.conf

JobDefs {
  Name = "windows"
  Type = Backup
  Level = Incremental
  Client = bareos-fd
  FileSet = "windows"                     
  Schedule = "WeeklyCycle"
  Storage = File
  Messages = Standard
  Pool = Incremental
  Priority = 10
  Write Bootstrap = "/var/lib/bareos/%c.bsr"
  Full Backup Pool = Full                  # write Full Backups into "Full" Pool         (#05)
  Differential Backup Pool = Differential  # write Diff Backups into "Differential" Pool (#08)
  Incremental Backup Pool = Incremental    # write Incr Backups into "Incremental" Pool  (#11)
}

fileset.conf

FileSet {
  Name = "windows"
  Enable VSS = yes
  Include {
    Options {
      Signature = MD5
      Drive Type = fixed
      IgnoreCase = yes
      WildFile = "[A-Z]:/pagefile.sys"
      WildDir = "[A-Z]:/RECYCLER"
      WildDir = "[A-Z]:/$RECYCLE.BIN"
      WildDir = "[A-Z]:/System Volume Information"
      Exclude = yes
    }
    File = "C:/Users/Florian/Desktop"
  }
}

Wäre super, wenn einer für mich einen kleinen Tipp hätte ☺

Grüße nessor

Hallo

Dein Bareos-Director kann keine Verbindung zu deinem Client herstellen

Failed to connect to client "flos-desktop-fd".

Hast du das Passwort aus der Client.conf (Bareos-Director) auch beim Client (flos-desktop-fd) in der bareos-dir.conf eingetragen. Welche Bareos Version (Director und Client) verwendest du denn.

Die Verbindung kannst du am besten mit der bconsole testen mit

status client=flos-desktop-fd

Gruß cflinux

Hey cflinux,

danke erstmal für Deine Antwort! Ja, dass die Verbindung nicht klappt, ist denke ich echt das Problem. Status sagt nämlich auch nur

Connecting to Client flos-desktop-fd at 192.168.42.10:9102
Failed to connect to Client flos-desktop-fd.
====

cflinux schrieb:

Hast du das Passwort aus der Client.conf (Bareos-Director) auch beim Client (flos-desktop-fd) in der bareos-dir.conf eingetragen. Welche Bareos Version (Director und Client) verwendest du denn.

Mh?? Ist es nicht so, dass alle Aktionen vom Direktor ausgehen? Also dass dieser sich beim FD "flos-desktop-fd" meldet? Das Passwort vom FD steht in der Client.conf vom Director drin, ja ☺

Ich könnte mir sehr gut vorstellen, dass irgendwie die Kommunikation unterhalb der Dockercontainer nicht klappt. Ich weiß aber ehrlich gesagt nicht, was ich mehr als --expose=9102 machen soll?

Gruß, nessor

EDIT: Versionen vergessen:

• FD auf Client 12.4.6

• Director: 17.2.4

Hallo

Die beiden Passwörter dienen zur Authentifizierung von Client und Director.

Bei deinem Client steht noch alles in einer Datei im Verzeichnis /etc/bareos/bareos-fd.d/ in dieser Datei gibt es einen Abschnitt für den Director, dort findest du auch einen Parameter Password.

von der Version 15 zu Version 16 wurde Datei Struktur geändert und alles in eigen Ordner und Dateien aufgeteilt.

Gruß cflinux

cflinux schrieb:

Hallo

Die beiden Passwörter dienen zur Authentifizierung von Client und Director.

Bei deinem Client steht noch alles in einer Datei im Verzeichnis /etc/bareos/bareos-fd.d/ in dieser Datei gibt es einen Abschnitt für den Director, dort findest du auch einen Parameter Password.

von der Version 15 zu Version 16 wurde Datei Struktur geändert und alles in eigen Ordner und Dateien aufgeteilt.

Gruß cflinux

Ja genau, das meinte ich. Dieses Passwort ist im Director (Ordner Clients) hinterlegt.

Hallo

Das mit den Passwörtern, hab ich total überlesen, ja ja wer lesen kann ist klar im Vorteil.

Da ich mich mit Docker nicht auskenne Frage ich mal für was die Option gut ist --expose=9102, wenn diese Option einen Port öffnet dann musst du auch noch die Ports 9101 und die Ports 9103 öffnen, die werden nämlich auch benötigt.

Bei den Address Optionen im Bareos verwendest du auch Hostnamen oder nur IP-Adressen? Wenn du auch Hostnamen verwendest musst du darauf achten, das sie von einem DNS-Server aufgelöst werden.

Gruß cflinux

cflinux schrieb:

Hallo

Das mit den Passwörtern, hab ich total überlesen, ja ja wer lesen kann ist klar im Vorteil.

Da ich mich mit Docker nicht auskenne Frage ich mal für was die Option gut ist --expose=9102, wenn diese Option einen Port öffnet dann musst du auch noch die Ports 9101 und die Ports 9103 öffnen, die werden nämlich auch benötigt.

Bei den Address Optionen im Bareos verwendest du auch Hostnamen oder nur IP-Adressen? Wenn du auch Hostnamen verwendest musst du darauf achten, das sie von einem DNS-Server aufgelöst werden.

Gruß cflinux

Hey,

ja, expose gibt den Port frei. Wenn 9101 und 9103 auch benötigt werden, versuche ich mal 9101-9103 freizugeben

Bei den Address Optionen benutze ist ausschließlich die IPs. Keine Hostnamen.

Gruß, nessor

Hallo,

wie startest du denn die Container? Mit docker run?

Wenn sich die Container finden sollen ist es einfacher, diese mit docker-compose oder docker stack deploy zu starten und sie in einem docker-compose-file zu definieren. Dann macht docker die Namensauflösung der Services untereinander.

▶ https://forum.ubuntuusers.de/topic/docker-netzwerk-dockercontainer-vernetzen/

Falls zu docker noch was unklar ist ,einfach hier nochmal melden.

Viele Grüße

BillMaier

BillMaier schrieb:

Hallo,

wie startest du denn die Container? Mit docker run?

Wenn sich die Container finden sollen ist es einfacher, diese mit docker-compose oder docker stack deploy zu starten und sie in einem docker-compose-file zu definieren. Dann macht docker die Namensauflösung der Services untereinander.

▶ https://forum.ubuntuusers.de/topic/docker-netzwerk-dockercontainer-vernetzen/

Falls zu docker noch was unklar ist ,einfach hier nochmal melden.

Viele Grüße

BillMaier

Hey BillMaier,

die Bareos Umgebung starte ich über Docker compose, den VPN Container über "run". Verstehe ich das richtig, dass wenn ich den VPN Container mit in das docker-compose.yml file schreibe, dass dieser automatisch jeglichen Zugriff auf die anderen Container bekommt? Hatte das nämlich eigentlich vor, finde ich dann aber doch etwas risky.

Gruß, nessor

Inwiefern? Der VPN-Container muss ja "irgendwie" Zugriff auf den Bareos haben. Oder wie soll das sonst funktionieren?

Gruß BillMaier

BillMaier schrieb:

Inwiefern? Der VPN-Container muss ja "irgendwie" Zugriff auf den Bareos haben. Oder wie soll das sonst funktionieren?

Gruß BillMaier

Ja klar. Durch Liebe und Hoffnung passiert da wahrscheinlich nix 😀 Meine nur, dass ich dann nur die Ports 9101-9103 freigebe.

Gruß

nessor schrieb:

BillMaier schrieb:

Inwiefern? Der VPN-Container muss ja "irgendwie" Zugriff auf den Bareos haben. Oder wie soll das sonst funktionieren?

Gruß BillMaier

Ja klar. Durch Liebe und Hoffnung passiert da wahrscheinlich nix 😀 Meine nur, dass ich dann nur die Ports 9101-9103 freigebe.

Wie definierst du "frei gebe"?

expose gibt die Ports nur innerhalb des Containers frei, bzw. für die Services, die du in docker-compose definiert hast (weil die alle im gleichen Netzwerk stehen).

Wenn du einen weiteren Container via run startest, wandert der in ein eigenes Netzwerk - abgeschieden vom ersten. (Das kannst du dir via docker container inspect anschauen)

Wenn du die via ports (als Portmapping) frei gibst, dann funktioniert der Zugriff auch über den Host mit den Ports. Wenn der Host im Internet hängt und keine Firewall davor steht, willst du das nicht haben.

Gruß BillMaier

BillMaier schrieb:

nessor schrieb:

BillMaier schrieb:

Inwiefern? Der VPN-Container muss ja "irgendwie" Zugriff auf den Bareos haben. Oder wie soll das sonst funktionieren?

Gruß BillMaier

Ja klar. Durch Liebe und Hoffnung passiert da wahrscheinlich nix 😀 Meine nur, dass ich dann nur die Ports 9101-9103 freigebe.

Wie definierst du "frei gebe"?

expose gibt die Ports nur innerhalb des Containers frei, bzw. für die Services, die du in docker-compose definiert hast (weil die alle im gleichen Netzwerk stehen).

Wenn du einen weiteren Container via run startest, wandert der in ein eigenes Netzwerk - abgeschieden vom ersten. (Das kannst du dir via docker container inspect anschauen)

Wenn du die via ports (als Portmapping) frei gibst, dann funktioniert der Zugriff auch über den Host mit den Ports. Wenn der Host im Internet hängt und keine Firewall davor steht, willst du das nicht haben.

Gruß BillMaier

Okay verstanden. Das hat mich schon mal weitergebracht!

Also erstelle ich ein Netzwerk über docker network create [NAME] und hänge da den VPN Container (wenn ich ihn über "run" starte) mittels --network="[NAME]" rein. Wenn ich jetzt die Ports über --expose freigebe, sind die dann nur für die Container offen, welche sich im identischen Netzwerk befinden -richtig?

Gruß nessor

Warum jetzt nicht beide einfach in das compose-file? Dann sparst du dir den ganzen "Schnassel".

nessor schrieb:

Wenn ich jetzt die Ports über --expose freigebe, sind die dann nur für die Container offen, welche sich im identischen Netzwerk befinden -richtig?

korrekt. Ggf. sind die Ports auch schon im Image bzw. Dockerfile definiert, dann musst du gar nichts machen.