Umstieg von OMV Raspi NAS auf TrueNAS (Anfänger)

Pitfrr

Wizard
Joined
Feb 10, 2014
Messages
1,523
Was Datensicherheit angeht, da schliesse ich mich an @ChrisRJ an.

-Wie würdest du sie einlaufen lassen? Wie geht man da vor?
Da gibt es in den Ressourcen mindestens 2 Artikel zu lesen (hier und hier).
Ich würde es so zusammenfassen:
- SMART long
- badblocks (im Schreibmodus, mindestens 1 bis 3 Durchgängen)
- SMART long
und SMART short dazwischen sind jederzeit auch wilkommen! :smile:

Über Backups: ich verstehe, dass man es erst später machen will aber es ist gut schon am Anfang daran zu denken.
Zum Beispiel wenn man Daten rum kopieren will (um den neuen Pool zu erstellen), dann könnte es auch Sinn machen schon eine zusätzliche Festplatte zu kaufen, die aber später für den Backup verwendet wird.

für das Backup könnte ich mir durchaus wieder eine RPi Lösung vorstellen
Stimmt, aber hier auch gut nachdenken, wenn dir die Daten wichtig sind, dann ist eine RPi Lösung vielleicht nicht das geeignetsten. :smile:
 

ChrisRJ

Wizard
Joined
Oct 23, 2020
Messages
1,903
Folgende Gedanken:

1. Backup
Backup wird gerne, wie vom OP auch, mit niedrigerer Qualitaet als das primaere NAS geplant. Aus meiner Sicht sollte es genau umgekehrt sein. Denn wenn das Backup gebraucht wird, dann wird es wirklich(!) gebraucht. Und deshalb sollte das Backup sicherer sein als die primaere Datenhaltung. Insofern kann ich @Pitfrr nur zustimmen.

Relativ einfach und guenstig ist in MS OneDrive (via Office 365 Family) mit Verschluesselung (als TrueNAS Cloud Sync Task). Kostet im Angebot ca. 60-70 EUR pro Jahr fuer 6 TB, was ich fair finde.

2. Burn-in
Ja nach Paranoia, und meine ist aus gegebenem Anlass sehr hoch, wuerde ich das neue NAS mehrer Monate (nicht Tage oder Wochen) parallel zum alten laufen lassen. Auch dann kann es noch passieren, dass die "neue" HDD nach 8 Monaten den Geist aufgibt. Jedenfalls ist es mir so gegangen.
 

s1mmi

Dabbler
Joined
Dec 2, 2022
Messages
17
Ich wuerde das 16 GB Modul behalten. Relativ zu HDDs ist der Unterschied voellig zu vernachlaessigen.
Habe ich jetzt auch so gemacht :D
Core ist wesentlich reifer und stabiler. Fuer mich ist Scale mind. noch 2 Jahre nicht relevant.
Ok spannend, das habe ich jetzt immer mal gehört. Dann wird es (besonders für meine Anwendungszwecke) eher auf Core hinauslaufen...
 

s1mmi

Dabbler
Joined
Dec 2, 2022
Messages
17
Das ist Deine persoenliche Erfahrung und ich freue mich wirklich fuer Dich, dass es so ausgegangen ist. Aber daraus eine allgemeine Sicht zu machen ist keine gute Idee. Ich habe meinen Sicherheitsgurt beim Autofahren in 30 Jahren auch noch nie gebraucht. Aber deshalb lege ich ihn trotzdem an. Und schliesslich, um wieder mehr auf die praktische Ebene zu kommen, sind Eure Systeme unterschiedlich, haengen an unterschiedlichen Elektroinstallationen usw. Klar wird es mit ueber 95% Wahrscheinlichkeit gut gehen. Aber es wird ein zusaetzliches Risiko eingefuegt, das nicht ignoriert werden sollte.

Das ist meine Sicht und sie ist stark vom Wert der Daten gepraegt, mit denen ich beruflich zu tun habe. Ob diese paranoide Sicht relevant ist, muss jeder fuer sich selbst entscheiden. In jedem Fall danke fuer die Sichtweise.
Danke für deine Einschätzung dazu! Aktuell tendiere ich auch eher zur "safe" Lösung
 

s1mmi

Dabbler
Joined
Dec 2, 2022
Messages
17
Danke @ChrisRJ @Pitfrr für eure Einschätzung zu Backup und Burn-in.
Mit Burn-in habe ich mich nie groß beschäftigt, was offensichtlich ein Fehler war...(ich werde meine Hausaufgaben also machen ;D)...

Beim Backup werde ich mich wohl gründlich überlegen, wie ich dieses angehe...und die Option gegeneinander Abwegen...
 

cap

Contributor
Joined
Mar 17, 2016
Messages
122
Auch wenn es hier scheinbar unpopulär ist: Ich nutze ganz bewusst einen ZFS Mirror

Gründe:
- zwei (Helium) Festplatten sind sparsamer und verbrauchen zusammen vielleicht 10 Watt.
- ZFS: You should use mirror vdevs, not RAIDZ: https://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-not-raidz/

Ich nutze noch TrueNAS Core 12.
Werde aber wahrscheinlich über Weihnachten auf Scale umsteigen.
Gründe:
- Linux ist ein gutes Stück stromsparender als FreeBSD bzw. TrueNAS Core. Mit PowerTOP kann man den Verbrauch teilweise noch mal ein gutes Stück drücken. Aktuell verbraucht mein Server mit zwei durchlaufen Platten ca. 25 Watt. Ich denke mit Linux könnte ich unter 20 Watt kommen.
- TrueNAS Scale: Für meine Nutzung als Heimanwender ist Scale vermutlich die bessere Wahl. Angebot über Docker & Co. ist scheinbar größer, z.B. Photoprism.
Aber Core ist natürlich ausgereifter.
 

s1mmi

Dabbler
Joined
Dec 2, 2022
Messages
17
Auch wenn es hier scheinbar unpopulär ist: Ich nutze ganz bewusst einen ZFS Mirror

Gründe:
- zwei (Helium) Festplatten sind sparsamer und verbrauchen zusammen vielleicht 10 Watt.
- ZFS: You should use mirror vdevs, not RAIDZ: https://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-not-raidz/

Ich nutze noch TrueNAS Core 12.
Werde aber wahrscheinlich über Weihnachten auf Scale umsteigen.
Gründe:
- Linux ist ein gutes Stück stromsparender als FreeBSD bzw. TrueNAS Core. Mit PowerTOP kann man den Verbrauch teilweise noch mal ein gutes Stück drücken. Aktuell verbraucht mein Server mit zwei durchlaufen Platten ca. 25 Watt. Ich denke mit Linux könnte ich unter 20 Watt kommen.
- TrueNAS Scale: Für meine Nutzung als Heimanwender ist Scale vermutlich die bessere Wahl. Angebot über Docker & Co. ist scheinbar größer, z.B. Photoprism.
Aber Core ist natürlich ausgereifter.
Danke für die spannende Erörterung zu Mirrors, der Link war sehr lehrreich!
Zum Aktuellen Planungsstand liegt es also zwischen RaidZ2 und Mirror. Was ich mich frage ist: Wenn nun aus einem VDev eine Platte stirbt, dann bestehe doch das (gefühlt recht hohe) Risiko, dass während des Resilvering die Andere Platte aus dem selben VDev stirbt. Damit wäre der gesamte Pool down, oder? Fühlt sich diese Angst nur für mich recht begründet an? Wäre es dann in so einem Fall sinnvoll (da ich ja ältere und neuere Platten habe) jeweils die einzelnen Vdevs aus einer neueren und einer älteren Platte zu erstellen? (Also nicht zwei (risikobelastetere) ältere Platten in einen Mirror).

Echt cool, dass du auch bei Scale vs Core eine andere Meinung vertrittst. Photoprism scheinte eine der Anwendungen zu sein, bei denen ich nicht wusste, dass ich sie will :wink:. Ist Photoprism nicht für Core verfügbar?
 

Patrick M. Hausen

Hall of Famer
Joined
Nov 25, 2013
Messages
7,737
Ist Photoprism nicht für Core verfügbar?
Es gibt kein Standardpaket für FreeBSD aber wohl den ein oder anderen Versuch, dss zu bauen. Muss man dann eben auf Github suchen und selbst Hand anlegen.

Allerdings kann man auf CORE problemlos komplette Linux-VMs für störrische Anwendungen betreiben. Ich hab hier zwei produktive Atlassian Confluence Instanzen. z.B.
 

ChrisRJ

Wizard
Joined
Oct 23, 2020
Messages
1,903
Danke für die spannende Erörterung zu Mirrors, der Link war sehr lehrreich!
Wobei dieser Artikel, vorsichtig formuliert, nicht ganz unumstritten ist. Die Empfehlung einen 2-way mirror einem RAIDZ2 vorzuziehen halte ich persoenlich fuer fahrlaessig. Man darf ausserdem nicht vergessen, dass dieser Artikel schon ein paar Jahre auf dem Buckel hat. Damit haben sich die Dinge potentiell ausreichend veraendert, dass die Schlussfolgerungen des Artikels fuer das eigene System hinterfragt werden sollten. Es sind viele gute und richtige Punkte beschrieben, aber eben auch Sachen, die nicht so schwarz-weiss sind wie dargestellt.
Zum Aktuellen Planungsstand liegt es also zwischen RaidZ2 und Mirror.
Beide sind fuer sehr unterschiedliche Workloads gedacht. Letzterer sollte der bestimmende Faktor sein.
Was ich mich frage ist: Wenn nun aus einem VDev eine Platte stirbt, dann bestehe doch das (gefühlt recht hohe) Risiko, dass während des Resilvering die Andere Platte aus dem selben VDev stirbt.
Genau dieser Eindruck wird im Artikel geweckt und er ist meiner Meinung nach aus mehreren Gruenden falsch.

1) Es stimmt, dass waehrend eines RAIDZ Resilverings die mechanische Beanspruchung einer Platte unter bestimmten Bedingungen hoeher ist als im Normalbetrieb. Mit anderen Worten: Im Normalbetrieb liegt die mechanische Auslastung ausreichend deutlich unter 100%. Das ist im Heimbereich sicher der Fall. Auf der anderen Seite sind zumindest Platten, die fuer den Einsatz im Rechenzentrum gedacht sind, hoffentlich auf mehr oder weniger 100% Auslastung ausgelegt. Und genau hier wird es interessant. Denn da mehr als 100% nicht geht, bedeutet dies, dass beim Resilvering einfach nur ein Teil der Aktivitaet anders ist als im Normalbetrieb. Statt Daten an den Client zu liefern, werden Daten an den Resilver-Prozess geliefert. Und man darf nicht vergessen, dass ZFS fuer extreme Szenarien im RZ-Betrieb entwickelt wurde. Insofern muss man aus meiner Sicht bei Ueberlegeungen wie dieser hier auch von einem solchen Umfeld ausgehen.

2) Statistik: Ein hoeheres Risiko ist nicht automatisch ein hohes Risiko. Mal angenommen, das mein Argument 1) falsch sei. Weiterhin angenommen, dass das Ausfallrisiko einer Platte ueber einen Zeitraum von 2 Wochen (wenn das die Dauer des Resilverings ist) im Normalbetrieb bei 1% liegt (sicher deutlich zu hoch angesetzt). Dann bedeutet ein um 50% erhoehtes Risiko beim Resilvering (sicher auch deutlich zu hoch angesetzt), dass das Gesamtrisiko auf 1,5% steigt. Ist das jetzt so eine Riesenunterschied? Aber halt! Bei RAIDZ2 waere auch das noch kein Problem. Denn erst beim Ausfall der dritten Platte sind meine Daten weg. Das Problem mit Wahrscheinlichkeiten ist, dass sie anders funktionieren als das normale "mathematische Bauchgefuehl".

3) Backup bzw. Business Continuity
Es gibt diverse Risiken (v.a. menschliche), die mit deutlich hoehrer Wahrscheinlichkeit eintreten als der Ausfall einer, geschweige denn mehrerer Platten quasi gleichzeitig (egal ob im Mirror oder RAIDZ). Insofern brauche ich sowieso immer ein Backup. Und das relativiert, wenn es funktioniert(!), auch die Auswirkungen eines katastrophalen Plattenausfalls.

4) Click-bait
Der Titel ist reisserisch gewaehlt und das sagt viel ueber den Autor bzw. Artikel aus. Es funktioniert ja offensichtlich seit vielen Jahren, sonst wuerde das Teil nicht regelmaessig auftauchen. Aber serioes finde ich den Text nicht.

Das sollte als Kritik erstmal reichen :wink:

Damit wäre der gesamte Pool down, oder? Fühlt sich diese Angst nur für mich recht begründet an?
Ja waere er. Aber zumindest aus meiner Sicht ist es in dieser Form Panikmache (s.o.). Und ich bin wirklich paranoid was meine Daten angeht. Aber das sichere ich ueber verschiedene Backup ab. Und ich habe, weil es primaer um Archiv-aehnliche Daten geht, immer nur RAIDZ genutzt. Nach 4 Jahren RAIDZ1 (5*1 TB) sind es nun ueber 10 Jahre RAIDZ2 (erst 6*4 TB und jetzt 8*16 TB). Und mir sind in Summe mind. 5 Platten verreckt.
Wäre es dann in so einem Fall sinnvoll (da ich ja ältere und neuere Platten habe) jeweils die einzelnen Vdevs aus einer neueren und einer älteren Platte zu erstellen? (Also nicht zwei (risikobelastetere) ältere Platten in einen Mirror).
Kannst Du Deine Platten nochmal kurz beschreiben?
 

bic

Contributor
Joined
Dec 7, 2021
Messages
182
.... mir sind in Summe mind. 5 Platten verreckt.
Nun mach ihm mal nicht solche Angst! Ich betreibe 2 NAS á 4 Platten seit mindestens 15 Jahren (mittlerweile sind es sogar 3 Maschinen), anfangs unter Open-E und nun schon seit geraumer Zeit unter Truenas. Während der ganzen Zeit ist mir nicht eine der Platten im laufenden Betrieb kaputt gegangen, dies passierte mir nur zweimal mit neuen Platten quasi beim "Einlaufen", dann allerdings auch nicht als Totalausfall. Man kann also auch Glück haben, bzw. sich völlig normal verhaltene Platten erwischen :smile:
 

emk2203

Guru
Joined
Nov 11, 2012
Messages
573
Bei solchen Aussagen sollte man immer dazusagen, wieviel Platten die Grundgesamtheit bilden. 5 Platten sind mir auch verreckt -- aber die Platten waren teilweise 10 Jahre alt, auf jeden Fall über 5 Jahre, mit 30.000 - 50.000 Betriebsstunden. Und meine NAS-Systeme zusammen haben insgesamt 32 Platten. Da sind die 5 Platten relativ wenig...

Ich empfehle jedem, das exzellente Blog von Backblaze zu dem Thema zu lesen: How long do disk drives last?

TL;DR:
  • 90% aller Platten leben länger als 4 Jahre und 65% leben länger als 6 Jahre.
    (bei 24/7 sind das 35.040 Stunden für 4 Jahre und 52.560 für 6 Jahre)
  • drive-survival-chart-.jpg

    Bis zum 5. Jahr sterben ca. 10% der Platten relativ linear mit 2,5%/a, im 5. Jahr sind es 6,5% und im 6. Jahr 18,5%.--> Platten nach 4 Betriebsjahren (35.040 Stunden) unter Beobachtung, nach 5 Betriebsjahren (43.800 Stunden) vorbeugend austauschen im SOHO-Bereich)
  • Nach 6 Jahren 8 Monaten sollten die Hälfte aller Platten hin sein (extrapoliert).
  • Die Platten bei Backblaze laufen im RC bei unter 30 °C. Da sieht man keine Temperaturabhängigkeit.
    --> Zusammen mit weiteren gängigen Industrieempfehlungen würde ich im SOHO-Bereich bis 45 °C als sicher ansehen und für weitere jeweils 5 °C 6 Monate von der Lebensdauer abziehen. Zur Erinnerung: Der Hersteller sagt, alles bis 60 °C ist innerhalb der Spezifikation.
Wer sich also ein System mit 5 Platten zusammenstöpselt, kann damit rechnen, dass in 5 Jahren mit (1-0.9^5) = 34,4% Wahrscheinlichkeit eine Platte von den fünfen wegstirbt. Wer sich das exzellente disk monitor script installiert und die Mails davon nicht ungelesen wegdrückt, sieht das auch rechtzeitig vorher. Wenn das System permanent im idle Modus ist oder man sogar noch den HDD spindown timer installiert hat, können die Platten natürlich viel, viel länger halten.

Aus meiner Erfahrung wirklich wichtig: Platten aus verschiedenen Chargen kaufen. Wenn von 5 Platten 3 auf einmal Probleme haben und man das wegen Abwesenheit oder so nicht rechtzeitig bemerkt, rettet einen auch kein RAIDZ2 mehr. Das ist mir schon passiert, aber ich konnte jeweils noch den Pool resilvern, bevor Platte #2 und dann #3 tot waren.

Sowas passiert z. B. dann, wenn ein System 4 oder 5 Jahre läuft und man es dann wegen Urlaub einmal ausschaltet. Nach dem Wiedereinschalten gibt es dann die Fehler.
 

ChrisRJ

Wizard
Joined
Oct 23, 2020
Messages
1,903
Man kann also auch Glück haben, bzw. sich völlig normal verhaltene Platten erwischen :smile:
Kann man. Aber auf dieser Hoffnung basierend auf Vorsichtsmassnahmen zu verzichten, ist schon "mutig". Ich verweise bei solchen Aussagen immer gerne auf den Sicherheitsgurt im Auto. Nur weil ich ihn noch nie auch nur ansatzweise gebraucht habe, kaeme ich nicht auf die Idee ihn nicht zu nutzen. Und ich kaeme erst recht nicht auf die Idee anderen zu sagen, dass er nicht zwingend notwendig ist.
 

emk2203

Guru
Joined
Nov 11, 2012
Messages
573
Beim Sicherheitsgurt gibt es Statistiken zuhauf, die zeigen, wie notwendig er ist. Bei manchen Praktiken im Bereich IT hat man aber den Eindruck, die werden gemacht, "weil man's kann" und weil ja theoretisch was passieren könnte. Klar, ist noch niemand gefeuert worden, der auf Nummer Sicher geht. Das ist ja auch das Denken dahinter, klassische Sachbearbeitung oder mittleres Management. Bestes Beispiel: Verschlüsselung. Brauchen privat vielleicht 2% der Leute, die das machen.

Aber wenn man mit Budgetverantwortung denkt, überlegt man sich auch mal die Kosten, Konsequenzen etc. als andere Seite der Medaille. TCO, erhöhter initialer Aufwand, Probleme im Fehlerfall, Zeitaufwand etc etc. Mal ein bisschen wie ein Führungsverantwortlicher denken schadet nicht. Auch bei Sicherungen und Best Practices kann man sich mal eine persönliche FMEA überlegen und dann danach handeln. Ich schick ja auch nicht meine Backups zu Elon Musk, um auch noch gegen den Alienangriff auf die Erde gefeit zu sein, wenn Elon das Backup mitnimmt auf die Marsmission.

Ich mag ja Statistiken oder notfalls gehäufte anekdotische Einzelfälle. Da sieht man konkret, warum man Dinge tut oder lässt. Die 200.000 Disks von BackBlaze lassen sich ja schlecht wegdiskutieren. Aber die sollten auch da sein, nicht nur "es könnte ja".
 

bic

Contributor
Joined
Dec 7, 2021
Messages
182
Aber auf dieser Hoffnung basierend auf Vorsichtsmassnahmen zu verzichten, ist schon "mutig".
Och, die sind schon da. Das Arbeitstier-NAS wird auf eine zweite Maschine repliziert und außerdem kümmert sich Veeam um ein echtes Backup inner- und auch per SSH und VPN außerhäusig.
 

s1mmi

Dabbler
Joined
Dec 2, 2022
Messages
17
Soooo...hallo erstmal und ein frohes neues Jahr (kann man das noch sagen?), den letzten Monat war ich auf Grund von Weihnachtsstress, Urlaub und so weiter etwas still. Aber jetzt will ich die Sachen angehen, die Komponenten sind da und es soll losgehen...

Erstmal vielen Dank euch allen für die wirklich spannenden und hilfreichen Kommentare! Ich habe alles mehrfach gelesen und für mich einige Schlüsse gezogen. Ich setze auf (vorerst) einen RaidZ2 Pool mit 5 x 12 TB... alles etwas gemischte Platten. 1 x Seagate Ironwolf Pro, 2 x neue WD Elements Platten (wohl "weiße" WD Red Platten) und 2 x zwei Jahre alte WD Elements (auf denen aktuell das RPi NAS drauf läuft und somit auch noch produktiv Daten liegen).

Der Plan sieht nun so aus (hier bin ich gespannt auf eure Gedanken dazu):

1. Hardware zusammen bauen, (zunächst mit 3 x 12 TB (weil die 2 x 12 TB noch am RPi hängen und die Daten noch transferiert werde müssen), vermutlich werde ich um den Pool aufbauen zu können zwei ältere 4 TB (eine intern eine extern) verbauen, welche dann nach dem Daten transfer ausgetauscht werden) und TrueNAS Scale installieren
2. Platten einlaufen (muss ich mich noch informieren wie und wie lange
3. Daten von RPi NAS auf TrueNAS umziehen (wie mache ich das am besten, möglicherweise über RSync?)
4. Die 2 x 12 TB vom RPi formatieren und in den Pool einbauen
5. Hoffen, dass alles funktioniert und alles Schnell ist....uff

Ich freue mich auf eure Gedanken :D
 

ChrisRJ

Wizard
Joined
Oct 23, 2020
Messages
1,903
Ein VDEV kann nicht nachtraeglich erweitert werden. Ein "RAIDZ2 Pool" ist streng genommen ein "Pool, der von einem RAIDZ2 VDEV unterfuettert ist". Man kann zusaetzliche VDEVs hinzufuegen, aber existierende koennen nicht erweitert werden.

EDIT: Mit anderen Worten - der geplante Ansatz funktioniert so nicht.
 

s1mmi

Dabbler
Joined
Dec 2, 2022
Messages
17
Ein VDEV kann nicht nachtraeglich erweitert werden. Ein "RAIDZ2 Pool" ist streng genommen ein "Pool, der von einem RAIDZ2 VDEV unterfuettert ist". Man kann zusaetzliche VDEVs hinzufuegen, aber existierende koennen nicht erweitert werden.

EDIT: Mit anderen Worten - der geplante Ansatz funktioniert so nicht.
Ich glaube ich habe mich schwer verständlich ausgedrückt...
Das VDEV wird nicht nachträglich erweitert. Ich baue den Pool direkt mit 5 Datenträgern auf. Zwei von diesen sind aber kurzfristige Platzhalter, welche nach der Datenübertragung durch die langfristig geplante Lösung ersetzt werden. Also technisch vermutlich, indem ich einen Resilvering Prozess für die neuen Platten starte...
 

Patrick M. Hausen

Hall of Famer
Joined
Nov 25, 2013
Messages
7,737
So hatte ich das auch gelesen. Bedenke, dass die kleinste Platte die Kapazität definiert. Du bekommst also 3x (5 - 2) 4 TB und erst, nachdem du die beiden Platten ausgetauscht hast, 3x 12 TB
 
Top