S3 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…

Proxmox Backup Server mit S3 Storage

Tue, 22 Oct 2024 00:00:00 +0000

Update: Es gibt bei Proxmox mittlerweile die Option, S3 nativ zu nutzen. Dazu habe ich auch hier einen neuen Post geschrieben.

Was ist JuiceFS?

In einem anderen Post hatte ich bereits von JuiceFS berichtet. Das ist ein Dateisystem, was einen Object Storage mit einer Datenbank verbindet, um so möglichst Posix-Compliant zu sein. Das heißt also, dass die Dateiinhalte in einem S3-Bucket landen, die Metadaten und Verzeichnisstrukturen liegen dann in z.B. einer MariaDB.

Das hatte ich erst für Nextcloud getestet, was auch soweit funktioniert hat. Zu dem Zeitpunkt war mir das ganze aber nicht geheuer, weshalb ich es produktiv dafür nicht einsetzen wollte und auch weiterhin nicht vor habe.

Die Kombination

Im Proxmox-Forum und bei Reddit findet man Beiträge dazu, wie Leute Proxmox Backup Server (PBS) mittels rclone mit einem S3-Speicher verbunden haben, um die Backups eben in S3 zu lagern. Das hat allerdings nur so lange funktioniert, wie leere Verzeichnisse im Cache von rclone waren, da S3 prinzipbedingt nicht mit leeren Verzeichnissen umgehen kann. JuiceFS dürfte diese Lücke füllen, da durch die Trennung von Inhalts- und Metadaten die Unterstützung für alle relevanten Attribute und co wiederhergestellt wird.

Das Setup

Benötigt wird ein Debian-Server mit folgenden installierten Komponenten:

Proxmox Backup Server (entweder von der ISO installieren oder zusätzlich installieren, siehe hier: https://pbs.proxmox.com/docs/installation.html)
MariaDB-Datenbank (in meinem Test lokal installierter Server)
JuiceFS (Installation siehe hier: https://juicefs.com/docs/community/getting-started/installation/)
Ein S3-Bucket (in meinem Test MinIO, aber es geht natürlich auch alles andere)

JuiceFS-Storage anlegen

Ich habe also die Datenbank und ein S3-Bucket angelegt und dann mit folgendem Command den JuiceFS-Store angelegt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


# diese Variable nutze ich, um die Zugangsdaten und Pfade zur Datenbank nicht jedes Mal neu angeben zu müssen
# Diese Zeile muss pro SSH-Session, in der mit JuiceFS gearbeitet werden soll, neu ausgeführt werden.
export METAURL=mysql://[user]:[passwort]@([datenbankserver]:3306)/[datenbankname]
# bei mir:
# export METAURL=mysql://juicefs:pbspbspbs@(localhost:3306)/juicefs

juicefs format \
 --storage s3 \
 --bucket [bucket-url] \
 --access-key [access-key] \
 --secret-key [access-secret] \
 $METAURL \
 pbsfs --trash-days=0

# bei mir:
#juicefs format \
# --storage s3 \
# --bucket http://s3.homelab.local:9000/pbs \
# --access-key pbs \
# --secret-key pbspbspbs \
# $METAURL \
# pbsfs --trash-days=0

Output:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


2024/10/20 10:14:59.175588 juicefs[15366] <INFO>: Meta address: mysql://juicefs:****@(localhost:3306)/juicefs [interface.go:504]
2024/10/20 10:14:59.177822 juicefs[15366] <INFO>: Data use s3://pbs/pbsfs/ [format.go:484]
2024/10/20 10:14:59.372276 juicefs[15366] <INFO>: Volume is formatted as {
 "Name": "pbsfs",
 "UUID": "97f66daa-c003-4b5b-b1ed-af4788cfbb06",
 "Storage": "s3",
 "Bucket": "http://s3.homelab.local:9000/pbs",
 "AccessKey": "pbs",
 "SecretKey": "removed",
 "BlockSize": 4096,
 "Compression": "none",
 "EncryptAlgo": "aes256gcm-rsa",
 "KeyEncrypted": true,
 "TrashDays": 0,
 "MetaVersion": 1,
 "MinClientVersion": "1.1.0-A",
 "DirStats": true,
 "EnableACL": false
} [format.go:521]

Damit wird nun also ein JuiceFS-Store angelegt. Die Daten für das S3-Bucket werden dabei mit im Metadaten-Speicher (also der MariaDB-Datenbank) abgelegt und müssen nicht noch mal eingegeben werden.

JuiceFS mounten

Mittels

1
2


mkdir /mnt/jfs
juicefs mount --update-fstab --background $METAURL /mnt/jfs

können wir nun das JuiceFS unter /mnt/jfs mounten, der Parameter --update-fstab sorgt dafür, dass direkt auch eine neue Zeile in der fstab angelgt und das JuiceFS beim Systemstart mit gemountet wird.

Mit

1

juicefs config $METAURL --capacity 100

lässt sich auch ein Quota festlegen, hier 100GB. Ansonsten hat ein JuiceFS theoretisch unbegrenzte Kapazität bzw. legt kein Limit fest.

Storage in PBS einrichten

In PBS können wir nun einen neuen Datastore hinzufügen und /mnt/jfs als Pfad angeben. Das Anlegen eines Storages wird allerdings eine ganze Zeit dauern, da hierbei einige Tausend Verzeichnisse erzeugt werden. In meinem Fall hat das etwa 20 Minuten gedauert, lokal ging das immer sehr viel schneller. Danach lässt sich der Storage normal in einem Proxmox VE Server einbinden und nutzen.

Performance

Meine Werte sind leider nur semi-aussagekräftig, da der Minio-Server, der hier als S3-Storage dient, wirklich langsam ist. Ich habe hierbei grob 5 MB/s bei Backups erreicht zeitweise auch 40 MB/s. Ich gehe davon aus, dass mit passend schnellem S3-Storage die reale Leistung eher bei den 40 MB/s liegt, sicher sagen kann ich das aber nicht.

Fazit

Da die Performance soweit okay ist, kann ich mir gut vorstellen, das auf einem vServer im Rechenzentrum mit einem Backblaze B2 Bucket als Storage tatsächlich zu verwenden bzw. dem ganzen so zumindest einem Langzeittest auszusetzen. Ich habe bislang mit JuiceFS auch außerhalb von solchen kurzen Tests wenig Erfahrung. Wenn es gut funktioniert, wäre es aber eine wirklich coole Möglichkeit, um günstig viel Speicher für Proxmox zu bekommen. Ich habe bisher allerdings auch keine Werte bzgl. Trafficnutzung und auch Anzahl der API-Calls, die beim S3-Storage entstehen, das kann schnell zu Kosten führen.

Update

Kleines Update: Ich habe das so temporär auf einem vServer mit Backblaze als Backend in Betrieb. Über etwa 1-2 Wochen hinweg habe ich nun getestet - das ganze lief stabil und mit brauchbarer Performance. Was dauert sind Operationen mit vielen kleinen Dateien, da merkt man dann die andere Speicherart. Generell kann man das nutzen, aber ich würde mich da nicht als einzige Backup-Lösung drauf verlassen - dafür fühlt sich das ganze zu sehr nach einer Bastellösung mit zu vielen beweglichen Teilen an.

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.