Naja, ocfs2 war eigentlich nie die erste Wahl, eben weil der Support dafür (sowohl auf Seiten von PVE als auch bei Hardware-herstellern) so lausig ist
Aber es erlaubt eben Snapshots mit qcow2 zu benutzen und funktioniert ähnlich aus Endusersicht ähnlich wie vmfs (was ja die Leute von vmware kennen), beides ging damals mit LVM/thick nicht. Seit PVE9 gibt es aber die Möglichkeit snapshots als volume-chains anzulegen auf LVM, sofern man als Format qcow2 nimmt (nur halt ohne Dateisystem ala vmfs, das geht so nach wie vor nicht):
https://pve.proxmox.com/pve-docs/chapter-pvesm.html#pvesm_lvm_config
Das hat allerdings auch noch einige Sachen, die man beachten/bedenken muss:
- Es ist noch technology-preview, also envtl. noch nichts für die Produktion je nach persönlicher Risikoabwägung, weil envtl. Kinderkrankheiten einen erwischen.
- Die Snapshots sind eben als Chain, man kann also nicht beliebig zurückspringen, sondern (wenn ich das richtig verstanden habe, selbst nutze ich das nicht) in Einserschritten
- Es kommt je nach Anwendung zu deutlichen Performanceauswirkungen (30%-90%), das gilt aber auch für qcow2-Images auf Dateisystemen (also auch ocfs2)
- @bbgeek17 hat zu diesen Themen ein tolles Writeup bei seinen Arbeitgeber veröffentlicht: https://kb.blockbridge.com/technote/proxmox-qcow-snapshots-on-lvm/index.html Auch wenn Blockbridge eine Art Konkurenzlösung verkaufen möchte, steht da vieles wichtige drin
Für raw-Images ohne Snapshots habe ich bisher noch nichts negatives hier im Forum gelesen, da geht der Konsens dahin, dass das rocksolide ist, sofern man mit den Limitierungen (kein thin-provisioning, muss dann auf Storageebene gemacht werden, keine Snapshots) leben kann.
@gurubert der ja mit an deinen damaligen Thread beteiligt war hat auch im englischen Forum mal erwähnt, dass aus seiner Sicht ocfs2 nur eine Übergangslösung ist, wenn man den alten Storage weiter verwenden möchte, ohne auf Snapshots zu verzichten. Beim nächsten Hardware-Renewal dann lieber etwas Funktionierendes nehmen
Was das dann ist, kommt dann natürlich darauf an, je nach Umgebung, Usecase oder Kunden kann die Antwort sehr unterschiedlich ausfallen, selbst wenn die Größenordnung und technischen sowie finanziellen Rahmenbedingungen gleich sind. Für die einen wird eine Hardware mit Proxmox-unterstützung wie Blockbridge das Kleingeld wert sein, andere werden darüber zu Fans von hyper-converged-Clustern auf Basis von Ceph. Für sehr kleine Cluster werden Leute dagegen vielleicht mit ZFS (trotz asynconer Natur also potentiellen minimalen Datenverlust) Storage Replication oder NFS (passende Hardware kann man ja kaufen und nicht nur von Netapp) glücklich.
Eine Alternative die auf jeden Fall funktioniert: ProxmoxBackupServer einrichten, dessen Snapshot_Backups arbeiten mit einen qemu-internen Mechanismus und sind als inkrementelle Backups sehr schnell fertig. Mit live-restore kann man damit dann auch ein schiefgegangenes Update einer VM mit geringer Downtime wieder zurückrollen ( VM läuft halt langsamer bis alles wieder da ist, aber sie läuft halt). Das müsste so auch mit Veeam gehen (falls bereits in Verwendung), da fehlt mir aber die eigene Erfahrung. Im Forum werden für meinen Geschmack etwas zuviele Probleme mit Veeams Proxmox-Support beschrieben, andererseits meldet sich hier auch niemand um zu schreiben, wenn es gut funktioniert
Bei Budget-Sorgen kann man den PBS auch ohne Subscription betreiben. Wäre für mich ein Nogo, sofern darüber auch alle Backups laufen, aber als Snapshotersatz kann man sich ja überlegen, ob das den Usecase abdeckt. To be fair ist das auch kein Ersatz für alle Usecases von Snapshots auf Storage-Ebene (da einfach ein anderer Mechanismus), aber den Klassiker "Update läuft schief, Kommando zurück" sollte damit klargehen.
