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.

Backup-Server für das NAS

Sun, 27 Apr 2025 00:00:00 +0000

Irgendwie bin ich in letzter Zeit im Backup-Fieber… Ich weiß auch nicht.

Bisher wurden die Daten von meinem NAS (etwa 8TB belegt) nicht gesichert, ich habe nur die wichtigsten paar hundert GB ab und an in meine Storagebox bei Hetzner gesynct. Damit bin ich aber nicht so zufrieden, da der Datenverlust im Zweifelsfall doch deutlich wäre.

Festplatten

Irgendwo müssen solche Datenmengen hin, so viel hat man auch nicht einfach an Festplatten herumliegen. Cloud-Speicher ist in den Größenordnungen auch eher teuer, selbst wenn man Archivspeicher (z.B. S3 Glacier bei Scaleway) nutzt. Daher habe ich hierfür Festplatten gekauft. Weil es nur um Backups geht, waren refurbished Platten für mich okay, solange die in einem RAID oder ZFS laufen. Konkret wurde es eine Seagate Enterprise Capacity mit 12TB und eine Seagate Ironwolf mit 12TB. Ich habe verschiedene Modellreihen genommen, um einem gleichzeitigen Ausfall etwas vorzubeugen.

Benchmarks

Bevor ich die Festplatten tatsächlich nutze, habe ich kurz mit CrystalDiskBench mit meinem Windows-Rechner Tests gemacht.

Server

Ich habe aus vorhandener Hardware einen kleinen Server gebaut, der dann in den Keller kommt und bei Bedarf eingeschaltet werden kann. Die Hardware ist absolut nicht herausragend, reicht für den Zweck allerdings problemlos:

CPU: Intel Pentium G3258
RAM: 4GB (zweiter Slot vom Mainboard leider defekt)
Datenträger:
- 120GB SSD (TrueNAS)
- 2x 12TB HDD

Ich habe dann das aktuelle TrueNAS Scale installiert und ein RAIDZ1 erstellt. Ich habe mich hier explizit für RAIDZ1 statt einem Mirror entschieden, damit ich später simpel die Kapazität mit z.B. einer weiteren 12TB-Platte erweitern kann. Das RAIDZ1 verhält sich mit zwei Festplatten eigentlich wie ein Mirror. Schade ist hierbei, dass sich so ein zdev nicht über die UI erstellen lässt, das muss per CLI passieren.

Datensicherung

Anfangs hatte ich die Sicherungen mit rsync gemacht, das funktioniert auch soweit gut. Es hat jedoch einen gravierenden Nachteil: Das Verschieben von Dateien wird nicht erkannt. Deswegen habe ich nun auf rclone umgestellt, weiterhin per SFTP. Dort gibt es das Argument --track-renames, was bei Dateien, die entweder nur in der Quelle oder nur im Ziel sind, versucht, ein Matching zu möglichen anderen Dateien zu machen und entsprechend umzubenennen. Das scheint auch gut zu funktionieren.

Nach einem Sync lege ich händisch einen ZFS Snapshot an, um den alten Stand einzufrieren. Mein Plan ist, dass ich den kompletten Prozess automatisiere, also dann folgende Schritte in ein Script gieße:

NAS hochfahren
Backup-NAS hochfahren
Sync ausführen und abwarten
ZFS-SNapshot auf Backup-NAS erstellen
Backup-NAS herunterfahren
NAS in Standby schicken

Das soll dann etwa 1x pro Woche erfolgen. Ich habe mich bisher mit der TrueNAS-API noch nicht auseinandergesetzt, aber ansonsten kann ich die ZFS-Snapshots auch einfach direkt per CLI erstellen.

TrueNAS on SecretMine.de