71-TiB-ZFS-NAS mit 10 Jahren ohne Laufwerksausfall
(louwrentius.com)- Ein 71-TiB-ZFS-NAS aus 24 4-TB-HGST-Laufwerken wurde über mehr als 10 Jahre betrieben; Mainboard und Netzteil wurden zwar ersetzt, aber es gab bislang keinen Laufwerksausfall
- Über 10 Jahre kamen die Laufwerke nur auf rund 6000 Betriebsstunden insgesamt; das System wurde nur bei Bedarf aus der Ferne eingeschaltet, was die Stromkosten deutlich senkte
- Auf HN wurde angemerkt, dass die Wahrscheinlichkeit, dass 24 Laufwerke über 10 Jahre alle ohne Ausfall bleiben, höher sei als gedacht; deshalb ist es schwer, das allein auf das häufige Abschalten zurückzuführen
- ZFS importierte den Pool auch nach Betriebssystemwechseln problemlos erneut, und bei den mehrmals pro Jahr ausgeführten zpool scrubs wurden nie Prüfsummenfehler gefunden
- Geräuschentwicklung, Netzwerk, UPS, Backups und Austauschplanung wurden jeweils als Kompromiss zwischen Stromverbrauch, Kosten und akzeptiertem Risiko betrieben; dieselbe Kapazität wäre künftig auch mit 6–8 Laufwerken in RAIDZ2 möglich
71-TiB-ZFS-NAS, das mehr als 10 Jahre durchgehalten hat
- Ein 4U-71-TiB-ZFS-NAS mit 24 4-TB-Laufwerken ist seit über 10 Jahren im Einsatz
- Das aktuelle System nutzt inzwischen das zweite Mainboard und das zweite Netzteil
- Einen Laufwerksausfall gab es bislang noch nie
- Die 4-TB-HGST-Laufwerke kommen zusammen auf etwa 6000 Betriebsstunden, was über 10 Jahre gerechnet ungefähr 250 Tagen Laufzeit entspricht
Strombetrieb: nur einschalten, wenn es gebraucht wird
- Das NAS ist standardmäßig ausgeschaltet und wird nur bei Bedarf aus der Ferne eingeschaltet
- Der Einschaltablauf sieht so aus
- Per Skript wird eine IoT-Steckdosenleiste eingeschaltet
- Sobald der BMC (Baseboard Management Controller) hochgefahren ist, wird das NAS selbst per IPMI eingeschaltet
- Alternativ wäre auch Wake-on-LAN möglich gewesen
- Nach der Nutzung wird der Server per kleinem Skript heruntergefahren und einige Sekunden später die Stromversorgung an der Wand abgeschaltet
- Wäre nur der Server ausgeschaltet worden, während Mainboard und BMC weiter mit Strom versorgt bleiben, würden dauerhaft etwa 7 W verbraucht; deshalb wurde diese Variante vermieden
- Andere Dienste laufen auf einem Raspberry Pi 4 oder auf Servern mit deutlich geringerem Standby-Verbrauch, daher musste das große NAS nicht dauerhaft laufen
- Der Hauptgrund war die Senkung der Stromkosten, und es wurde außerdem angenommen, dass dies der Lebensdauer der Festplatten zugutekommt
- Allerdings wurde auf HN darauf hingewiesen, dass die Wahrscheinlichkeit eines ausfallfreien Betriebs von 24 Laufwerken über 10 Jahre höher ist als erwartet; deshalb lässt sich das Ergebnis schwer eindeutig auf das Abschalten der Stromversorgung zurückführen
- Auch das vorherige NAS mit 20 1-TB-Samsung-Spinpoint-F1-Laufwerken lief etwa 5 Jahre lang ohne Laufwerksausfall
Komponenten, die vor den Laufwerken Probleme machten
- Die Laufwerke waren in Ordnung, aber das Mainboard musste vor einigen Jahren ersetzt werden
- Der Defekt äußerte sich so, dass kein BIOS-Zugang mehr möglich war und das System gelegentlich nicht bootete
- Grundlegende Maßnahmen wie das Entfernen der CMOS-Batterie wurden versucht, lösten das Problem aber nicht
- Dasselbe Mainboard war auf Ebay zu einem vernünftigen Preis erhältlich und konnte daher ohne größere Probleme ersetzt werden
- Dass genau dasselbe Board nötig war, lag daran, dass der Server vier PCIe-Slots nutzte
- Die Konfiguration bestand aus drei HBAs und einer 10-Gbit-NIC
- Das Netzteil musste beim Booten bewältigen, dass alle Laufwerke gleichzeitig anliefen und für einige Sekunden rund 600 W zogen
- Das Netzteil war mit 750 W spezifiziert und konnte auf der 12-V-Schiene nach Erinnerung ausreichend Leistung liefern, schaltete beim Start aber gelegentlich trotzdem ab
ZFS-Betrieb und Ergebnisse der Scrubs
- ZFS lief über Jahre hinweg problemlos
- Das Betriebssystem wurde mehrfach gewechselt, aber nach jeder Neuinstallation ließ sich der bestehende Pool ohne Schwierigkeiten wieder importieren
- Würde ein neuer Storage-Server gebaut, würde erneut ZFS verwendet werden
- zpool scrub wird einige Male pro Jahr ausgeführt
- Ein vollständiger Scrub dauert etwa 20 Stunden
- Weil der Stromverbrauch während eines Scrubs steigt, wird er bei dynamischen Stromtarifen an Tagen mit günstigem Strom ausgeführt
- Bisher wurde bei keinem Scrub auch nur ein einziger Prüfsummenfehler gefunden
- Insgesamt dürften über alle Laufwerke hinweg mehr als 1 Petabyte Daten gelesen worden sein, ohne dass ZFS jemals zur Wiederherstellung eingreifen musste
Laufwerksfehler und stille Datenkorruption
- Laufwerksausfälle lassen sich im Wesentlichen in zwei Formen einteilen
- Totalausfall, bei dem ein Laufwerk gar nicht mehr erkannt wird
- Lese-/Schreibfehler oder defekte Sektoren
- Die dritte Form, stille Datenkorruption, wird als sehr selten angesehen
- Dabei liefert die Festplatte beschädigte Daten, ohne selbst zu erkennen, dass sie fehlerhaft sind
- Oder Fehler bei der SATA-Verbindung werden nicht per Prüfsumme erkannt
- Da es viele Prüfsummenprüfungen auf niedriger Ebene gibt, wird dieses Risiko als sehr klein eingeschätzt
- Stille Datenkorruption ist ein reales Risiko, wird aber eher in großen Umgebungen wie Rechenzentren als im Wohnumfeld als relevantes Problem gesehen
- ZFS ist für Nutzer, die mit Linux oder FreeBSD vertraut sind, durchaus lernenswert und nicht besonders schwer zu erlernen
Lüftersteuerung für ein leises NAS
- Für ein NAS ist dieses System sehr leise
- Im Gehäuse sitzen drei robuste 12-V-Lüfter, die die 24 Laufwerksschächte kühlen
- Mit Standarddrehzahl sind sie sehr laut, bei niedriger RPM jedoch ziemlich leise und in den meisten Situationen mit ausreichendem Luftstrom
- Nur mit niedriger Drehzahl stieg die Temperatur der Laufwerke bei Lese- und Schreibvorgängen mit der Zeit dennoch an
- Das verwendete Supermicro-Mainboard erlaubte unter Linux die Steuerung aller Lüfteranschlüsse
- Es wurde ein Skript erstellt, das die Lüftergeschwindigkeit anhand der Temperatur des heißesten Laufwerks regelt
- In einem Mathematik-Subreddit wurde nach einem Algorithmus gefragt, der sowohl leise ist als auch die Laufwerke wirksam kühlt; empfohlen wurde ein PID-Regler
- Der PID-Regelcode wurde in Python geschrieben, Beispielcode übernommen und die Parameter angepasst
- Dieses Skript funktionierte über Jahre zuverlässig und hielt die Laufwerkstemperaturen unter 40 °C
- Da der Grundluftstrom gering war, wurde zusätzlich ein Lüfter benötigt, um die vier PCIe-Karten wie HBA und Netzwerkkarte zu kühlen
Veränderungen in der Netzwerkkonfiguration
- Anfangs wurden ein Quad-Port-Gigabit-Netzwerkcontroller und Network Bonding verwendet
- Mit dieser Konfiguration wurde zwischen mehreren Systemen ein Datendurchsatz von etwa 450 MB/s erreicht
- Weil dafür zu viele UTP-Kabel nötig waren, wurde später auf günstige InfiniBand-Karten umgestellt
- Mit der InfiniBand-Konfiguration waren zwischen Systemen etwa 700 MB/s möglich
- Bei der Rückkehr von Ubuntu zu Debian funktionierten die InfiniBand-Karten nicht mehr, und die Ursache konnte nicht gelöst werden
- Danach wurden gebrauchte 10-Gbit-Ethernet-Karten gekauft, die bis heute problemlos laufen
UPS, Backups und akzeptiertes Risiko
- Eine Zeit lang wurde eine große UPS verwendet, damit das System bei Stromausfällen sauber herunterfahren konnte
- Nachdem festgestellt wurde, dass die UPS zusätzlich zum Serververbrauch mehr als 10 W benötigt, wurde sie entfernt
- Das Risiko, das System durch Stromprobleme zu verlieren, wurde bewusst akzeptiert
- Die wichtigsten Daten werden dreifach gesichert
- Viele der auf dem Server gespeicherten Daten gelten nicht als wichtig genug für ein Backup
- Gegen Datenverlust durch Laufwerksausfälle wird auf Ersatzhardware und ZFS vertraut
- Falls dieser Schutz nicht ausreicht, wird der Verlust in Kauf genommen — unter dieser Prämisse lief das System 10 Jahre lang
Nächste Generation auch mit kleinerer Konfiguration möglich
- Aktuell gibt es keine konkreten Pläne für zukünftigen Storage
- Der Server wurde ursprünglich gebaut, um Daten nicht ständig wegen Platzmangels verschieben zu müssen, und auch heute ist noch ausreichend Speicher frei
- Es gibt Ersatzteile wie Mainboard, CPU, Arbeitsspeicher und HBA-Karten, sodass das System bei einem Ausfall wahrscheinlich wiederbelebt werden könnte
- Da die Kapazität von Festplatten stark gestiegen ist, könnte das 24-Bay-Gehäuse eines Tages durch einen kleineren Formfaktor ersetzt werden
- Die gleiche nutzbare Kapazität mit ähnlicher Redundanz ließe sich heute mit 6 bis 8 Festplatten und RAIDZ2, also auf dem Niveau von RAID 6, aufbauen
- Storage wird weiterhin als teuer angesehen
- Eine weitere Möglichkeit ist, dass das System in den nächsten Jahren endgültig ausfällt, nicht ersetzt wird und damit das Storage-Hobby endet
1 Kommentare
Meinungen auf Hacker News
Ich frage mich, ob es einen Austauschzyklus für die Laufwerke gibt.
Die 24 Laufwerke sind wahrscheinlich dasselbe Modell und stammen aus derselben Charge, und auch ihr Verschleiß dürfte ähnlich sein. Dann könnten die meisten ungefähr zur gleichen Zeit ausfallen, und die übrigen könnten wegen der erhöhten Last während des Rebuilds ebenfalls ausfallen.
Zuverlässiger Storage ist knifflig.
Natürlich fielen beide gleichzeitig aus, und wir mussten die ganze Nacht Wiederherstellungsarbeiten machen.
Da hatte ich wirklich Glück :D
Aber ich glaube nicht, dass Hardware-Verschleiß derart konsistent ist.
Es hielt gut durch, bis ein Laufwerk starb und während des Rebuilds ein zweites hinterher starb.
Natürlich war es kein ZFS, es gab keine regelmäßigen Scrubs, die Ausfallraten von Laufwerken in den 2000ern waren möglicherweise anders, und er schaltete es bei Nichtbenutzung auch nicht aus.
Der Kernpunkt sind korrelierte Ausfälle, weniger die genaue Ursache. Dazu gelten die üblichen Vorbehalte: Stichprobe von 1, irgendeine zufällige Person aus dem Internet.
Die Stelle „Dieses NAS ist für ein NAS sehr leise“ liegt daran, dass Lüfter mit großem Radius auch bei niedriger Drehzahl viel Luft bewegen können und zudem deutlich energieeffizienter sind.
Oxide Computer hat in einer Präsentation erklärt, warum sie 80-mm-Lüfter verwenden: weil sie leise sind und, noch wichtiger, wenig Strom verbrauchen.
Sie hätten beobachtet, dass in anderen Servern bis zu 25 % der Leistung für den Lüfterantrieb aufgewendet werden, während es bei ihnen etwa 1 % seien.
https://www.youtube.com/shorts/hTJYY_Y1H9Q
https://www.youtube.com/watch?v=4vVXClXVuzE
Abgesehen von den 40-mm-Lüftern in den fast verschwundenen Flex-ATX-Netzteilen; selbst 80 mm sind heute ziemlich selten. Meist sieht man 120 mm oder 140 mm.
Das hochfrequente Geräusch typischer kleiner DC-Hochdrehzahl-Lüfter hasse ich wirklich.
Ich hoffe, sie nutzen auch irgendeine „smarte“ Methode zur Steuerung der Lüfterdrehzahl ;-)
Die Idee, mehr Luft mit geringerer Drehzahl zu bewegen, überzeugt mich vollständig.
Dass das in 1U- oder 2U-Gehäusen schwierig ist, verstehe ich.
Trotzdem gut. Schon allein die Reduktion des Lüfterlärms ist erstaunlich, und man fragt sich, warum bei etwas, das so einfach wirkt, vorher niemand darauf gekommen ist.
Ich habe schon den genau gegenteiligen Rat gehört: Laufwerke sollten durchgehend laufen, um Verschleiß durch Power-Cycles zu reduzieren.
Ich weiß nicht, was man glauben soll, aber mir gefällt, dass man ein ZFS-NAS eingeschaltet lassen kann, um regelmäßig Scrubs laufen zu lassen und die Daten zu prüfen.
Zur Einordnung: Ich habe ein System mit vier Laufwerken zehn Jahre lang betrieben und in dieser Zeit zwei Laufwerksausfälle gehabt, allerdings waren es keine Enterprise-Laufwerke, sondern WD Green.
Ein Laufwerk ein- oder zweimal am Tag ein- und auszuschalten ist etwas anderes, als es alle 15 Minuten oder noch häufiger herunterzuspinnen.
WD-Green-Laufwerke werden für NAS nicht empfohlen. Früher parkten sie die Lese-/Schreibköpfe alle paar Sekunden; bei seltenem Datenzugriff ist das in Ordnung, in einem Server kann es aber zu dauerhaftem Verschleiß und damit zu frühem Ausfall führen.
Die Lese-/Schreibköpfe verschleißen kaum, solange sie über den Plattern schweben. Wenn man den Strom abschaltet, setzen die Köpfe physisch auf einer Rampe oder in der Landing Zone der Platter auf, und Landung und Abheben verursachen den größten Verschleiß an den Köpfen.
Im schlimmsten Fall kann wegen Haftreibung beim Abheben der Kopf abgerissen werden.
Auch die Lager halten länger; wenn sie zu lange stillstehen, können sie festgehen. Dasselbe gilt für den Laufwerksmotor.
Der Einschaltstrom beim Hochfahren ist, so klein er auch sein mag, ebenfalls elektrischer Stress.
Gründe, eine Festplatte auszuschalten, sind nur Stromsparen, weniger Lärm und Transport.
Dadurch kann es an einem Tag mehrfach zu Spin-up und Spin-down kommen, weshalb mich dieses Argument überhaupt nicht überzeugt.
Belege dafür habe ich allerdings nicht.
In diesem Fall kann es der Lebensdauer helfen, die Platten durchgehend drehen zu lassen, damit sie nicht alle paar Minuten ein- und ausgeschaltet werden.
In einem Homelab gibt man aber wahrscheinlich deutlich mehr für Strom aus, als man bei den laufenden Kosten der Laufwerke spart.
Ich habe einige große Laufwerke für Familienmedien und würde sie gern mit mehr Gewissheit schützen als nur „das Laufwerk ist nicht ausgefallen“.
Diskussionen über Dateisysteme mit Checksummen drehen sich meist um ZFS und BTRFS, aber ich frage mich, ob hier jemand bcachefs ausprobiert hat.
Es wurde in den Linux-Kernel upstream aufgenommen und unterstützt meines Wissens vollständige Checksummen. Der Autor scheint die Verantwortung eines Dateisystems ebenfalls sehr ernst zu nehmen.
Nutzt es hier jemand?
https://bcachefs.org/
Es dauerte ungefähr eine Woche, bis das gesamte RAID wegen eines Journal-Problems nicht mehr gemountet werden konnte. Die Konfiguration bestand aus 8 HDDs, 2 SSDs als Schreib-Cache und 2 NVMe-Laufwerken als Lese-Cache.
Der Autor antwortete auf Reddit innerhalb eines Tages, und ich habe seinen Fix ausprobiert. Ich musste dafür den Linux-Kernel kompilieren und davon booten, aber das Problem wurde dadurch nicht gelöst.
Danach kam leider keine Antwort mehr, also wartete ich ein paar Tage, wischte alles und ging zu einem gewöhnlichen mdadm-RAID zurück.
Die wichtigen Daten waren natürlich vollständig gesichert, aber ein Teil der unwichtigen Daten ging verloren, und es erinnerte mich wieder daran, dass Cutting Edge instabil ist.
Allerdings waren der Einrichtungsprozess und die Funktionen hervorragend. Allein die Möglichkeit, Laufwerke hinzuzufügen und als Lese-/Schreib-Cache zu markieren, war großartig.
Nach ein paar weiteren Jahren Reife werde ich es sicher wieder versuchen.
[1] https://linuxiac.com/torvalds-expresses-regret-over-merging-...
[2] https://news.ycombinator.com/item?id=41407768
Bei Produktionsdaten würde ich das Risiko nicht eingehen wollen, aber für ein Homelab kann es in Ordnung sein.
Man sollte sich allerdings fragen, wie viel Zeit man investieren möchte, wenn etwas schiefgeht.
Ich nutze ZFS seit über 15 Jahren und habe wegen schlechter Hardware schon allerlei erlebt, aber auf guter Enterprise-Hardware lief es makellos.
Ich teste gerade eine Kombination, bei der eine SSD mit etwa 2 TiB vor großen Festplatten mit etwa 8 TiB als SSD-Cache verwendet wird.
Unter Ubuntu hatte ich mit der inzwischen als Legacy geltenden Kombination aus zsys + Root-ZFS kleinere Probleme, aber das ist ein verbreitetes Setup, seit Jahren breit im Einsatz und Support ist leicht zu finden.
bcachefs werde ich vermutlich erst nutzen, wenn es ein ähnliches Maß an Verbreitung und Community-Support erreicht hat.
Ich denke, die Umgebung, in der die Laufwerke laufen, macht einen enormen Unterschied für die Lebensdauer.
Wohnumgebungen sind viel variabler als Rechenzentren oder Büros. Temperatur- und Feuchtigkeitsschwankungen sind ebenfalls große Herausforderungen, aber überraschend war für mich, dass selbst kleine Mengen Staub einen ziemlich deutlichen Einfluss haben.
Vor langer Zeit betrieb ich im Keller auf einem alten Dell-Server ein 8x500G-Array. Die Laufwerke waren alle neue Seagates mit 7200 RPM, vielleicht sogar „Enterprise“-Versionen.
Über 5 Jahre hinweg fiel im Schnitt alle 6 Monate ein Laufwerk aus. Ich hatte 2 Paritätslaufwerke, hielt Ersatzlaufwerke vor und schickte bei jedem Ausfall ein RMA ein.
Nach einem Umzug bekam ich einen eigenen Raum fürs Labor, und mit derselben Konfiguration gab es in den folgenden 5 Jahren keinen einzigen Ausfall. Ich hatte erwartet, dass die neue Umgebung besser sein würde, aber es war überraschend, wie viel besser eine sauberere und stabilere Umgebung sein kann.
Ich habe NAS-/Dateiserver dauerhaft in staubigen Wohnumgebungen betrieben, und selbst jetzt sieht man noch das flauschig graue Synology-Logo, aber so etwas habe ich nie erlebt.
Ich glaube, diese Generation hatte ein Firmware-Problem.
Die jährliche Ausfallrate sieht man hier: https://www.backblaze.com/blog/best-hard-drive-q4-2014/
Bei heutigen versiegelten, heliumgefüllten Laufwerken dürfte das kein großes Problem mehr sein, selbst wenn es früher eines war.
Im Zusammenhang mit der Aussage, man nehme „das Risiko in Kauf, das System durch Stromprobleme zu verlieren“, gibt es einen weiteren sehr seltenen Ausfall, vor dem eine UPS schützt: elektrische Ungleichgewichte
Wenn bei Bauarbeiten in der Nähe etwas mit der Stromversorgung schiefgeht oder ein Blitz in einen Strommast in der Nähe des Hauses einschlägt, können Spikes nach oben oder unten entstehen, und beides kann zerstörerisch sein
In meinem ersten Job sind vor etwa zehn Jahren mehrere Server auf diese Weise gestorben. Allerdings war das auch das einzige Mal, dass ich von so einem Problem gehört habe
Soweit ich es verstehe, fängt eine UPS auch solche Spikes ab, und die UPS würde zuerst sterben, bevor der Server beschädigt wird
Der Blitz schlug direkt in die TV-Antenne im Haus meiner Eltern ein, und diese war über Koaxkabel mit dem Verstärker/Verteiler im Kommunikationskasten verbunden
Danach ist es irgendwie auf ein nahegelegenes Netzwerk-Patchpanel übergesprungen und hat alle kabelgebundenen Ethernet-Controller im Netzwerk durchgebrannt. Einschließlich der in Switch-Ports und APs eingebauten
Im Netzwerkswitch wurde sogar das Netzteil zerstört, vermutlich weil der Strom zur Erde wollte
Wie es vom Koax auf Cat5 übergesprungen ist, ist mir bis heute ein kleines Rätsel. Vielleicht hatte der Elektriker irgendwo einen Abschnitt nahe parallel verlegt
Das gesamte Netzwerk musste neu aufgebaut werden, aber zum Glück gab es vor Ort keine kabelgebundenen Computer. Speichergeräte hätten das wohl auch kaum überstanden
Ein 99-Dollar-850VA-APC von Office Depot macht das nicht. Er schaltet lediglich sehr schnell von Netzstrom auf Batterie um, führt aber keine echte Stromaufbereitung durch
Wenn man sich ein gutes Gerät leisten kann, erhöht es langfristig wirklich die Zuverlässigkeit der Hardware. Sauberer Strom ist gut
An der Verteilung der ausgefallenen, beschädigten und scheinbar unversehrten Geräte sieht man, dass die Kupferleitung mit VDSL ein sehr direkter Pfad war. Das Modem war per Ethernet mit allen anderen Geräten verbunden
Die saubere Lösung wäre vermutlich, auf Glasfaser zu wandeln, ein kleines Stück Glasfaser dazwischenzuschalten und dann wieder zurückzuwandeln. Strom nimmt mit hoher Wahrscheinlichkeit einen anderen Weg als durch Glas
Die Produktauswahl war aber deutlich nerviger als erwartet, und da ich kein Netzwerkmensch bin, habe ich nach etwa einer Stunde aufgegeben, die Produkte auseinanderzuhalten
Also habe ich zwischen VDSL-Modem und die restliche Ausrüstung eine Wi-Fi-Bridge gesetzt. Ich hoffe, dass dieser Fehlermodus beim nächsten Gewitter isoliert bleibt
Am selben Modem hing ein ZFS-Array, das zwar überlebt hat, aber ich glaube, da hatte ich Glück
Damals hatte ich keinen Server, aber LED-Lampen gingen alle paar Wochen kaputt, was nervig war. Das Gebäude war aus den 60ern, und auch die Elektrik in meiner Wohnung hatte fragwürdige provisorische Reparaturen
Das „Geheimnis“ ist nicht, den Strom abzuschalten, sondern einfach Glück
Ich betreibe seit über zehn Jahren 4-TB-HGST-Laufwerke rund um die Uhr. Es sind zwar nicht genau 24, sondern 8, aber es gab 0 Ausfälle
Ich habe einfach Glück, und ich kenne Leute, die dieselben Laufwerke mehrfach per RMA eingeschickt haben
Am meisten interessiert mich, welche Daten 71 TB brauchen, obwohl man sie die meiste Zeit ausgeschaltet lassen kann. Ist das ein Backup-Speicherserver?
Zum Beispiel können Lager festgehen, wenn sie kalt sind
Jemand, der Statistik richtig beherrscht, könnte wohl ausgehend von einer jährlichen Ausfallrate von etwa 1 % die Wahrscheinlichkeit berechnen, dass alle 24 überleben
Außerdem hatten auch die 20 Laufwerke des vorherigen NAS keine Ausfälle. Dann ist N=44; wie viel Glück braucht man dafür?
Es wird privat genutzt, und wenn Daten benötigt werden, werden sie normalerweise per 10 Gbit auf ein deutlich stromsparenderes System kopiert, danach wird dieses NAS wieder ausgeschaltet
Es gab Laufwerke, bei denen Power-Cycling riskant war
Daher stimme ich dem Modell zu, aber man sollte nicht annehmen, dass es immer für alle eine gute Methode ist. Manche SSDs müssen regelmäßig mit Strom versorgt werden
Beim Nutzungszyklus eines NAS wird diese Anforderung vermutlich erfüllt
Wahrscheinlich ist es in Ordnung, und die Stromrechnung ist definitiv niedriger. Laufwerke mit zusätzlichem Fett an der Achse waren eine Besonderheit einer bestimmten Zeit
Ich frage mich, ob Backblaze ein statistisches Modell zu Ein-/Ausschalten von Laufwerken und Lebensdauer hat. Vermutlich bewegen sie sich eher im Problemraum von immer eingeschalteten Laufwerken
In meinem Fall power-cycle ich diese Laufwerke aber nicht häufig. Höchstens ein paar Mal im Monat
Ich kann nicht sagen oder beweisen, dass es kein großes Risiko ist, aber ich glaube das und akzeptiere dieses Risiko seit über 15 Jahren
Man sollte auch bedenken, dass Festplatten die Option haben, im Leerlauf herunterzuspinnen. Das heißt, Festplatten können viele Spin-ups pro Tag verkraften
Zum Sichern einiger Synology-Geräte wurden interne 3,5-Zoll-Festplatten und ein USB-Dock verwendet, und wenn man ein Laufwerk für eine Dateiwiederherstellung oder ein zusätzliches Backup wieder in das Dock steckte, fühlte es sich an, als würde es in etwa 1 von 10 Fällen nicht wieder anlaufen
Ich nutze seit Jahren in der Produktion mehrere TB große PostgreSQL-Datenbanken auf ZFS und hatte bisher keinerlei Probleme, auch keine Bit-Flips
Für Interessierte habe ich meine Erfahrungen hier dokumentiert:
https://lackofimagination.org/2022/04/our-experience-with-po...
Zu den sporadischen Stromausfällen während des Bootens sollte man beachten, dass die Laufwerke beim Start Strom aus der 5V-Schiene ziehen
Ähnliche Laufwerke verbrauchen normalerweise bis zu 1,2 A. Zusammen mit der maximalen Last von 25 A auf der 5V-Schiene (Seasonic Platinum 860W) ist es sehr wahrscheinlich, dass es beim Booten zu Stromausfällen kommt, wenn kein staggered spinup verwendet wird