Warum ist der PBS so "picky" bei NFS-Storage-Mounts?

[jacotec]

Hallo zusammen,

zuerst einmal: Ja, ich weiß dass es nicht die empfohlene Betriebsart ist, die Datastores des PBS auf einem per NFS oder CIFS angebundenen Speicher abzulegen

Aber in meinem Homelab habe ich nunmal ein DS923+ mit 20TB Backupspeicher, das bekomme ich in so einer Umgebung mit einem eigenen Server und Enterprise-SSDs kostenmäßig absolut nicht abgebildet. Mit SSD-Cache auch für die BTRFS-Metadaten performt das Ganze auch wirklich nicht schlecht, der PBS läuft in einer VM und wird per vzdump gesichert - Schmiert der ganze Host mit dem PBS ab, habe ich den auf einem anderen Host binnen 3 Minuten wieder hergestellt und kann Wiederherstellen was ich will. Ist für mich das ideale Setup.

Die Synology-Datastores sind via CIFS gemountet, das funktioniert einwandfrei und völlig problemlos.

Nun wäre NFS hier noch besser, performanter insbesondere bei vielen kleinen Dateien wie sie PBS verwendet. Leider kann ich den PBS nicht wirklich dazu bewegen so mit NFS zu arbeiten, dass ich das gute Gefühl habe, dass das auf lange Sicht stabil läuft. Obwohl im Synology per Flag "Alle Benutzer dem admin zuordnen" alle Verzeichnisse und Dateien frei beschreib- und lesbar sind, zickt PBS hier massiv und akzeptiert den Datastore nicht bzw. kann erst gar keinen anlegen, weil "der User nicht stimmt". WFT ... es kommt darauf an dass da alles vom Backupuser gelesen und geschrieben werden kann - und das tut es.

Lege ich den Datastore nun ohne das "Alle Benutzer dem Admin zuordnen" im Synology an, funktioniert das erstmal - fällt aber dann auf die Nase weil dann Verzeichnisse nicht vom Backupuser gelesen werden können (obwohl sie im NAS selber alle 34:34 als Besitzer haben ... womit das Synology aber scheinbar wieder nichts anfangen kann).

Die Workarounds die man in den Anleitungen so findet (Den DS anlegen lassen, dann erst "Alle Benutzer dem Admin zuordnen" im Synology einschalten, dann das .lock-File löschen) funktionieren auch nicht immer - und geben mir auch nicht das Gefühl, dass so etwas dauerhaft und über jedes Synology- oder PBS-Update hinaus funktioniert.


Jetzt gehöre ich zu den Menschen, die gerne die Hintergründe verstehen wollen. Der PBS hat einen Storage, in dem der User "backup" beliebig schreiben, lesen, löschen und anlegen kann wie es ihm beliebt (alles auf der Shell als Backupuser getestet) - stört sich aber partout daran, dass die Daten nicht dem User "backup" selber gehören - technisch eigentlich grundlos?

Warum muss das so sein - oder ist das nur so gebaut, damit die bösen User nicht den bösen, nicht empfohlenen Weg gehen?

Im PVE kann ich im Cluster sogar über die GUI genau solche NFS-Freigaben prima mounten, da meckert nichts und es funktioniert einwandfrei für vzdump-Backups, ISO's und so weiter ...

Ich danke jedem, der hier Licht ins Dunkle bringen kann

Grüße,
Marco

 

[Johannes S]

Die DS923+ erlaubt doch eine VM anzulegen, wenn ich das Datenblatt gerade richtig verstanden habe?
https://global.synologydownload.com...DS923+/ger/Synology_DS923+_Data_Sheet_ger.pdf

Warum richtest du dir dann keine PBS VM darauf ein? Vorteile: Kein Ärger mehr mit Netzwerkfreigaben, PBS läuft außerhalb des Proxmox-Servers, ich sehe da eigentlich nur Vorteile.

Zu deiner Frage: Für ISOs und vzdumps werden auch deutlich weniger Daten geschrieben als beim PBS, der splittet ja seinen Datenbestand in zig kleine Dateien, die bei jeder garbage collection und jeden verify-Job auch wieder eingelesen werden, hier mal als Illustration ein Ausschnitt aus einen aktuellen GC-Log von mir:

2025-01-11T02:00:25+01:00: Original data usage: 19.087 TiB
2025-01-11T02:00:25+01:00: On-Disk usage: 199.521 GiB (1.02%)
2025-01-11T02:00:25+01:00: On-Disk chunks: 157025
2025-01-11T02:00:25+01:00: Deduplication factor: 97.96
2025-01-11T02:00:25+01:00: Average chunk size: 1.301 MiB

Für meine aktuell gespeicherten 390 Snapshots (würden 390 vzdumps mit insgesamt 19,087 TiB Platzverbrauch entsprechen) liegen also 157025 im Datastore-Verzeichnis des PBS, die dafür dort nur knapp 200 GB Platz belegen.
Siehe dazu auch (die generell lesenswerte) PBS-Doku, da wird das genauer erklärt, wie das alles zusammenhängt:
https://pbs.proxmox.com/docs/technical-overview.html
NFS, CIFS und andere Netzwerkspeicher haben daher generell eine lausige Performance in Vergleich zu lokalen Speichermedien (darum meine Empfehlung zur PBS VM auf dem NAS), hier hat das mal jemand gebenchmarkt:
https://forum.proxmox.com/threads/datastore-performance-tester-for-pbs.148694/
Meine Vermutung ist nun, dass bei dir sich das nicht nur mit einer lausigen Performance, sondern auch zusätzlichen Fehlern bemerkbar macht, die man bei lokalen Medien nicht hätte.

 

[jacotec]

Ich hatte den PBS wirklich mal zum "Spielen" in einer VM auf der Synology laufen ... bin aber ziemlich schnell davon weg. Erstens läuft das Ding da grottigst langsam (die Synology hat natürlich deutlich weniger Beef als die VM auf meinem R730) - aber vor allem muss ich da den Platz für die Disk-Images der Datastores auf der Synology vorbelegen. Mit noch ein paar Nachteilen:

• Ich komme ohne weiteres nicht an die Rohdaten dran, wenn was schief läuft
• Ich habe keine vzdump-Backups des PBS um den "mal eben" wieder herzustellen, wenn dem PBS auf der Synology mal "was passieren" sollte

Aber insbesondere hat es schon Charme, dass der gesamte Platz der Synology eben "dynamisch" für alles genutzt werden kann und nicht mal eben 10TB für den PBS vorab weg sind - die ich dann auch nicht erweitern kann, wenn es mehr werden würden. Das könnte man nur umgehen, wenn man intern die Datastores auf der Synology wieder per NFS/CIFS anbindet, dann habe ich aber bei NFS die gleichen Probleme wie jetzt.

Wie gesagt: Mit der Performance habe ich eigentlich keine Probleme. Wie lange läuft eine GC bei Dir oben (hast Du das auf der Synology)?

Meine letzte wöchentliche GC lief 12,5 Stunden (sind aber gut 13 mal mehr Rohdaten im Backup als bei Dir):

2025-01-12T19:57:59+01:00: Removed garbage: 103.259 GiB

2025-01-12T19:57:59+01:00: Removed chunks: 75419

2025-01-12T19:57:59+01:00: Original data usage: 251.03 TiB

2025-01-12T19:57:59+01:00: On-Disk usage: 5.453 TiB (2.17%)

2025-01-12T19:57:59+01:00: On-Disk chunks: 2692248

2025-01-12T19:57:59+01:00: Deduplication factor: 46.04

2025-01-12T19:57:59+01:00: Average chunk size: 2.124 MiB

Zusätzliche Überlegung:
Der PBS komprimiert ja die Daten ... ist der PBS auf der Synology, dürften ja die unkomprimierten Rohdaten von den Nodes zum PBS über das LAN laufen, der PBS komprimiert dann mit seiner deutlich schwächeren CPU die Daten.
Läuft der PBS als VM auf dem Node, findet auch die Komprimierung schneller auf den stärkeren vCPU's der VM statt und zum NAS laufen dann nur die schon komprimierten Daten.

 

[Johannes S]

Ich hatte den PBS wirklich mal zum "Spielen" in einer VM auf der Synology laufen ... bin aber ziemlich schnell davon weg. Erstens läuft das Ding da grottigst langsam (die Synology hat natürlich deutlich weniger Beef als die VM auf meinem R730) - aber vor allem muss ich da den Platz für die Disk-Images der Datastores auf der Synology vorbelegen. Mit noch ein paar Nachteilen:

• Ich komme ohne weiteres nicht an die Rohdaten dran, wenn was schief läuft
• Ich habe keine vzdump-Backups des PBS um den "mal eben" wieder herzustellen, wenn dem PBS auf der Synology mal "was passieren" sollte

Aber insbesondere hat es schon Charme, dass der gesamte Platz der Synology eben "dynamisch" für alles genutzt werden kann und nicht mal eben 10TB für den PBS vorab weg sind - die ich dann auch nicht erweitern kann, wenn es mehr werden würden. Das könnte man nur umgehen, wenn man intern die Datastores auf der Synology wieder per NFS/CIFS anbindet, dann habe ich aber bei NFS die gleichen Probleme wie jetzt.

Wie gesagt: Mit der Performance habe ich eigentlich keine Probleme. Wie lange läuft eine GC bei Dir oben (hast Du das auf der Synology)?

Nö, als VM auf einen Mini-PC, der mit einer TrueNAS VM auch als NAS dient. GC ist da eine Sache von Minuten. Ich habe allerdings da auch gebrauchte Enterprise-SSDs als Storagemedien, das lässt sich also mit HDDs o.ä. in einer per NFS angebunden NAS nicht wirklich vergleichen.

Meine letzte wöchentliche GC lief 12,5 Stunden (sind aber gut 13 mal mehr Rohdaten im Backup als bei Dir):

Naja, wenn die auf HDDs liegen, wird das vor allen daran liegen. Hat man ZFS, lässt sich das mit einen sogenannten special device beschleunigen (da die Metadaten dann dort gespeichert werden und Garbage Collection vor allen mit den Metadaten arbeitet), da muss man aber beachten, dass man mindestens zwei SSDs im Mirror hat, da bei einen Ausfall des special devices auch alle Daten auf den HDDs weg sind:
https://pve.proxmox.com/wiki/ZFS_on_Linux#sysadmin_zfs_special_device

Für die Kapazitätsplanung liest man je nach Quelle 0,3% (https://forum.level1techs.com/t/zfs-metadata-special-device-z/159954 ) bis 2% (dieses Forum) oder 3% (TrueNAS Forum) der Kapazität der HDDs, bei dir wären das also zwei kleine SSDs (480 GB). Die kriegt man als gebrauchte Enterprise-SSDs schon für 40-60 Euro bei regulären Händlern, bei Ebay vermutlich auch für weniger

Zusätzliche Überlegung:
Der PBS komprimiert ja die Daten ... ist der PBS auf der Synology, dürften ja die unkomprimierten Rohdaten von den Nodes zum PBS über das LAN laufen, der PBS komprimiert dann mit seiner deutlich schwächeren CPU die Daten.

Hm, ich bin mir gerade gar nicht so sicher, ob das wirklich erst der PBS macht. Grundsätzlich sollte es ja schneller gehen, erst zu komprimieren, bevor die Daten dann durchs LAN oder Internet geschickt werden. Worum PBS sich kümmert: Die Deduplizierung, damit bereits vorhandene Daten nicht noch mal gespeichert und übertragen werden.

 

[jacotec]

Aber noch was anderes: Wenn der PBS auf der Synology läuft, büße ich quasi die Vorteile meines SSD-Caches ein. Die Festplatte mit den zehntausenden kleinen Dateien liegt dann für die Synology nur in einem VMDK-File. Der BTRFS-Metadaten-Cache im schnellen SSD-Cache der Synology, der beim PBS echt einiges bringt, ist dann sinnlos und alle Metadaten müssen wieder von den HDD's gelesen werden.

 

[jacotec]

Naja, wenn die auf HDDs liegen, wird das vor allen daran liegen. Hat man ZFS, lässt sich das mit einen sogenannten special device beschleunigen (da die Metadaten dann dort gespeichert werden und Garbage Collection vor allen mit den Metadaten arbeitet), da muss man aber beachten, dass man mindestens zwei SSDs im Mirror hat, da bei einen Ausfall des special devices auch alle Daten auf den HDDs weg sind

Dafür habe ich bei der Synology den oben beschriebenen BTRFS-Metadaten-Cache auf zwei 1TB-NVMe-SSD (als RAID-1) im Gerät. Das ist quasi das "Special Device" in dem Fall. Bei Verwendung der PBS als VM auf der Synology leider völlig nutzlos.

 

[Johannes S]

Um auf dein ursprüngliches Problem zurückzukommen: Bitte einmal das komplette Log eines Backuplaufes auf den NFS-Share hier posten, außerdem (soweit vorhanden) das dazugehörige Log und die Einstellungen im PBS und der NAS.

 

[jacotec]

@Johannes S OK ... Planänderung. Erstmal Danke an Dich!

Getriggert durch Dein Posting habe ich meinen Test-PBS in der Synology-VM mal gestartet und mal einen Quick&Dirty-Test gemacht. Backup von 3 VM's auf neue Test-Datastores.

Das Backup auf den Synology-PBS dauerte 56 Minuten, das Backup via meiner PBS-VM auf das mit CIFS angebundene NAS 59 Minuten. Soweit also alles im ähnlichen Bereich - zumindest ist das Synology-VM-Backup nicht langsamer.

Jetzt kommt das dicke "Aaaaaaaber":

Dann eine GC auf diese jungfräulichen DS mit knapp 85.000 Chunks laufen lassen.

PBS auf dem Node mit CIFS-Anbindung, trotz BTRFS-Metadaten-SSD-Cache: 8 Minuten, 11 Sekunden
PBS auf der Synology: 6 Sekunden

Das war's dann ... ich stelle dann mal auf die Version mit dem PBS auf der Synology um

 

[Johannes S]

PBS auf dem Node mit CIFS-Anbindung, trotz BTRFS-Metadaten-SSD-Cache: 8 Minuten, 11 Sekunden
PBS auf der Synology: 6 Sekunden

Einen so krassen Unterschied hätte ich dann doch nicht erwartet, aber das ist mal eine Ansage

Das war's dann ... ich stelle dann mal auf die Version mit dem PBS auf der Synology um

Das ist doch mal ein klarer Fortschritt Und dank der Deduplizierung solltest du bei deinen weiteren Backups ja nicht mehr über 50 Minuten brauchen

 

[jacotec]

Die Deduplizierung habe ich ja jetzt schon, und die ist beeindruckend beim PBS. Aber Faktor 80 bei der GC hat mich echt vom Sockel gehauen ... Man lernt

 

[Johannes S]

Die Deduplizierung habe ich ja jetzt schon, und die ist beeindruckend beim PBS. Aber Faktor 80 bei der GC hat mich echt vom Sockel gehauen ... Man lernt

Naja du hast ja geschrieben, dass du fürs Testen neue Datastores angelegt hast, wo also noch keine Chunks drin waren und die dann ca 50 Minuten gebraucht haben für die initialen Backups. Bei den nächsten würde ich also mit deutlich weniger Zeit fürs Backup rechnen

Was mich noch interessieren würde: Wie lange dauert bei dir ein verify-Job über CIFS im Vergleich zur VM direkt auf der Synology? Diese Jobs sollten ja regelmäßig laufen, damit man weiß, ob man die Backups noch wiederhergestellt kriegen würde (und von Zeit zu Zeit natürlich auch händisch das restoren testen).

 

[jacotec]

Was mich noch interessieren würde: Wie lange dauert bei dir ein verify-Job über CIFS im Vergleich zur VM direkt auf der Synology? Diese Jobs sollten ja regelmäßig laufen, damit man weiß, ob man die Backups noch wiederhergestellt kriegen würde (und von Zeit zu Zeit natürlich auch händisch das restoren testen).

Es läuft seit 9:00 Uhr der Verifyjob für die Backups der letzten Nacht. Wie ich im Log im Vergleich zum gleichen Job die Woche vorher (das war der PBS auf dem Node via CIFS) sehe, ist er geringfügig schneller - aber scheinbar nicht signifikant. Letzte Woche via CIFS lief er 5h 2m, ich schreibe nachher mal hier wie lang der nun auf der Synology lief.

Ein paar interessante Erkenntnisse liefert mir das aber:

• Quasi kein signifikanter Netzwerktraffic auf der Synology. Das Verify scheint keine Daten von der Original-VM auf dem Node zu benötigen ... vielleicht liest der alles komplett und vergleicht das gegen die Checksummen in den Metadaten.
• Der Ressourcenmanager sagt: Hoher Lesetraffic auf dem Volume und kaum Schreibtraffic auf das Volume, für "Datenträger" gibt es aber sowohl hohen Lese- als auch Schreibtraffic. Kann sein dass der SSD-Cache bei den Datenträgern hier mit reinspielt in die Statistik.

Ich denke, der begrenzende Faktor ist hier die Lesegeschwindigkeit der HDD's, es muss ja alles eingelesen werden. Es fällt hier nur die 1GBit/s-Netzwerkverbindung raus.

Wenn der Verify-Job durch ist, lasse ich mal spaßeshalber eine GC drüberlaufen. In der Nacht sind 17 VMs mit insgesamt 1TB initial in den Store gekommen.

 

[Johannes S]

• Quasi kein signifikanter Netzwerktraffic auf der Synology. Das Verify scheint keine Daten von der Original-VM auf dem Node zu benötigen ... vielleicht liest der alles komplett und vergleicht das gegen die Checksummen in den Metadaten.
• Der Ressourcenmanager sagt: Hoher Lesetraffic auf dem Volume und kaum Schreibtraffic auf das Volume, für "Datenträger" gibt es aber sowohl hohen Lese- als auch Schreibtraffic. Kann sein dass der SSD-Cache bei den Datenträgern hier mit reinspielt in die Statistik.

Ich denke, der begrenzende Faktor ist hier die Lesegeschwindigkeit der HDD's, es muss ja alles eingelesen werden. Es fällt hier nur die 1GBit/s-Netzwerkverbindung raus.

Genau, da würde auch der Metadatencache nicht so viel bringen, wie bei Garbagecollection, so ist es zumindestens bei ZFS: verify und gc profitieren beide davon, aber verify bei weiten nicht so stark wie gc.

Mich interessiert an der Stelle halt, ob der Nachteil des fehlenden Caches durch die lokale Anbindung kompensiert wird.

 

[Azunai333]

Mich interessiert an der Stelle halt, ob der Nachteil des fehlenden Caches durch die lokale Anbindung kompensiert wird.

Mich auch, da ich überlege meinen PBS auch auf's NAS zu schieben.
Wobei hier ja die Reaktionszeit wegen dem Netzwerkstack (PBS VM <-> NAS) immer noch länger sein könnte, als bei einer lokalen Festplatte.

 

[jacotec]

So, also der Verify war dann doch um einiges schneller. Die 17 VMs mit 1TB Backup-Daten liefen in 3h 40min (CIFS 5h 30 min). Beim Verify hat die CPU auch gut zu tun, die 3 zugewiesenen vCPU auf der Synology 923+ liefen da so bei gut 70%. Da war der CIFS-PBS auf dem R730 mit 6 vCPU á la E5-2650 L v4 um Welten performanter.

Die GC ist echt der Hammer, klar löscht der noch nix weg, aber er muss ja alles durchgehen. Lief in 62 Sekunden durch.

2025-01-15T12:43:43+01:00: Original data usage: 14.613 TiB
2025-01-15T12:43:43+01:00: On-Disk usage: 938.969 GiB (6.27%)
2025-01-15T12:43:43+01:00: On-Disk chunks: 553874
2025-01-15T12:43:43+01:00: Deduplication factor: 15.94
2025-01-15T12:43:43+01:00: Average chunk size: 1.736 MiB
2025-01-15T12:43:43+01:00: TASK OK