Proxmox on SecretMine.de

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.

Der Fujitsu Futro S740 im Homelab – Der ideale Server?

Thu, 27 Nov 2025 00:00:00 +0000

Der Fujitsu Futro S740 ist nun seit fast drei Jahren zentraler Bestandteil meines Homelabs und ist auch hier im Blog regelmäßig Thema. Es wird Zeit, mal Bilanz zu ziehen und etwas zu meinen Langzeiterfahrungen zu schreiben.

Leistung und Einsatz im Cluster

Die Leistung des Futro S740 reicht für viele Homelab-Anwendungen aus, ist jedoch begrenzt. Aber gut, was erwartet man auch von einem Gerät, das als Thin Client konzipiert wurde und einen passiv gekühlten Intel Celeron verbaut hat. Gerade bei Single-Thread-Anwendungen und virtuellen Maschinen merkt man schnell den Overhead und die begrenzte CPU-Power. Deshalb bevorzuge ich Proxmox LXC-Container, die deutlich ressourcenschonender sind, schneller starten und effizienter laufen. Für wirklich rechenintensive Anwendungen ist der S740 einfach nicht gebaut.

Neben zwei Futro S740 läuft in meinem Proxmox-Cluster auch ein leistungsstärkerer Mini-PC. Auf diesem laufen Workloads, die mehr CPU-Leistung brauchen, wie Gameserver, Windows-VMs und Linux-Workstation-VMs. So verteile ich die Last passend und nutze die Hardware im Cluster optimal.

Hardwareerweiterungen

Meistens kommt der Futro S740 mit 8/16 GB EMMC-Speicher und 4 GB RAM. Das lässt sich aber deutlich aufrüsten.

Speicher

Eine gute SATA-SSD ist für den Futro Pflicht, um vernünftige I/O-Performance zu gewährleisten. Ich habe zusätzlich eine NVMe-SSD im M.2-Slot für Wifi mit einem simplen Adapter eingebaut. Der Einbau erfordert etwas unorthodoxe Maßnahmen, funktioniert aber auch auf Dauer stabil. Obwohl dieser Slot technisch nicht die volle NVMe-Bandbreite bietet, spürt man die geringeren Latenzen und deutlich höheren IOPS trotzdem. Wichtig ist, hier auf gute Qualität zu achten und lieber kein QLC-Modell zu verwenden. Auch wenn der Slot limitiert ist, lohnt sich die Investition in eine zuverlässige und langlebige SSD, damit der Storage nicht zum Flaschenhals wird.

Auf ZFS habe ich bei den Futros verzichtet, auch wenn ich sonst wegen der transparenten Komprimierung und dem integrierten Volume-Manager ein großer Fan bin. Auf den Thin Clients hat sich Thin LVM als deutlich schlanker und von den Features her ausreichend bewiesen.

RAM

Der maximale RAM-Ausbau liegt bei 16 GB, was für die meisten Homelab-Nutzer ausreicht. Damit lässt sich auf jeden Fall einiges erreichen. Wer mehr will, muss sich nach anderer Hardware umsehen. Es empfiehlt sich auch, möglichst gleich 16 GB zu verbauen, um genug Reserven zu haben und nicht später noch wieder neuen RAM kaufen zu müssen.

Stromverbrauch und Lautstärke

Das Highlight ist der sehr niedrige Stromverbrauch: Der Futro benötigt im Alltag oft nur um die 5 Watt, was ihn ideal für den Dauerbetrieb macht. Die passive Kühlung macht ihn auch komplett lautlos, wobei man beim Betrieb von mehreren Futros auf eine gute Belüftung achten sollte. Ich habe bei mir einen 120mm-Lüfter, der für Kühlung sorgt.

Was ich auf den Futros betreibe

Die Liste ist tatsächlich recht lang.

Zentral ist HomeAssistant, dazu ist am ersten Futro S740 auch ein Zigbee-Stick angeschlossen. Außerdem habe ich einen ADSB-Empfänger, womit ich Daten an z.B. FlightRadar24 übertrage. Dazu folgt vielleicht auch mal ein Post.

Nextcloud mit Collabora ist ein weiterer sehr zentraler Dienst, das ist die Hauptaufgabe vom zweiten Futro. Dazu (und auch zu diversen anderen Services) gehört natürlich auch ein Reverse-Proxy, wofür Caddy in einem weiteren LXC läuft.

Ansonsten laufen zwei Blocky-Instanzen für redundantes DNS, Bind als authoritativer DNS-Server für lokale DNS-Zonen, der Unifi-Controller für meinen Access Point und Smokeping für Latenz-Monitoring. Prometheus, Alertmanager und Grafana darf natürlich auch nicht fehlen. Harbor als lokale Registry (dazu könnte ich auch mal schreiben), Lyrion Music Server, Memos als Notizbuch, Code-Server als Blog-Editor und Firefly3 für die Haushaltsfinanzen. Uptime-Kuma darf natürlich auch nicht fehlen.

Und das ist mit Sicherheit noch nicht alles, das ist nur das, was ich gerade im Kopf habe. Generell lässt sich sagen, dass man mit den Futros mehr machen kann, als man so denkt. Die meisten der Services benötigen im Normalbetrieb fast keine Rechenleistung, damit lande ich bei um die 40 % konstante CPU-Last auf beiden Hosts. Beim RAM sind jeweils 11-12GB voll.

Generell kann man eigentlich alles auf den Dingern betreiben, nur von Dingen wie einer Windows-Workstation-VM oder einem Minecraft-Server würde ich wegen der fehlenden Single-Core-Performance eher absehen.

Weitere mögliche Szenarien

Mit einem DAS, also einem per USB angebundenen Gehäuse für mehrere Festplatten, lässt sich der S740 mit einem OS wie TrueNAS oder unRAID auch sicherlich gut als NAS verwenden. Die integrierte Intel-GPU kann hier bei einem Mediaserver wie Plex auch Transcoding durchführen. Über den Wifi-Slot lässt sich statt der SSD laut dem Internet auch eine zweite Netzwerkkarte (mit z.B. auch 2,5 GBit/s) verbauen, damit wäre auch der Einsatz als Router denkbar.

Ein effizienter Kubernetes-Cluster ist auch möglich. Zu Container-Orchestrierung folgt auch in den nächsten Wochen noch ein Post.

Klar, als klassischer Thin Client - wofür der Futro eigentlich auch gebaut wurde - ist der auch geeignet, ein modernes Desktop-OS (egal ob Windows oder Linux) dürfte auch für einfache Aufgaben brauchbar und flüssig laufen. Als Mediaplayer am Fernseher oder Retro-Spielekonsolen-Emulator taugt der Thin Client sicherlich auch.

Ich selbst setze einen Futro als Printserver für einen 3D-Drucker ein, funktioniert super.

Ich finde es erstaunlich, wie vielseitig sich dieses Gerät einsetzen lässt, vor allem bei dem Preis, zu dem man den Futro heutzutage bekommt. Bei mehreren Händlern für Refurbished Hardware gibt es immer mal wieder Angebote mit etwa 40 € pro Stück.

Alter der Hardware

Auch, wenn ich fast nur positives berichten kann:

Ich denke, die Hauptzeit des Fujitu Futro S740 ist langsam vorbei. Die CPU ist von 2017 und geht damit langsam auf die 10 Jahre zu und es gibt zunehmend mehr Alternativen.

Wenn man myDealz und ähnliche Plattformen ansieht, taucht der HP T740 zunehmend häufiger auf. Für mittlerweile unter 100 € bekommt man deutlich mehr Leistung und etwas bessere Aufrüstoptionen. Die CPU-Leistung vom T740 liegt grob beim Dreifachen der des S740. Wenn ich etwas Spielgeld über habe, werde ich mir davon vermutlich auch mal einen zulegen.

Ansonsten sind Mini-PCs mit dem Intel N100 recht weit verbreitet, ich selbst hatte davon allerdings noch keinen in der Hand. Mini-PCs wie der Lenovo oder auch diverse Modelle von HP oder Dell sind für ein Homelab ebenfalls eine gute Wahl - benötigen aber deutlich mehr Strom.

Trotz der Alternativen bleibt der Futro S740 auch heute noch eine gute Wahl, vor allem bei den Preisen, zu dem die Geräte mittlerweile erhältlich sind.

Fazit

Der Fujitsu Futro S740 ist seit fast drei Jahren ein zuverlässiger, stromsparender Baustein in meinem Homelab. Für leichte bis mittlere Aufgaben reicht die Leistung gut. Vor allem im Cluster mit mehreren Geräten lässt sich viel machen, sogar hochverfügbarkeit mit Ceph ist denkbar. Vor allem als Smart-Home-Zentrale und für leichte bis mittelschwere Services wie Nextcloud, Immich und die anderen üblichen Verdächtigen zum selbst hosten ist der S740 gut geeignet.

Das größte Argument für mich ist aber tatsächlich die Kombination aus Preis, Leistung und dem Stromverbrauch von um die 5 Watt, das ist einfach kaum schlagbar.

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.