PBS meets Hetzner Storagebox

[Baconpie]

Moin,

ich habe jetzt bereits eine weile eine Hetzner Storagebox via SMB in meinem PBS eingebunden und bin gerade dabei zu schauen wie ich die Geschwindigkeit optimieren kann.

cache=none
actimeo=60
closetimeo=5

6 Threads im Lesen
6 Threads im Schreiben

Den meisten Leistungszuwachs habe ich durch die Erhöhung der Threads bekommen. Hat jemand hier mehr Erfahrungswerte? Wie weit kann ich die Threads hoch schrauben bis ich ans maximum bei Hetzner komme?

Angebunden bin ich mit 300mb/s Mbit/s up und down.

 

[Johannes S]

ich habe jetzt bereits eine weile eine Hetzner Storagebox via SMB in meinem PBS eingebunden und bin gerade dabei zu schauen wie ich die Geschwindigkeit optimieren kann.

Keine Storagebox benutzen, da PBS nicht dafür entwickelt wurde, Storage über Netzwerkfreigaben anzubinden:

D

[TUTORIAL] Thread 'Datastore Performance Tester for PBS'

Jun 11, 2024

This is a performance tester for datastores of your PBS.

-> Intended before you setup a production PBS. <-

apt-get update
apt-get install git
git clone https://github.com/egandro/pbs-storage-perf-test.git
cd pbs-storage-perf-test
# replace datastore-dir with your own directory
./create_random_chunks.py /datastore-dir
rm -rf /datastore-dir/dummy-chunks

- Read how/what/and why we test in this way: https://github.com/egandro/pbs-storage-perf-test/blob/main/README.md
- Our results: https://github.com/egandro/pbs-storage-perf-test/blob/main/results.md
- Our conclusion...

• Der Harry
• Replies: 19
• Forum: Proxmox Backup: Installation and configuration

• 

Im lokalen Netzwerk ist das schon nicht geil ( siehe https://forum.proxmox.com/threads/warum-ist-der-pbs-so-picky-bei-nfs-storage-mounts.160610/ ) über Internet ist es noch schlimmer.
Im Thread zu NFS-Storage-Mounts (ist bei smb nicht anders, sogar eher noch schlimmer siehe Thread zum Datastore-Performance-Tester) steht auch die Lösung: Lokalen Storage direkt am PBS verwenden. Also: Entweder vom lokalen PBS die Backups auf einen anderen PBS (etwa bei Freunden/Familienangehörigen, als Cloud-PBS (etwa bei Inett oder tuxis.nl) oder ein günstiger vserver mit lokalen virtuellen Server) syncen.
Wenn das nicht geht, ist der neue S3-Support ein praktikabler Kompromiss, das würde ich dann aber nicht als Hauptbackup nutzen.

 

[news]

Und noch als Anmerkung eine SMB Share bricht über eine weltweite Internetverbindung ständig zusammen und wird schon deshalb mit festgefahrenen Proxmox BS erfreuen.
Habe ich vor ca. 3 Jahren selbst alles durch gespielt.

 

[GMBauer]

Liebe Mitforisten,

klar, der PBS ist über alle Maßen träge auf einen externen Speicher, aber welche Lösung würdet Ihr empfehlen um ein Backup außerhalb des Firmengebäudes zu speichern? (Klar, für schnelle Backups und Restores benutzt man einen PBS mit internen SSDs und wir haben auch einen zweiten PBS im Gebäude, der vom ersten zieht.) Aber unsere Firma ist ein einziger Brandabschnitt und deswegen suche ich immer noch eine Möglichkeit, Backups außer Haus zu sichern. USB-Medien hin und her zu tragen sehe ich ehrlich gesagt nicht als wirklich gute Lösung.

Also, was würdet Ihr benutzen / empfehlen?

 

[IsThisThingOn]

S3 oder offsite PBS

 

[TErxleben]

Liebe Mitforisten,

klar, der PBS ist über alle Maßen träge auf einen externen Speicher, aber welche Lösung würdet Ihr empfehlen um ein Backup außerhalb des Firmengebäudes zu speichern? (Klar, für schnelle Backups und Restores benutzt man einen PBS mit internen SSDs und wir haben auch einen zweiten PBS im Gebäude, der vom ersten zieht.) Aber unsere Firma ist ein einziger Brandabschnitt und deswegen suche ich immer noch eine Möglichkeit, Backups außer Haus zu sichern. USB-Medien hin und her zu tragen sehe ich ehrlich gesagt nicht als wirklich gute Lösung.

Also, was würdet Ihr benutzen / empfehlen?

Ihr habt ja schon einen PullPBS. Warum stellt ihr das Ding nicht einfach an einen Ort, der per Internet/VPN ins Netz eingebunden ist? Mit Mut zur Lücke verzichtet ihr sogar auf ein VPN und gebt Port 8007 auf der Firewall frei. Ein Angeifer braucht eh den Fingerprint des Quellservers und vlt. noch fail2ban um Rabauken einzubremsen. Bleibt noch die Frage, wieviel Vertrauen man den seitens Proxmox angebotenen Diensten entgegenbringt.

 

[GMBauer]

Den zweiten bzw. einen weiteren PBS "selbst gehostet" aufzustellen scheitert an der miesen Anbindung meines Hauses. Ich bekomme nach wie vor nur 50+ down und 15+ up. MBit pro Sekunde. Da dauert ein Restore bis Sankt Nimmerlein. Dann müsste das ein fremdgehosteter sein. Da nehme ich lieber einen S3, glaube ich. Gibts ja auch in D gehostet.

Das Backup durch PBS 1 auf die interne SSD und das Backup durch PBS 1 auf S3 sind dann zwei getrennte Vorgänge, oder? War es dann nicht so, dass der jedesmal eine Komplettsicherung macht und die Dirty Bitmap nicht nutzt? Weil zwei getrennte Dirty Bitmaps gibts ja nicht.

 

[TErxleben]

Den zweiten bzw. einen weiteren PBS "selbst gehostet" aufzustellen scheitert an der miesen Anbindung meines Hauses. Ich bekomme nach wie vor nur 50+ down und 15+ up. MBit pro Sekunde. Da dauert ein Restore bis Sankt Nimmerlein. Dann müsste das ein fremdgehosteter sein. Da nehme ich lieber einen S3, glaube ich. Gibts ja auch in D gehostet.

Das Backup durch PBS 1 auf die interne SSD und das Backup durch PBS 1 auf S3 sind dann zwei getrennte Vorgänge, oder? War es dann nicht so, dass der jedesmal eine Komplettsicherung macht und die Dirty Bitmap nicht nutzt? Weil zwei getrennte Dirty Bitmaps gibts ja nicht.

Wenn dein externer PBS hinter einem 50/15er-Anschluss steckt, dann handelst du immer mit Zitronen, außer du trägst das Ding im schlimmsten Fall ins Zielnetz. Sicherung über diese Leitung wird womöglich zufriedenstellend funktionieren.
Mir wären es die Kosten für externe S3-Speicherkapazität nicht wert, die auch mit guter Anbindung immer noch extrem lahmarschig ist.
Überhaupt ist ein Restore von z.B. 20TB selbst über 1GBit/s schon rechnerisch eine mittlere Katastrophe.

 

[Johannes S]

Den zweiten bzw. einen weiteren PBS "selbst gehostet" aufzustellen scheitert an der miesen Anbindung meines Hauses. Ich bekomme nach wie vor nur 50+ down und 15+ up. MBit pro Sekunde. Da dauert ein Restore bis Sankt Nimmerlein. Dann müsste das ein fremdgehosteter sein. Da nehme ich lieber einen S3, glaube ich. Gibts ja auch in D gehostet.

Das Backup durch PBS 1 auf die interne SSD und das Backup durch PBS 1 auf S3 sind dann zwei getrennte Vorgänge, oder? War es dann nicht so, dass der jedesmal eine Komplettsicherung macht und die Dirty Bitmap nicht nutzt? Weil zwei getrennte Dirty Bitmaps gibts ja nicht.

Nein, man macht im Idealfall eben NICHT eine Sicherung auf S3, sondern zuerst auf einen lokalen Datastore, von dem dann anschließend auf den S3-Datastore gepushed wird. Oder eben alternativ vom offsite-PBS gepullt. Falls die Anbindung dafür zu schlecht ist: Externe USB-laufwerke als removable datastore nehmen mit allen damit verbundenen Nachteilen, aber deren Bandbreite kann kaum geschlagen werden.
Der offsite-PBS pullt sich dann nur Änderungen, gleiches gilt bei S3, auch da werden nur neue Chunksn übertragen. Was man bei s3 aber bedenken muss: Verschlüsselt man den Content (was ja grundsätzlich sinnvoll ist, wenn das Backup nicht bereits schon verschlüsselt angelegt ist), geht die Verschlüsselung auch auf die Performance.
Eine lahme Datenanbindung wird freilich weder durch S3 noch durch eine Anbindung per NFS/sshfs/cifs oder sonstige Hacks schneller oder zuverlässiger. Und während man im Homelab meinetwegen das noch machen kann (mir ist selbst das zu blöd) finde ich derartige Stunts (nfs/sshfs/cifs) im gewerblichen Einsatz schon grob fahrlässig.

 

[TErxleben]

Was mir da wieder mal durch den Kopf geht, ist die Frage warum immer noch kein Link VMxyz-latest bei einer Sicherung angelegt wird, dessen Inhalt dann elegant per z.B. rsync im script über schmale Leitungen geschoben werden kann. Es müsste nur einen zusätzlichen Ordner in der ohnehin automatisch vorhandenen Liste von PVE-Ordnern geben.
Das ganze funktioniert i.ü. auch hervorragend per CLI im Pullbetrieb. Ganz ohne Klimbim drum herum.
Wenn ich noch GUI drum herum will, dann benutze ich z.B. SeaFile.

 

[Johannes S]

Was mir da wieder mal durch den Kopf geht, ist die Frage warum immer noch kein Link VMxyz-latest bei einer Sicherung angelegt wird, dessen Inhalt dann elegant per z.B. rsync im script über schmale Leitungen geschoben werden kann. Es müsste nur einen zusätzlichen Ordner in der ohnehin automatisch vorhandenen Liste von PVE-Ordnern geben.

Das wird wenig bringen, da ja generell beim Syncen nur die Änderungen/Chunks übertragen werden, die am Ziel noch nicht vorhanden sind. Enthält also dein letztes Snapshot keine Änderungen, wird auch nichts übertragen. Und falls du über Tag 1TB geschrieben hast, werden 1 TB übertragen. Eine Sicherung als vzdump o.ä. wäre dagegen kein Vorteil, weil das immer den kompletten Inhalt einer Sicherung übertragen würde.
Man kann dazu im im Sync-Job eintragen (in den erweitern Einstellungen), dass nur die letzten n Snapshots übertragen werden (etwa weil man keine temporären Sicherungen mitschleppen möchte o.ä., also um die Übersicht im offsite-PBS aufgeräumer zu haben), aber für das Problem der Bandbreite ändert das nichts:
- Entweder seit dem letzten übertragenen Snapshots sind keine oder nur wenig neue Chunks dazugekommen, dann zieht sich der PBS auch nur wenig Daten. Oder es sind viele Chunks dazugekommen, die wird er dann auch für den letzten Snapshot übertragen müssen.
Das kann man aber auch alles in der Doku und diversen Forumsthreads nachlesen...

 

[TErxleben]

Das wird wenig bringen, da ja generell beim Syncen nur die Änderungen/Chunks übertragen werden, die am Ziel noch nicht vorhanden sind. Enthält also dein letztes Snapshot keine Änderungen, wird auch nichts übertragen. Und falls du über Tag 1TB geschrieben hast, werden 1 TB übertragen. Eine Sicherung als vzdump o.ä. wäre dagegen kein Vorteil, weil das immer den kompletten Inhalt einer Sicherung übertragen würde.

rsync arbeitet ja nicht auf reiner Dateiebene.
Lokales vzdump geht intern i.d.R rattenschnell. Das ganze sogar unterbrechungsfrei.
So gibt es viele Freiheiten bzgl. der Sicherungsfrequenz, ohne überhaupt eine externe Leitung anfassen zu müssen.
1TB Bewegungsdaten sind natürlich immer ein Koffer, welchen man nicht wegdiskutieren kann.
Rücksicherungen aus externen Quellen ist immer PITA.
vzdump+rsync löst das auch ohne PBS sehr gut. Natürlich immer nur um einen letzten Pfeil im Köcher zu haben (kein Archiv o.ä.).
Ein PBS hat noch nicht mal Mechanismen um vzdumps auf externe Medien zu exportieren und anschließend per peitendem Boten zu verschicken.
Wenn du ein externes vzdump online zurückholen musst, dann ist die Leitung immer der begrenzende Faktor.

 

[GMBauer]

Wenn dein externer PBS hinter einem 50/15er-Anschluss steckt, dann handelst du immer mit Zitronen, außer du trägst das Ding im schlimmsten Fall ins Zielnetz. Sicherung über diese Leitung wird womöglich zufriedenstellend funktionieren.
Mir wären es die Kosten für externe S3-Speicherkapazität nicht wert, die auch mit guter Anbindung immer noch extrem lahmarschig ist.
Überhaupt ist ein Restore von z.B. 20TB selbst über 1GBit/s schon rechnerisch eine mittlere Katastrophe.

Obacht, wie der Südstaatler sagt. Unsere Firma bekommt bald nen Glasfaser mit 1 GBit down und ??? up. (Telekom)
Zuhause, auf dem möglichen Standort für einen zweiten PBS habe ich nur 50+/10+

Und die Backupgröße von allem liegt irgendwo bei 1 bis 2 TByte bei einer Veränderung der Nutzdaten von xx GByte pro Tag. Beim Hetzner im S3 wären das dann 14 Euro oder so. PBS sichert ja in einen S3 nach dem ersten mal auch nur die veränderten Daten, oder?

'Tschuldigung übrigens fürs Kapern des Threads...

Aber noch was zum S3: Wie arbeitet der PBS mit dem S3? Sichert der zuerst alle VMs etc auf einen Hilfsspeicher und schiebt das dann in den S3 oder arbeitet er peu a peu wie bei einem normalen Backup auf ein lokales Laufwerk im PBS?

 

[TErxleben]

Obacht, wie der Südstaatler sagt. Unsere Firma bekommt bald nen Glasfaser mit 1 GBit down und ??? up. (Telekom)
Zuhause, auf dem möglichen Standort für einen zweiten PBS habe ich nur 50+/10+

Wie ich schon sagte, 50/10 kann mit Geduld sogar für 2TB reichen. Oder eben Kiste schleppen.

Und die Backupgröße von allem liegt irgendwo bei 1 bis 2 TByte. Beim Hetzner im S3 wären das dan 14 Euro oder so. PBS sichert ja in einen S3 nach dem ersten mal auch nur die veränderten Daten, oder?

14€ sind nun auch nicht die Welt. Für die Sicherung sind nur aktuelle Änderungen leitungsrelevant. Für die Kosten bei Hetzner, die Menge an Daten, die du dort aufheben möchtest. Für die Rücksicherung immer deine Downloadgeschwindigkeit. Das Hetzner schneller Daten liefert, als deine Download von 1GBit/s oder dein muckeliger privater Anschluss ist logisch.
Da sind wir wieder bei der Datenmenge, die es gilt zu restaurieren. 2TB sind m.E. mit etwas Geduld durchaus machbar.
Wieviele Daten es im Worstcase sind, kann ich natürlich nicht beurteilen.
Das sollte aber ja eigentlich vom internen PBS machbar sein.

 

[TErxleben]

Aber noch was zum S3: Wie arbeitet der PBS mit dem S3? Sichert der zuerst alle VMs etc auf einen Hilfsspeicher und schiebt das dann in den S3 oder arbeitet er peu a peu wie bei einem normalen Backup auf ein lokales Laufwerk im PBS?

Ob die modernste Sau nun S3, NFS, SMP, CEPH etc.pp heißt ist egal. Aus Sicht eines PVE/PBS ist das alles nur externer Speicher.
CEPH hat den Vorteil, extrem schnell angebunden sein zu können. Den Netzwerknachteil (Latenz) gibt es aber sogar da.
Sobald eine "Gurkenleitung" dazwischen hängt, ist dunkeltuten.

 

[IsThisThingOn]

Mit Mut zur Lücke verzichtet ihr sogar auf ein VPN und gebt Port 8007 auf der Firewall frei. Ein Angeifer braucht eh den Fingerprint des Quellservers und vlt. noch fail2ban um Rabauken einzubremsen.

Oder halt einfach IPv6 verwenden.
Dann kann man auf der Destination sowas einstellen:
Allow all incoming traffic from StaticIPv6PVE to StaticIPv6PBS on Port 8007

Wobei OP von einem Hausanschluss und von 20TB VMs spricht.

'Tschuldigung übrigens fürs Kapern des Threads...

Warum lässt du es nicht bleiben, statt dich dafür zu entschuldigen?

 

[GMBauer]

Weil meine initiale Frage durchaus reingepasst hat.

 

[Johannes S]

rsync arbeitet ja nicht auf reiner Dateiebene.

Doch natürlich, es guckt sich die Dateien auf dem Dateisystem an und ob da sich was geändert hat. Es braucht dafür keine Features des Dateisystems (etwa zfs send/receive) außer den Standardmetadaten (also Erstellungs- und Änderungstimestamps etc). Am Ende schaufelt rsync dann diese Daten dann nur durchs Netz oder (bei lokalen Rechnern) halt über die Platte. Ein lokales cp ist auch schneller als scp.
Nur: Das macht PBS bei seinen syncs nicht anders, zu glauben, dass rsync da irgendwas beschleunigen würde ist eine fixe Idee, die nicht von der Realität gedeckt ist.

Ein PBS hat noch nicht mal Mechanismen um vzdumps auf externe Medien zu exportieren und anschließend per peitendem Boten zu verschicken.

Ich wage die ketzerische These, dass das schlicht daran liegt, weil das niemand braucht. Wenn von zahlenden Kunden der Wunsch schon öfter gekommen würde, gäbe es das sicher schon. Sicherung auf USB für air-gapped Backups geht dagegen schon (und kann auch für reitende Boten genutzt werden), weil das (anders als Azubis mit ganzen Servern als reitende Boten durch Deutschland schicken) eben ein gängige Anforderung ist.

Wenn du ein externes vzdump online zurückholen musst, dann ist die Leitung immer der begrenzende Faktor.

Ja, und da spart PBS mit seinen inkrementellen Mechanismen ordentlich Bandbreite. Den initialen Sync könnte man dann ja sogar per USB-Storage machen, sodass danach nur noch Änderungen übertragen werden müssen.

 

[TErxleben]

Doch natürlich, es guckt sich die Dateien auf dem Dateisystem an und ob da sich was geändert hat. Es braucht dafür keine Features des Dateisystems (etwa zfs send/receive) außer den Standardmetadaten (also Erstellungs- und Änderungstimestamps etc). Am Ende schaufelt rsync dann diese Daten dann nur durchs Netz oder (bei lokalen Rechnern) halt über die Platte. Ein lokales cp ist auch schneller als scp.
Nur: Das macht PBS bei seinen syncs nicht anders, zu glauben, dass rsync da irgendwas beschleunigen würde ist eine fixe Idee, die nicht von der Realität gedeckt ist.

Das ist einfach falsch. Rsync überträgt auch nur die Deltas die es innerhalb einer Datei erkennt. Die Standard Metadateien spielen eine absolut untergeordnete Rolle. Bei Metadateien geht es nur um: Datei da oder nicht. Darum wird rsync effektiver, je größer die Datei ist. Warum basieren wohl 95% aller Tools auf rsync?

Ich wage die ketzerische These, dass das schlicht daran liegt, weil das niemand braucht. Wenn von zahlenden Kunden der Wunsch schon öfter gekommen würde, gäbe es das sicher schon. Sicherung auf USB für air-gapped Backups geht dagegen schon (und kann auch für reitende Boten genutzt werden), weil das (anders als Azubis mit ganzen Servern als reitende Boten durch Deutschland schicken) eben ein gängige Anforderung ist.

Wie auch immer. Das wäre ein kleiner, zu lutschender Drops. Es soll Gegebenheiten geben, bei denen ein reitender Bote schneller wäre, als selbige über eine unpassende Leitung zurück zu saugen.

Ja, und da spart PBS mit seinen inkrementellen Mechanismen ordentlich Bandbreite. Den initialen Sync könnte man dann ja sogar per USB-Storage machen, sodass danach nur noch Änderungen übertragen werden müssen.

Wenn du jetzt noch darlegst, wie du die 10GB, mit denen dein PBS, initial im schnellen Netz "beladen" wurde, komplett in adäquater Zeit über die Bummelleitung des Zielortes wieder zurückbekommst, wird die Wiese grün.
Klingt nach Quadratur des Kreises.

 

[IsThisThingOn]

Nur: Das macht PBS bei seinen syncs nicht anders,

Das ist einfach falsch. Rsync überträgt auch nur die Deltas die es innerhalb einer Datei erkennt.

Uff, das sind gleich ein paar grosse Themen, die hier geöffnet werden.
Es gibt rsync, PBS und ZFS send, alle arbeiten total unterschiedlich und haben draum auch total unterschiedliche Performance Charakteristiken.
Take it with a grain of salt, bin jetzt auch nicht der Profi.

Gehen wir doch alle mal durch und schauen uns an wie die arbeiten:

rsync:
Metadata ist hier Grösse und modification time.
- lese metadata von destination
- lese metadata von source
- send changes, aber inkrementell

PBS:
- PVE holt sich die paar kb grosse Hash table von remote PBS. Dort stehen alle hashes der gespeicherten Blöcke drin
- PVE liest JEDEN einzelnen Block, hasht ihn, schaut in der table ob es den bei PBS schon gibt
- Falls nein, wird er gesendet
- Falls ja, nicht

ZFS send:
ZFS ist CoW. Darum ist passiert alles mit Ausnahme der Übertragenung von tatsächlichen Änderungen sozusagen instant.


TLDR und stark vereinfacht:
Rsync performance: abhängig von wie viele Files existieren und von der metadata performance von source und destination
PBS performance: Abhängig von wie viele TB Daten PVE hat und die lese und hash performance von PVE
ZFS performance: Instant. Braucht aber halt ZFS an beiden Orten.