Angebote · Proxmox Backup Server · Dedup · Verify · Restore
Backup
heißt Restore.
Proxmox Backup Server speichert deduplizierend, prüft seine Snapshots automatisch und gibt sie im Ernstfall wieder her — vom einzelnen File bis zum kompletten Cluster. Wir planen, betreiben und testen den Restore.
Die Ausgangslage
Ein Backup, das nie getestet wurde, ist kein Backup.
Tar-Skripte, USB-Platten-Rotation, monatliche Vollbackups — viele KMU-Backups sind über die Jahre gewachsen statt geplant. Im Ernstfall stellt sich heraus, dass das letzte Backup zu klein war, zu alt ist oder schlicht nicht zurückkommt. PBS dreht das um: dedupliziert, verifiziert, getestet.
- Dedup-Faktor bis 25× Deduplizierung bei vielen ähnlichen VMs, wie Anwender im Proxmox-Forum sie messen; bei gemischten Beständen sind 5–10× realistischer
- Inkrementell ab Lauf 2 nach dem ersten Vollbackup wandern nur geänderte Blöcke — Backup-Fenster schrumpfen drastisch
- Lizenz 0 € Community-Edition vollständig produktionsreif. Subscription nur für Enterprise-Repos optional
Die Lösung
Drei Standorte. Eine Restore-Logik.
VMs und Linux-Hosts sichern verschlüsselt auf den primären PBS — der synchronisiert die Snapshots auf einen zweiten PBS an einem anderen Standort. 3-2-1-Regel ohne Tape-Roboter, mit zentralem Restore aus jedem Standort.
Verifikation läuft kontinuierlich im Hintergrund.
- 01 — Speicherung
Dedup, verifiziert, verschlüsselt
PBS speichert Block-basiert dedupliziert, prüft Snapshots regelmäßig auf Integrität und verschlüsselt Client-seitig — der Backup-Server selbst sieht nur unlesbare Chunks.
- Block-basierte Deduplikation
- Inkrementell ab dem zweiten Lauf
- Automatische Hash-Verifikation jedes Snapshots
- Client-seitige Verschlüsselung (AES-256-GCM)
- 02 — Wiederherstellung
Vom Einzelfile bis zur ganzen VM
Restore ist der eigentliche Test eines Backups. PBS erlaubt granulare Wiederherstellung — einzelne Files, ganze VMs, Container, oder vollständige Linux-Hosts.
- File-Level-Restore aus VM-Images
- VM- und Container-Restore in Proxmox VE
- Linux-Host-Restore via proxmox-backup-client
- Live-Restore für laufende VMs
Kernfunktionen im Überblick
Was einen ernsthaften Backup-Server ausmacht.
-
Deduplikation
Block-basiert: gleiche Datenblöcke landen einmal auf dem Storage, unabhängig davon, in wie vielen VMs oder Snapshots sie auftauchen.
-
Inkrementell-Forever
Nach dem initialen Vollbackup nur noch Deltas — keine wöchentlichen Vollbackups mehr, keine künstlichen Backup-Fenster.
-
Verifikation
Snapshots bekommen automatische Hash-Checks im Hintergrund — Bitrot, Storage-Fehler und korrupte Chunks werden sichtbar, bevor man sie braucht.
-
Client-Encryption
Verschlüsselung passiert vor dem Upload, der Schlüssel bleibt beim Client. Selbst ein kompromittierter PBS-Server gibt nur unlesbare Chunks her.
-
Replikation
Sync zwischen zwei PBS-Standorten — verschlüsselt, dedupliziert, inkrementell. 3-2-1-Regel ohne Tape-Roboter erfüllbar.
-
Universal-Client
Nicht nur Proxmox VE: der proxmox-backup-client sichert beliebige Linux-Hosts file- oder block-basiert direkt in den PBS.
Regulatorischer Kontext
3-2-1, BSI, DSGVO, NIS2 — strukturell erfüllt.
- 3-2-1-Regel Branchen-Standard Drei Kopien, zwei verschiedene Medien, eine offsite. Mit PBS + Replikation strukturell erfüllt — kein Tape-Roboter, keine USB-Platten-Rotation nötig.
- BSI CON.3 IT-Grundschutz-Baustein Datensicherungskonzept ist Pflichtbaustein im IT-Grundschutz. PBS liefert die technische Umsetzung samt Verifikation und Restore-Test.
- DSGVO Art. 32 Technische Maßnahmen Backups als Teil der „Wiederherstellbarkeit personenbezogener Daten" — verschlüsselt, dokumentiert, getestet.
- NIS2 Art. 21.2.c Business Continuity NIS2 verlangt nachweisbare Wiederherstellbarkeit — PBS-Logs, Verifikations-Reports und Restore-Tests sind genau dieser Nachweis.
Setup-Pakete
Welcher Scope passt zu Ihrer Umgebung?
- Scope 01
Standalone
Ein PBS-Server mit lokalem Storage — der Einstieg für KMU mit überschaubarem Datenvolumen und einem Standort.
- PBS auf eigener Hardware
- Deduplikation, Verifikation, Verschlüsselung
- Backup für Proxmox VE und Linux-Hosts
- Replikation an Zweitstandort (nicht enthalten)
- Multi-Site und Tape-Anbindung (nicht enthalten)
- Scope 02 Empfehlung
Replicated
Zwei PBS-Server an unterschiedlichen Standorten, synchronisiert — die 3-2-1-Regel strukturell umgesetzt, ohne Tape-Roboter.
- Alles aus Standalone
- Zweiter PBS an separatem Standort
- Verschlüsselte Replikation
- Getrennte Encryption-Keys
- Multi-Site und Tape-Anbindung (nicht enthalten)
- Scope 03
Enterprise
Mehrere Standorte, optionale Tape-Anbindung, dokumentierte Restore-SOPs — für Unternehmen mit strengen Compliance-Anforderungen.
- Alles aus Replicated
- Multi-Site-Replikation
- Tape-Anbindung (LTO)
- Dokumentierte Restore-SOPs
- Vierteljährliche Restore-Übungen
So sieht die Einführung aus
In vier Schritten zum getesteten Backup.
-
Assessment
Workloads, Datenmengen, RPO/RTO-Ziele, Compliance-Anforderungen, Standorte für Replikation.
-
Setup
Hardware-Sizing, ZFS-Storage-Pool, Verschlüsselungsstrategie, Netzwerkanbindung, Monitoring.
-
Erstbackup
Volles Initialbackup aller Workloads, Verifikation, Aufbau der Retention-Policy und Replikation.
-
Managed Operation
Verifikations-Monitoring, regelmäßige Restore-Tests, Reporting, Kapazitätsplanung.
Typische Time-to-First-Backup bei mittelständischen Kunden: 1 bis 2 Wochen bis das primäre PBS-Setup läuft. Das Initial-Vollbackup dauert je nach Datenvolumen entsprechend länger.
Warum pad.systems
PBS ist die Software. Wir sind die, die regelmäßig restoren — bevor jemand fragen muss.
pad Software GmbH · Puchheim bei München · seit über 30 Jahren
- 01 Konzept & Sizing Datenvolumen, Retention, Replikationsstrategie und Hardware-Auswahl.
- 02 Implementierung Installation, ZFS-Pool, Verschlüsselung, Replikation, Backup-Jobs aufsetzen.
- 03 Managed Service Tägliche Verifikation, monatlicher Restore-Test, Kapazitäts-Reporting.
- 04 Notfall-Restore Definierte Reaktionszeiten und SOPs für den eigentlichen Ernstfall — vom File bis zum kompletten Cluster.
Wann war Ihr letzter Restore-Test?
Ein 30-minütiges Erstgespräch reicht, um den passenden Backup-Scope abzustecken und eine realistische Sizing-Schätzung zu liefern.