Proxmox Backup Server Offsite: Pull-Architektur mit asymmetrischer Retention für ransomware-sichere Backups

Proxmox Backup Server als Managed Service — WZ-IT übernimmt Konzeption, Aufbau und Betrieb Ihrer PBS-Offsite-Architektur. NIS2-konform, mit definierten SLAs und dokumentierten Restore-Tests. Termin vereinbaren · Mehr zu Proxmox Backup Server

Drei Kernfragen entscheiden, ob Ihre Backups eine Ransomware-Welle überstehen: Wer hat Zugriff auf was, wer initiiert die Datenbewegung, und wie lange leben Daten an welchem Ort? Bei Proxmox Backup Server (PBS) lassen sich diese Fragen architektonisch elegant beantworten — mit einer Pull-Architektur und asymmetrischer Retention zwischen primärem und Offsite-Standort.

Dieser Beitrag erklärt, warum die Sync-Richtung über die Sicherheit Ihrer Backups entscheidet, wie sich Retention sauber auf zwei Standorte verteilen lässt, was im NIS2-Kontext zu beachten ist und welche Hosting-Optionen für den externen PBS in der Praxis taugen.

Inhaltsverzeichnis

• Pull oder Push: Warum die Sync-Richtung entscheidet
• So funktioniert die Pull-Architektur
• Was Offsite wirklich bedeutet
• Deduplizierung: warum Offsite bezahlbar bleibt
• Asymmetrische Retention: lokal kurz, offsite lang
• Sync-Job-Flags richtig setzen
• Hosting-Optionen für den externen PBS
• 3-2-1-1-0 und der NIS2-Kontext
• Häufige Stolperfallen
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Pull oder Push: Warum die Sync-Richtung entscheidet

Proxmox Backup Server unterstützt zwei Modi für die Replikation zwischen zwei PBS-Instanzen: Pull (der Ziel-Server holt Daten aktiv vom Quell-Server) und Push (der Quell-Server schickt Daten an den Ziel-Server). Technisch erreichen beide das gleiche Ergebnis. Sicherheitstechnisch sind sie himmelweit verschieden.

Bei einem Push-Setup muss der produktive PBS den externen erreichen können, Schreibrechte besitzen und die Credentials des Remote-Servers kennen. Wird die produktive Infrastruktur kompromittiert — durch Ransomware, einen kompromittierten Admin-Account oder einen Insider — hat der Angreifer alle Werkzeuge in der Hand, um auch die Offsite-Backups zu verschlüsseln oder zu löschen.

Bei einem Pull-Setup kennt der produktive PBS den externen Server gar nicht. Der Sync wird vom Remote initiiert, der Remote zieht sich Daten ab und schreibt sie in seinen eigenen Datastore. Auf der Quelle braucht er nur Leserechte. Selbst wenn die gesamte Produktiv-Umgebung gekapert wird, bleibt der Offsite-Speicher intakt — er ist von der Quelle aus weder erreichbar noch bekannt.

Das Proxmox-Team formuliert es explizit: Pull ist die empfohlene Variante, wo immer möglich. Push wurde später eingeführt, um Quellen hinter Firewalls ohne Port-Forwarding einbinden zu können — ist aber sicherheitstechnisch der schlechtere Default. Ein zusätzlicher Vorteil von Pull: Beschädigte Snapshots auf der Quelle können neu synchronisiert werden, was Push nicht kann.

Praktisch heißt das: Die Firewall des produktiven Standorts muss nur ausgehende Verbindungen erlauben oder, eleganter, nur eingehende Verbindungen vom externen Server auf TCP/8007 zulassen. Die gesamte Kommunikation läuft TLS-verschlüsselt; mit gesetzten Fingerprints sind self-signed Zertifikate unbedenklich.

So funktioniert die Pull-Architektur

Eine produktionsreife PBS-Pull-Architektur besteht aus drei Komponenten:

Der lokale PBS sitzt im Produktiv-Netz, idealerweise in einem HA-Proxmox-Cluster integriert. PVE-Hosts schicken VM- und Container-Backups dorthin. Inkrementelle Übertragung mit Deduplizierung sorgt dafür, dass nach dem ersten Vollbackup nur noch Deltas über die Leitung gehen.

Der Offsite-PBS steht in einem geografisch und administrativ getrennten Rechenzentrum. Er holt sich neue Snapshots per Pull, dedupliziert sie noch einmal in seinen eigenen Datastore und wendet seine eigene Retention-Policy an. Die einzige eingehende Verbindung, die er nach außen braucht, ist die zur Quelle — keinerlei Verbindungen vom Internet zum Offsite-Server.

Der Sync-User ist ein dedizierter API-User auf dem lokalen PBS mit ausschließlich der Rolle DatastoreReader auf einem konkreten Datastore. Statt Passwort empfiehlt sich ein API-Token, das ohne Login-Eingriff rotiert werden kann. Schreibrechte hat dieser User nirgendwo — selbst wenn das Token kompromittiert würde, kann der Angreifer höchstens lesen, nicht zerstören.

Beim Pull lädt der Remote zuerst die Liste vorhandener Chunks für jeden zu syncenden Snapshot herunter. Existiert ein Chunk bereits lokal (etwa weil er bereits durch einen vorherigen Sync vorhanden ist oder weil eine andere VM denselben Inhalt hat), reicht der Hash. Nur wirklich neue Chunks werden komplett übertragen. Auch über die Leitung wirkt die Deduplizierung also voll.

Konfigurativ landen Sync-Jobs in /etc/proxmox-backup/sync.cfg, Remote-Definitionen in /etc/proxmox-backup/remote.cfg. Beide Dateien sind versionierbar und gehören in Ihre Provisioning-Pipeline.

Was Offsite wirklich bedeutet

"Offsite" wird in der Praxis oft mit "extern" oder "auf einem anderen Server" verwechselt. Das ist gefährlich. Ein PBS im selben Rack wie der PVE ist off-host, ein PBS im selben Standort, aber außerhalb des PVE-Clusters ist off-cluster — beides hilft gegen Hardware-Ausfälle eines einzelnen Servers, aber nicht gegen Brand, Wassereinbruch, RZ-Stromausfall, Diebstahl oder einen Hoster, der den Account sperrt.

Echtes Offsite verlangt drei Trennungen:

Geografisch. Faustregel: 50-100 km Mindestdistanz, idealerweise andere Stromnetz-Region. Wer in NRW sitzt, sollte den Offsite-PBS nicht in NRW haben. Großflächige Stromausfälle wie 2006 im Münsterland und Hochwasser-Risiko-Karten sind Argumente für echte geografische Verteilung.

Administrativ. Idealerweise nicht beim selben Hoster wie das Primärsystem. Wer auf Hetzner produktiv läuft, sollte den Offsite-Standort woanders haben — nicht weil die Hetzner-Standorte unsicher wären, sondern weil eine Account-Sperrung (verspätete Zahlung, kompromittierte Hoster-Credentials) sonst beide Standorte gleichzeitig abschalten kann.

Rechtlich. Bei Insolvenz oder einem Konflikt mit dem Primärprovider sollten die Offsite-Daten weiter erreichbar sein. Provider-Diversität ist auch ein juristisches Argument.

Praktischer Vorschlag für eine deutsche Mittelstand-Konstellation: Primär bei Hetzner Falkenstein, Offsite bei netcup Nürnberg oder Wien. Andere Stromnetz-Region, anderer Hoster, andere Verwaltungsdomäne, beide DSGVO-konform und EU-ansässig.

Deduplizierung: warum Offsite bezahlbar bleibt

Offsite-Storage scheint zunächst teuer — bis man versteht, wie aggressiv PBS dedupliziert. Die Mechanik:

VM-Backups werden in Fixed-Size-Chunks von 4 MiB zerlegt. Jeder Chunk bekommt einen SHA-256-Hash. Identische Chunks (etwa in mehreren Snapshots derselben VM oder in mehreren VMs mit gleichem Basis-Image) landen nur einmal physisch im Datastore — nachfolgende Snapshots referenzieren dieselbe Datei.

Container- und Host-Backups werden in dynamische Chunks zerlegt, deren Grenzen ein Buzhash-Rolling-Hash über pxar-Archive bestimmt. Der Vorteil: Bei einer kleinen Änderung in der Mitte einer großen Datei verschiebt sich nicht die ganze Chunk-Aufteilung — nur der betroffene Chunk wird neu.

Inkrementell mit Bitmap. Bei laufenden VMs trackt QEMU geänderte Blöcke per Dirty Bitmap. PBS liest dann nur diese Blöcke und überträgt nur die unbekannten Chunks. Wichtig zu wissen: Die Bitmap lebt im RAM. Nach VM-Stop, Restart oder Migration ist sie weg, und das nächste Backup muss wieder die ganze Disk lesen — überträgt aber trotzdem nur unbekannte Chunks. Längere Laufzeit, kein Mehrverbrauch an Speicher.

Cross-VM-Dedup. Fünf VMs mit Debian-12-Base teilen die Systemdateien. Drei Wochen tägliche Snapshots derselben VM teilen alles, was sich nicht geändert hat. PBS rechnet das automatisch raus.

In der Praxis: HorizonIQ dokumentiert in einem Erfahrungsbericht eine Reduktion von 7 TB unkomprimierten NFS-Backups auf knapp über 1 TB nach Umstieg auf PBS — bei gleichzeitig schnellerem Restore. Der konkrete Faktor lässt sich pro Datastore in der WebUI einsehen, aktualisiert sich allerdings erst nach einem Garbage-Collection-Lauf.

Ein paar Limits sind ehrlich zu benennen. Bei stark fragmentierten Datenbanken kann ein Byte-Update einen ganzen 4-MiB-Chunk neu schreiben. Wer auf Block-Ebene fein-granulare Deduplizierung braucht, muss zusätzlich auf Storage-Ebene mit ZFS-Dedup oder ähnlichem arbeiten. PBS ist als Backup-Layer ausgelegt, nicht als Storage-Engine.

Asymmetrische Retention: lokal kurz, offsite lang

Hier kommt eine Eigenart von PBS, die viele beim ersten Setup übersehen: Sync-Jobs sind unabhängig von Prune-Einstellungen. Der Sync zieht alle Snapshots, die neuer sind als der lokal vorhandene letzte. Was lokal bereits geprunt wurde, kommt nicht zurück.

Daraus folgt die Regel: Retention muss in eine Richtung geplant werden — lokal kürzer als offsite, niemals umgekehrt. Wenn auf dem lokalen PBS nach 14 Tagen geprunt wird, bevor der nächste Sync läuft, geht der Snapshot offsite verloren.

Eine sinnvolle Aufteilung in der Praxis:

Lokaler PBS (kurz, schnell, operativ): keep-last 3 plus keep-daily 7. Schnelle Restores für die häufigen Fälle (versehentlich gelöschte VM, beschädigtes Update).

Offsite-PBS (lang, compliance): Die offizielle PBS-Doku zeigt eine 10-Jahres-Strategie: keep-last 3, keep-daily 13, keep-weekly 8, keep-monthly 11, keep-yearly 9. Damit haben Sie aktuell tagesgenaue Backups, gehen rückwirkend auf Wochen-, dann auf Monats-, dann auf Jahres-Granularität — bei minimalem Speicheraufwand dank Dedup.

Wichtig: Die keep-*-Optionen werden in Reihenfolge abgearbeitet (last → hourly → daily → weekly → monthly → yearly). Jede Option markiert nur Snapshots im eigenen Zeitfenster, die noch nicht von einer früheren Option markiert wurden. Wer das Zusammenspiel verstehen will, sollte den offiziellen Prune-Simulator nutzen — dort lassen sich Policies gegen Beispiel-Daten durchspielen.

Drei Stellen, an denen Retention konfiguriert werden kann — und das ist der häufigste Fehler:

1. PBS Datastore (Prune & Garbage Collection-Tab)
2. PVE-Storage-Konfiguration (PBS als Storage in PVE)
3. PVE-Backup-Job

Wenn Retention an mehreren Stellen gesetzt ist, wirken alle parallel — und die aggressivste gewinnt. Die saubere Lösung: Retention ausschließlich am PBS-Datastore (oder Namespace) setzen, in der PVE-Storage-Konfiguration "Keep all backups" aktivieren. Zusätzlich sollte der PBS-User, mit dem PVE die Backups schreibt, kein Prune- oder Destroy-Recht haben — sonst kann ein kompromittierter PVE die eigenen Backups löschen.

Pruning entfernt übrigens nur die Snapshot-Referenz, nicht die zugrunde liegenden Chunks. Erst die Garbage Collection (typischerweise ein Wochenende-Job) löscht unreferenzierte Chunks nach einer Grace-Period von 24h plus 5 Minuten. Speicher wird also erst nach dem nächsten GC-Lauf wirklich frei.

Sync-Job-Flags richtig setzen

Ein paar Flags entscheiden zwischen "läuft sauber" und "produziert Datenverlust":

--remove-vanished false (empfohlen für asymmetrische Retention). Wenn auf der Quelle ein Snapshot gepruned wird, soll er auf dem Offsite nicht mit verschwinden. Auf true gesetzt würde der Pull-Job den Offsite zum reinen 1:1-Mirror machen — was die ganze Retention-Asymmetrie zerstört.

--verified-only true synchronisiert nur Snapshots, die auf der Quelle bereits per Verify-Job geprüft wurden. Empfehlenswert, wenn der Remote-Server in einer weniger vertrauenswürdigen Umgebung läuft.

--encrypted-only true zieht nur clientseitig verschlüsselte Snapshots offsite. Wenn Sie clientseitige Verschlüsselung mit AES-256-GCM einsetzen — was bei Offsite-Storage Pflicht sein sollte — verhindert dieses Flag, dass versehentlich unverschlüsselte Backups das Haus verlassen.

--rate-in <Bandbreite> begrenzt die Sync-Geschwindigkeit. Bei knappem Uplink (etwa 50 Mbit/s in einem KMU-Anschluss) macht es Sinn, den Sync auf 20 MiB/s oder weniger zu deckeln, damit das Tagesgeschäft nicht ausgebremst wird. Tipp: Sync-Jobs in die Nachtstunden legen.

--ns und --remote-ns mappen Namespaces. Pro Mandant einen Namespace im selben Datastore: getrennte ACLs, getrennte Prune-Policies, aber gemeinsame Deduplizierung. Bei mandantenfähigen Setups oder Hosting-Szenarien ist das oft die richtige Antwort.

--schedule akzeptiert die Calendar-Event-Syntax von systemd: daily 03:30, *-*-* 02:00, Wed 02:30. Sync-Jobs sollten nach den Backup-Jobs laufen, aber vor den Prune-Jobs.

Hosting-Optionen für den externen PBS

Vier sinnvolle Architektur-Varianten, abhängig von Volumen, Compliance-Anforderung und Budget:

netcup Root Server mit Local Block Storage. Aktuelle G12-Generation mit AMD EPYC, garantierten Cores und DDR5-RAM. Local Block Storage bis 8 TB pro Server, ohne Mindestlaufzeit erweiterbar. Standorte Nürnberg oder Wien. PBS profitiert spürbar von lokalem Block-Storage statt Network-Filesystemen — Garbage Collection und Verify werden deutlich schneller. Preislich attraktiv, EU-souverän.

Hetzner Storage Box als CIFS-Mount. Funktioniert technisch, ist preislich verlockend, performt aber bei PBS schlecht. Garbage Collection auf Network-Filesystemen mit hoher Latenz frisst sich in die Stunden. Wer trotzdem damit arbeiten will, sollte das Setup auf Restore-only beschränken oder als zusätzliche Cold-Layer parallel zu einem performanten primären Offsite einsetzen.

Managed-PBS-Anbieter. Tuxis, Cloud-PBS, Inett und einige andere bieten gemanagte PBS-Instanzen ab etwa 12-20 €/TB/Monat an. Vorteil: Sie betreiben den PBS nicht selbst, der Anbieter kümmert sich um Updates, Hardware-Defekte und Skalierung. Nachteil: weniger Kontrolle, Vendor-Lock-in, je nach Setup keine eigene Kryptographie-Hoheit.

Eigene Hardware in einem zweiten Rechenzentrum. Beste Performance und volle Kontrolle, ökonomisch sinnvoll erst bei größeren Volumina (typischerweise ab 20 TB) oder wenn ohnehin ein zweiter Standort mit Anbindung existiert. Für kleinere Setups oft Overkill.

Bonus seit PBS 4.0: S3-Backend mit Object Lock. Seit Mitte 2025 unterstützt PBS S3-kompatibles Object Storage als Datastore-Backend nativ. Mit Object Lock (verfügbar bei AWS S3, Backblaze B2, Wasabi, Cloudflare R2, MinIO selbst gehostet) wird das Backup zur logisch immutable Kopie — selbst der Root-Account kann gelockte Objekte vor Ablauf der Retention-Periode nicht löschen. Hybride Architektur, die wir oft empfehlen: PVE → lokaler PBS (hot, schnell), lokaler PBS → externer PBS bei netcup (warm, Pull), externer PBS → S3-Backend mit Object Lock (cold, immutable). Damit ist die NIS2-Anforderung "1 immutable" abgedeckt, ohne auf Tape ausweichen zu müssen.

3-2-1-1-0 und der NIS2-Kontext

Die klassische Backup-Regel "3-2-1" — drei Kopien, zwei Medien, eine offsite — wird im Ransomware-Zeitalter um zwei Stellen erweitert: 3-2-1-1-0. Eine zusätzliche Kopie soll immutable oder offline sein (gegen Ransomware), und 0 Fehler sollen Verify-Jobs zeigen.

Eine Pull-PBS-Architektur deckt 3-2-1 elegant ab:

• 3 Kopien: Original auf PVE-Storage, Backup auf lokalem PBS, Sync auf externen PBS
• 2 Medien: PVE-Storage und PBS-Datastore (oder zwei PBS-Datastores auf unterschiedlichem Storage)
• 1 offsite: der externe PBS

Die zusätzliche immutable Kopie verlangt mehr — entweder Tape-Backup (PBS unterstützt LTO nativ), Removable Datastores (rotierende externe Platten, die nur zum Sync angeschlossen werden, seit PBS 3.4), oder eben das oben beschriebene S3-Object-Lock-Backend.

Verify-Jobs auf 0 Fehler sind kein Nice-to-have. Ein Backup, das nie restored oder verifiziert wurde, ist Hoffnung — kein Backup. Quartalsweise Restore-Tests einer Test-VM aus dem Offsite-Datastore gehören in den Operations-Kalender.

Im NIS2-Kontext ist diese Architektur nicht nur gute Praxis, sondern de facto Pflichterfüllung. Das Anfang 2026 in deutsches Recht überführte NIS2-Umsetzungsgesetz schreibt der Geschäftsführung wesentlicher und wichtiger Einrichtungen ein dokumentiertes Risikomanagement vor — explizit inklusive Backup- und Wiederherstellungsstrategie. Bei Verletzung haftet die Geschäftsführung persönlich, mit Bußgeldern bis zu 10 Millionen Euro oder zwei Prozent des weltweiten Konzernumsatzes.

Auditoren wollen Belege sehen: dokumentierte Patch-Zeiten, dokumentierte Backup-Strategie mit RTO/RPO, dokumentierte Verify-Ergebnisse, dokumentierte Datenresidenz. Eine PBS-Pull-Architektur in EU-Rechenzentren mit nachweisbarer asymmetrischer Retention liefert genau diese Belege — und schützt zusätzlich gegen das Ransomware-Szenario, das in den vergangenen Jahren unzählige Mittelständler kalt erwischt hat.

Wer tiefer in das Thema einsteigen will: Wir haben dazu einen ausführlichen Beitrag geschrieben — "Linux-Kernel-Schwachstellen 2026: Warum Patch-Management jetzt Chefsache ist" ordnet den NIS2-Kontext im Detail ein.

Häufige Stolperfallen

Ein paar Lektionen aus produktiven Setups:

Latenz frisst Bandbreite. Sync-Geschwindigkeit hängt nicht nur vom Uplink ab, sondern auch von der Round-Trip-Time zwischen Source und Destination. Bei hoher Latenz oder Packet-Loss bremst die TCP-Congestion-Control aggressiv ein. Workaround: WireGuard-Tunnel mit BBR-Congestion-Control. Der Bug-Tracker-Eintrag 4182 dokumentiert das Problem im Detail.

Initial-Sync lokal machen. Der erste Sync kann bei mehreren Terabyte über einen 50-Mbit/s-Uplink Tage dauern. Praktisch hat sich bewährt, den Offsite-PBS lokal aufzubauen, den ersten Sync im lokalen Netz laufen zu lassen und die Maschine dann ins Remote-Rechenzentrum zu verbringen. Configs werden danach auf die neue IP angepasst, der Datastore ist bereits gefüllt. Alternativ: Removable Datastores für den Initial-Sync per externer Platte.

Verify-Jobs einrichten — auf beiden Seiten. Auf der Quelle, um Bit-Rot frühzeitig zu erkennen. Auf dem Offsite, um zu wissen, dass der Sync nicht stillschweigend kaputte Chunks übertragen hat. Verify ist IO- und CPU-intensiv; das Schedule sollte zwischen GC und Sync liegen.

Encryption-Keys offsite hinterlegen. Wenn Backups clientseitig verschlüsselt sind und der Schlüssel nur auf dem zerstörten PVE liegt, sind die Backups unbrauchbar. Schlüssel gehört in einen Cloud-Passwort-Manager (Bitwarden, 1Password) plus eine Offline-Kopie an einem zweiten Standort — im Notfall ein gedruckter QR-Code im Bankschließfach. Ja, wirklich.

DNS-Failover für Restore vorbereiten. Im Disaster-Recovery-Fall ist der lokale PBS oft auch weg. Restore muss direkt vom externen PBS auf einen frisch installierten PVE funktionieren. Heißt: externer PBS muss erreichbar sein, Credentials müssen verfügbar sein (Passwort-Manager mit Offline-Backup), Encryption-Keys müssen sicher hinterlegt sein, Restore-Walkthrough muss dokumentiert sein. Restore-Test ist Pflicht, nicht Kür.

Namespaces für Mandantenfähigkeit nutzen. Pro Kunde oder pro Workload-Klasse einen Namespace im selben Datastore: getrennte ACLs, getrennte Prune-Policies, getrennte Sync-Filter. Aber: Wenn dieselbe VM in zwei Namespaces gesichert wird, geht die Dirty Bitmap verloren — komplette Disk muss bei jedem Backup neu gehasht werden. Praktisch heißt das: Eine VM lebt in genau einem Namespace.

Drei Retention-Stellen — eine Quelle der Wahrheit. Wir haben es oben erwähnt, es ist aber so wichtig, dass es zweimal gehört: Retention nur am PBS-Datastore. PVE-Job auf "Keep all backups". Sonst marken Sie sich Snapshots weg, von denen Sie hofften, sie offsite zu haben.

Bandbreiten-Asymmetrie beachten. Privatanschlüsse haben oft 1 Gbit/s Down, 50 Mbit/s Up. Initial-Sync vom Offsite zurück (im DR-Fall) ist schnell — Sync ins Offsite ist langsam. Bei Business-Anschlüssen meist symmetrisch, aber lohnt sich zu prüfen.

Unser Vorgehen bei WZ-IT

Bei WZ-IT bauen und betreiben wir PBS-Pull-Architekturen als integralen Teil unserer Proxmox & Private Cloud-Services. Drei Stationen:

Architektur-Workshop (Proxmox Beratung). Gemeinsam mit Ihnen klären wir Datenmenge, RTO/RPO-Anforderungen, Compliance-Pflichten (NIS2, ISO 27001, BSI C5) und Bandbreiten-Realitäten. Output: ein Architektur-Dokument mit Hosting-Empfehlung, Retention-Policy, Verschlüsselungs-Strategie und Restore-Runbook.

Aufbau der Pull-Architektur (Proxmox Setup). Lokaler PBS hochverfügbar im Cluster, Offsite-PBS bei netcup oder einem anderen EU-Provider Ihrer Wahl, dedizierter Sync-User mit DatastoreReader-Rolle, Encryption-Keys sicher hinterlegt, Verify- und Restore-Tests dokumentiert. Inklusive Provisioning als Code, sodass die Konfiguration reproduzierbar bleibt.

Betrieb mit definierten SLAs (Wartung & SLA). 24/7-Monitoring der Sync-Jobs, der Garbage Collection und der Verify-Ergebnisse. Quartalsweise Restore-Tests, monatlicher Compliance-Report an die Geschäftsleitung. Bei kritischen CVEs auf Kernel- oder PBS-Ebene reagieren wir innerhalb der vereinbarten Reaktionszeit über unser Managed CVE-Monitoring — Live-Patching für PBS-Kernel inklusive.

Ergänzend für Compliance-Pflichten: Bei NIS2-relevanten Setups dokumentieren wir die Architektur als Anlage zu Ihrer Risikomanagement-Dokumentation. Auditoren bekommen den vollständigen Nachweis: Datenresidenz, Retention, Encryption, Restore-Tests, Verify-Ergebnisse — alles auf Knopfdruck exportierbar.

Weiterführende Guides

• Proxmox Backup Server (Hub) — Übersicht zu PBS, S3-Backend und Managed-Service-Optionen
• Proxmox Disaster Recovery — RTO/RPO, Failover-Runbooks und DR-Drills für den ganzen Cluster
• Proxmox Security Hardening — Cluster-Härtung nach BSI-Empfehlung und CIS-Benchmark
• Linux-Kernel-Schwachstellen 2026: Patch-Management Chefsache — der NIS2-Kontext im Detail
• CVE-Monitoring für Self-Hosted Software — wie man strukturell auf CVE-Veröffentlichungen reagiert
• PBS 4.2 S3 Storage Stable — das S3-Backend für Object-Lock-Immutability

Sie planen ein PBS-Offsite-Setup oder zweifeln an der Sicherheit Ihrer aktuellen Backup-Architektur? Wir prüfen Ihre Konfiguration kostenfrei und liefern eine konkrete Empfehlung — Pull oder Push, lokal oder Managed, S3 oder Tape. Mit dokumentierter Retention-Policy, Restore-Runbook und Compliance-Bewertung.

Kostenloses Backup-Architektur-Review buchen · Mehr zu PBS · Proxmox-Hub