Proxmox Cluster oder Backup Server oder andere Lösung

[UdoB]

Oder macht es sinn, dass die PBS VM auf dem Synology im selben Volume wie die Backups liegen?

Du meinst damit die virtuelle Platte des Betriebssystem und den Speicherort der Chunks?

Ich habe zwei Synology-Kisten. Eine hat nur ein einziges riesiges Volume und eine hat acht oder neun. Mehre Volumes hatte ich angelegt, weil ich die Eigenschaften einzeln managen wollte. Bei mir zeigt sich: das mache ich nicht wirklich; ich verwende diese Hardware nur für Backupzwecke. Und für eine solche, dedizierte Kiste ist das nicht hilfreich. Wenn man aber Docker/VMs/Media/Webserver/Mailserver usw. usf. auf derselben Hardware installieren will, ist das sicher sinnvoll.

Zurück zum Thema: ist (mir, im momentanen Kontext) egal ;-)

Wichtiger ist, dass das OS eine separate (virtuelle) Platte hat. Gerade bei einem Backupsystem wie PBS ist das Betriebssystem winzig im Vergleich zu den Nutzdaten. Wenn ich ein Backup der PBS-Instanz (als VM) mache, will ich auf keinen Fall, dass die Chunks darin enthalten sind.

 

[spooner]

Also ich hab ja folgendes vor:

Proxmox 3-Node Cluster:
System 1: Proxmox Server für VMs
System 2: Proxmox Server für VMs
System 3: Proxmox Server (Mini-PC) aber nur für Verwaltungs-Server, QDevice, und CheckMK (quasi ein bisschen losgelöst)

Proxmox Backup Server und Backups sollen auf ein Synology NAS


Synology NAS Einrichtung:

Volume 1:
Virtual-Manager
PBS mit 2 HDDs: 1. fürs OS, 2. für Backups

Volume 2:
Für Nextcloud Sync (als weiteres zusätzliches Backup)

Volume 3:
Active Backup for Business
Weiß ich noch nicht so genau wo ich das überall verwende

 

[Bu66as]

Zu deinem Plan: wenn System 3 ein vollwertiger Proxmox-Node im Cluster ist (also 3 Nodes), brauchst du kein QDevice mehr. Mit 3 Stimmen hast du automatisch Quorum, auch wenn einer ausfällt. Ein QDevice brauchst du nur bei 2-Node-Clustern als Tie-Breaker.

Wenn du System 3 als QDevice nutzen willst, darf der nicht im Cluster sein. Das ist entweder/oder.

Bei 3 Nodes im Cluster würd ich aber den Hinweis von @Johannes S nochmal bedenken: wer auf einen Cluster-Node kommt, kommt auf alle. Für den PBS auf der Synology ist das egal, der ist ja eh nicht im Cluster. Aber ob der Mini-PC wirklich als Cluster-Member rein muss oder besser standalone bleibt und nur QDevice + CheckMK macht, ist ne Überlegung wert. Gerade wenn's Richtung Kundeneinsatz geht, ist die Trennung sauberer.

Zur Synology: mach dir das mit den Volumes nicht zu kompliziert. PBS-VM mit zwei virtuellen Platten (OS + Datastore) auf einem Volume reicht. Wichtig ist, dass die Chunks nicht im VM-Backup landen, wie @UdoB schon sagte. Die restliche Volume-Aufteilung kannst du später immer noch anpassen.

 

[Johannes S]

Bei 3 Nodes im Cluster würd ich aber den Hinweis von @Johannes S nochmal bedenken: wer auf einen Cluster-Node kommt, kommt auf alle. Für den PBS auf der Synology ist das egal, der ist ja eh nicht im Cluster. Aber ob der Mini-PC wirklich als Cluster-Member rein muss oder besser standalone bleibt und nur QDevice + CheckMK macht, ist ne Überlegung wert. Gerade wenn's Richtung Kundeneinsatz geht, ist die Trennung sauberer.

Nun ja mittlerweile tendiere ich dazu, dass man auch das qdevice sauber vom Rest trennen sollte, ob nun vom PBS oder (wie in diesen Fall) Monitoring. Bei PBS ist das besonders wichtig, weil man ja per Zugriff auf das qdevice dann auch an die Backups kommt. @UdoB hat hier beschrieben, wie man das nach Einrichtung sichern kann: https://forum.proxmox.com/threads/f...nd-secure-it-by-disabling-root-access.181525/
Noch besser finde ich aber ein Setup wie es @aaron hier beschrieben hat:

Post in thread 'Planning advice'

Aug 13, 2025

What I do in some personal infra is the following:

2x PVE nodes with local ZFS storage (same name)
1x PBS + PVE side by side bare metal.

The 2x PVE nodes are clustered. To be able to use HA I make sure that the VMs all have the Replication enabled. For Mailservers and other VMs where any data loss is painful, I replicate with the shortest possible interval of 1 minute. Other VMs, like a DNS server, are replicated with longer intervals.

On the PBS server I have one LXC container running which is providing the external part of the QDevice, so that the 2x PVE nodes get their 3rd vote and...

• aaron

• 

Die Grundidee ist dabei PBS und PVE paarallel auf dem gleichen Gerät (in deinen Fall also einen Mini-PC) zu installieren: https://pbs.proxmox.com/docs/installation.html#install-proxmox-backup-server-on-proxmox-ve

Im Fall des OP mag man einwenden, dass das doch nicht nötig ist, weil er ja für Backups eh die Synology hat. Ich finde es persönlich aber ganz praktisch nicht nur ein Backup zu haben und wenn der Mini-PC eh schon läuft, wäre das ja eine einfache Möglichkeit eine weitere Kopie für den Fall der Fälle bereitzustellen. Für das offsite-Backup müsste der OP sich dann halt noch was überlegen (PBS an anderen Standord, manuelles Devicegetausche mit Tapes oder ext. USB-Platte, S3-Storage).

Als qdevice wird dann eine kleine VM oder ein lxc-Container eingerichtet, das funktioniert so natürlich auch für checkmk. Somit kommt man aus den Cluster nur noch auf das qdevice, nicht die Backups, nicht checkmk und nicht den ProxmoxVE-Host auf den Mini-PC.
Was ist denn mit Verwaltungsserver gemeint? Falls damit der DatacenterManager gemeint ist: Im Cluster könnte man den im HA-Modus (fällt der Knoten auf dem er läuft aus, geht es auf den anderen weiter) betreiben. Dafür könnte ein Angreifer mit Übernahme des Clusters auch den PDM übernehmen (inklusive envtl. dort gespeicherter Zugangsdaten), das wäre bei einen Betrieb auf den Mini-PC nicht der Fall.

 

[Bu66as]

Das Setup von @aaron mit PBS + PVE parallel auf dem Mini-PC ist ne gute Variante. Dann hast du auf einer Box PBS, QDevice als LXC und CheckMK getrennt, und noch ne zweite Backup neben der Synology.

@spooner was meinst du eigentlich mit "Verwaltungs-Server" in deinem Plan? Falls das der Proxmox Datacenter Manager werden soll, würde ich den auf dem Mini-PC lassen und nicht in den Cluster packen. Ist zwar noch recht frisch (Alpha/Beta), würde ich da nochmal drauf achten.

 

[spooner]

Hallo Zusammen,
mir wurde erzählt es wäre einfacher / besser / wie auch immer den Mini-PC als 3. Node zu integrieren, weil ich über diesen dann die beiden eigentlich Nodes verwalten könnte.
Was damit genau gemeint ist, kann ich nicht sagen, da ich noch nie mit einem Cluster gearbeitet habe.

Wenn ihr sagt, es ist quatsch, dann bleibe ich bei meinem ursprünglichen Plan mit dem 2 Node Cluster und dem quasi stand-alone Mini-PC mit Proxmo als QDevice, CheckMK und Jump Host VM.
Hier sollte eigentlich auf der PBS eingerichtet werden, aber das mit dem Netzwerk Traffic war mir einleuchtend.
Wie verhält sich das dann?

Noch mal zusammengefasst:
Mini-PC als Proxmox Host (stand alone)
Parallel auf dem PVE Host den PBS installieren (nicht als VM)
QDevice LXC
CheckMK VM
Jump Host VM

Auf der Synology zwei Volumes:
Vol 1: PBS Backups der VMs vom 2-Node-Cluster
Vol2: Nextcloud Sync
eventuell Vol3: andere Backups, Active Backup for Business, wie auch immer.

Fürs Offsite Backup / Cloud Backup könnte ich einen Wasiba S3 Datastore verwenden und Hyper-Backup der Synology dorthin pumpen oder demnächst N-ABLE Cove Data Protection (das nutze ich aktuell bei Hyper-V und soll jetzt für Proxmox erscheinen)

Ich hab in allen Systemen leider eine 1G NIC verbaut, ist das ein Problem?

Gruß Arthur

 

[spooner]

Noch ne Frage:
Oder macht es sinn in die beiden Nodes für die Replizierung eine weitere NIC einzubauen?
Z.B. TP-Link PCI 2.5G NIC
Fürs Backup hilft es nichts

 

[Bu66as]

Plan passt so, ja. Standalone Mini-PC mit PBS parallel + QDevice als LXC + CheckMK ist genau das richtige Setup.

1G ist für den Anfang kein Problem. ZFS-Replikation schickt nur die Deltas seit dem letzten Snapshot, bei ner Handvoll VMs geht das selbst bei 15-Minuten-Intervall locker durch 1Gbit. Wird höchstens eng wenn Replikation und Backup zur Synology gleichzeitig über denselben Port laufen, aber das kann man zeitlich entzerren (Backup nachts, Replikation tagsüber oder umgekehrt).

Ne dedizierte NIC für die Replikation zwischen den beiden Nodes ist trotzdem ne gute Idee, gerade wenn du eh grad am Aufbauen bist. Nachrüsten ist halt nerviger als gleich einbauen. Saubere Trennung von Storage-/Replikations-Traffic und Management ist best practice, und für 15€ machst du da nix falsch. Muss aber keine 2.5G sein wenn's nur für die Replikation ist, 1G reicht da auch als dedizierter Link.

 

[spooner]

Super.

Aber dann noch mal kurz zum Backup:
Verursacht das extremen Traffic?
Wie läuft der Traffic?
Alles über den PBS vom Mini-PC?
Mini-PC zieht die Backups von den Hosts und dann auf die Synology?
Oder ist das auch überschaubar?

 

[Bu66as]

PBS arbeitet mit Deduplikation auf Chunk-Ebene. Beim ersten Backup wird alles übertragen (das dauert je nach VM-Größe halt), danach gehen nur noch die geänderten Chunks rüber. Bei ner typischen VM mit 100GB Disk ändern sich zwischen zwei Backups vielleicht 2-5%, also ein paar GB pro Backup-Run. Über 1G ist das kein Thema.

Die PVE-Hosts pushen die Backups direkt zum PBS auf dem Mini-PC. Der Mini-PC zieht nix, die Hosts schicken aktiv. Wenn du dann noch nen zweiten PBS auf der Synology willst, kannst du vom Synology-PBS nen Sync-Job einrichten der sich die Daten vom Mini-PC-PBS holt (Pull-Sync). Dann geht der Traffic Host→Mini-PC und danach Mini-PC→Synology, aber zeitversetzt.

Der Mini-PC ist schon der Flaschenhals mit seinem 1G Port, weil über den sowohl die Backups reinkommen als auch der Sync zur Synology rausgeht. Bei ner Handvoll VMs ist das aber kein Problem. Leg den Backup-Job auf 2 Uhr nachts und den Sync zur Synology auf 5 Uhr, dann kommen die sich nicht in die Quere.

 

[Johannes S]

mir wurde erzählt es wäre einfacher / besser / wie auch immer den Mini-PC als 3. Node zu integrieren, weil ich über diesen dann die beiden eigentlich Nodes verwalten könnte.
Was damit genau gemeint ist, kann ich nicht sagen, da ich noch nie mit einem Cluster gearbeitet habe.

Das ist so quatsch. Generell ist es so, dass man über alle Knoten in einen Cluster alle verwalten kann, da auf jeden Knoten ein Webinterface läuft, worüber auch die anderen Knoten im Cluster erreichbar sind. Hat man also einen dritten Knoten, der aber nicht im Cluster ist, muss man sich da halt extra anmelden. Die Frage ist halt, ob das schlimm ist: Envtl. will man ja bewusst (z.B. Backup oder Monitoring) vom Cluster trennen, um das unabhängig voneinander zu halten. Um VMs oder lxcs zwischen Knoten zu migrieren und ein gemeinsames Interface zu haben, kann man ja auch den ProxmoxDatacenterManager nehmen. Also auch dafür braucht es nicht unbedingt einen Cluster. Wofür ein Cluster aber super ist: Man kann da Hochverfügbarkeit einrichten, sobald ein Knoten down ist, werden die entsprechend konfigurierten VMs/Container auf den anderen Knoten gestartet. Im Umkehrschluß ist das also nicht möglich, wenn die entsprechende VM/Container NICHT im Cluster läuft. Für ein qdevice und Backup ist das nicht schlimm, das will man ja gerade unabhängig vom Cluster haben, weil ein qdevice eines Clusters im Cluster doppelt gemoppelt wäre Und auch das Backup soll ja wiederherstellbar sein, falls der Cluster mal kaputt ist. Für CheckMK müsstest du dir halt überlegen, ob dir es wichtiger ist, das Monitoring unabhängig vom Cluster zu haben oder eine Hochverfügbarkeit dafür sicherzustellen. Pick your poison
HA setzt aber einen gemeinsamen Storage (Ceph, NAS o.ä.) bzw. ZFS (als Pseudo-Shared-Storage) voraus. Was ein Cluster außerdem benötigt: Ein dezidiertes Netzwerk nur für die Cluster-Kommunikation mit corosync (und im Idealfall noch eines für die Datenübertragung des Storages), damit gerät man dann früher oder später an die Grenzen, was mit einen Mini-PC sinnvoll möglich ist: https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_cluster_network

Rein technisch braucht es das nicht zwingend (habe selbst einen 2-Knoten-Cluster lange nur mit einer NIC betrieben), aber bei viel Netzwerkverkehr kann es sonst passieren, dass der Cluster durcheinander kommt, weil der corosync-Traffic nicht "durchkommt". Und dann funktioniert auch der Cluster nicht mehr wie erwartet.

Ich würde es bei deinen geplanten Aufbau (2-Knoten-Cluster plus Mini-PC für Monitoring/qdevice und ggf. pbs) lassen, aber definitiv die zusätzliche NIC in deine Knoten einbauen. Die nimmst du dann für das corosync-Netzwerk und die Replikation, die bereits vorhandene Netzwerkkarte nutzt du dann für das Backup und als zusätzlichen Link für corosync: https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_redundancy

 

[spooner]

Ah ok, danke euch.

Also ich brauch keine zwei PBS, es reicht einer auf dem Mini-PC.
Und der nutzt dann das Synology als Backup Target.
Dann einfach per NFS Freigabe, oder?
Macht hier eine zweite USB NIC eventuell sinn? Und dann direkt mit einer NIC der Synology verbinden?

Ein gemeinsames Storage habe ich nicht, ich wollte das per ZFS Replication lösen und halt jetzt über die zusätzliche NIC

Die eingebaute NIC ist dann für den normalen Netzwerkzugriff der Clients usw. und halts fürs Backup.

 

[Bu66as]

PBS auf NFS zur Synology ist nicht ideal. PBS braucht viel random I/O auf den Chunks, und über NFS wird das ziemlich zäh, @UdoB hatte das weiter oben schon angesprochen. Wenn der Mini-PC ne halbwegs brauchbare SSD drin hat (muss keine 4TB sein, mit Dedup kommst du erstaunlich weit), lass den PBS lokal darauf arbeiten. Zur Synology dann entweder nen Sync-Job auf nen zweiten PBS dort, oder halt klassisch vzdump per NFS als zusätzliches Backup.

Wenn der Mini-PC wirklich gar keinen Platz hat, wäre PBS als VM direkt auf der Synology die bessere Variante, wie anfangs mal besprochen. Da fällt der NFS-Overhead weg.

USB-NIC für ne Direktverbindung zur Synology geht, aber USB-NICs sind manchmal etwas wackelig. Wenn der Mini-PC nen freien PCIe-Slot hat, lieber da ne günstige Intel-Karte rein. Ansonsten kann man's probieren, für Backup-Traffic reicht das meistens.

 

[spooner]

Oh, dann hab ich das total falsch verstanden.

Mmh, dann ist es ja vielleicht wirklich die beste Lösung mit der PBS VM auf der Synology?
Sprich, das Backup sollte am Besten immer auf einer lokalen Festplatte liegen, richtig verstanden?
Hab gerade noch mal nachgeschaut, die VMs werden insgesamt so ca. 3 TB groß sein.

 

[TErxleben]

Oh, dann hab ich das total falsch verstanden.

Mmh, dann ist es ja vielleicht wirklich die beste Lösung mit der PBS VM auf der Synology?
Sprich, das Backup sollte am Besten immer auf einer lokalen Festplatte liegen, richtig verstanden?
Hab gerade noch mal nachgeschaut, die VMs werden insgesamt so ca. 3 TB groß sein.

Den Speicher eines PBS per 1GB Netzwerk anzubinden ist natürlich ein extremer Flaschenhals.
Der nächste ist dann rotierendes Eisen.
3TB sind auch kein Pappenstil. 300GB musst du im Betrieb mindestens über die Leitung schieben.Ergibt im Idealfall netto über den Daumen eine knappe Stunde.
Also ja richtig, LOKALE MEDIEN.
Ich virtualisiere einen PBS sogar gerne und nehme einen marginalen Leistungsverlust in Kauf. Jedoch binde ich selbst fette externe Speicherorte nur ungern ein. Der Aufwand und die Kosten sind mir zu hoch.
Da arbeite ich lieber mit einem Pull-PBS und den dann sogar auch mit o.g. rotierenden Eisen.

 

[Johannes S]

Mmh, dann ist es ja vielleicht wirklich die beste Lösung mit der PBS VM auf der Synology?

Für die Sicherung auf der Synology auf jeden Fall. Ob man dann zusätzlich noch ein Backup auf dem Mini-PC hat, muss man sich halt überlegen. Vorteil wäre halt, dass man nicht nur ein Backup hätte. Wenn man den Zeitpunkt für die syncs richtig wählt (wie @Bu66as oben vorschlug) sollte das mit den Flaschenhals ja nicht problematisch sein, nachts braucht man das Netzwerk ja im Regelfall sonst für nichts

Sprich, das Backup sollte am Besten immer auf einer lokalen Festplatte liegen, richtig verstanden?

Ja, das ist für die Performance auf jeden Fall eine gute Idee. Der PBS ist nicht wirklich auf den Betrieb mit Netzwerkfreigaben ausgelegt, auch wenn es rein technisch funktioniert und im lokalen Netzwerk meistens auch noch erträglich ist, über das Internet (es gibt Helden die so ihre Hetzner-Storagebox per smb an den PBS anbinden) macht das in der Regel keinen Spaß (Ausnahme: S3-Support, aber der arbeitet dann auch mit einen lokalen Cache).
Siehe dazu auch: https://forum.proxmox.com/threads/warum-ist-der-pbs-so-picky-bei-nfs-storage-mounts.160610/

 

[anna_pve_berlin]

Ich würde die PBS-VM selbst und den PBS-Datastore nicht auf dasselbe Volume legen, wenn du es vermeiden kannst. Das trennt zwar keinen Hardwareausfall der Synology, aber es begrenzt Fehler durch volllaufende Datastores/Snapshots und macht Restore/Umzug einfacher. Praktisch: kleines, eigenes Volume/vDisk für die PBS-VM, Datastore auf ein separates Backup-Volume mit viel IOPS/Cache. Und trotzdem noch eine Kopie außerhalb der Synology einplanen – sonst ist die Synology weiterhin der gemeinsame Ausfallpunkt.

 

[spooner]

Guten Morgen,
OK, also fürs Backup dann folgende Konstellation:

Synology
Vol 1: PBS VMs mit kleiner VM Disk
Vol2: Backup Storage und große VM Disk für PBS
Vol3: Nextcloud Sync
eventuell Vol4: andere Backups, Active Backup for Business, wie auch immer.

Offsite Backup dann in die Cloud mit Synology Hyper-Backup auf einen Wasabi Storage

Hab ich das richtig zusammengefasst?

 

[Bu66as]

Passt so. Volume-Trennung für PBS-VM (klein) und Datastore (groß, separates Volume) ist sauber.

Beim Offsite über Hyper-Backup überleg dir was du genau nach Wasabi schiebst. Den kompletten PBS-Datastore als Block-Backup hochladen wird bei 3TB VM-Daten ordentlich groß. Einfacher: zusätzlich zum PBS noch vzdump-Backups per NFS auf die Synology legen und nur die per Hyper-Backup in die Cloud syncen. Sind einzelne Dateien, viel handlicher fürs Cloud-Backup, und im Ernstfall kannst du die auch ohne funktionierenden PBS restoren.

 

[Johannes S]

Wasabi ist doch S3-kompatibel? Dann würde ich das gar nicht mit HyperBackup machen, sondern mit PBS eigenen S3-Support. Mit den Traffickosten muss man bei S3 so oder so aufpassen, aber das hätte den Vorteil dass nur hochgeladen wird, was sich tatsächlich geändert hat/neu dazukommt.
Disclaimer: Soweit ich weiß ist der S3-Support noch Technology-Preview und ich habe den noch nicht getestet, aber die Berichte im Forum lesen sich vielversprechend
Alternativ oder zusätzlich halt Bu66as Vorschlag mit vzdumps. Ich selbst habe einen offsite-PBS auf einen netcup-Vserver und lasse mir wöchentlich zusätzlich vzdumps anlegen, die ich mit rclone auf eine Hetzner-Storagebox sichere, um notfalls auch ohne PBS restoren zu können.