ZFS-Pool mit einem Laufwerk - Optimale Backupstrategie um Fehler zu korrigieren

[saveZFS]

Hallo,

ich würde gerne aus Kostengründen einen Z-Pool nur mit einem Laufwerk betreiben um nicht zwei Laufwerke für einen Mirror erwerben zu müssen.

Soweit ich mich eingelesen haben, habe ich fast alle ZFS-Features auch mit einem Laufwerk bis auf die automatische Bit-rot Korrektur.
Im Grunde ist der Aufbau dann wie ein Mirror im Status 'degraded' zu sehen. Da ist weiterhin die Fehlererkennung möglich.

Jetzt geht es darum einen möglichen Pool-Fehler nach der Fehlererkennung korrigieren zu können auch wenn die Konsequenz ist, dass Daten von ein paar Tagen (bis zum letzten Backup) im schlimmsten Fall verloren gehen.

Das einfachste wäre die ZFS-Replikation auf einen anderen Pool mit einer größeren Redundanz (z.B. auf einen Z2 oder Z3 Pool).
Allerdings befürchte ich, dass mir das im Falle von Bitfehlern nichts bringt, weil der gesamte Datenbestand inkl. Snapshots auf den neuen Pool geclont wird und ich eigentlich ein 100% Abbild habe aus dem ich den Fehler auch nicht mehr korrigieren kann.
Die Frage ist nur, ob das das soweit korrekt ist?

Falls ja, dann würde noch folgende Lösung bleiben.
Zum Beispiel täglich die Daten auf einen anderen Z-Pool (Z2 oder Z3) kopieren (keine Replikation, also ohne Metadaten des 1-Disk-Pools) und auf diesen Pool täglich einen Snapshot machen.
In dem Fall hätte ich doch ein Backup aus dem ich sicher den fehlerfreien Zustand wiederherstellen könnte?

Kann man das generell so machen oder ist das aus euerer Schicht so und so unsinnig und nicht praktikabel?

 

[John Doe]

ich bin mir nicht sicher, ob ich es richtig verstanden habe.

du möchtest einen raid-Z1 pool aus einer disk erstellen, damit du die "zfs features" hast, um schleichende bitfehler korrigiert zu bekommen?
Und hast die sorge, dass die snapshots bei bitfehlern ebenfalls korrupt sein könnten?

klingt für mich leicht ungewöhnlich. wenn du aus kostengründen keine weiteren platten verwenden möchtest, mach halt einen pool aus einer disk. scrub läuft auch darauf. ECC ram wirst du wohl haben, wenn du so sensibel bei bitfehlern bist oder?


ich hatte mit meinem ersten freenas (j1900 und realtec nic) nach 5 mal hin und herkopieren auf eine windows maschine korrupte daten.
seit ca. 5-7 jahren server grade hardware (ECC Ram- Intel Nic) und replication task zu nem 2. freenas (zum umziehen von daten) keine bitfehler. abschließend kann ich nicht sagen, ob der datenverlust durch fehlender ecc ram, durch den miesen realtec nic oder durch windows oder das häufige hin und her kopieren entstanden ist. Generell sind bitfehler im ram eher selten, nachdem was ich gelesen habe.

die kette geht von der quelle zum netzwerk stack, in dem ram und dann auf die hdd.
von quelle zu netzwerk stack bis zu dem RAM sollte die überprüfung mit CRC gewährleistet sein. Im Ram können unerkannte bitflips auftreten und dann falsch auf die hdd geschrieben werden. ECC Ram sollte dies korrigieren oder zumindest benachrichtigen. Bit fehler auf der HDD (z.b. 0 oder 1 dreht sich durch magnet/strahlung/whatever) sollten mittels scrub jobs eleminiert oder zumindest erkannt werden. Wenn ich dich richtig verstanden habe, sorgst du dich um letzteres.

*disclaimer*
oben steht mein verständnis der technik, ich bin leihe und kein profi, wenn etwas nicht richtig sein soll bin ich happy über eine konstruktive korrektur.

 

[saveZFS]

du möchtest einen raid-Z1 pool aus einer disk erstellen, damit du die "zfs features" hast, um schleichende bitfehler korrigiert zu bekommen?
Und hast die sorge, dass die snapshots bei bitfehlern ebenfalls korrupt sein könnten?

Eigentlich einen Stripe, aber nur ein Laufwerk.
Das mit den Snapshots ist in der Tat meine Sorge und ich frage mich, ob ich dass irgendwie durch ein Backup absichern kann.
Wenn nämlich ein Bitfehler auf dem Laufwerk entsteht, dann hätte es auch die Replikation des Pools und mir bringen die Snapshots nichts.
Aber vielleicht gibt es hier auch gute Lösungen um die Sache automatisiert abzusichern?
Wäre es eine Idee vor jeder Replikation einen Scrub zu machen und nur zu replizieren, wenn der Scrub fehlerfrei war?

ECC ram wirst du wohl haben, wenn du so sensibel bei bitfehlern bist oder?

Ja ECC ist vorhanden!

 

[John Doe]

dann mach dir ein pool mit einem laufwerk, erstelle die scrubs (gibt hier im forum gute anleitungen zu den intervallen), einen snapshot task (gibt auch hierfür gute anleitungen) und einen replication task zu einem 2. pool oder besser zu einem 2. truenas server an einem anderen ort.

damit solltest du ausreichend bedient sein und meines wissens nach auch nach aktuellem stand der technik kurz vor dem maximum sein, was ein privatanwender technisch überhaupt machen kann.

ich persönlich würde die warscheinlichkeit von bitfehlern von ruhenden daten und korrekt geplanten/durchgeführten scrubs als gering einschätzen.

 

[saveZFS]

dann mach dir ein pool mit einem laufwerk, erstelle die scrubs (gibt hier im forum gute anleitungen zu den intervallen), einen snapshot task (gibt auch hierfür gute anleitungen) und einen replication task zu einem 2. pool oder besser zu einem 2. truenas server an einem anderen ort.

OK, so hatte ich es vor.
Danke, dass du mich darin bestärkst, dass das was ich vor habe nah am technisch machbaren (für privat) ist.

Weiß ggf. wer, ob man den Start der Replication an eine Bedingung koppeln kann. In etwa so?

when Srub passed
then start replication
else do nothing

 

[Patrick M. Hausen]

Es gibt (mit extrem hoher Wahrscheinlichkeit) keine Bitfehler, die ZFS nicht bemerkt. Alle Blocks - Daten und Metadaten - haben Prüfsummen. Wenn bei der Replikation ein Block kaputt ist, werden keine kaputten Daten repliziert sondern eine Fehlermeldung erzeugt. Mal abgesehen davon, dass du ja Snapshots replizierst, d.h. die letzte intakte Replikation ist auf dem Ziel dann ja auch noch da.

 

[saveZFS]

Wenn bei der Replikation ein Block kaputt ist, werden keine kaputten Daten repliziert sondern eine Fehlermeldung erzeugt. Mal abgesehen davon, dass du ja Snapshots replizierst, d.h. die letzte intakte Replikation ist auf dem Ziel dann ja auch noch da.

Vielen Dank für diese sehr wertvolle Information.
Ich dachte bei der Replizierung würde einfach der Stand von A nach B übertragen (auch mit möglichen Bitfehler). In dem Fall wäre dann ja auch der Snapshot nicht mehr brauchbar.
Wenn jetzt aber hier bei einem Fehler nicht repliziert ist, dann ist wie du sagst der alte Snapshot (am Replikations-Ziel) ja noch perfekt in Ordnung und könnte bei Bedarf zurückgespielt werden.

Dann werde ich einmal am Tag replizieren und gut ist. Vielen Dank für deinen Input!

 

[micneu]

@saveZFS ich habe mal eine frage, warum willst du es unbeding nur mit einer platte machen, festplatten sind doch heute nicht mehr so teuer (habe meine ironwolf 8TB für ca. 280€/platte gekauft)?

 

[saveZFS]

ich habe mal eine frage, warum willst du es unbeding nur mit einer platte machen, festplatten sind doch heute nicht mehr so teuer (habe meine ironwolf 8TB für ca. 280€/platte gekauft)?

Es geht nicht um die HDD-Pools, sondern um die SSDs für die VMs.
Hier zahle ich jetzt für eine Intel P4510 1TB plus M.2 Adapter gute 300 Euro.
Mein Budget gibt es einfach momentan nicht her für ein redundantes TB 300 Euro auszugeben.
Wenn für jemanden 300 Euro natürlich nicht viel ist, dann gebe ich dir uneingeschränkt recht! ;)

 

[Patrick M. Hausen]

Dann ist aber wirklich alles schick. Betreib deine VMs auf der Enterprise-SSD und mach Snapshots und Replikation auf z.B. einen RAIDZ2-Pool aus Festplatten. Das habe ich an verschiedenen Stellen seit Jahren in Betrieb. ZFS wird dir sagen, wenn irgendwo ein Bit gekippt ist. Es gibt ja auch keine explizite "Bit-Rot Korrektur". Woher kommt die Idee auf einmal?

In einem redundanten VDEV gibt es einfach N Kopien von einem Block. Ist eine davon kaputt, wird das durch Prüfsummen bemerkt und eben eine der intakten Kopien ausgeliefert. Gleichzeitig wird auf dem betroffenen Device ein Checksum-Error vermerkt. Bei TrueNAS sollte dazu oben rechts die Alarm-Lampe im UI angehen.

Und dann tauscht man die Platte und macht ein Resilver.

Was an ZFS neu gegenüber traditionellem RAID ist, ist, dass es eben mit verteilter partiell intakter Information umgehen kann. Block X kaputt auf Platte 1, Block Y kaputt auf Platte 2 - ZFS liefert dir immer noch Daten. Alle Kopien eines Blocks kaputt - ZFS sagt dir klipp und klar "diese Datei ist nun beim besten Willen hinüber" und liefert dir aber alle anderen Dateien noch aus. Ein traditionelles RAID sagt "oh, Platte 1 kaputt, die buch ich mal aus und werfe einen Alarm". "Oh, jetzt ist Platte 2 auch noch kaputt - sorry, das RAID5 ist im Eimer."

Das ist der eigentliche Unterschied.

Grüße
Patrick

 

[saveZFS]

Es gibt ja auch keine explizite "Bit-Rot Korrektur". Woher kommt die Idee auf einmal?

Ich dachte bei einem Mirror würden beim Scrub mögliche Bitfehler anhand der Checksummen automatisch korrigiert werden, falls welche erkannt werden.

 

[Patrick M. Hausen]

Da gibt es nichts zu korrigieren. Wenn es noch eine intakte Block-Kopie gibt aufgrund der Redundanz, dann wird auf dem Laufwerk mit dem kaputten Block ein neuer Block mit den intakten Daten geschrieben, um die Redundanz wiederherzustellen.

 

[saveZFS]

Dann ist aber wirklich alles schick. Betreib deine VMs auf der Enterprise-SSD und mach Snapshots und Replikation auf z.B. einen RAIDZ2-Pool aus Festplatten.

Ja das wäre wirklich schick gewesen, aber die Odyssee nimmt leider kein Ende.
Die SSD lässt sich jetzt trotz ESXi-Workaround 'pcipassthru0.msiEnabled = FALSE' nicht an die TrueNAS VM durchreichen! :(
Dazu habe ich im Entwicklerbereich mal ein Thema eröffnet (https://www.truenas.com/community/threads/nvme0-missing-interrupt-on-intel-ssd.100873/).
Das sieht mir nämlich sehr nach einem Treiberproblem aus oder es liegt am ESXi! :(

 

[Patrick M. Hausen]

Du hattest nicht geschrieben, dass du virtualisieren willst. Funktioniert es denn, wenn du TrueNAS direkt auf der Hardware installierst? Da du geschrieben hast, du möchtest auf der einen SSD VMs laufen lassen, bin ich von TrueNAS-VMs ausgegangen. Wozu dann noch der ESXi?

Wenn du von ESXi-VMs sprichst - wozu dann das TrueNAS bei nur einer SSD? VMFS drauf und feddich ...

 

[saveZFS]

Funktioniert es denn, wenn du TrueNAS direkt auf der Hardware installierst?

Das weiß ich jetzt leider nicht und kann ich auch ohne weitere HW nicht so leicht ausprobieren! :(

Da du geschrieben hast, du möchtest auf der einen SSD VMs laufen lassen, bin ich von TrueNAS-VMs ausgegangen. Wozu dann noch der ESXi?

Ich bin den ESXi einfach gewohnt und weiß nicht, ob TrueNAS als Virtualisierungsumgebung schon auf Augenhöhe mit VMware ist.

Wenn du von ESXi-VMs sprichst - wozu dann das TrueNAS bei nur einer SSD? VMFS drauf und feddich ...

Ja das wäre eine Lösung, wobei ich es schon schön finden würde, wenn TrueNAS (als VM) die Oberhand über die HW hätte. Vor allem auch wegen SMART und der genialen Snapshot Funktion in Truenas.
Aber wenn es nicht geht mit dem Passtrough, dann werde ich das wohl so machen müssen.

 

[Patrick M. Hausen]

Du kannst von den VMs automstisiert Snapshots machen und diese auf ein z.B. von TrueNAS bereitgestelltes NFS-Volume, vorzugsweise dann mit Redundanz, speichern lassen.

GitHub - lamw/ghettoVCB: ghettoVCB

ghettoVCB. Contribute to lamw/ghettoVCB development by creating an account on GitHub.

github.com

 

[saveZFS]

Du kannst von den VMs automstisiert Snapshots machen und diese auf ein z.B. von TrueNAS bereitgestelltes NFS-Volume, vorzugsweise dann mit Redundanz, speichern lassen.

Danke für den Tipp. Das hatte ich schon mal in Betrieb.
Beim "Neuaufbau" wollte ich allerdings alles in TrueNAS haben und den ganzen Server bis auf die TrueNAS Bootpartition auf ZFS.
Aber ich sehe langsam, dass das ggf. gut gedacht war und in der Praxis leider nichts als Ärger macht. :(
Jetzt schon wieder, aber vielleicht bekomme ich den Passthrough mit der Intel SSD doch noch bewerkstelligt. ;)

 

[Patrick M. Hausen]

Das ergibt aber keinen Sinn. Du hast eine SSD für VMs. Und die willst du an TN durchreichen. Wie bekommst du die zurück in die VMware? Per iSCSI? Und dann ein VMFS drauf? Dann darfst du sie maximal zu 50% befüllen. Isso.

Oder NFS. In beiden Fällen hast du synchrone Schreibzugriffe. Du verlierst also Kapzität und Performance. Pack VMFS auf die SSD und überleg dir ein gescheites Backupkonzept.

Oder nutz TrueNAS zum Virtualisieren. Das habe ich hier privat und in der Firma in Produktion 24x7 und keine Probleme. Ist hakeliger als ESXi, aber wenn die VM(s) mal eingerichtet sind, läuft's.

 

[saveZFS]

Wie bekommst du die zurück in die VMware?

Per NFS, wie du es bereits unten beschrieben hast.
Deshalb auch die Probleme bzw. die schlechte Performance wegen den sync-writes.
Ich habe es jetzt übrigens geschafft die Intel P4510 an TrueNAS durchzureichen. Musste in ESXi noch etwas in der passtrouph.map anpassen.

Aber du hast dennoch recht. Auf lange Sicht, sollte ich mir hier ein besseres Konzept fürs Backup überlegen und vielleicht wieder zurück auf das ghettoVCB gehen. Dann wären viele Probleme von Grund auf eliminiert.
Wobei die Snapshots in TrueNAS schon echt komfortabel funktioniert haben! :D

 

[saveZFS]

Pack VMFS auf die SSD und überleg dir ein gescheites Backupkonzept.

Ich habe zwar noch nicht auf VMFS umgestellt, aber mit ghettoVCB die letzten Tage nochmals experimentiert.
Das Tool ist ja generell sehr mächtig und wirklich gut.
Leider ist der Speicherbedarf für diese Backupstrategie im Vergleich zum NFS-Datastore mit ZFS-Snapshots enorm.

Von meiner Windows VM (vmdk = 150 GB) habe ich alle zwei Stunden (nur zum Testen, sonst würde täglich einmal reichen) ein Backup auf einen NFS-Datastore (TrueNAS RaidZ2-Pool) angelegt.
Nach 24 Stunden hatte ich bereits eine Backup-Größe von fast einem TB. Also über Monate hinweg auch bei einem "nur" täglichem Backup nicht praktikabel.

Die Frage ist jetzt nur, wie ich das vom Speicherplatzverbrauch optimieren könnte?
Wäre hier ggf. ZFS-Deduplizierung sinnvoll? Wobei ich befürchte, dass das meine HW nicht leisten kann.
Hat hier ggf. jemand so eine Art von Backup am Laufen und ein Konzept das nicht zig TB Daten benötigt?