Proxmox Backup Server auf Raspberry Pi installieren

/ 8. September 2023

Ich habe vor kurzem mein Zimaboard zu einem Proxmox Server aufgebaut und der läuft sehr anständig. Problem: Was passiert, wenn das System mal abschmiert oder Daten manipuliert oder gelöscht werden? Korrekt BACKUP-TIME!

Inhalt
show

AKTUALISIERUNG 2025-03-07: Die Anleitung wurde entsprechend neuer Vorgaben korrigiert. Bitte schaut selbst, ob im Github-Repository etwas anders ist. Die Anleitung kann natürlich nur eine Momentaufnahme darstellen. Hinweise gerne in die Kommentare.

Es gibt kein offizielles Image für den Proxmox Backup Server auf dem Raspberry Pi, aber wir können es uns mit der Anleitung und dem Compiler Skript aus dem Github Repository https://github.com/wofferl/proxmox-backup-arm64 von Wofferl installieren.

Dazu benötigen wir einen Raspberry Pi 4 mit am besten 8 GB RAM, minimum 4 GB RAM, mindestens 32 GB Micro-SD-Karte und einen Backup Speicher von entsprechender Größe.
Ich habe hier ein Argon One Gehäuse mit M.2 Anschluss für einer 1 TB M.2 SSD. Die reicht, vor allem da Deduplication angeschaltet ist.

Vorbereitung

Zunächst stellt man die Grundinstallation mit Raspberry Pi OS auf einer SD-Karte und die Aktualisierungen fertig, seht hierzu gerne in den Post Raspberry Pi: Getting Started/Erste Schritte (Raspbian / Raspberry Pi OS) rein.
Achtung!!: Verwendet das 64-Bit Image vom Raspberry Pi OS um die gesamte Performance und den kompletten Speicher verwenden zu können.

Installation und Kompilierung vom Proxmox Backup Server

Kompilierung von PBS

Wenn die Grundinstallation erledigt ist, müssen vorher einige Programme auf dem Pi installiert werden. Führt nachfolgend die Befehle aus:

sudo apt-get install -y --no-install-recommends \
	build-essential curl ca-certificates sudo git lintian fakeroot \
	pkg-config libudev-dev libssl-dev libapt-pkg-dev libclang-dev \
	libpam0g-dev
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs -sSf | sh -s
source ~/.cargo/env

Für die Rust-Installation wählt man dann einfach mit [1] die Standardinstallation aus.

sudo reboot

Nach dem Reboot laden wir nun das Github Repository im Homeverzeichnis in das Unterverzeichnis „pbs“ herunter.

git clone https://github.com/wofferl/proxmox-backup-arm64.git ./pbs/

Anschließend gehen wir in den Ordner „pbs“ und führen die Kompilierung aus.

cd pbs/
./build.sh

Die Kompilierung benötigt dann etwas Zeit und kann auch mal an einem Punkt für mehrere Minuten stehen bleiben. Bei mir hat es um die 2 Stunden gedauert. Wenn die Kompilierung fertig ist, sind all ARM Pakete in dem Ordner „./pbs/packages“ abgelegt.

Download der vorkompilierten Debian-Pakete

Seit kurzem kann man als Alternative die entsprechend vorkompilierten Debian Pakete herunterladen.

Dazu wird dennoch das Github Repository wie bekannt heruntergeladen.

git clone https://github.com/wofferl/proxmox-backup-arm64.git ./pbs/

Anschließend gehen wir in den Ordner „pbs“ und führen einen Download der aktuellen Version für Bullseye aus, 3.2.6-1.
Nach dem alten Stand vom 2023-09-04 ist das Raspberry Pi OS noch nicht auf Bookworm aktualisiert gewesen.

Nach dem Stand vom 2025-09-04 gibt es das Raspberry Pi OS mit Bookworm, somit kann die aktuellste Version heruntergeladen werden.

cd pbs/
./build.sh download=3.2.6-1

Sobald der Download fertig ist, findet man unter „./pbs/packages“ die Debian-Pakete. Man spart sich damit die Zeit für die Kompilierung, muss dann allerdings darauf hoffen, dass die vorgefertigten Debian-Pakete alle in Ordnung sind. Es gab aber bei meinem Test mit einem Raspberry Pi 4, 8 GB RAM keine Probleme.

Installation PBS

Wenn man mit einem der beiden Möglichkeiten die Debian-Pakete in „packages“ hat, gehen wir nun hinein und führen mit dem apt Befehl die Installation der erstellten Debian Pakete aus.

cd packages
sudo apt install \
  ./libjs-extjs_*_all.deb \
  ./libjs-qrcodejs_*_all.deb \
  ./libproxmox-acme-plugins_*_all.deb \
  ./pbs-i18n_*_all.deb \
  ./proxmox-backup-docs_*_all.deb \
  ./proxmox-backup-server_*_arm64.deb \
  ./proxmox-mini-journalreader_*_arm64.deb \
  ./proxmox-widget-toolkit_*_all.deb \
  ./proxmox-termproxy_*_arm64.deb \
  ./pve-xtermjs_*_all.deb
sudo reboot

Nach der Installation und einem weiteren Neustart kann man auf das Webinterface des Proxmox Backup Servers unter https://{IP-des-PI}:8007/ zugreifen. Vorher muss allerdings der Root Anmeldung des PBS noch ein Passwort vergeben werden.

sudo passwd root

Anschließend muss man das neue Passwort eingeben und bestätigen. Anmelden kann man sich dann mit dem Benutzer root und dem entsprechenden selbst ausgesuchten Passwort.

Eine Sache müssen wir nun noch tätigen, zumindest wenn eine zusätzliche SSD verwendet wird. Der Speicher muss formatiert werden.

Mit sudo fdisk -l kann man sich alle vorhandenen Speicher anzeigen:

fdisk -l eine Liste aller Partitionen und Speicher anzeigen lassen.

Wir sehen, dass die 1 TB SSD auf /dev/sda1 hängt. Das ist standardmäßig so, wenn keine weiteren Festplatten im System erkannt werden. Als nächstes wird mit sudo fdisk /dev/sda1 das Partitionierungstool geöffnet.

Mit „d“ könnt ihr die alte Partition löschen – wahrscheinlich NTFS – und mit „n“ könnt ihr eine neue Partition erstellen. Wenn die gesamte Festplatte verwendet werden soll, können alle Defaults bestätigt werden. Mit „w“ werden die Änderungen dann in die Formatierungstabelle geschrieben.

Konfiguration des Proxmox Backup Servers

Backupstorage erstellen und konfigurieren

Nun also können wir zum Webinterface, wie oben beschrieben, und die letzten Einstellungen tätigen.

Als Erstes wird ein Ordner erstellt, wo das Backup-Repository beheimatet sein wird. Dazu geht man auf „Storage/Disks“ und auf den Reiter „Directory“ und klickt auf „Create: Directory“. Dort wählt man dann den entsprechenden Speicher und das Dateisystem ext4 aus und gibt einen entsprechenden Namen ein. Mit „Create“ wird das Verzeichnis erstellt.

Storage in PBS erstellen

Nun geht man auf den erstellten Storage unter „Datastore“ und wählt den Reiter „Prune & GC“ aus. Unter Prune Jobs kann man dann auf den „Add“ Button klicken, wo man nun einstellt, wie lange die Backups erhalten bleiben sollen und wann die Backup-Snapshots wieder entfernt werden können.

Prune Jobs für den Storage einstellen

Die momentane Einstellung bei mir zeigt, dass stündlich geprüft wird, dass nur 10 stündliche Backups, 3 tägliche, 2 wöchentliche und 1 monatliches Backup vorhanden sind. Sollte das die entsprechende Anzahl überschreiten, wird das älteste Backup entfernt.

Mit „Add“ bestätigt man die Einstellung. Prinzipiell kann man die Einstellung auch in dem Backup-Job auf dem Proxmox Virtual Environment Server einstellen. Es wird aber empfohlen, die Einstellung direkt auf dem Backupserver zu konfigurieren, damit währenddessen die Last nicht auf dem Virtualisierungshost liegt.

Wenn man möchte, kann man unter dem Punkt „Verify Jobs“ die Backup-Snapshots überprüfen lassen. Die lasse ich aber bspw. direkt beim Erstellen des Backups prüfen.

Update konfigurieren

Wie ihr euch sicher vorstellen könnt, sind Updates nicht so einfach möglich bei den selbst kompilierten Proxmox Backup Server Paketen. Daher muss man unter „Administration“ und dann im Reiter „Repositories“ die Repository „https://enterprise.proxmox.com/debian/pbs“ deaktivieren.

PBS Update Repository deaktivieren

Ein Update der Software wird wie die Installation durchgeführt. Ihr kompiliert die Software neu oder ladet die neue Version der vorkompilierten Pakete herunter, führt die Paketinstallation durch und die Software wird auf die aktuelle Version gebracht.

Garbage Collection

Als Tipp noch: Führt ab und zu die Garbage Collection unter „Prune & GC“ auf dem PBS aus. Deduplication führt der Backupserver selbstständig aus, allerdings zeigt er beim Datastore den Deduplcation Factor nur ordentlich an, wenn die Routine ab und an mal durchgeführt wird.

Bei mir sind es 22.27 nach 3 Monaten. Das liegt daran, dass die Container relativ ähnlich sind und nicht so viele Änderungen auf den Containern stattfindet. Daher sind die Backups deutlich kleiner. Wie gesagt, mit einem TeraByte kann man sehr lange haushalten.

Deduplikationsfaktor im PBS anzeigen

Backup-Job auf dem Proxmox Virtual Environment Server konfigurieren

Backupspeicher auf dem PVE einrichten

Gleich ist alles soweit für das erste Backup. Zunächst müssen wir allerdings den Datastore vom PBS (Proxmox Backup Server) in den PVE (Proxmox Virtual Environment Server) hinzufügen – diese Abkürzungen. 😀

Dazu gehen wir auf unserem Virtualisierungshost auf Rechenzentrum bzw Datacenter – sorry der PVE ist bei mir auf Deutsch – und klicken auf „Storage“ – warum das jetzt nicht übersetzt ist 😀 . Dort wird per „Hinzufügen“ in der Liste „Proxmox Backup Server“ hinzugefügt. Im Dialogfenster werden nun alle benötigten Daten eingefügt, also Name des Speichers auf dem Host, Anmeldedaten und Name des Datastores (Achtung: Case-Sensitive!).

Hinzufügen des Backupspeichers in PVE

Wie man sieht, benötigt man noch den Fingerabdruck des Backupservers, da wir ein selbstsigniertes Zertifikat verwenden. Dazu wechseln wir kurz wieder auf den PBS und können unter Dashboard auf den Knopf „Show Fingerprint“ klicken. Die entsprechende Zeile kopiert man sich dann raus, trägt sie in das Fenster auf dem Virtualisierungshost ein und klickt anschließend auf „Hinzufügen“.

Fingerprint auf dem PBS anzeigen lassen

Die Verschlüsselung der Backups kann ebenfalls eingestellt werden. Ich habe dies jedoch abgeschaltet gelassen, da das natürlich vor allem mit dem Raspberry Pi auch auf die Leistung und Geschwindigkeit geht.

Backup-Job einrichten

Nun benötigen wir nur noch ein Backup-Job. Dazu gehen wir wieder auf dem PVE unter Rechenzentrum bzw. Datacenter auf Backup und klicken auf „Hinzufügen“.

Backup-Job auf dem PVE erstellen.

Nun geben wir den zuvor erstellen Storage an, wie der Zeitplan aussehen soll – hier */2:00, heißt alle zwei Stunden zu jeder Tageszeit, mittlerweile habe ich allerdings auf */4:00 für alle vier Stunden gestellt – und welche VMs oder Container gesichert werden soll – hier alle. Der Modus gibt an, wie das Backup erstellt werden soll. Wenn der Betrieb nicht gestört werden soll, dann ist Snapshot die beste Wahl, könnte aber selten auch zu kaputten Backups oder auch zu Problemen beim Zusammenführen der Snapshots führen, hatte ich bisher allerdings nicht.

Falls man auf Nummer sicher gehen will, lässt man alle VMs vorher stoppen und herunterfahren und zieht dann die Sicherung. Das bedeutet aber natürlich auch, dass die Dienste für den Zeitpunkt des Backups nicht laufen. Suspend ist wie Pause zu behandeln, die VM wird auf halt gesetzt und der RAM-Speicher in eine Datei geschrieben, bevor das Backup beginnt. Auch hier sind die Dienste während des Backups nicht verfügbar. Nach dem Backup startet die VM allerdings schneller und setzt da an, wo sie pausiert wurde.

Machen wir es kurz, normalerweise ist Snapshot der bestmögliche Modus ohne größere Probleme für ein Backup.

Und fertig ist der Proxmox Backup Server. War gar nicht so schwer.

Verwandte Artikel

19 Gedanken zu “Proxmox Backup Server auf Raspberry Pi installieren”

  2. Damit man auch TFS Nutzen kann muss noch folgendes auf dem Raspberry Pi installiert werden mit Debian 12 Bookworm -> sudo apt install raspberrypi-kernel-headers zfsutils-linux zfs-dkms zfs-zed

    Antworten

    • Hallo Alisha,

      guter Hinweis!
      Ich persönlich würde auf einem PI mit ZFS etwas vorsichtiger agieren. Kann doch recht CPU und RAM heavy sein und PBS ist auch nicht gerade sparsam.

      Antworten

  3. Vielen Dank für die tolle Anleitung! Hat bei mir super geklappt. Jetzt hat der PI eine Verwendung und es läuft ein sparsamer Backup Server.

    Antworten

  4. Danke für die sehr hilfreiche Anleitung!

    Für PBS Version 3.2-7 musste ich bei der Erstellung des Directory jedoch einiges „hinfrickeln“.
    Wie es aussieht, darf die SSD keinerlei Partition haben, sonst wird sie nicht als ‚unused‘ geführt und kann beim Erstellen des Directory nicht ausgewählt werden. Und die (leere) Partition-Table muss vom Type GPT sein, sonst funktioniert das Erstellen des Directory nicht und man bekommt eine Meldung dass das Kommando „sgdisk …“ nicht funktioniert hat – ohne Fehlermeldung.
    Nachdem ich also „fdisk /dev/sda“ und dort das Kommando ‚g‘ für die GPT-Partition-Table und ‚w‘ für das Schreiben der leeren GPT-Partition-Table auf die Platte ausgeführt hatte, lief alles.

    Antworten

  5. Hallo, Danke für die Anleitung. Ich bekomme bei der Installation der Debian Pakete leider folgendes gemeldet:

    Reading package lists… Done
    E: Unsupported file ./pve-xtermjs_*_arm64.deb given on commandline

    Was ist denn falsch gelaufen und kann man das beheben, oder soll ich die Installation ganz neu starten? Ich bin den Weg über das Kompilieren gegangen. Ich habe dennoch auch einen reboot gestartet und versucht ein passwort zu setzen. Dann heisst es:

    sudo: proxmox-backup-manager: command not found

    Antworten

    • Hallo Mörks,

      leider ein wenig spät, aber schau dir mal den Kommentar von Bernhard an. Meine Anleitung ist natürlich auch nur eine Augenblickaufnahme. Wenn sich die Version erhöhen, können sich auch Pakete ändern.

      Antworten

  6. Hallo,
    ich habe mit ./build.sh download=3.2.6-1 alle benötigten Daten heruntergeladen und wollte nun mit
    sudo apt install \
    ./libjs-extjs_*_all.deb \
    ./libjs-qrcodejs_*_all.deb \
    ./libproxmox-acme-plugins_*_all.deb \
    ./pbs-i18n_*_all.deb \
    ./proxmox-backup-docs_*_all.deb \
    ./proxmox-backup-server_*_arm64.deb \
    ./proxmox-mini-journalreader_*_arm64.deb \
    ./proxmox-widget-toolkit_*_all.deb \
    ./pve-xtermjs_*_arm64.deb
    weitermachen.. Leider bekomme ich folgende Meldung: Unsupported file ./pve-xtermjs_*_arm64.deb given on commandline
    Was mache ich verkehrt?
    Das System auf dem PI wurde ordnungsgemäß bis zum angegeben Punkt installiert.
    Über Hilfe würde ich mich freuen.
    Vielen Dank.

    Antworten

  7. Zwei Tipps die mich viel Zeit kosteten:

    Github hat bereits 3.3.2-2 on file, somit funktioniert ./build.sh download=3.3.2-2

    1. Für 3.3.2.-2 lautet das Install Skript wie folgt:
    sudo apt install \
    ./libjs-extjs_7.0.0-5_all.deb \
    ./libjs-qrcodejs_1.20230525-pve1_all.deb \
    ./libproxmox-acme-plugins_1.5.1_all.deb \
    ./pbs-i18n_3.3.2_all.deb \
    ./proxmox-backup-client_3.3.2-2_arm64.deb \
    ./proxmox-backup-docs_3.3.2-2_all.deb \
    ./proxmox-backup-file-restore_3.3.2-2_arm64.deb \
    ./proxmox-backup-server_3.3.2-2_arm64.deb \
    ./proxmox-mini-journalreader_1.4.0_arm64.deb \
    ./proxmox-termproxy_1.0.1_arm64.deb \
    ./proxmox-widget-toolkit_4.3.3_all.deb \
    ./pve-xtermjs_5.3.0-3_all.deb

    2. Mit 3.3 hat sich der Befehl für das Passwort setzen geändert. Änderung erfolgt nun über API
    sudo proxmox-backup-debug api set /access/password –userid someuser@pbs –password „somepassword“

    Ich hoffe das erspart Euch einen halben Nachmittag 😉

    Antworten

    • Hallo Peter,

      in der Theorie würde ich erstmal sagen, sollte man zumindest mal ausprobieren. Ubuntu baut ja auch auf Debian auf. Also ich sehe jetzt erstmal keinen gravierenden Grund. Gemacht habe ich es selbst bisher nicht.

      Antworten

  9. Vielen Dank für den Beitrag. Bei mir funktioniert das Setzen des Passwort für den Root nicht bzw. wird wohl ignoriert:

    sudo proxmox-backup-manager user update root@pam –password PASSWORD

    Die Hilfe sagt auch folgendes:

    –password
    This parameter is ignored, please use ‚PUT /access/password‘ to
    change a user’s password

    Ich habe eine API Token für den Root generiert und versucht über den API Endpoint „/access/password“ das Passwort zu setzen, aber bekomme jetzt folgende Fehlermeldung: „API tokens cannot access this API endpoint“

    Ich konnte mir immerhin schon einen Benutzer für den PBS erstellen und anmelden. Nur wie löse ich jetzt das Thema mit dem Root?

    Antworten

  10. Hallo Zusammen,

    ich habe alles wie beschrieben auf einem RasPi 4 – 4GB installiert. Soweit läuft es auch. Bis zum Hinzufügen des Datastore des PBS in PVE unter dem Punkt „Backup-Job auf dem Proxmox Virtual Environment Server konfigurieren“.
    Sobald ich auf „Hinzufügen“ klicke, wird der Datastore in der PVE hinzugefügt, der PBS aber bricht dauernd weg. In der grafischen Oberfläche lädt er und dann ist die Seite nicht mehr erreichbar. Zwischnezeitlich taucht er immer wieder auf und bricht sofort wieder weg. Per PC kann ich den RasPi dann auch nicht mehr anpingen.

    Das Ganze läuft bei mir auf einem Server: PVE mit pfSense -> VLANs -> managed Switch.
    Der Raspi hängt mit am Switch, da ich so eine externe Backuplösung aufbauen will.
    Entferne ich den Datastore in der PVE, läuft PBS wieder stabil.

    Ich dachte zunächst, dass es an der Installation auf dem RasPi oder einem Defekt an der Festplatte liegen könnte. Deshalb habe ich zum Testen in der PVE eine VM erstellt, PBS dort per ISO installiert und die Festplatte durchgereicht. Die Festplatte habe ich dann auch nochmal durch einen neuen USB-Stick ersetzt um die Platte als Fehlerquelle auszuschließen.
    Mit PBS in der VM verhält es sich wie auf dem RasPi. Allerdings kann ich hier direkt über die Shell der VM weiter auf PBS zugreifen und mich in der Verzeichnisstruktur bewegen. Es scheint also nur die GUI einzubrechen, nicht aber das eigentliche System des PBS.
    Beim Raspi ist es auffällig, dass er nach einem Neustart ca. 20-30 Minuten braucht um vom PC angepingt werden zu können oder auch sonst irgendwie in Erscheinung zu treten.
    Die anderen VLANs der pfSense, samt DHCP-Server und teilweisen statischen IPs laufen problemlos. Ich habe auch schon gegoogelt etc. aber nichts hilfreiches gefunden.

    Hat Jemand das Problem mal gesehen, oder weiß woran es liegt, bzw. liegen könnte?

    Freundliche Grüße!
    Chris

    Antworten

    • Hallo Chris,

      da ich die Anleitung heute bearbeitet habe, bin ich die Anleitung nochmal komplett durchgegangen und kann deinen Fehler leider nicht nachvollziehen.

      Bei mir funktionierte die Verbindung und die Netzwerkschnittstelle am Pi 4 ohne weitere Störungen.
      Ich vermute, dass da etwas im Netzwerk dazwischen funkt. Port 8007, welcher als Kommunikationsport zwischen PVE und PBS verwendet wird, sollte nicht Firewall-seitig geblockt werden. Darauf achten das Hin- und Rückweg freigegeben sind.
      Hast du die VLANs korrekt eingestellt? Also korrektes Tagging und Untagging der richtigen IDs auf dem Switch oder in den VMs.

      Es hört sich jedenfalls so an, als ob der PBS, aus welchen Gründen auch immer, mit Paketen zugeschmissen wird und daher der Netzwerkstack wegbricht und nicht mehr antwortet, egal ob Pi oder VM. Möglicherweise weil der PVE keine Antwort bekommt und daher immer wieder anfragt. Oder die pfsense funkt dazwischen und sendet die Pakete falsch raus. Dafür müsste man ein besseres Verständnis über die gesamte Netzwerkinfrastruktur bei dir haben.

      Aber möglicherweise helfen die Hinweise ja schon.

      Viele Grüße
      LierschIT

      Antworten

      • Vielen Dank für die schnelle Antwort!

        Port 8007 ist/sollte frei sein. Der Storage wird auch in der PVE angezeigt.
        Die VLANs sind soweit auch korrekt und funktionieren ohne Probleme.

        Von der Struktur her ist es ein Server, auf dem PVE mit WAN- und LAN-Anschluss läuft. In der PVE gibt es:

        – eine VM mit der pfSense. Der LAN-Port führt als Trunk zum Switch welches einen Teil der VLANs für den RasPI-Backupserver (VLAN 2) PCs (VLAN 3), ein WLAN (VLAN 4), etc. bereiststellt. Bei VLAN2 handelt es sich um ein /30-Netz (Gateway + Backupserver), beim Rest sind es /24-Netze.

        – testweise eine weitere VM mit dem PBS, der ja eigentlich extern über den Raspi (am Switch) laufen soll. Den Raspi habe ich natürlich vom Netz genommen, bevor ich die VM erstellt habe.

        – mehrere LXC mit verschiedenen Webservern, etc. (VLAN 1) die WAN-seitig über HA-Proxy angesprochen werden.

        In der pfSense laufen neben dem HA-Proxy auch pfBlockerNG und Snort (habe ich auch schon deaktiviert und hat keinen erkennbaren Einfluss).

        Schaue ich in die Systemprotokollierung der pfSense fällt auf, dass jedes Mal, wenn ich den Storage in der PVE einhänge, 6x die gleiche Block-Meldung kommt:

        Schnittstelle: VLAN des Backupserver

        Quelle: IP des Backupserver auf Port 8007

        Ziel: IP des Gateway des VLANS mit einem bestimmten Port (gleicher Port alle 6 Versuche).
        Hänge ich den Storage aus und wieder ein, passiert das gleiche -> gleicher Port alle 6 Versuche, allerdings wird hier jedes mal, wenn ich neu eingehängt habe ein anderer Port des Gateway angesprochen.

        QUELLE ZIEL PROTOKOLL
        x.x.x.2:8007 x.x.x.1:46660 TCP:SA
        x.x.x.2:8007 x.x.x.1:46660 TCP:SA
        x.x.x.2:8007 x.x.x.1:46660 TCP:SA
        x.x.x.2:8007 x.x.x.1:46660 TCP:SA
        x.x.x.2:8007 x.x.x.1:46660 TCP:SA
        x.x.x.2:8007 x.x.x.1:46660 TCP:SA
        x.x.x.2:8007 x.x.x.1:57984 TCP:SA
        x.x.x.2:8007 x.x.x.1:57984 TCP:SA
        x.x.x.2:8007 x.x.x.1:57984 TCP:SA
        x.x.x.2:8007 x.x.x.1:57984 TCP:SA
        x.x.x.2:8007 x.x.x.1:57984 TCP:SA
        x.x.x.2:8007 x.x.x.1:57984 TCP:SA

        Protokoll: TCP:SA (zu dem :SA habe ich nichts gefunden)

        Diese Meldung taucht auch auf, wenn ich in dem VLAN eine all-open-Regel erstelle, die wie der Name sagt, einfach alles durchlassen soll.

        Freundliche Grüße!
        Chris

  11. Vielen Dank für die schnelle Antwort!

    Port 8007 ist/sollte frei sein. Der Storage wird auch in der PVE angezeigt.
    Die VLANs sind soweit auch korrekt und funktionieren ohne Probleme.

    Von der Struktur her ist es ein Server, auf dem PVE mit WAN- und LAN-Anschluss läuft. In der PVE gibt es:

    – eine VM mit der pfSense. Der LAN-Port führt als Trunk zum Switch welches einen Teil der VLANs für den RasPI-Backupserver (VLAN 2) PCs (VLAN 3), ein WLAN (VLAN 4), etc. bereiststellt. Bei VLAN2 handelt es sich um ein /30-Netz (Gateway + Backupserver), beim Rest sind es /24-Netze.

    – testweise eine weitere VM mit dem PBS, der ja eigentlich extern über den Raspi (am Switch) laufen soll. Den Raspi habe ich natürlich vom Netz genommen, bevor ich die VM erstellt habe.

    – mehrere LXC mit verschiedenen Webservern, etc. (VLAN 1) die WAN-seitig über HA-Proxy angesprochen werden.

    In der pfSense laufen neben dem HA-Proxy auch pfBlockerNG und Snort (habe ich auch schon deaktiviert und hat keinen erkennbaren Einfluss).

    Schaue ich in die Systemprotokollierung der pfSense fällt auf, dass jedes Mal, wenn ich den Storage in der PVE einhänge, 6x die gleiche Block-Meldung kommt:

    Schnittstelle: VLAN des Backupserver

    Quelle: IP des Backupserver auf Port 8007

    Ziel: IP des Gateway des VLANS mit einem bestimmten Port (gleicher Port alle 6 Versuche).
    Hänge ich den Storage aus und wieder ein, passiert das gleiche -> gleicher Port alle 6 Versuche, allerdings wird hier jedes mal, wenn ich neu eingehängt habe ein anderer Port des Gateway angesprochen.

    QUELLE ZIEL PROTOKOLL
    x.x.x.2:8007 x.x.x.1:46660 TCP:SA
    x.x.x.2:8007 x.x.x.1:46660 TCP:SA
    x.x.x.2:8007 x.x.x.1:46660 TCP:SA
    x.x.x.2:8007 x.x.x.1:46660 TCP:SA
    x.x.x.2:8007 x.x.x.1:46660 TCP:SA
    x.x.x.2:8007 x.x.x.1:46660 TCP:SA
    x.x.x.2:8007 x.x.x.1:57984 TCP:SA
    x.x.x.2:8007 x.x.x.1:57984 TCP:SA
    x.x.x.2:8007 x.x.x.1:57984 TCP:SA
    x.x.x.2:8007 x.x.x.1:57984 TCP:SA
    x.x.x.2:8007 x.x.x.1:57984 TCP:SA
    x.x.x.2:8007 x.x.x.1:57984 TCP:SA

    Protokoll: TCP:SA (zu dem :SA habe ich nichts gefunden)

    Diese Meldung taucht auch auf, wenn ich in dem VLAN eine all-open-Regel erstelle, die wie der Name sagt, einfach alles durchlassen soll.

    Freundliche Grüße!
    Chris

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert