Beratung / Best Practise: ein PBS mit Storages per CIFS oder drei PBS mit gegenseitigen Remotes?

philippms

New Member
Nov 6, 2025
18
1
3
Hi,

wir haben drei Standorte:

A) Dort, wo die Hypervisor und ein Backup-NAS steht.
B) Dort, wo ein zweites Backup-NAS steht
C) Unsere Büroräume, in denen ein Tape Laufwerk steht.

Außerdem haben wir im mittleren zweistelligen TB-Bereich VMs, die zu backuppen sind.

Zwischen A, B und C gibt es einen 10Gbit/s-Link. Bei Single-TCP-Verbindungen begrenzt aber eine kleine Latenz die Bandbreite auf effektiv 200-300MB/Sek.

Aktuell haben wir an Standort (C) am Tape einen kleinen Server mit Proxmox Backup Server laufen, der die Storages von (A) und (B) per CIFS gemountet hat. Die Hypervisor von (A) schreiben die Backups auf den Miniserver (C), der es dann nach (B) per CIFS speichert.

Das läuft an sich recht gut, das Backup läuft mit 200-300MB/sek schreibend. Allerdings ist beispielsweise der Zugriff auf die zur Verfügung stehenden Backups in der Proxmoxoberfläche recht lahm. Auch Jobs, die zufällig auf Chunks zugreifen und nicht einfach eine große Menge schreiben (Garbage Collection, Verify etc) recht langsam. Erklärt sich von selber, durch die Latenz bei jedem Zugriff.

Da die Storages selber mit Truenas laufen: Ergäbe es Sinn dort jeweils in einer VM auch einen Proxmox Backup Server laufen zu lassen und die Backup Server sich gegenseitig als Remote einzubinden?

Dann würden die Hypervisor von (A) auf (B) direkt backuppen, und der würde die Backups täglich nach (A) zurück pushen (zwei Standort Sicherheit), während sich das (C) die Backups für das Tape pulled....
 
Last edited:
Das läuft an sich recht gut, das Backup läuft mit 200-300MB/sek schreibend. Allerdings ist beispielsweise der Zugriff auf die zur Verfügung stehenden Backups in der Proxmoxoberfläche recht lahm. Auch Jobs, die zufällig auf Chunks zugreifen und nicht einfach eine große Menge schreiben (Garbage Collection, Verify etc) recht langsam. Erklärt sich von selber, durch die Latenz bei jedem Zugriff.
Eher weniger, hier spielt das lokale Storage auf dem PBS eine entscheidende Rolle: wenn du kein Full-Flash-System hast, wird das das Problem sein.
Eine akzeptable Performance erreicht man mit lokalen ZFS auf Festplatten, wenn man special devices für die Metadaten hinzufügt. Damit ist es akzeptabel, aber ein reines Festplattensystem ist immer langsam.
 
  • Like
Reactions: Johannes S and UdoB
Absolut. Steht außer Frage.

Ich frage mich nur: Lohnt der Aufwand, drei PBS Systeme zu betreiben, die als Remote kommunizieren oder bringt das nicht den großen Vorteil gegenüber der CIFS-Lösung?

Die CIFS-Lösung hat unter Veeam jahrelang gut funktioniert - das mit den langen Läufen für verify und garbage collection hat man einfach ausgehalten, so tragisch ist das ja auch nicht, so lange es in absehbarer Zeit über die Bühne geht.

Nur wenn dort gerade viel läuft ist der Zugriff von innerhalb des PVE auf die Backuplisten recht lahm, da wird wohl wenig gecached.
 
Hi @philippms

vielen Dank für deinen Post!

SMB / CIFS ist im Vergleich ein relativ redseliges Protokoll und mag daher Latenzen nicht besonders.
Da der Proxmox Backup Server für seinen Sync zwischen Remotes HTTP(S) verwendet, welches besser mit Latenzen umgehen kann, dürfte die Performance dadurch allein schon etwas besser sein.
Zusätzlich kann für die Sync Jobs zwischen den PBS eine Anzahl an Workern angegeben werden, siehe [1].
Sollte also auch in diesem Fall wieder die Verbindung der limitierende Faktor sein, kannst du darüber noch etwas Performance herausholen.

Trotzdem muss ich @LnxBil natürlich Recht geben, dass hier der limitierende Faktor wsh. die Festplatten werden.

Da die Storages selber mit Truenas laufen
Gehe ich Recht in der Annahme, dass die NAS noch etwas anderes tun als Backup-Speicher zur Verfügung zu stellen und daher keine Option besteht den PBS bare-metal zu installieren?

Viele Grüße
Jonas

[1] https://pbs.proxmox.com/docs/managing-remotes.html#:~:text=Setting the worker,better
 
  • Like
Reactions: Johannes S
Die CIFS-Lösung hat unter Veeam jahrelang gut funktioniert - das mit den langen Läufen für verify und garbage collection hat man einfach ausgehalten, so tragisch ist das ja auch nicht, so lange es in absehbarer Zeit über die Bühne geht.
... und Veeam weiter zu verwenden ist keine Option?
 
Gehe ich Recht in der Annahme, dass die NAS noch etwas anderes tun als Backup-Speicher zur Verfügung zu stellen und daher keine Option besteht den PBS bare-metal zu installieren?
Ja genau, daher keine Option. Allerdings könnte ich überlegen, ob ich die HDDs direkt durchgebe - mal schauen.


... und Veeam weiter zu verwenden ist keine Option?

Da bin ich noch unsicher. Im Gegensatz zu PBS sind die Dirty Maps persistent auch bei SwitchOff und co. Gerade für einige riesige VMs bei uns im TB-Bereich ist das nice.

Allerdings habe ich da nur die Lizenz für 5 Objekte. Die Lizenz da kommt noch aus der "pro Sockel"-Zeit und der Support-Contract dazu liefe Ende des Jahres ab, bei Proxmox zählt die nicht. Bei der Menge an VMs, die wir fahren, würden wir wohl arm werden.
 
Ich würde den NAS-Systemen auf jeden Fall SSD-Mirrors als special device hinzufügen und PBS als VM auf der NAS installieren, die Datenspeicher dann aber per NFS einbinden ( um den höheren Overhead von Cifs zu vermeiden):

NFS hat zwar auch Overhead aber immer noch weniger als CIFS über Netzwerk. Eine Alternative könnte die Einbindung per virtiofs sein ( bin mir aber gerade unsicher ob TrueNAS das unterstützt ), allerdings gab es dazu auch Berichte über langsamere Performance im Vergleich zu nfs. Dafür braucht es keine Netzwerkfreigabe, was ja bei Backups ganz gut ist.
Ich frage mich nur: Lohnt der Aufwand, drei PBS Systeme zu betreiben, die als Remote kommunizieren oder bringt das nicht den großen Vorteil gegenüber der CIFS-Lösung?

Imho ja: Wenn man die ( und die NAS darüber ) gut voneinander abschottet ( also unterschiedliche Passwörter, restrictive Permissions und Firewallregeln, Detaiks siehe Kapitel zum Ransomwareschutz in der PBS-Doku ) hat man mehrere Backups, an die man auch noch drankommt, wenn ein PBS ausfällt oder kompromittiert wurde:
https://pbs.proxmox.com/docs/storage.html#ransomware-protection-recovery

Siehe auch folgenden Post von @Falk R.
https://forum.proxmox.com/threads/ransomware-angriffen-backups-strategie.124421/post-541808

Generell finde ich an eure Setup problematisch, dass ihr Backups zusammen mit Produktionsdaten auf den gleichen NAS habt. Ich würde mindestens an einen Standort ( plus eine offsite-Kopie ) einen dezidierten Server nur für Backups mit eigenen, vom Rest getrennten Zugangsdaten haben wollen, um ruhig schlafen zu können. Netzwerk-/Firewall-/Backup dann so einrichten, dass der Backupserver sich die Backups vom Rest ziehen kann, aber der Rest nicht durekt ans Backup kommt.
Allerdings habe ich da nur die Lizenz für 5 Objekte. Die Lizenz da kommt noch aus der "pro Sockel"-Zeit und der Support-Contract dazu liefe Ende des Jahres ab, bei Proxmox zählt die nicht. Bei der Menge an VMs, die wir fahren, würden wir wohl arm werden.
Braucht ihr denn die application-awaren Backups von veeam für ActiveDirectory oder MS SQL ( für Oracle, MariaDB/mysql oder postgres würde ich veeam wegen mangelnder Unterstützung für Clustering nicht verwenden wollen)? PBS hat keine vergleichbare Funktion. Eine kostensparende Variante jann es dann sein den PBS für die Masse der VM-Backups zu nehmen und den Veeam-Agenten ( in der Minimalsubscription ) dann in den AD-/MSSQL-VMs. Falk schrieb hier öfter, dass seine Kunden mit der Variante gut leben können.


Was mir in deiner Übersicht fehlt: Wie macht ihr das mit den offsite-Backup? Wo werden die Tapes gelagert? Und habt ihr mal durchgespuekt, wie lange ein restore im worst case dauern würde? Envtl. macht es Sinn zusätzlich S3-Storage oder einen cloud-PBS als zusätzliche Absicherung dazuzunehmen, sofern das Budget das hergibt.
 
  • Like
Reactions: UdoB
NFS hat zwar auch Overhead aber immer noch weniger als CIFS über Netzwerk.
Ja, wäre ein Option. Auf anderen Storages haben wir sogar schon NFS over (k)TLS im Einsatz - die Wenigsten wissen, dass man NFS mittlerweile schon nativ SSL-Verschlüsseln kann, mit gegenseitigen Zertifikatschecks. Leider von Truenas noch nicht nativ unterstützt....

Imho ja: Wenn man die ( und die NAS darüber ) gut voneinander abschottet hat man mehrere Backups, an die man auch noch drankommt, wenn ein PBS ausfällt oder kompromittiert wurde:
Ja, das habe ich im Hinterkopf. Daher sind aktuell die NAS auch per CIFS angebunden. Das Truenas macht im Hintergrund Snapshots. Der Disasterplan sähe da aus die Snapshots raus zu kramen. Und auch die Tapes sind ein gewisser Schutz davor.
Generell finde ich an eure Setup problematisch, dass ihr Backups zusammen mit Produktionsdaten auf den gleichen NAS habt.
Das wäre Unsinn - und habe ich auch nicht geschrieben. A, B und C bezieht sich nur auf "Orte", sprich Serverräume.

Eine kostensparende Variante jann es dann sein den PBS für die Masse der VM-Backups zu nehmen und den Veeam-Agenten ( in der Minimalsubscription ) dann in den AD-/MSSQL-VMs. Falk schrieb hier öfter, dass seine Kunden mit der Variante gut leben können.
Ja, werden wir eventuell so machen, insbesondere für die "BigVMs", s.o.

Was mir in deiner Übersicht fehlt: Wie macht ihr das mit den offsite-Backup? Wo werden die Tapes gelagert? Und habt ihr mal durchgespuekt, wie lange ein restore im worst case dauern würde? Envtl. macht es Sinn zusätzlich S3-Storage oder einen cloud-PBS als zusätzliche Absicherung dazuzunehmen, sofern das Budget das hergibt.

Primärbäckup auf NAS an Standort A, Sekundär an NAS an Standort B, dazu Tapes an Standort C im Tresor. Ich denke, da sind wir aktuell schon gut aufgestellt ;-)


Vielen lieben Dank für euren Input! Ich mache mir mal weiter gedanken, teste ein paar Szenarien und sage am Ende Bescheid, was es geworden ist ;-)
 
Ja, wäre ein Option. Auf anderen Storages haben wir sogar schon NFS over (k)TLS im Einsatz - die Wenigsten wissen, dass man NFS mittlerweile schon nativ SSL-Verschlüsseln kann, mit gegenseitigen Zertifikatschecks. Leider von Truenas noch nicht nativ unterstützt....

Das NFS würde ich eh nur für die Anbindung an lokale vms auf der NAS nehmen, NICHT über das Netzwerk.
Das wäre Unsinn - und habe ich auch nicht geschrieben. A, B und C bezieht sich nur auf "Orte", sprich Serverräume.

Dann habe ich deine Antwort auf @jtheisen Nachfrage falsch verstanden:

Gehe ich Recht in der Annahme, dass die NAS noch etwas anderes tun als Backup-Speicher zur Verfügung zu stellen und daher keine Option besteht den PBS bare-metal zu installieren?

Das ist ja keine Option für euch laut deiner Antwort, warum denn, wenn ihr die NAS nicht für Produktionsdaten habt sondern für Backups?
 
So, ich habe mal ein wenig geforscht und ausprobiert. Allen vorweg: Truenas kann ab 25.10 "Container" - das ist zwar noch experimentiell, gibt aber ein Trixie Base Image mit eigener Mac und NIC, man kann aber Datasets vom Host direkt hinein mounten - ohne Umweg über NFS oder CIFS.

Wie geschaffen für meinen Anwendungszweck - und tatsächlich verdoppele ich damit den Durchsatz. Danke für eure Tipps.

Was mir allerdings nicht klar war: An Standort C mit den Tapes habe ich ja bisher das NAS von B per CIFS angebunden. So konnte ich den Tape Backup Job von einem "lokalen" Datastore anlegen. Jetzt gerade merke ich: Tape Jobs gehen nur von lokalen Datastores.

Habt ihr eine Idee, wie man damit umgehen kann? Alles ein weiteres mal zu syncen nur für den Backup Job ist irgendwie overkill. Kann man Tape-Jobs irgendwie auch von Remote Datastores machen? Oder gibt es eine Möglichkeit, ein TapeDrive an einem Remote Linux an ein PBS anzubinden?