Backup 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.

Scriptausführung mit Healthchecks überwachen

Fri, 31 Oct 2025 00:00:00 +0000

Ich nutze für regelmäßige Backups von Daten (z.B. Nextcloud) ein kleines Script, das Restic verwendet. Ich hatte allerdings schon mehrfach den Fall, dass ein Backup nicht sauber durchlief und das Backup-Repository damit gesperrt war und weitere Backups fehlschlugen, was ich dann natürlich erst Wochen (okay, Monate) später bemerkt habe.

Abhilfe schafft hier das Tool Healthchecks (https://github.com/healthchecks/healthchecks). Das funktioniert so, dass man Checks einrichtet und dafür eine Webhook-URL bekommt. In einem Script ruft man dann diese URL auf und setzt damit den Timer zurück. Sofern der Webhook nicht innerhalb der richtigen Zeit aufgerufen wird, wird ein Alert ausgelöst. Insgesamt also recht simpel.

Installation

Ich nutze hier, wie üblich, Docker. Hier meine docker-compose.yml:

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


services:
 healthchecks:
 image: healthchecks/healthchecks:latest
 container_name: healthchecks
 environment:
 - DB=sqlite
 - DB_NAME=/data/hc.sqlite
 - DEBUG=False
 - DEFAULT_FROM_EMAIL=me@example.com
 - EMAIL_HOST=smtp.example.com
 - EMAIL_HOST_PASSWORD=MyMailPassword
 - EMAIL_HOST_USER=me@example.com
 - EMAIL_PORT=587
 - EMAIL_USE_TLS=True
 - SECRET_KEY=Hok4K0Va6EwaYltk4ah7muc223rUVmz3
 - SITE_ROOT=https://checks.example.com
 - DISCORD_CLIENT_ID=123123
 - DISCORD_CLIENT_SECRET=123123
 - REGISTRATION_OPEN=False
 ports:
 - 8000:8000
 volumes:
 - ./data:/data
 restart: unless-stopped

REGISTRATION_OPEN muss initial auf True gestellt werden, damit man sich selbst registrieren kann, danach sollte das allerdings wieder auf False gesetzt werden, damit sich keine fremden User registrieren können. Ich habe hier direkt die Discord-Integration eingerichtet, damit ich auf dem Weg auch Notifications verschicken kann. Die beiden Variablen sind aber natürlich optional.

Das Datenverzeichnis muss die richtigen Zugriffsrechte haben, damit der Container starten kann. Das geht schnell mittels

1
2


mkdir ./data
chown -R 999:999 ./data

Danach lässt sich der Stack mit docker compose up -d starten und die Seite aufrufen. Dort kann man sich dann mit einer E-Mail-Adresse registrieren.

Einbindung in ein Script

Um jetzt einen Check einzurichten, muss zuerst im Webinterface ein neuer Check erstellt werden. Dabei wird auch das normale Intervall (z.B. täglich) sowie eine Karenzzeit eingestellt.

Nun wird eine Check-URL angezeigt, ich nehme hier https://checks.example.com/ping/bla-bla-blub als Beispiel.

Simpler Check

Für einen einfachen Check, ob das Script gelaufen ist, reicht es, einen Befehl wie z.B.

1

curl -fsS -m 10 --retry 5 https://checks.example.com/ping/bla-bla-blub

mit der Check-URL auszuführen. Der Befehl sollte im Script als letztes ausgeführt werden, damit er erst ausgeführt wird, wenn alles andere funktioniert hat.

Check mit Laufzeitberechnung

Healthchecks kann auch die Laufzeit eines Scripts mit prüfen. Dazu wird erst der Endpunkt https://checks.example.com/ping/bla-bla-blub/start aufgerufen und nach Fertigstellung dann https://checks.example.com/ping/bla-bla-blub. Hierbei sollte auch noch eine Request-ID mitgegeben werden, um die einzelnen Ausführungen voneinander unterscheiden zu können.

Ich habe das bspw. so umgesetzt:

1
2
3
4
5
6
7
8


set -e
RID=`uuidgen`
HEALTHCHECK_ID=bla-bla-blub
curl -fsS -m 10 --retry 5 https://checks.example.com/ping/$HEALTHCHECK_ID/start?rid=$RID

# do backup

curl -fsS -m 10 --retry 5 https://checks.example.com/ping/$HEALTHCHECK_ID?rid=$RID

Nachdem das Script ausgeführt wurde, sieht das im Webinterface so aus:

Sollte ein Check nicht innerhalb der eingestellten Zeit aufgerufen werden, wird eine Notification ausgelöst. So sollte ich in Zukunft fehlschlagende Backups schneller bemerken.

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…

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.

Proxmox Backup Server für den Hauptcluster

Sun, 30 Mar 2025 00:00:00 +0000

Ich habe schon länger darüber nachgedacht, wie ich gut und günstig meine VMs und Container sichern kann. Ich hatte in dem Zuge erst PBS über S3 getestet, was lief, aber nicht optimal war - und dann lange einen externen Anbieter (Tuxis) für PBS genutzt. Da bin ich mit 150GB allerdings beim Speicherplatz stark eingeschränkt.

Bisherige Backup-Strategie

Bisher landen die wichtigsten VMs und Container auf einem externen PBS-Server bei Tuxis, die Dateien der Nextcloud werden mittels restic auf eine Storage-Box bei Hetzner gesichert. Das deckt aber nur einen Teil der VMs und Container ab, und vor allem ist die Wiederherstellung teilweise aufwändiger. Daher habe ich schon länger den Wunsch, das ganze zu vereinfachen

Der Plan

Ich habe eine billige 1TB Sata-SSD gekauft (genauer gesagt eine Lexar NQ100 im Angebot). Diese soll in den dritten Host (der Mini-PC, Lenovo Tinkcentre M715q Tiny) kommen, damit dort dann Proxmox Backup Server laufen kann. Damit habe ich dann genügend Kapazität, um wirklich alle VMs und Container zu sichern und bei Bedarf schnell wiederherstellen zu können.

Die Umsetzung

Ich habe also die SSD verbaut (nebenbei auch noch die NVMe von 240GB auf 480GB getauscht und mittels gparted die bisherigen Partitionen kopiert und vergrößert).

Installation von PBS

Ich habe PBS direkt mit auf dem Host installiert. Da das ein Proxmox ist, war das auch nicht weiter schwierig (wäre es allerdings auf jedem Debian nicht). In der Doku befindet sich dazu auch eine Anleitung, die man recht gut befolgen kann (https://pbs.proxmox.com/docs/installation.html#install-proxmox-backup-server-on-proxmox-ve). Vor dem apt-Befehl muss man aber noch manuell das APT-Repo hinzufügen. Die ganze Installation sieht also etwa so aus:

1
2
3
4


wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" > /etc/apt/sources.list.d/pbs.list
apt update
apt install proxmox-backup-server

Die Befehle habe ich vor dem Posten nicht getestet, das habe ich jetzt im Nachhinein noch kurz zusammengesammelt.

Danach ist Proxmox Backup Server unter https://[host]:8007 erreichbar.

Lexar NQ100 für diesen Zweck

Die SSD scheint soweit gut geeignet als Backup-Ziel zu sein, auch wenn ich leichte Zweifel an der Langlebigkeit dieser SSD habe. Das liegt aber eigentlich nur am Preis, mir sind generell bisher eigentlich fast keine SSDs kaputt gegangen (eine noname 32GB SSD aus Chinau und eine 240GB Billig-SSD von Toshiba).

Spiegel vom PBS Datastore

Proxmox Backup Server kann Backups auf einen externen Server replizieren. Ich habe im Keller im zweiten Part vom Homelab einen Thin-Client (Fujitsu Futro S720) mit einer Sata-HDD, der als Backup-Server und Storage für die Server im Keller dient. Dorthin will ich einen (unregelmäßigen und manuellen) Sync einrichten, damit ich zumindest halb-offsite auch noch einen schnell verfügbaren Spiegel habe.

Proxmox Backup Server kostenlos (bei Tuxis)

Fri, 14 Mar 2025 00:00:00 +0000

Was ist Proxmox Backup Server überhaupt?

Der Proxmox Backup Server (PBS) ist eine Open-Source-Lösung zum Sichern von virtuellen Maschinen (VMs), Containern und physikalischen Hosts. Besonders in Kombination mit Proxmox VE ist PBS ideal, um effiziente und sichere Backups zu erstellen. PBS ist in Proxmox VE direkt integriert.

PBS unterstützt deduplizierte und inkrementelle Backups, was bedeutet, dass nur geänderte Daten gesichert werden, um Speicherplatz zu sparen. Backups können zudem komprimiert und verschlüsselt werden, was die Sicherheit und Effizienz erhöht.

Der kostenlose Anbieter

Durch Zufall bin ich bei Reddit in einem Kommentar darauf gestoßen, dass es einen Anbieter gibt, der Proxmox Backup Server mit 150 GB Speicherplatz komplett kostenfrei anbietet. Tuxis ist ein IT-Service-Provider mit Sitz in den Niederlanden.

Der Link zum Angebot: https://www.tuxis.nl/de/proxmox-backup-server/

Beim Schreiben dieses Posts muss ich leider feststellen, dass es die kostenlosen Pakete zumindest Stand heute nicht verfügbar sind. Vielleicht kommen die noch wieder, vielleicht aber auch nicht.

Meine Erfahrung

Ich habe den kostenlosen PBS also bestellt und innerhalb weniger Minuten die Zugangsdaten bekommen. Das ganze habe ich dann auch direkt in meinem Homeserver eingerichtet, hierbei mit Verschlüsselung, da die Daten nicht in meiner Hoheit liegen. Der Backup Space funktioniert, hat bisher keinerlei Fehler geworfen und scheint auch zuverlässig zu sein. Ich nutze das ganze allerdings auch erst seit ein paar Tagen, von daher kann ich zur langfristigen Stabilität noch nichts sagen. Bei kostenlosen Angeboten wie diesen muss man natürlich auch immer damit rechnen, dass das Angebot ohne große Ankündigung eingestellt wird, daher nutze ich es auch nur als zusätzliches Offsite-Backup. Ich gebe mir dabei auch Mühe, dass ich nicht zu viel Platz belege, immerhin ist es ein kostenloses Angebot, von dem ich hoffe, dass es so schnell nicht eingestellt wird.

Alternativen

Mir sind sonst auf dem Markt nicht wirklich viele Alternativen (also bezahlt) bekannt, die PBS anbieten. Es gibt sie aber. Ansonsten geht natürlich auch ein vServer mit genügend Storage - dafür findet man auch problemlos Anbieter (teilweise auch mit kleinem SSD-Boot-Speicher und dickem HDD-Speicher dazu). Und PBS statt reinem Storage (z.B. Hetzner Storage Box oder so) hat den großen Vorteil, dass die Deduplizierung bzw. inkrementelle Sicherung greift (und damit nicht nur Speicherplatz, sondern auch Bandbreite spart). Bei mir ist das aktuell (insgesamt knapp 300 Snapshots) ein Deduplizierungsfaktor von etwa 17.

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.