Backblaze on SecretMine.de

Mein Backupkonzept - 2025 Edition

Wed, 24 Dec 2025 00:00:00 +0000

Ein kleines Weihnachtsgeschenk? Naja. Wie dem auch sei.

Ich habe in den letzten Monaten immer wieder an meinem Backupkonzept gefeilt, bis es in der jetzigen Form stabil und weitestgehend automatisiert läuft. Das Ganze ist ein Mix aus Proxmox-Backups und Datei-Backups mit Restic - mit Fokus auf Verschlüsselung und Praktikabilität.

Proxmox-Cluster zuhause

Mein Haupt-Homelab läuft als Proxmox-Cluster. Alle VMs und LXC-Container werden täglich mit dem Proxmox Backup Server gesichert. Das Ziel ist eine billige große SSD im Cluster. Für kritische Systeme (Nextcloud, DNS, Reverse Proxy etc.) gibt es zusätzlich ein Offsite-Backup über S3 zu Backblaze B2. Der Part läuft verschlüsselt, da ich keinem Anbieter 100%ig vertraue. Wichtig war mir, dass der Backup-Server dedupliziert und komprimiert, um die Kosten für den S3-Storage möglichst gering zu halten. Da Proxmox Backup Server das inzwischen nativ kann, war der Aufwand überschaubar.

Neben dem automatischen täglichen Backup gibt es außerdem einen manuellen Sync auf eine externe Festplatte, die normalerweise im Keller lagert. Diese ist als “Removable Storage” im Backup Server eingehängt und dient als zusätzliche Offline-Kopie im Worst-Case. Ich habe auch einen Thin Client mit einer Festplatte und Proxmox Backup Server im Keller, zu dem ich unregelmäßig die Backups spiegele. Aufgrund der geringen Bandbreite in den Keller will ich diese Variante aber ablösen, dafür habe ich mit der externen Festplatte begonnen.

Nutzerdaten (Nextcloud, Gameserver usw.)

Für Dienste, die viele Nutzerdaten enthalten, setze ich zusätzlich auf Restic. Nextcloud-Daten und Backups der Gameserver werden etwa alle acht Stunden auf eine Hetzner Storage Box geladen. Auch hier läuft alles verschlüsselt, und die Snapshots lassen sich im Notfall granular wiederherstellen. Restic erfüllt neben der Verschlüsselung auch hier wieder die Kriterien mit Deduplizierung und Komprimierung, damit ich möglichst effizient viele Snapshots speichern kann.

Bei der Nextcloud gibt es generell die Besonderheit, dass ich alle Daten, um die Nextcloud wiederherzustellen (www-Verzeichnis, Datenverzeichnis, Dump der Datenbank) via Restic sichere, die virtuelle Festplatte mit den Nextcloud-Daten wird via Proxmox Backup Server aktuell wegen des Speicherbedarfs tatsächlich nicht gesichert.

NAS

Im Keller steht ein Backup-NAS mit TrueNAS. Hier laufen in unregelmäßigen Abständen manuelle rsync-Jobs, die Daten vom Haupt-NAS kopieren. Über ZFS-Snapshots sind ältere Stände ebenfalls abrufbar. Die Variante mit einem zusätzlichen NAS hat hauptsächlich Kostengründe, da das Speichern von über 10TB inkl. Snapshots sonst sehr viel teurer gewesen wäre.

vServer-Backups

Auf meinen externen vServern (hauptsächlich Docker-Dienste, diese Website und mein Mailserver) verwende ich ebenfalls Restic mit einer Hetzner Storage Box als Ziel.

Sicherung der Keys und Monitoring

Ich hatte zwischenzeitlich die Situation, dass die Keys für alle Offsite-Backups nur in einer Keepass-Datei in meiner Nextcloud gespeichert waren - die wiederum Teil genau dieser Offsite-Backups sind. Da ich alles verschlüssele, was offsite landet, hätte ich im Worst-Case zwar Backups, aber keinen Zugang mehr zu diesen Backups gehabt. Deshalb lagern die Keys mittlerweile zusätzlich auf einem USB-Stick bei meinen Eltern, just in case.

Die Backup-Scripte werden mittels Healthchecks auf ihre Ausführung überwacht, damit nicht (schon wieder) monatelang keine Backups passieren.

Offene Punkte

Was ich bisher zu selten mache sind Restore-Tests. Ich habe zwar bei jeder verwendeten Technik irgendwann mal einen Test-Restore gemacht und geprüft, aber seitdem nicht wieder getestet. Ich möchte für einige wichtige Dinge wie z.B. die Nextcloud auch Langzeitbackups einführen, die einen monatlichen Stand für mehrere Jahre effizient und günstig vorhalten können. Restic nutze ich aktuell nur mit --keep-last n, hier sollte ich eine bessere Retention Policy einsetzen. Mein Backup-Script loggt aktuell auch zu wenig - das ist generell ein offener Punkt.

Auch eine Dokumentation, wie Dinge wiederhergestellt werden können, fehlt komplett. An dem Thema bin ich aber aktuell dran. Basis wird eine möglichst automatische Datensammlung mit Ansible, Ergänzung mit eigenen Informationen und dann Erzeugen eines Wikis mittels MKDocs. Wenn ich das irgendwann mal fertig habe, gibt es dazu auch wieder einen Post.

Eine Ansible-Rolle zum Deployen vom Backup-Script wäre auch noch angenehm, aktuell passiert das komplett händisch.

Fazit

Das Setup ist über die Zeit gewachsen und sicher nicht perfekt - aber es deckt die wichtigsten Fälle ab: Hardwaredefekt, Ransomware, versehentliches Löschen und kompletten Verlust vom Cluster (bspw. durch einen Brand). Und das ganze wie üblich in möglichst kosteneffizient. Einige Dinge muss ich allerdings noch nachbessern.

Proxmox Backup Server 4 mit S3 Storage - ein Update nach einigen Wochen

Tue, 09 Dec 2025 00:00:00 +0000

Vor einiger Zeit habe ich ja Proxmox Backup Server 4 mit S3 Storage als Offsite-Backup eingerichtet. Hier nun also ein kleiner Zwischenbericht zur Speicherbelegung.

Ich sichere aktuell 8 LXCs zu dem Backup-Repo, pro CT werden jeweils drei Backups behalten. Im Bucket liegen 11,5 GB und etwa 7500 Dateien. PBS scheint aber im Bucket nur eher wenige Aktionen durchzuführen - auf der Abrechnung von Backblaze ist nur der belegte Speicher relevant, die S3-Operationen liegen bei mir komplett im kostenfreien Bereich. Proxmox Backup Server zeigt bei dem Repo eine Belegung von 8 GB an, das scheint nur der lokal zwischengespeicherte Part zu sein. Der Deduplizierungsfaktor liegt bei etwas über 7, das entspricht grob dem Faktor, den ich auch sonst erreiche.

Insgesamt sieht es für mich bisher so aus, als ob das ganze gut funktioniert. Große Restore-Tests habe ich allerdings weiterhin nicht gemacht und Stand heute ist das S3-Feature auch weiterhin nur eine Tech-Preview - also mit Vorsicht zu genießen und sollte nicht das einzige Backup sein.

Proxmox Backup Server 4 mit S3 Storage - diesmal in Richtig

Thu, 25 Sep 2025 00:00:00 +0000

Proxmox Backup Server 4 hat eine erste tech preview für S3-Speicher mit drin, um offsite Backups zu speichern. Das ist durch die Deduplizierung und Komprimierung ideal, um günstig Backups zu machen. Als S3-Provider nutze ich Backblaze B2, da der Storage hier recht günstig ist (okay, ich hab auch einfach schon einen Account da). Die Backups werden auch lokal zwischengespeichert, es bedeutet also einiges an Schreibvorgängen auf der SSD/HDD.

Achtung! Das ganze ist noch im Preview-Stadium und ist mit Vorsicht zu genießen!

Bucket erstellen

Im Backblaze B2 Webinterface einen neuen Bucket anlegen.
- Bucket-Name: lowercase (z. B. pbsoffsite)
- Endpunkt notieren, z. B.: s3.eu-central-002.backblazeb2.com
Lifecycle-Einstellungen für den Bucket setzen:
- Nur die letzte Version der Datei aufbewahren

Application Keys erstellen

Im Menü Application Keys → Add New wählen.
Namen definieren, z. B.: PBSOffsiteKey
Im Feld Allow access to Bucket(s) den eben erstellten Bucket auswählen.
Haken setzen bei Allow List All Bucket Names

Die Ausgabe enthält die benötigten Werte:

1
2


keyID: keyIDblablablub
applicationKey: blablablub

S3 Endpoint im PBS hinzufügen

Im PBS-Webinterface einen S3-Endpoint hinzufügen:

ID: bspw. backblaze
Endpoint: ``{{bucket}}.s3.{{region}}.backblazeb2.com`
Region aus dem Endpunkt ableiten, z. B. eu-central-002
Access Key (keyID) und Secret Key (applicationKey) eintragen
Advanced → Provider Quirks: Skip If-None-Match header aktivieren

Cache-Verzeichnis erstellen

Die Doku empfiehlt hier 64-128GB Speicher. Ich nutze LVM-Thin und habe dementsprechend auf dem Host ein neues Volume erstellt und gemountet. Das Anlegen eines neuen logischen Volumes bei LVM geht mit folgendem Befehl:

1

lvcreate -V 100G -T vg-data/thinpool -n pbs-s3

Gemountet habe ich das unter /mnt/pbs-s3.

Datastore hinzufügen

Name: backblaze
Local Cache: /mnt/pbs-s3
S3 Endpoint ID: passenden Endpoint auswählen
Bucket: den angelegten Bucket auswählen. Wenn hier nichts auftaucht oder ein Fehler erscheint, stimmt was mit den Zugangsdaten nicht oder der Bucketname ist z.B. nicht kleingeschrieben.
Prune Options: nach Bedarf konfigurieren

Datastore nutzen

Ich habe nun also in Proxmox einen zweiten Proxmox Backup Server als Storage eingefügt und einen zweiten Backup-Job mit dem Offsite-Storage und nur den wichtigsten Containern und VMs angelegt. Ich lasse das aktuell erstmal nur mit eher kleinen Backups laufen, bis ich ein Gefühl dafür bekommen habe, was mich das dann am Ende so kostet. Irgendwann wird dementsprechend ein Update-Post folgen.

Ein Restore-Test steht auch noch aus…

Backups von Pterodactyl in S3 speichern

Sun, 20 Oct 2024 00:00:00 +0000

Pterodactyl bietet als Möglichkeit an, Backups zu erstellen. Das muss konfiguriert werden, wie das geht steht in der Doku unter https://pterodactyl.io/panel/1.0/additional_configuration.html. Standardmäßig kommt hierfür ein Verzeichnis auf den Nodes zum Einsatz, was meistens auch genügt. Es gibt allerdings auch die Option, die Backups in einem S3-Bucket zu speichern.

Ich habe mich dazu entschieden, die Option mit S3-Speicher zu nutzen. Einerseits liegen damit alle Backups am selben Ort und belegen lokal auf den Nodes keinen Speicher, andererseits ist Off-Site bei Backups immer besser. Als Storage-Anbieter für S3 habe ich mich hierbei für Backblaze entschieden. Es handelt sich nicht um hochkritische Daten und Nutzer bin nur ich selbst, daher halte ich es für vertretbar, diese Daten bei einem US-Unternehmen zu speichern. Es gibt mit OVH oder Scaleway (und bald Hetzner) aber auch europäische Anbieter, die S3-Speicher anbieten. Backblaze war einfach die günstigste Option und hat keine Mindestabnahme o.ä..

Ich habe also ein Bucket bei Backblaze angelegt, in den Lifecycle-äEinstellungen vom Bucket es so eingestellt, dass nur die letzte Version einer Datei erhalten bleibt und dann einen Application Key für dieses Bucket erzeugt.

In Pterodactyl werden die Einstellungen fürs Backup in der .env im Hauptverzeichnis vom Panel durchgeführt. Dort habe ich folgende Einstellungen vorgenommen:

1
2
3
4
5
6


AWS_USE_PATH_STYLE_ENDPOINT=true
AWS_DEFAULT_REGION=eu-central-003 # Die Region kannst du der Endpoint URL vom Bucket bei Backblaze entnehmen
AWS_ACCESS_KEY_ID=<keyID von Backblaze>
AWS_SECRET_ACCESS_KEY="<applicationKey von Backblaze>"
AWS_BACKUPS_BUCKET=<Bucket Name>
AWS_ENDPOINT="https://s3.eu-central-003.backblazeb2.com/" # Der Endpoint steht in der Bucketübersich beim Bucket dabei

Danach sollte es schon möglich sein, Backup zu erstellen, diese sollten auch dann im Bucket landen. Bei mir funktioniert das seit einigen Monaten so stabil.