Zweites PBS zu Hause: Offsite-Backups ohne S3, ohne White IP, ohne VPS-Zwischenhändler

Fortsetzung der Geschichte über den Umzug von fünf VPS auf einen Dedik. Beim letzten Mal bin ich bei dem Schema „PBS in LXC auf dem Host + Offsite-Synchronisierung in S3“ gelandet. Diese Konfiguration habe ich am Ende neu aufgebaut — und festgestellt, dass S3 hier ein unnötiges Glied ist.

Wo ich im letzten Mal stehen geblieben bin

Im vorherigen Artikel habe ich mein Backup-Schema auf vier Ebenen beschrieben:

ZFS-Snapshots im Pool (instant, gegen „ups, DB gelöscht“).
PBS in LXC auf demselben Host (vollwertige Inkremente).
Sync-Job von PBS nach S3 (offsite).
Discourse-Backups direkt in S3 (Absicherung der Anwendung).

Ebene 3 hat mich die ganze Zeit irgendwie nicht überzeugt. Nenne ich drei Gründe — und einer davon begegnet dir in Tutorials vermutlich kaum.

S3 zerstört die Deduplizierung von PBS. Der eigentliche Charme von PBS liegt in der Chunk-Deduplizierung: Ein neues Backup wiegt die Delta gegenüber dem vorherigen und nicht die komplette VM-Größe. Beim Sync nach S3 legt PBS die Chunks als Objekte ab — und ja, formal bleibt die Deduplizierung erhalten. Aber die Integrität des Backups prüfen heißt: eine erhebliche Menge an Chunks wieder herunterladen. Und hier kommt Grund zwei ins Spiel.

Selectel wirkt zwar „eigener“ — aber wenn sie morgen die Preise erhöhen oder die Region verlieren, habe ich keinen Hebel. Das sind Kosten, die jeden Monat weiterlaufen, und die im Katastrophenfall unter Umständen nicht ausgezahlt werden (legal hold, Kontosperrung, was auch immer). Für Backups ist das entscheidend — genau dann, wenn du deinen Haupt-Standort verlierst, musst du ohne Verhandlungen mit dem Provider schnell auf ein Backup-System umschalten können.

Direktes Restore ist unmöglich. In S3 liegen nur Bytes. Um sie zurückzuspielen, muss man zuerst ein Zwischen-PBS aufsetzen, die Daten wieder synchronisieren und erst dann qmrestore ausführen. Wenn mir ein Dedik komplett abfackelt, brauche ich einen zweiten Ort, der sofort bereit ist, wiederherzustellen. Nicht „in einer Stunde, wenn ich ein temporäres PBS hochgezogen habe“.

Logische Schlussfolgerung: Statt S3 brauchst du ein zweites vollständiges PBS, physisch an einem anderen Ort — bereit, Sync-Jobs anzunehmen und bei Bedarf Backups direkt auszuliefern.

Wo das zweite PBS leben soll

Die Optionen waren:

Beim Hoster mieten — das ist deja vu aus dem letzten Artikel; ich bin ja gerade weg vom Modell „viele Konten“.
Günstiger VPS mit eigenem PBS — ein paar Dutzend Euro pro Monat, eine nicht kontrollierbare Plattform und noch ein weiterer Single Point of Failure.
Zuhause auf dem eigenen NAS installieren — Platz ist da, das NAS steht bei mir im Wohnzimmer, RAID, USV, der Provider blockiert kein SSD ¯\(ツ)/¯.

Option drei gewinnt in allen Punkten, außer einem: NAS zuhause hinter NAT, einen White IP vom Provider gibt es nicht ohne Tanz und Extrazahlung. Port-Weiterleitung geht nicht, DDNS und dynamische IPs „rumzuhantieren“ will ich nicht, und den PBS-Port ins Internet offen zu halten — dafür gibt es zusätzlich keinen Spielraum.

Dann kommt das Mesh ins Spiel, das ich bereits habe: Netbird, beschrieben im vorherigen Artikel. Daran sind bereits der Dedik, ein Peer-Server, mein Laptop und ein paar alte Maschinen angeschlossen. NAS hinzufügen heißt nur: einmal Agent installieren und einmal Setup-Key. Die NAS bekommt eine Adresse 100.x.x.x im selben privaten Mesh-Netz und ist für den Dedik genauso erreichbar wie ein Nachbar in vmbr1.

Was am Ende rausgekommen ist

flowchart LR
    subgraph DC["🇵🇱 Dedik OVH Warsaw"]
        PVE["Proxmox Host<br/>217.182.203.187"]
        subgraph LXC102["LXC 102"]
            PBS1["PBS primary<br/>10.10.10.3"]
        end
        VMs["VM 200, 201, 202, 203<br/>LXC 120, 121, 122"]
        PVE --- LXC102
        PVE --- VMs
    end

    subgraph HOME["🏠 Zuhause hinter NAT"]
        NAS["Synology NAS"]
        subgraph COMPOSE["Container Manager"]
            NB["netbird agent"]
            PBS2["PBS secondary<br/>:8007"]
            NB -.network_mode.- PBS2
        end
        NAS --- COMPOSE
    end

    subgraph CLOUD["☁️ Netbird Cloud"]
        MGMT["Management<br/>+ Signal"]
    end

    VMs -."vzdump backup".-> PBS1
    PVE <-->|control plane| MGMT
    NB <-->|control plane| MGMT
    PBS1 <==>|"PBS Sync Job<br/>WireGuard tunnel"| PBS2

    classDef dc fill:#2d3748,stroke:#4a5568,color:#e2e8f0
    classDef home fill:#22543d,stroke:#38a169,color:#f0fff4
    classDef cloud fill:#2c5282,stroke:#3182ce,color:#ebf8ff
    class DC dc
    class HOME,COMPOSE home
    class CLOUD cloud

VMs und LXC-Container werden lokal auf PBS primary in LXC 102 gesichert — schnell, per localhost, mit vollständiger Deduplizierung. Einmal pro Tag spült ein sync job in PBS primary das Delta auf PBS secondary auf der NAS über das Mesh. Snapshots bleiben an beiden Orten, Deduplizierung funktioniert auf beiden PBS unabhängig, und das Restore kann von beiden Seiten aus gemacht werden — beide sind „echte“.

Über Mesh läuft nur der Sync — das heißt: die NAS ist von außen für nichts sichtbar, keine Ports, kein DDNS. Über die Netbird-Cloud läuft nur das control plane (Verwaltung der Peers); die eigentlichen Backups fließen direkt per WireGuard-Tunnel Dedik ↔ NAS.

Installation: was sich von Standard-PBS geändert hat

Der Großteil der Installation ist ein normales docker-compose-Projekt im Synology Container Manager: PBS aus dem Community-Setup ayufan/proxmox-backup-server plus Sidecar netbird-Agent im gemeinsamen network namespace. Details zu Compose-Datei, Memory-Limits, Mounting von /etc, /lib, /backups — das habe ich bereits in einer separaten Notiz über den Prozess aufgeschrieben. Hier konzentriere ich mich auf das, was für das zweite PBS spezifisch ist, nicht auf die Grundlagen.

Hostname im Mesh — sinnvoll benannt

yaml

1environment:
2  - NB_HOSTNAME=synology-pbs-offsite

Wenn die Peers mehr als ein Dutzend sind, verlieren Namen wie synology ihren Sinn. synology-pbs-offsite sagt sofort, dass es (a) eine NAS ist, (b) mit PBS und (c) für die Offsite-Rolle vorgesehen. Auf dem Dedik in storage.cfg taucht exakt dieser Name auf.

Netbird-ACL — nur den Dedik erlauben

In der Netbird-Konsole habe ich die Gruppe pbs-sync erstellt und dort nur zwei Peers abgelegt: den PVE-Host und die Synology. Regel: Alles andere in der Gruppe default darf nicht zu pbs-sync.

Laptop, Peer-Server, alte Maschinen — niemand davon kann Port 8007 auf der NAS sehen. Wenn man mir morgen sagt, ich soll jemandem RDP auf den Laptop geben, erhält er nicht automatisch Zugriff auf meine Backups.

Das ist übrigens der größte Vorteil des Mesh mit ACL gegenüber WireGuard pur: In WG sehen alle, die im Tunnel sind, alle — ACLs werden mit iptables-Regeln gebaut und werden schnell zur „Kleistermasse“.

Datastore auf einem separaten Volume

Auf der Synology habe ich einen eigenen shared folder /volume2/PBS auf der Partition mit großen mechanischen Platten erstellt (BTRFS, RAID 5). Das NVMe-Volume auf der NAS lasse ich für Hot-Daten und Docker. PBS benötigt für Backups keine IOPS — es braucht vor allem Kapazität, und die lauten HDD-Spindeln passen hier perfekt.

yaml

1volumes:
2  - ./etc:/etc/proxmox-backup
3  - ./logs:/var/log/proxmox-backup
4  - ./lib:/var/lib/proxmox-backup
5  - ./backups:/backups

Den Datastore gebe ich in der PBS-UI als /backups an. Größe: 4 TB — mit den aktuellen Daten reicht das für ein paar Jahre mit Retention keep-daily=7 keep-weekly=4 keep-monthly=12 keep-yearly=3.

Sync Job — das Spannendste

Das ist der neue Teil für mich; im letzten Artikel gab es ihn noch nicht. PBS hat die eingebaute Funktion Remote + Sync Job: Ein PBS kann „Client“ des anderen sein, Snapshots von ihm ziehen und in seinen eigenen Datastore einsortieren.

Schritt 1: Remote auf der Seite des primary

Auf dem primären PBS (LXC 102) füge ich die secondary als Remote-Ziel hinzu. In der UI: Configuration → Remotes → Add.

Remote ID: nas-offsite
Host: synology-pbs-offsite (das ist der Name aus Netbird DNS, der sich von jedem Peer auflösen lässt)
Auth ID: sync@pbs (eigener User auf der secondary, siehe unten)
Password / Token: das Passwort sync@pbs
Fingerprint: SHA-256-Fingerprint des Zertifikats der secondary

Den Fingerprint holt man auf der secondary mit einem einzigen Befehl:

bash

1docker exec pbs proxmox-backup-manager cert info | grep -i fingerprint

Schritt 2: User für Sync auf der secondary

Auf der NAS, innerhalb des Containers pbs:

bash

1proxmox-backup-manager user create sync@pbs --password 'LongRandomPassword2026'
2proxmox-backup-manager acl update /datastore/main DatastoreBackup --auth-id sync@pbs
3proxmox-backup-manager acl update /remote DatastorePowerUser --auth-id sync@pbs

[!IMPORTANT] Das Passwort muss lang und ohne Sonderzeichen sein. PBS akzeptiert beim Erstellen eines Users über proxmox-backup-manager jedes Passwort kommentarlos, aber auf API-Ebene verwirft es schwache Passwörter mit 401 Unauthorized. Ich bin genau darauf reingefallen, habe dafür eine Stunde verloren, bis ich einen neuen User mit einem „normalen“ Passwort angelegt hatte. Eigentlich sollte PBS beim Erstellen meckern — tut es aber nicht.

Schritt 3: Sync Job

Auf dem primary PBS: Datastore → main → Sync Jobs → Add.

Local Datastore: main (das ist der Datastore auf dem primary)
Remote: nas-offsite
Remote Datastore: main (das ist der Datastore auf der secondary)
Schedule: daily 03:30 (nach dem täglichen Backup um 02:00, bis zum Morgen)
Owner: sync@pbs
Remove vanished: yes (wenn du auf dem primary einen alten Snapshot aufgrund der Retention gelöscht hast — dann soll er auch auf der secondary gelöscht werden; sonst wächst die secondary)

Run Now drücken → in den Logs siehst du, wie PBS Chunk für Chunk die Daten schiebt. Beim ersten Mal ist es das komplette Volumen (bei mir waren es beim Start etwa 180 GB), alle folgenden sind nur das Delta.

Geschwindigkeit

Mich hat Folgendes beschäftigt: NAS zuhause, mein Kanal hat 600/600 Mbps, der Dedik in Warschau dazwischen etwa 30 ms. Über WireGuard im Mesh schiebt PBS etwa 400 Mbit/s — das wird auf der NAS durch die Verschlüsselung ausgebremst, nicht durch den Kanal. Für ein Offsite-Backup ist das mit großem Puffer ausreichend. Das tägliche Delta im Bereich von 5–15 GB ist in wenigen Minuten durch.

Wiederherstellung: funktioniert wirklich auf beiden Seiten

Den Ablauf „Dedik brennt / OVH liegt / Festplatte zerbröselt“ habe ich so durchgespielt:

Nimm irgendeinen freien Server (entweder Proxmox lokal in einer VM hochziehen oder bei einem neuen Hostanbieter einen neuen Dedik holen).
Installiere auf ihm den Netbird-Agent und füge ihn ins Mesh ein.
Verbinde die NAS als PBS Storage: Datacenter → Storage → Add → Proxmox Backup Server, server synology-pbs-offsite, user sync@pbs.
qmrestore für die gewünschte VM aus dem NAS-Datastore. Kein Vermittler, kein „erst ein PBS hochziehen“ — die secondary ist schon PBS.

Der Test-Restore der Discourse-VM auf einem leeren Proxmox-Instance hat in 18 Minuten funktioniert (4 GB RAM, 50 GB Disk). Mit S3 wäre das die ganze Nacht gewesen.

Kosten

Was	Früher	Jetzt
Objektspeicher in S3 für Backups	~$8/Monat für 200 GB	$0
Egress beim Test-Restore	~$15 für 100 GB	$0
Zeit für Offsite-Restore	ab einer Stunde	Minuten
Kontrolle über den Storage	bei Selectel	bei mir

Das NAS steht sowieso zuhause — es wurde nicht für diese Aufgabe gekauft, es wurde einfach zum Bonus. Strom kostet Peanuts, weil das Spin-down für inaktive Disks funktioniert.

Was ich auf dem Weg gelernt habe

Mesh ist ein Infrastruktur-Baustein, kein „VPN für Remote“. Im letzten Artikel schrieb ich über Netbird im Kontext von Admin-Zugriff und Umgehung von Blockierungen. Jetzt verstehe ich: Das Mesh ist die Nullschicht der ganzen Infrastruktur. Jeder neue Knoten verbindet sich zuerst ins Mesh, danach bekommt er seine Rolle. Das verändert das Architekturdenken: Du hörst auf, Server in „eigene/fremde/öffentliche“ zu teilen — alle werden zu Peers mit unterschiedlichen ACLs.

S3 für Backups war intelligente Faulheit. Ich habe S3 gewählt, weil es ein „kanonisches Pattern“ ist, nicht weil es für meine Aufgabe wirklich passt. Das zweite PBS passt in allen Punkten besser — mit einer Ausnahme: es muss selbst installiert und konfiguriert werden. Und selbst das nur einen Abend.

Off-site != offline. Viele schreiben, das Backup müsse offline sein (air-gapped). Bei mir ist die secondary immer online über das Mesh, und formal ist sie nicht vor Ransomware geschützt, die beim primary angekommen wäre und dann per Sync-Job die Snapshots auf der secondary verdürbe. Der Schutz hier ist das Flag verify-new und ZFS/BTRFS-Snapshots direkt auf dem Synology auf Shared-Folder-Ebene. Das PBS auf der secondary kann keinen Snapshot über sich löschen oder beschädigen — das macht nur der NAS-Host. Ergebnis: secondary ist online aus Bequemlichkeit, aber darunter steckt die offline-history, an die die Sync-Logik nicht herankommt.

Wie es weitergeht

Erweiterungen an der Backup-Kette:

Verify jobs auf der secondary alle zwei Wochen, um zu wissen, dass die Daten auf dem NAS wirklich lesbar sind und nicht nur „liegen“. Früher spielte diese hypothetische Möglichkeit eine Rolle, aus S3 herunterzuladen und zu prüfen — jetzt ist es ein eingebautes PBS-Feature.
Dritte Offsite-Stufe für das ganz paranoide Szenario „Zuhause und Dedik gleichzeitig“. Sehr wahrscheinlich wird es ein periodischer manueller Export der kritischen Datastore-Snapshots auf eine externe USB-Platte, die bei den Eltern in einer anderen Stadt liegt. Keine Automatisierung, sondern ein Ritual — einmal im Quartal hinfahren, aktualisieren.

Wenn du schon ein NAS zuhause hast und Mesh zwischen den Servern — dann hast du bereits ein fertiges Offsite-PBS, du musst es nur zusammenbauen. Wenn nicht: schau es aus einer anderen Perspektive an — das heimische NAS hört auf, „nur ein Ding für Urlaubsfotos“ zu sein, sondern wird Teil der Production-Infrastruktur. Und das ist erstaunlich normal.

Im nächsten Beitrag erzähle ich über verify jobs, die Prune-Strategie für zwei PBS und wie man das reale RPO/RTO für so ein Setup berechnet. Wenn dich das interessiert, schreib in die Kommentare.

PBS auf Synology für NAT via Netbird: Backup-Server ohne White IP