Das Offsite Backup geht in die Cloud.
Das wollte ich dann mit Synology Hyper Backup machen.
Sprich: die Backups der VMs in Cloud pumpen.
Das kann man machen, dann würde ich aber NICHT den PBS für das offsite-Backup nehmen, da es derzeit noch kein offiziell unterstütztes Verfahren gibt, um dessen Datenbestand zuverlässig auf Cloudspeicher zu übertragen. Es kursieren Hacks wie man das trotzdem hinkriegt, aber die Berichte über deren Zuverlässigkeit sind vorsichtig ausgedrückt durchmischt. Stattdessen würde ich auf der Synology mit dem Standardbackupverfahren von ProxmoxVE die vzdump vma-Dateien speichern und die dann synchronisieren mit dem Hyper Backup. Ein oder zwei lokale PBS für zusätzliche lokale Backups sind dagegen sehr sinnvoll, da dort die Backups weniger Platz wegnehmen und somit mehr Kopien aufbewahrt werden könnten. Die Offsite-Backups sind dann halt für den absoluten Notfall
Wenn du etwas Budget überhast, könntest du dir aber auch PBS als Cloudstorage bei Inett mieten (0,02 Euro pro GB), bei tuxis.nl ein freies Konto (maximal 150 GB) registrieren (die Bezahlvariante geht in Deutschland leider nur für Firmenkunden) oder (so mache ich es) dir bei Netcup oder einen anderen Anbieter einen günstigen vserver für einen offsite-PBS mieten.
Wenn ich ein Cluster einrichte, dann muss es ein ZFS Volume sein, richtig?
Nein. Grundsätzlich wird ein Cluster eingerichtet, weil man gerne möchte, dass im Fehlerfall die VMs/Container eines ausgefallenen Knoten auf einen anderen Knoten weiterlaufen müssen. Dafür müssen die Daten natürlich für beide Knoten verfügbar sein. Das wird man normalerweise über einen gemeinsamen Speicher realisieren (z.B. eine NFS- oder ISCSI-Freigabe auf einer NAS oder per fibre channel an eine SAN) , verteilten Netzwerkspeicher (wie Ceph oder (als Drittbieterangebot) Starwind Virtual SAN). ZFS ist dafür NICHT nötig:
https://pve.proxmox.com/wiki/Storage#_storage_types
Alle diese Lösungen haben gemeinsam, dass sie entweder teuer sind oder (für ein Homelab) überdimensioniert sind, wenn man keinen single-point-of-failure haben will (da entsprechend mehr Hardware, Netzwerkinfrastruktur etc benötigt wird), hier ist ein Beispiel für Ceph:
https://forum.proxmox.com/threads/fabu-can-i-use-ceph-in-a-_very_-small-cluster.159671/ für Ceph
ZFS ist dagegen eigentlich kein gemeinsamer Storage, da es sich um ein Dateisystem auf dem lokalen Festplatten handelt. Es hat aber einiges an Features, die andere Dateisysteme nicht haben ( siehe dazu auch
https://forum.proxmox.com/threads/f...y-a-few-disks-should-i-use-zfs-at-all.160037/ ). Eines davon ist die Möglichkeit Snapshots zwischen verschiedenen Servern zu synchronisieren (zfs send/receive sind relevante Google-Stichwörter). Das kann in einen ProxmoxVE Cluster für eine Art Pseudo-HA genutzt werden:
https://pve.proxmox.com/wiki/Storage_Replication
Damit werden standardmäßig alle 15 Minuten die VMs/Container, ihre Daten und Konfiguration auf andere Knoten übertragen. Effekt: Beim Ausfall eines Knotens gehen nur die dazugekommenen Daten seit der letzten Synchronisation verloren, die VM/der Container selbst läuft dann auf einen anderen Knoten weiter (halt mit Datenverlust bei Ausfall, bei einer Migration ohne, da noch fehlende Daten dann synchronisiert werden).
Diesen Zeitraum kann man auch erhöhen (auf mehrere Stunden) oder (bis auf eine Minute) reduzieren. Damit bietet sich gerade für kleine Cluster (wie bei mir zuhause im Homelab oder kleineren Mittelständlern) an, wo Ceph oder ein shared storage völlig überdimensioniert wären, man aber trotzdem eine annährende Hochverfügbarkeit mit minimalen Datenverlust realisieren möchte.
@Falk R. hat hier mehrmals beschrieben, wie er solche Setups für mittelständische Unternehmen eingerichtet hat (Zwei Server als ProxmoxVE Cluster, dazu ein dritter Server als PBS und quorum device für den Cluster
https://pve.proxmox.com/wiki/Cluster_Manager#_corosync_external_vote_support ). Je nach Anwendung kann man schließlich mit so einen minimalen Datenverlust leben und wo man das nicht kann, ist ja unter Umständen immer noch möglich, die Hochverfügbarkeit auf Anwendungsebene zu realisieren (bei Datenbanken etwa indem auf jeden ProxmoxVE-Knoten eine Datenbank-VM aufsetzt, die wieder untereinander einen Cluster bilden und somit die Verfügbarkeit und Konsistenz sicherstellen).
Wenn man dagegen die Daten zwischen verschiedenen Clustern transferieren möchte, kann man pve-zsync nutzen:
https://pve.proxmox.com/wiki/PVE-zsync
Das überträgt die Daten samt Konfiguration auf einen anderen Host und diese können dort dann auch gestartet werden (praktisch, wenn man bei einen Ausfall schnell wieder die Dienste am laufen haben will).
Aber: Sowohl PVE-zsync als auch die Storage replication setzen ZFS voraus, da nur dort die nötige Funktionalität enthalten sind. Nur wie gesagt kann man einen Cluster mit Hochverfügbarkeit auch mit anderen Storages aufsetzen. Generell sollte man sich klar machen, dass ein Cluster auch mehr Komplexität bedeutet, daher würde ich mir das in deinen Fall gut überlegen, ob du die Funktionalität wirklich brauchst oder ob es nicht sinnvoller ist beide Server als single-node-Instanzen (also nicht im Cluster) zu betreiben->Geringere Fehlerquelle.
Weil ich irgendwo mal gelesen habe, dass ein LVM Volume den Vorteil hätte, das man die VMs als Datei vorliegen hätte und man diese einfach per copy&paste auf ein anderes System kopieren könnte.
Das geht mit ZFS auch, die Frage ist aber wozu? Standardmäßig speichert ProxmoxVE die VMs in Blockspeichern (egal ob Ceph, ZFS oder LVM), da damit der Overhead eines Dateisystems wegfällt kann das je nach Anwendung deutlich schneller sein. Außerdem ist diese Datei "nur" die jeweilige Festplatte der VM, die restliche Konfiguration muss man immer noch auf anderen Weg auf das andere System packen. Innerhalb eines Clusters kann man eine Migration dagegen direkt über die GUI machen, zwischen zwei verschiedenen Clustern oder cluster-losen Knoten auf der Kommandozeile mit pct remote-migrate (container) oder qm remote-migrate (VMs). Falls man dafür eine GUI möchte: Die ist gerade im Alphatest:
https://pve.proxmox.com/wiki/Proxmox_Datacenter_Manager_Roadmap
We’re excited to announce the alpha preview of Proxmox Datacenter Manager! This is an early-stage version of our software, giving you a first impression at what we’ve been working on and a chance to collaborate.
What's Proxmox Datacenter Manager?
The Datacenter Manager project has been developed with the objective of providing a centralized overview of all your individual nodes and clusters. It also enables basic management like migrations of virtual guests without any cluster network requirements.
The project is fully developed in the Rust programming language, from the...
Ein Vorteil ist das eher für Leute, die das so von vmware oder was auch immer sie vorher hatten so gewohnt sind. Wenn man von PVE auf vmware wechselt, würde man das genau umgekehrt empfinden (Der Mensch mag Vertrautes, nicht böse gemeint).
Oder kann das Backupfile über das Standard Proxmox Backup über GUI auch so verwendet werden?
Wo ist der Unterschied zum vzdump statt der GUI?
Im einen startet an das Backup über die GUI im anderen über die Konsole, die Technik dahinter ist die Gleiche.
