Das Problem:
Ein ZFS Snap ist wie Netzstecker ziehen. Ein ZFS Dateisystem selber geht dabei nicht kaputt sondern bleibt bei dem gültigen Stand vor dem Stromausfall als ist auch ein Snap valide. Das gilt aber nicht für VMs mit ihrem Gastdateisystem. Da kann ein Snap korrupt sein wenn man den während eines Schreibvorgangs erstellt. Die VM selber läßt sich durch sync write absichern, nicht jedoch die VM im Snap. Wie oft man einen Fehler hat läßt sich wohl statistisch ermitteln. Ist jedoch ein ungutes Gefühl wenn man nicht genau sagen kann ob ein ZFS Snap gut oder schlecht ist. Um sicher zu gehen kann man die VM vor dem Snap herunterfahren oder einen sicheren ESXi Snap in den ZFS Snap integrieren. ESXi Snaps (quiesce oder hot memory sind sicher) um bei Bedarf nach einem Rollback darauf zurückzugehen. Das mach die ESXi snap Funktion in napp-it und das ist Vorraussetzung für snapbasiertes sicheres Hot Backup. ESXi Snaps sind per VM.
Am einfachsten ein NFS Share für alle VMs anlegen.
Beitrag automatisch zusammengeführt:
Hab hier was zur Z1/Z2 Konfiguration mit Laufwerksanzahl gefunden, weil wir das Thema erst hatten. ine
ZFS/The problem with RAIDZ.md at main · jameskimmel/ZFS
Stuff about ZFS. Contribute to jameskimmel/ZFS development by creating an account on GitHub.github.com
Sieht ja weniger toll aus erstmal, aber inwiefern ist das in der Realität überhaupt zutreffend, vor allem mit TrueNAS?
Hat mit TrueNAS nichts zu tun sondern ist ein ZFS Problem. Seit man aber Compress immer aktiviert, ist es ein Nicht Problem da die Größe eines komprimierten ZFS Datenblocks variabel ist. Die "Golden Number von 2^n Datenplatten" per Raid-Zn war vor vielen Jahren eine Empfehlung bei vdevs ohne Compress. Heute einfach nehmen was da ist und Compress aktivieren.
10 Jahre alt aber aktuell:
How I Learned to Stop Worrying and Love RAIDZ
The popularity of OpenZFS has spawned a great community of users, sysadmins, architects and developers, contributing a wealth of advice, tips…
www.delphix.com
Zuletzt bearbeitet:
