[FAQ] RAID ersetzt kein Backup! und Warum eigentlich ECC RAM?

[Janero]

Im Aufbau.

Was sind denn die Probleme um die man sich kümmern muss?
Worum geht es bei dem Thema im Kern?
Warum eigentlich ECC RAM?
Wann brauche ich ein Backup trotz Raid?
Worauf muss ich bei ECC Speicher achten?
Gibt es unterschiedliche Arten von ECC?
Kann mir nicht jemand das lesen abnehmen?

Warum eigentlich ECC RAM?n4
Zitat von Holt
"Desktopplatten in ein NAS zu bauen würde ich niemandem empfehlen, schon gar nicht bei einem 4 Bay NAS. Hinterher taugen natürlich dann die Platten nichts, wenn die das nicht lange mitmachen
Aufwand bei Einrichtung und Wartung hast Du bei einem Fertig-NAS auch, der ist bei einem System wie OMV, welches eine fertige Distribution von einem Debian Linux für NAS Anwendung ist, nicht wirklich höher.
Erstens hat auch das DS716+ die Prüfsummen nur zur Erkennung und nicht auch Korrektur bei Fehlern aktiviert und zweitens ist das auch gut so und verantwortungsvoll. Das DS716+ hat nämlich genauso wenig ECC RAM wie das DS415+, wobei es beim DS415+ wirklich unverständlich ist, da dessen Atom C2538 sogar ECC RAM unterstützen würde, man hat nur eben keines verbaut, weil die NAS Hersteller diese Feature nur den ganz teuren Kisten spendieren.

Filesysteme mit Fehlerkorrektur über Prüfsummen sind aber ohne ECC RAM nicht nur Schwachsinn, sondern sogar gefährlicher Blödsinn. Schwachsinn ist es, weil HDDs praktisch nie falsche Daten rückliefern, die liefern dann einen Lesefehler und keine korrupten Daten, wenn die Daten eines Sektors nicht zur ECC dahinter passen. Das dies unerkannt bleibt, also die Daten falsch sind und trotzdem zur ECC passen, ist so gut wie ausschlossen. Die Übertragung über SATA wird ebenfalls abgesichert, da gibt es eine CRC32 hinter jedem FIS, also jedem Übertragungspaket welches bis zu 8192 Bytes Nutzdaten haben kann und das reicht um nur etwas weniger als einen von 10^40 Fehler nicht zu erkennen, das mal 8k ist ein Datenvolumen größer als das Internet und da man Ultra-DMA Fehler wegen der Verzögerung bei der Übertragung und in den S.M.A.R.T. Werten sowieso erkennt, sollten die sowieso behoben werden, also praktisch dürfte wohl noch nie ein Fehler bei der SATA Übertragung unbemerkt geblieben sein.

Damit bleiben nur Fehler auf den internen Datenpfaden oder Fehler aufgrund von FW Bug der Platte oder des Host Controllers die so eine Prüfsumme erkennen kann und die man sonst nicht durch Lesefehler von der Platte erkannt hätte. Solche Lesefehler sind bei einem funktionierenden echten RAID (also kein RAID 0) dann aber auch kein Problem, da über die Paritydaten die Daten rekonstruiert und wieder auf die Platte mit dem Fehler geschrieben werden. Nur dann liest ein normaler Linux SW RAID überhaupt mal die Paritydaten aus. Ein FS mit Prüfsummen liest die immer (geht auf die Performance) und meldet jeden Fehler, nur wenn der Fehler im RAM passiert ist weil eben kein ECC RAM verwendet wird, denn gibt es mindestens mal einen Fehlalarm das eine Datei korrupt sein.

Wird nun aber auch die Fehlerkorrektur verwendet und die Paritydaten bzw. Prüfsumme ist gerade in dem RAM Bereich wo ein Fehler vorliegt, denn wird es schnell kritisch, diese Filesysteme trauen ihren Prüfsummen nämlich mehr als den gelesenen Daten und korrigieren den vermeidlichen Fehler und schreiben die nun kaputtkorrigierten Daten zurück. Bei einem hard-error der RAMs, also einem wiederholt an bestimmten RAM Adressen bei stimmten Bitmustern auftretenden Fehler, frisst sich der Fehler dann wie ein Krebs durch die Daten und wenn die Metadaten betroffen sind, ist der Pool kaputt und mit Pech hat man die korrupten Daten schon auf dem Backup. Berichte von Leute denen sowas mit ihren ZFS Pools auf Consumer-HW ohne ECC passiert ist, finden sich zu genüge im Netz.

Dagegen ist das was bei einem Linux md SW-RAID bei RAM Fehlern passiert geradezu harmlos, denn die RAID sind ja nicht auf zugleich Filesysteme, wie eben ZFS und BTRFS, die beides sind, RAID und Filesystem. Auf einem md-RAID kann man jedes Filesystem verwenden, die Daten des Filesystems werden vom darunter liegen Layer des RAIDs daher auch nie geändert, außer eben bei der oben beschrieben Rekonstruktion, aber die ändert ja auch keine Daten. Gibt es hier einen RAM Fehler, werden die Daten oder die Parity falsch geschrieben, sind die Daten betroffen war es das, aber bei ZFS oder BTRFS ist das nicht anders, wenn die Daten von der Netzwerkkarte kommen und in einem RAM Bereich mit einem Fehler landen, werden die vom Filesystem auch schon verändert gelesen, die Prüfsumme wird über die korrumpierten Daten gebildet und der Fehler ist permanent, man fühlt sich nur in der falschen Sicherheit sie wären korrekt.

Wird beim md SW-RAID die Parity falsch geschrieben, werden die Daten nur in dem Fall korrupt, wenn dann auch in dem betroffenen Bereich ein Lesefehler passiert und Daten rekonstruiert werden müssen, was ja nun auch nicht so oft auftritt. Die RAM Fehler haben da also weniger gravierende Auswirkungen, auch wenn sie ebenfalls das Filesystem korrumpieren können, wenn Metadaten betroffen sind und in jedem Fall können die Nutzerdaten unbemerkt korrupt sein, wenn diese Veränderung eben vor dem Schreiben im RAM passiert ist, nur wiegt man sich eben nicht in einer falschen Sicherheit.

Man sollte es mit Matt Ahren halten, einem der Mitentwickler von ZFS und der rat dazu zu aller erst einmal ECC RAM und natürlich ein passendes System welches dieses auch unterstützt zu verwenden, wenn man seine Daten liebt:

Besonders gerne missverstanden wird übrigens dieser erste Teil seines Posts aus dem das Zitat stammt: Die eigentliche Aussage des Satzes habe ich mal hervorgehoben, aber weil eben Filesysteme wie NTFS oder ext gerne auf Desktops ohne ECC genutzt werden, versuchen viele darauf abzuleiten man könnte dies auch genauso gut mit ZFS machen, weil ja nichts bei ZFS speziell nach ECC RAM verlangt was es bei anderen Filesystemen nicht auch tun würde. Richtig ist aber und das wird ja auch im Satz "if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data" klar, dass kein System ohne ECC RAM sicher für die Daten ist und man beim ECC RAM eben anfängt, dann erst lohnt es überhaupt erst sich um Prüfsummen Gedanken zu machen aber eben nicht umgekehrt. Ohne ECC RAM ist es dann auch egal ob man ein Filesystem mit Prüfsummen hat oder nicht.

Das der erste Teil "There's nothing special about ZFS that requires/encourages the use of ECC RAM" so nicht ganz stimmt, habe ich ja schon erklärt, aber er wird sein Baby nicht schlechtreden und der Verbreitung im Wege stehen wollen. Außerdem ist es im globalen Kontext, dass eben ohne ECC RAM die Daten sowieso immer gefährdet sind, ja auch egal ob sie nun mehr oder weniger in Gefahr geraten.

Wenn Du Dir Gedanken um BTRFS machst, denn erwartest Du also vermutlich mehr Schutz vor Silent Data Corruption als der gewöhnlich Heimanwender und Fertig-NAS Kunde, der auch mit dem von Consumer HW üblichen Sicherheitsniveau zufrieden ist. RAM passieren, aber sie kommen nicht dauernd und überall vor, sonst würde auch kein Mensch solche NAS kaufen. Consumer HW soll billig sein und meistens bei den meisten fehlerfrei laufen, solange das gegen ist, wird kein Cent für mehr Schutz vor Fehlern ausgegeben. Das tun die NAS, aber mehr Sicherheit durch BTRFS zu versprechen ohne ECC RAM einzusetzen, was gerade beim DS415+ mit seinem Atom C2538 nur einen 9. RAM Chip und ein paar Verbindungen auf dem Mainboard kosten würde, ist mit Verlaub schwerste Kundenverarschung von den NAS Herstellern.

Wenn Du wirklich Sicherheit vor Silent-Data-Corruption willst, dann nimm einen echten Server mit ECC-RAM, für solche HW wurden auch die Filesysteme wie ZFS und BTRFS entwickelt, weshalb sie auch ihre Datenstrukturen im RAM nicht schützen, nur leider hat man darauf verzichtet diese wirklich als technische Voraussetzung zu erklären, wohl um die Verbreitung zu beschleunigen. Diese Filesystem sind für Pentabytestorages entwickelt, die haben auch nicht einmal ein Recoverytool, weil man bei Produktionssystemen eben kein Recovery probiert, wenn mal der schlimmste Fall eintritt. Da zählt für den Techniker nur dem Chef sagen zu können, wann das System wieder am laufen ist und bei einem Recoveryversuch könnte er das nicht, er wüsste ja nicht ob es gut ausgeht. Also werden da in jedem Fall die Backups zurückgespielt, da weiß man recht genau wie lange es dauert, der Chef schluckt dann wenn er hört wie lange es dauert, aber wenn es nach der angegebenen Zeit oder besser kurz vorher wieder läuft, ist alles gut. Klappt es nicht, ist K*cke am dampfen, also riskiert niemand Zeit mit ungewissen Dingen zu verschwenden, daher gibt es keine Recoverytools, die braucht die Zielgruppe nicht und die Heimanwender mit ihren winzigen 10 oder 20TB Storages brauchen solche Filesysteme nicht.
Vergiss nicht das Scrubbing, welche ein RAID gewöhnlich macht. OMV macht es per Default einmal im Monat, da kommen bei 4TB Platten dann schon 48TB zusammen und viele empfehlen es wöchentlich zu machen, damit sind es dann 200TB und damit mehr als der Workload selbst von Enterprise Cloud HDDs. Srubbing macht man in einem RAID um zu verhindern, dass es so viel unerkannte schwebende Sektoren und damit Lesefehler gibt, dass es doch passiert das es auf zwei Platten im gleichen Bereich einen gibt, womit das Rekonstruieren der Daten eines RAIDs dann fehlschlagen würde."


n4Computer sagt Nein

Bei Einwänden, Beiträge oder hilfreichen Links habt einfach melden/posten.

Hi,

also schon mal vielen Dank für die tatkräftige Beteiligung und hilfreichen Beiträge. Ich hoffe es ist ok wenn ich in dem einen oder anderen Post noch Sprungmarken setze um dann entsprechend darauf im ersten Post zu verlinken. Das macht es für mich leichter den Thread zu pflegen wenn ihr noch mal etwas neues habt.

Das gesamte Thema sollte sich aber auf allgemeine Fragen die immer und immer wieder aufkommen beschränken. Daher halte ich auch konkrete Hardwareempfehlungen nicht für sinnvoll weil diese:
1. meist nur eine gewisse Halbwertszeit haben und
2. meisten auch recht individuell sind.

 

[Ash-Zayr]

die kursive, recht kleine Schrift macht es für mich unlesbar....sorry...;(

 

[Janero]

neben dem Zitat sind so zwei Doppelpfeile wenn du auf diese Klicks gelangst du zum original Beitrag.

 

[pumuckel]

ECC Ram ist sicherlich nice (und ja ich nutze es) aber wenn jemand nen Low Cost Homeserver will, dann kann man das weglassen

ab einem kaufwert > 200 kann und ist ECC gut .... wer aber nur ne "billige" Nas haben mag dem reicht locker auch non ECC

ich hab mir zur regel gemacht, das jeder mit mehr als 4 HDDs ECC haben sollte es sei denn, er will < 200€ ausgeben (ohne HDDs)

btw grad in dem Bereich ist AMD mit ECC unter 200€ teils besser als Intel da die erst ab 150+ MB anfangen im aktuellen Bereich

90% wollen für 100€ einfach den ultimativen HS ... no comment und ja verbrauchen darf er nur 2-3 Watt
... und natürlich ohne jede BSD/Linux kentnisse

 

[gea]

Bei dem Thema Raid, Backup und ECC

handelt es sich letztlich um das Bestreben, die Wahrscheinlichkeit und den Umfang eines Datenverlusts möglichst klein zu halten. Während die technischen Grundlagen unstrittig sind, geht es nun darum, die Gefährdung und Relevanz der beteiligten Komponenten für einen Datenverlust abzuschätzen. Dazu gehört auch eine Wertung welches Problem wie häufig auftritt und wie man die einzelnen Gefahren klein halten kann - für sich betrachtet aber auch im Verhältnis zu den benutzten Dateisystemen


Was sind denn die Probleme um die man sich kümmern muss?

defekte Hardware
- defekte Festplatten, defekte Sektoren/ Flashzellen, defekter RAM/ Controller/Kabel/ PSU etc
Das ist mit Echtzeit-Raid, Prüfsummen und Backup beherrschbar

Statistische Probleme/ silent errors
Wenn man ein Multi-Terabyte Array mit "0" vollschreibt und anschliessen liest, so wird sich an der einen oder anderen Stelle eine "1" finden. Läßt man das ein Jahr liegen und liest nochmal, so hat sich die Anzahl der "1" erhöht - ein massives Problem bei Langzeitspeicherung. Nennt sich bitrot oder Datenrost. Gleiches gilt für den RAM. Auch da kippt mit einer statistischen Wahrscheinlichkeit z.B. eine "0" zu einer "1" was zu Abstürzen oder Datenverfälschung führt. Nicht zu vergessen dass eine schlechte Stromversorgung, ja selbst schlechte Kabel oder Steckkontakte z.B. in der Backplane zu Datenverfälschungen beim Lesen oder Schreiben führen können.

Das sind Probleme, die mit Echtzeit-Raid, Prüfsummen, Datascrubbing und ECC RAM beherrschbar sind. Bei Backup-Einzelplatten und ZFS kann man Copies=2 setzen. Dann wird jeder Datenblock ein zweitesmal an anderer Stelle auf der Platte gesichert.

Transaktionsprobleme
Wenn dem OS "a" als geschrieben gemeldet wird, muss es auch auf stabilem Storage sein
Wenn "a" und "b" geschrieben werden soll, dann nur gemeinsam oder gar nicht.

Lösungen dafür sind Batteriepufferung im Raidcontroller bei älteren Dateisystemen oder CopyOnWrite und sicheres Sync Write Schreiben mit einem ZIL Device bei Dateisystemen wie ZFS.

Zeitprobleme
Unbeabsichtigtes Löschen, Wunsch ältere Versionen eines Dokuments zu lesen, Sabotage, Trojaner die unerkannt im Hintergrund anfangen Daten zu verschlüsseln. Merkt man oft erst wenn bereits auch das Backup betroffen ist. Das Backupsystem sollte zudem so aktuell wie möglich sein.

Das sind Probleme, die man deshalb nur ansatzweise mit einfachen Backups lösen kann. Am besten ist eine read only Versionierung mit vielen, auch älteren Snapshots auf dem Dateisystem im Hauptstorage aber auch auf dem externen Backupsystem. Eine Aktualisierung des Backupsystems das auch offene Dateien mit ihrem aktuelles Stand sichert ist ZFS Replikation. Das kann nahezu in Echtzeit Daten im Backupsystem aktuell halten - bis herunter in den Minutenbereich.

Disaster
wie Feuer, Überspannung, Diebstahl oder ein defektes Array wenn z.B. mehr Platten ausfallen als es der Raidlevel erkaubt. Da hilft nur externes Backup, wenigstens in einem anderen Brandabschnitt. Bei sehr wichtigen Daten zwei Backupsysteme nehmen damit bei Ausfall eines Systems das Backup weiterläuft.



Die beteiligten Systemkomponenten

Raid

-Raid ist primär dazu da, den Ausfall einer oder mehrerer Festplatten ohne Datenverlust zu erlauben oder bei Dateisystemen mit Prüfsummen die Reparatur defekter/veränderter Daten (Datenrost) beim Zugriff zu ermöglichen (nennt sich Self-Healing Feature). Raid schützt dabei in Echtzeit im Gegensatz zu Backupverfahren die zwar auf Raidverfahren aufbauen aber nur auf Anforderungen arbeiten wie Snapraid/ Unraid etc, ansonsten aber die Daten komplett auf den Einzelplatten belassen also ohne die Datenblöcke zu verteilen/stripen/spiegeln.

Dazu skaliert bei einen Echtzeit-Raid die sequentielle Performance mit der Anzahl der Datenplatten bzw. die iops mit der Anzahl der Raid-Subsysteme (z.B. Verdoppelung bei Raid 50/60 oder bei ZFS mit der Anzahl der vdevs). Raid bringt damit neben Verfügbarkeit auch Performance.

Das Hauptproblem bei Raid:
-Beim Ausfall von mehr Platten als es der gewählte Raidlevel zulässt, ist das ganze Array verloren.
Bei ZFS Raid-Z3 sind z.B. bis zu drei Plattenausfälle je vdev erlaubt ohne daß Daten verloren gehen.

- bei einem normalen Raid-1 oder Raid 5/6 besteht bei einem Stromausfall beim Schreiben die Gefahr, dass das Dateisystem oder das Raid anschließend korrupt sind da die Daten nacheinander auf die Platten des Raid geschrieben werden. Folge sind unterschiedliche Daten auf den beiden Platten eines Raid-1 Mirrors oder teilweise geschriebene Raid 5/6 Stripes, siehe Write Hole Problem: "Write hole" phenomenon in RAID5, RAID6, RAID1, and other arrays.. Ein neueres CopyOnWrite Dateisystem mit Software Raid kennt dieses Problem nicht.


Raid schützt aber nicht in jedem Fall vor korrupten Daten z.B.

- Wenn man ein Raid-1 nutzt, führen Silent Errors/ Datenrost dazu, dass beide Teile des Mirrors nicht mehr identisch sind. Beim Lesen kann es dann passieren dass gute oder falsche Daten gelesen werden. Das OS kann nur bei einem Dateisystem mit Prüfsummen erkennen, ob Daten gerade gut oder schlecht sind und dann den anderen Mirror lesen und den fehlerhaften Mirrorteil reparieren.

- Wenn man SSD benutzt kommt dazu die Gefahr, dass Hintergrund Datenumorganisationen (Garbage Collection) die die Firmware dauernd vornimmt bei Stromausfall zu einem Datenverlust/Veränderungauf der SSD führen kann.

Wenn man Platten, Controller oder Dateisysteme/Betriebssysteme mit einem Schreibcache nutzt ergeben sich zusätzliche Probleme. Stürzt das System beim Schreiben ab, so sind ohne weitere Massnahmen die Daten im Cache verloren. Man muss dann folgendes unterscheiden.

- jeder Schreibcache deaktiviert: viel zu langsam - will man nicht
Sicheres syncrones Schreiben wird bis zu 10x langsamer als bei Nutzung eines Caches.

- Schreibcache aktiviert
Bei Dateisystemen wie ext oder ntfs bleibt ohnehin das Problem dass es passieren kann, dass Daten bereits geschrieben wurden, die Metadaten aber noch nicht aktualisiert sind. Das Ergebnis kann ein korruptes Dateisystem sein. Ein offline Checkdisk/ Filecheck kann das beheben. Dieses Problem besteht unabhängig davon ob man einen Schreibcache nutzt oder nicht. Der Cache verstärkt aber das Problem. Zudem können je nach Cachegröße mehrere Sekunden Daten verloren gehen, die dem Betriebssystem bereits als "ist auf stabilem Storage" gemeldet wurden. Insbesondere bei Transaktionen z.B. Datenbanken kann das kritisch werden. Eine Buchhaltung wird es nicht mögen, dass es die Abbuchung eines Betrags noch auf Platte geschafft hat, nicht aber die Aufbuchung auf das Zielkonto, die ging im Cache verloren.

Neuere CopyOnWrite Dateisysteme kennen ersteres Problem nicht. Atomare Schreibaktionen z.B. Datenblock schreiben + Metadaten aktualisieren werden immer gemeinsam oder gar nicht durchgeführt unabhängig vom Schreibcache. Das Dateisystem ist also niemals korrupt nach einem Abstürz.

Bleibt das Transaltionsproblem für abhängige Aktionen. Dies ist auch fürCopyOnWrite Systeme ein Problem, ganz besonders wenn man z.B. bei Storage für VMs ältere Dateisysteme auf ZFS lagert. Die haben ja dann gar keine Kontrolle mehr darüber was im Cache verlorengeht oder auf Platte landet.

Lösung
Für Hardwareraid und ältere Dateisysteme: Einen Controller mit Cache + BBU nutzen.
Wird dem OS ein Schreibvorgang bestätigt, so landet der tatsächlich auf der Platte. Bei einem Absturz dann beim nächsten Booten. Ein Raid-Contollercache ist aber meist relativ langsam und es bleibt das Write Hole Problem

Für ZFS wurde das Problem über eine Protokollfunktion der Daten im Cache gelöst die dem OS als "sind auf Platte" gemeldet sind. Da ZFS grundsätzlich einen sehr großen Rambasierten Schreibcache nutzt, der mehrere Sekunden Schreiben aufnimmt um damit aus vielen kleinen langsamen Schreibaktionen einen einzigen großen und schnellen sequentiellen Schreibvorgang zu machen, wird dieses Logging auf ein ZIL genanntes Device gemacht. Dieses muss sicheres Schreiben garantieren. Aus Performancegründen nutzt man nicht den Pool als ZIL sondern ein Extra Logging Device das darauf optimiert ist. Das nennt sich dann Slog, z.B. eine Dram SSD mit Batteriepufferung wie ein 8GB ZeusRAM, eine NVMe wie eine Intel P-Serie (750, 3600, 3700) oder eine Intel S 3700/3710 Sata SSD mit Powerloss Protection, geringsten Latenzen und hohen konstanten Schreib-IOPS bei QD/Queudepth=1.

Eine komplette Datei z.B. ein Worddokument ist bei einem Absturz beim Schreiben natürlich immer kaputt. Dagegen kann nur das Programm z.B. Word etwas unternehmen indem es Temp-Dateien anlegt. Wenn man Versionierung/ Snaps hat bleibt zudem der Zugriff auf eine Vorversion.


ECC

ist quasi Raid im RAM. Ein Bitfehler wird erkannt und aus der Speicherredundanz repariert.
Diese Speicherfehler sind nicht in jedem Fall ein Speicherdefekt sondern ein statistisches Problem das umso häufiger auftritt je mehr RAM man hat. Speicherfehler führen zu Abstürzen oder Datenveränderungen, entweder beim Verarbeiten der Daten oder beim Lesen/Schreiben. Derartige Probleme können durch ECC RAM verhindert werden. Selbst neue Dateisysteme können nur Probleme in der Kette Platte > Kabel > Controllerhardware > Controllertreiber erkennen und reparieren.

ECC RAM sollte man daher nach Möglichkeit immer vorsehen. Teils wird die Meinung vertreten, man bräuchte das nur oder unabdingbar bei neueren Dateisystemen weil ansonsten die extreme Gefahr von Datenverlusten besteht, teils mit Hinweis darauf dass Platten immer valide Daten liefern würden und Datenveränderungen auf dem Storage damit ausschliesslich durch RAM Fehler begründet würden.

Das dem nicht so ist, zeigen die doch die relativ häufigen Prüfsummenfehler die z.B. ZFS findet und repariert ohne dass ansonsten (Smart, OS, etc) ein Problem berichtet wird, trotz ECC RAM und ohne dass ECC Fehler bemerkt werden. Das nennt sich dann schön neudeutsch "Datenrost" also Veränderungen auf dem Storage selber mit einer statistischen Häufigkeit, Je größer das Array und je länger die Lagerzeit der Daten desto mehr Probleme. Die Wahrscheinlichkeit dieser Fehler je GByte ist geringer als beim Ram ein bitflop, dafür sind mehr Bytes beteiligt - damit ist das ähnlich problematisch wie das RAM/ECC Problem.

Ich empfehle niemand auf ECC zu verzichten, ein kompletter Datenverlust z.B. bei ZFS der garantiert ausschliesslich auf RAM Probleme zurückzuführen wäre, ist mir aber nicht bekannt - und ich lese seit 7 Jahren intensiv alle ZFS Foren. Bei einem Pool/ Datenverlust kann man allenfalls spekulieren dass RAM Probleme beteiligt waren. Ich halte daher den Nutzen von ZFS ohne ECC für größer als das Risiko eines zusätzlichen Problems durch RAM. Aber wie gesagt, man sollte nicht spekulieren und auf sein persönliches Glück hoffen sondern ECC nehmen und das nicht nur auf dem Storage sondern auch auf dem Arbeitsplatz falls da kritisches verarbeitet wird - zumal da ja heutzutage auch RAM von 16GB aufwärts üblich wird.


Backup

dient dazu, bei Verlust einer Platte oder eines Arrays, einen bestimmten Datenstand wiederherzustellen. Man kann dazu rollierendes mehrstufiges Backup machen (in der Art "diese Woche", "letzte Woche" und "vorletzte Woche")

Da Backup aber praktisch nie aktuell ist und meist nur wenige Vorversionen hat, ist das eher für "Disaster Backup" geeignet, nicht als Option zur schnellen Wiederherstellung eines früheren Dateistandes. Auch besteht die Gefahr, dass sich Veränderungen oder Trojaner-Angriffe wie Datenverschlüssellungen z.B. durch Ransomware die man zu spät erkennt sich bereits auch auf dem Backup befinden.

Für den alltäglichen Betrieb ist es besser ein Dateisystem mit Versionierung zu nutzen. Bei Windows gibt es dazu Shadow Copies. Noch besser ist Versionierung auf Basis eines CopyOnWrite Dateisystems mit readonly Snapshots (btrfs, Netapp WAFL, ReFS oder ZFS) auf dem NAS zu machen da dann selbst ein Admin-User nichts mehr an den Snapshots ändern kann - im Gegensatz zu einer reinen oder gar lokalen Windowslösung die viel mehr Angriffspunkte bietet.

Damit lassen sich beliebig oft z.B. stündlich/täglich/ wöchentlich/monatlich etc Snapshots anlegen, auf die man bei ZFS über Clones (ein beschreibbares Dateisystem das man aus einem Snapshot erzeugt oder bei dem man den Inhalt eines Dateisystems mit einem Snapshot tauscht) oder bei einzelnen Dateien über Windows "vorherige Version" zugreifen kann. ZFS kennt zudem "Rollback", also das komplette Zurücksetzen des Dateisystems auf einen früheren Snapshotstand. Im Gegensatz zu einem Restore aus Backup geht das unmittelbar, also ohne einen Zeitverzug.

Angesichts neuer Bedrohungen wie Samsa ( http://www.heise.de/security/meldun...Erst-schauen-dann-verschluesseln-3153767.html ) bei der die Infrastruktur samt Storage und Backup bedroht wird, gewinnt Randomware sichere read only Versionierung mit kurzen Intervallen (stündlich/ tägliche ZFS Snaps) zunehmend an Bedeutung. Hier hilft Backup nur ansatzweise und auf keinen Fall alleine.


Mein Lösungsansatz um die Wahrscheinlichkeit eines Datenverlustes klein zu halten

sind neben guter Hardware und Backups die neueren Dateisysteme wie ZFS die ja gerade deswegen entwickelt wurden um mit den heutzutage großen Arrays (Multi-Terabyte bis Petabyte) sicher arbeiten zu können. Auch sind Multi-Terabyte Arrays mit ext4 oder ntfs im Vergleich nicht nur von der Datensicherheit problematisch. Da es sich dabei um keine CopyOnWrite Systeme handelt, besteht die Gefahr dass Dateisysteme nach einem Absturz korrupt sind. Das dann nötige Prüfen der Metadaten (Daten selbst können hier mangels Prüfsummen eh nicht repariert werden) muss offline erfolgen und kann bei sehr großen Arrays Tage dauern.

auf Ebene der Hardware
- ECC RAM, ohne sicheren Speicher geht nichts

Auf Ebene des Dateisystems
- CopyOnWrite: Bei einer Datenveränderung werden nicht wie z.B. bei ext oder ntfs Datenblöcke geändert sondern immer komplett neu geschrieben. Einen Datenblock neu schreiben + Metadaten updaten wird dann ganz oder gar nicht vorgenommen, daher hat man ein immer valides Dateisystem, kein chkdsk per Design nötig (es gibt daher bei ZFS kein chkdsk Tool) - nur online Scrubbing um Silent Errors/Datenrost Fehler anhand der Prüfsummen zu reparieren. Der alte Datenblock wird dann zum Überschreiben freigegeben - es sei denn ein Snap schützt den Datenblock vor überschreiben.

Der Ansatz ist dabei wie bei einem Atomkraftwerk. Ein GAU (größter anzunehmender Unfall der beherrschbar ist), also selbst massive Probleme sind durch ZFS ohne weitere Tools beherrschbar. Die ZFS internen Reparaturmöglichkeiten gehen weit über die Möglichkeiten von ext4 oder ntfs hinaus und decken die üblichen Probleme wie Stromausfall beim Schreiben, defekte Platten oder Sektoren, Datenrost etc ab. Lediglich ein SuperGau bei dem selbst ZFS nichts mehr retten kann, erfordert dann ein Backup. Der häufig genannte Mangel bei ZFS & Co gäbe es kein Prüftool/Reparaturtool wie bei ntfs/ext ist eher so zu sehen dass ZFS alles eingebaut hat und das nicht braucht um Probleme im Griff zu haben. Da dadurch SuperGau Probleme (nicht mehr beherrschbare Fehler) extrem selten sind aber Rettungstools, die auch Daten-Bruchstücke auf einem defekten Array retten können nicht vorhanden - ausser bei professionellen Datenrettern. Ob man damit aber bei Problemen wirklich etwas gewonnen hat ist zweifelhaft. Ich hatte mal einen derartigen Datensalat aus kleineren oder größeren Dateifragmenten nach der "Datenrettung" bei einem ntfs Dateisystem - unbrauchbar. Disaster Backup heißt dann die Lösung.

- Prüfsummen
Nur damit können Fehler sicher erkannt werden. Bei vorhandener Redundanz/Raid oder Copies=2 werden die beim Zugriff oder bei einem Scrubbing über alle Daten repariert.


Auf Ebene des Raid
- ZFS Software Raid. ZFS beispielsweise ist nicht nur ein Dateisystem sondern bietet zusätzlich Software-Raid, Raid-, Volume- und Sharemanagement. Insbesondere in Kombination mit CopyOnWrite bietet es erheblich zuverlässigeres Raid als z.B. ein Hardware RaidController mit BBU

Bei SSDs auf Powerloss Protection achten.

Auf User-Ebene
- Versionierung/ Snapshots nutzen. Die werden ohne Zeitverzug in beliebiger Anzahl angelegt und schützen aktuelle Daten auch vor Verschlüssellungs Trojanern. Der Platzverbrauch entspricht unabhängig von der Anzshl der Snaps den geänderten Datenblöcken zur Vorversion da diese vor Überschreiben gesperrt werden (ZFS Snaps mit CopyOnWrite bedeutet Einfrieren des alten Dateisystandes, kein Kopieren). Selbst stündliche erstellte readonly Snapshots die man monatelang behält sind damit problemlos möglich.

- Backup durch Replikation auf Snapshotbasis
Das arbeitet ultraschnell da es nach dem ersten Aufruf nur geänderte Datenblöcke überträgt. Offene Dateien werden mit dem auf Platte gesicherten Stand mitübertragen.


Letztlich sehe ich das Thema ECC, Backup, CopyOnWrite Dateisysteme und Raid wie eine mittelalterliche Burg, bei der es darum geht, das Leben des Fürsten, seines Hofstaats und seinen Wohlstand (Daten) zu sichern. Es gibt mehrere Verteidigungslinien, Gräben und Wehranlagen. Normale Angriffe sollen die soweit wie möglich abwehren, mal mehr mal weniger je nach Qualität der Konstruktion. Wenn aber alle überrannt werden oder nicht mehr schützen, ist ein Fluchttunnel (Backup) die letzte Rettung um wenigstens das nackte Leben zu retten.

 

[besterino]

Ich würde noch einen Schritt früher bei der "Einführung in die Problemstellung" ansetzen:

Worum geht es bei dem Thema im Kern? Mal ganz allgemein um den Schutz vor Datenverlust bzw. - aus der anderen Richtung betrachtet - um die Erhaltung bzw. Verfügbarkeit von Informationen und zwar "ganz konkreten" Informationen.

Beispiel 1: Wenn ich heute eine "1" abspeichere, soll auch morgen noch eine "1" dort gelesen werden.

Beispiel 2: Wenn ich heute eine "1" lese, diese nach vorgegebenen Rechenschritten bearbeite, z.B. "nimm die 1 und subtrahiere 1", soll genau das Ergebnis des Rechenvorgangs geschrieben werden, hier also "0". Und diese "0" soll dann gemäß Beispiel 1 auch morgen dort wieder gelesen werden können.

Nun kann es aber "morgen" zu verschiedenen Problemen (="Datenverlust") kommen, nämlich (natürlich nicht abschließend) z.B.:

Problem 1: Dort, wo gestern z.B. die "1" geschrieben wurde, steht heute dummerweise "gar nichts", da der "Platz" nicht mehr gelesen werden kann. Es wird also nicht etwas "Falsches" gelesen, sondern es ist schlicht "gar nichts da zum Lesen". Beispiele: Sektor auf der Platte kaputt, Platte kaputt, Controller kaputt, Rechner kaputt...

Problem 2: Dort, wo gestern z.B. die "1" geschrieben wurde, steht heute dummerweise eine "0". Das ist z.B. der klassische Fall von "Bitrot": zunächst wurde zwar eine "1" geschrieben, diese hat sich aber "über Nacht" in eine "0" verwandelt, ohne das jemand sagen kann warum. Doof, aber passiert.

Problem 3: Dort, wo gestern z.B. die "1" hätte geschrieben werden sollen, wurde dummerweise eine "0" geschrieben. Beispiele: RAM-Defekt, CPU-Rechenfehler, RAM-Bitflip, Firmware-Bug in HDD/SSD uvm.

Problem 4: Dort wo gestern morgens z.B. die "1" geschrieben wurde, hat gestern Abend dummerweise ein Vollidiot/Virus/Unberechtigter/Fehlkonfiguration... eine "0" geschrieben und heute hätte ich gerne wieder das was gestern morgens geschrieben wurde, also die "1" .

(Der ein oder andere Schlaumeier hat natürlich erkannt, dass manches in Wahrheit nicht ein Problem von "morgen" sondern von "heute" ist bzw. "gestern" war, sich aber ggf. erst "morgen" zeigt...wer folgt mir noch?)


So unterschiedlich wie die Probleme, so unterschiedlich sind die Schutzmechanismen und Gegenmaßnahmen, die sich schlaue Leute als Lösung ausgedacht haben. Dummerweise hilft aber eben nicht Lösung A bei allen Problemkonstellationen, sondern wenn ich wirklich sicher sein will, dass das was ich "heute" brauche, auch wirklich zuverlässig genau so auch heute "da" ist, muss ich einen bunten Blumenstrauß an Maßnahmen ergreifen, der je nach Kosten-Nutzen-Abwägung weit über das hier Dargestellte hinausgeht bzw. hinausgehen kann.

BEISPIELE zur Verdeutlichung einiger verschiedener Konzepte:

Gegen Problem 1 hilft u.a. Raid und Backup.
Gegen Problem 2 hilft u.a. ein Dateisystem mit Parität/Prüfsummen wie z.B. ZFS/BTFRS.
Gegen Problem 3 hilft u.a. ECC RAM.
Gegen Problem 4 hilft u.a. Backup und Snapshots.

Manche Lösungen helfen dann auch (teilweise) bei mehreren Problemen, aber die Aufstellung der Probleme oben ist natürlich nur ein extrem verkürzter Ausschnitt. Umgekehrt hilft nicht jede Lösung vollständig gegen das Problem im Ganzen: Bin ich in Problem 1 weil der Controller kaputt gegangen ist, hilft mir ein Raid "nur" aus mehreren Platten gar nüschts. Oder hat bei Problem 3 die CPU einen weg, hilft ECC ggf. leider nicht (und je nachdem wann ich das erst merke und auch mein ältestes Backup noch zu jung ist: eventuell einfach GAR NICHTS).

Aber es wird vielleicht klar, woher der Spruch "RAID" ersetzt kein Backup herrührt: Bei Problem 1 wegen Plattendefekts hilft (auch) ein Raid (außer Raid0 - haha), bei Problem 2 und 3 vielleicht, und bei Problem 4 eben gar nicht. Umgekehrt hilft zwar ein Backup auch bei Problem 1 - aber zieht man den Zeitfaktor hinzu (für die Wieder-Erreichung der Arbeitsfähigkeit und/oder das Alter des Backups), kann ein Backup allein eben unbefriedigend sein.

Und dann kommt am Ende ein Maßnahmen-Katalog heraus, der im Idealfall auf einer ganz konkreten und individuellen Abwägung aus z.B. "was brauch ich", "was hätt' ich gern", "was kann/weiß ich" und "was bezahl ich" hervorgeht. Und da das eine ganz subjektive Gemengelage ist, lässt sich darüber m.E. ganz hervorragend streiten, was denn nun eigentlich "richtig" oder auch nur "wirklich wichtig" ist...

Die denkbaren "Probleme" lassen sich fast beliebig/unendlich erweitern und/oder verkomplizieren. Ich habe mich bei den Problemen 1-4 mal beispielhaft nur auf einige gängige Erwägungen im "Homebereich" beschränkt. Zieht man aber z.B. den Hausbrand mit in die Betrachtung ein oder bedenkt, dass die Daten nicht nur in einem System gelesen, bearbeitet und wieder geschrieben werden, dass es Kriege geben kann und und und, und überlegt dann, was man als Schutzmaßnahme ergreifen müsste, bekommt man vielleicht ein Gefühl dafür, warum Unternehmen für ihre WIRKLICH WICHTIGEN DATEN einen Monsteraufwand fahren und ein Heidengeld ausgeben.

Für mich in meinem bescheidenen Heim fällt halt dann hingegen doch aber Vieles in die Kategorie "Dann hab' ich halt am Ende einfach Pech gehabt". Sollte es zum Krieg in meinem Vorgarten kommen, mache ich mir wahrscheinlich ganz andere Gedanken als zu der Frage, ob ich - wenn alles vorüber ist - denn meine Urlaubsfotos wieder anschauen kann... (gut, etwas übertriebenes Beispiel vielleicht). Gegen alle Eventualitäten KANN ich mich nicht schützen, also passt scho' und wird schon / muss halt gutgehen!

P.S.: So viele "Anführungszeichen" habe ich wohl noch nie in einem Text verwendet...

 

[Luckysh0t]

Vlt ist es auch noch gut wenn man die unterschiedlichen Arten von ECC Speicher erklärt - gibt bestimmt nicht nur einen User der sich registered Module gekauft hat und dann gemerkt hat das sein Board nur Standard ECC RAM kann.

 

[underclocker2k4]

Es gibt keine unterschiedlichen ECC Arten.
ECC ist ECC.
Buffered Module haben mit ECC garnichts zu tun.
Buffered Module werden idR aber nur mit ECC ausgestattet, da der Anwendungsfall der Module (Server) ECC quasi zwingend fordert. Ein kausaler Zusammenhang zwischen reg und ECC besteht aber nicht.

 

[besterino]

Ist halt die Frage, wie sehr das hier ein allgemeiner Hardware-Erklärungs-Fred werden soll.

Aus meiner Sicht ist es vielleicht gerade mal machbar, unter engen Rahmenbedingungen NAS-, Storage- bzw. Fileserver-Hardware hier zu beschreiben. Jedenfalls passt das zum Titel und die da könnte man einige Grundlagen zu abhandeln.

Denkbar wäre z.B. so ein paar Builds abgestuft nach "Ausfallsicherheitsniveau" aufzuführen, wo man dann eben auch prima mal die Fertig-NASen und Build-Your-Own mit den unterschiedlichen OS bzw. Filesystemen einsortieren kann. Also so was wie eine Tabelle mit Spalten für (beispielsweise) Raidmodi, ECC, Filesystem (ggf. mit Anmerkungen für Besonderheiten wie "BTRFS, aber ohne automatische Fehlerkorrektur"), OS, Backupmöglichkeiten (rsync, Replikation, ...), Anzahl Festplatten und noch ein paar Dinge mehr. Zusätzlich könnte man da zum Beispiel (nur) die gängigsten Server aufnehmen/verlinken, zu denen es hier auch Sammler gibt - aber eben nur für den primären Einsatz als Storage (sonst würde es zu unübersichtlich).

Nur eine Idee.

 

[pumuckel]

dann kannste gleich zu sowas verlinken : https://geizhals.de/supermicro-superserver-5028a-tn4-sys-5028a-tn4-a1279218.html?hloc=at&hloc=de

bzw: https://www.ixsystems.com/freenas-mini/ (freenas whiteglove certified) .... wundert mich dass das keiner Leuten anrät die eigentlich "sicheren Storage suchen"

wobei ich lieber das https://geizhals.de/chenbro-sr30169-a885987.html?hloc=at&hloc=de mit z.B. https://geizhals.de/asus-p10s-i-90sb05e0-m0uay0-a1367146.html?hloc=at&hloc=de + wenn gewünscht dem 20€ iKVM Modul da nehmen würde
... schickeres Webinterface für klicki bunti mit ASWM Enterprise - https://www.google.de/search?q=asm+...D&biw=2304&bih=842#tbm=isch&q=aswm+enterprise


*grins* ok, aber ASRock hat (derzeit) noch das "bessere" IKVM ... Supermicro migriert aber grad zu HTML5 Consolen : https://tinkertry.com/supermicro-superserver-ikvm-moving-from-java-to-html5
... java hassen wir ja alle


aber warum denkt ihr wollen die Leute

https://geizhals.de/hp-proliant-microserver-gen8-819185-421-a1322637.html?hloc=at&hloc=de
https://geizhals.de/hp-proliant-ml10-v2-814483-421-a1321006.html?hloc=at&hloc=de

weils billig ist ---- leider kommen dann immer noch hunderte € (und Arbeitsstunden) für "unnötige" Aufrüstungen (+ Silence Mods) dazu ... am ende kann man dann gleich was passendes kaufen (wo man nicht basteln muss)

Ich bekomm z.B. immer "krause haare" wenn jemand bei esxi einen lan Controller "durchreichen" will und deshalb nen Xeon kauft (statt vSwitch zu nutzen)
oder leute die für 4 HDDs einen passthrough wollen (hint Hyper-v kostenfrei, Proxmox Pass by-id)

wäre Unraid nicht kostenpflichtig, würd ich eh alle ("will alles") da hinschicken : https://lime-technology.com/

 

[besterino]

bzw: https://www.ixsystems.com/freenas-mini/ (freenas whiteglove certified) .... wundert mich dass das keiner Leuten anrät die eigentlich "sicheren Storage suchen"

Weil wahrscheinlich keiner weiß, wie teuer das wäre (und ich zu faul bin, nach 'nem Quote zu fragen). Und zum Rest: Ok, hab mich unklar ausgedrückt. Mit build-your-own mein ich nicht Hardware-Kombos, sondern primär die OS-Seite. Alle DIY-Hardware-Ideen abzubilden, ist ja nun wirklich völlig utopisch. Daher der Ansatz mit den bezahlbaren Fertig-Servern zu denen es ja aus gutem Grund die Sammler gibt (die sind ja auch halbwegs in der Hardware-Konfiguration - jedenfalls offiziell - überschaubar und somit auch ganz gut zu den Fertig-NASen vergleichbar).

 

[pumuckel]

Weil wahrscheinlich keiner weiß, wie teuer das wäre

gibts sogar per Amazon für 999 Dollar - dicker gelber Button

 

[besterino]

Öhm Limited Warranty 1 year Hardware. Also null auf die Software oder wie?

Ist doch prima, dann poste hier mal Deine Erfahrungen und dann wäre das bestimmt auch was, was eine nähere Betrachtung wert wäre.

So und jetzt mal im Ernst: wenn du die Idee Kacke findest, sag das doch einfach. Dein gutes Recht, und wahrscheinlich hättest Du sogar inhaltlich recht (weil es z.B. außer mich niemanden interessiert).

Aber so'n Exotensystem rauszusuchen, was hier kein Mensch nutzt (zumindest hab ich noch keinen Thread dazu gesehen hier) - ich hab den Sinn davon wie auch den deiner anderen Links nicht verstanden außer als verschwurbelten Kommentar in die Richtung "ich bin dagegen" und "ich weiß was" - aber was genau du (mir) damit sagen willst, das bleibt mir leider verborgen.

 

[flxmmr]

Von denen hat man schon mal gehört, die sind nämlich vom BSD-Hoster irgendwann zum Hardwareverkäufer umgestiegen (BSD-Workstations...) und haben dann wohl entdeckt, wo man Geld machen kann – jetzt sind sie NetAPP für Arme und Leute, die den proprietären Lösungen nicht vertrauen müssen.

Da man aber offensichtlich immer noch einen Support-Vertrag zur Hardware kaufen muss, weiß ich nicht, wieweit es hier sinnvoll ist, die anzupreisen.

Unraid finde ich persönlich etwas gewöhnungsbedürftig, das hat gefühlt mit dem Grundspirit der meisten OS-Projekte sehr wenig gemeinsam und verspricht recht zweifelhafte Dinge:

Protect an array of up to 24 devices and utilize 100% of their capacity.

und am Ende steckt da vermutlich LVM drin...

Prevent simultaneous multi-device failure from causing data loss on other devices.

failsafe ist es dann auch einfach nur RAID4 mit einer Paritätsplatte: https://lime-technology.com/network-attached-storage/ (wie man aber da 100% nutzen will, weiß ich nicht ).
Wenn die wirklich irgendetwas eigenes hätten, spezifisch eigene Treiber, die ihr System irgendwie von der typischen mdadm/lvm-Flickerei abgrenzen, fände ich persönlich ja einen Vergleich mit diesen Systemen sinnvoll und man könnte den auf der Seite auch klar hervorheben. Interessanterweise findet man das nicht so einfach heraus, weshalb ich einfach glaube, dass es da nichts gibt und man somit für 60€ ein proprietäres Webinterface einkauft. Wenn mich jemand informieren will und mir die Funktion des gegen Festplattenausfall geschützten Unraid erklären will: nur zu .
EDIT: scheint ja auch ganz nette Performance-Probleme zu haben, dieses Unraid...

 

[Janero]

Hi,

also schon mal vielen Dank für die tatkräftige Beteiligung und hilfreichen Beiträge. Ich hoffe es ist ok wenn ich in dem einen oder anderen Post noch Sprungmarken setze um dann entsprechend darauf im ersten Post zu verlinken. Das macht es für mich leichter den Thread zu pflegen wenn ihr noch mal etwas neues habt.

Das gesamte Thema sollte sich aber auf allgemeine Fragen die immer und immer wieder aufkommen beschränken. Daher halte ich auch konkrete Hardwareempfehlungen nicht für sinnvoll weil diese:
1. meist nur eine gewisse Halbwertszeit haben und
2. meisten auch recht individuell sind.

 

[pumuckel]

p.s. wer mit BSD rumspielt der darf auch gern ab und an BSD Now | Jupiter Broadcasting gucken

... auch wenn es nicht so wirken mag, Allan hat BSD und ZFS im Blut - er steht hinter https://www.scaleengine.com/

@flxmmr die sind die Entwickler hinter Freenas / Truenas (kommerzielle Version von freeNas - https://www.ixsystems.com/truenas/ )

... und btw kommt bald (soon) ein 8 Bay Freenas von denen - https://www.ixsystems.com/blog/bigger-freenas-mini/

die Servervarianten kannste "as big as u wish" haben (zu den "1 Year" das ist der Usus in den USA für Endkunden )

 

[passat3233]

- bei einem normalen Raid-1 oder Raid 5/6 besteht bei einem Stromausfall beim Schreiben die Gefahr, dass das Dateisystem oder das Raid anschließend korrupt sind da die Daten nacheinander auf die Platten des Raid geschrieben werden. Folge sind unterschiedliche Daten auf den beiden Platten eines Raid-1 Mirrors oder teilweise geschriebene Raid 5/6 Stripes, siehe Write Hole Problem: "Write hole" phenomenon in RAID5, RAID6, RAID1, and other arrays.. Ein neueres CopyOnWrite Dateisystem mit Software Raid kennt dieses Problem nicht.

Genau deshalb gehört zu einem ernsthaften Raid immer auch eine USV, die bei einem Stromausfall puffert und bei zu Ende gehender Batteriekapazität dann schlußendlich den PC/Server/NAS sauber runterfährt.
Ist z.B. bei mir in der Firma so.
Alle Server und NAS hängen an USVs.
Hinzu kommt natürlich, das diese Systeme (auch die USVs) den Systemadmin regelmäßig über ihre "Gesundheit" per Mail informieren und auch, wenn es Probleme gibt (z.B. Ausfall einer Platte im Raid oder Ende der Batterielebensdauer bei einer USV).
Eine gute Idee bei einem Raid 5/6 etc ist übrigens eine HotSpare.
Fängt eine Platte im Raidverbund an, Probleme zu machen, greift sich der Controller automatisch die HotSpare, nimmt die problematische Platte offline und macht einen Rebuild. Der Admin wird über diesen Vorgang natürlich vollautomatisch per Mail informiert, so das er da entsprechend tätig werden kann.
Redundanz diverser Hardware ist auch keine schlechte Idee. Z.B. doppelte Netzteile, doppelte Plattencontroller etc. Fällt eine Komponente aus, übernimmt automatisch die andere Komponente.
So etwas wie Raid kann man bei sehr vielen Servern auch mit dem RAM veranstalten.
Da spielt dann auch ein defekter RAM-Baustein keine große Rolle.
Der Server merkts und nimmt die RAM-Bank offline und meldet den Defekt natürlich per Mail dem Admin.
Professionelle Hardware bietet da sehr sehr viele Möglichkeiten.
Ein Datenverlust durch Hardwarefehler ist bei entsprechend konfigurierter professioneller Hardware nahezu immer die Schuld des Admins, weil der nicht rechtzeitig auf die Fehlermeldungen des Systems reagiert hat.

 

[Digi-Quick]

Genau deshalb gehört zu einem ernsthaften Raid immer auch eine USV, die bei einem Stromausfall puffert und bei zu Ende gehender Batteriekapazität dann schlußendlich den PC/Server/NAS sauber runterfährt.

Was bringt die USV, wenn das Netzteil die Grätsche macht?
Das Netzteil wird natürlich im Professionellem Umfeld redundand ausgelegt - wie von die im weiterem Text angemerkt.

Eine andere "Böse" Geschichte ist, wenn das OS mit einem Fehler aussteigt (BSOD). der dann erfolgende Neustart (egal ob Kalt- oder Warmstart) führt zu einen Reset auf dem Controller, auch hier geht der Cacheinhalt verloren, wenn nicht durch BBU gepuffert.
Die USV ist einzig dafür da, im Falle eines Stromausfalles das System ordentlich herunterzufahren - und erst in zweiter Linie das System bei Stromausfall eine definierte Zeit weiter in Betrieb zu halten. Es ist nicht die Aufgabe der USV den Cacheinhalt des Controllers zu puffern.

Daher wird im Professionellem Umfeld auch immer eine BBU eingesetzt.

 

[gea]

Bei neueren CopyOnWrite Dateisystemen kann zwar ein plötzlicher Absturz nicht mehr zu einem korrupten Dateisystem führen, eine USV ist dennoch immer eine sinnvolle Massnahme. Ein Komplettabsturz macht mir da zwar weniger Sorgen - kurze Spannungsschwankungen können aber völlig unvorhersehbare Effekte haben. Ich hatte in der Vergangenheit aber auch schon Abstürze weil die Batterien Probleme hatten. USV nehme ich daher bei wichtigen Systemen nur zusammen mit redundanten Netzteilen bei denen die USV nur eines absichert.

Eine BBU bei Hardware-Raid und ext4 oder ntfs oder bei ZFS und Softwareraid das Benutzen von Sync-Write mit einer SSD als Slog die Powerloss-Protection hat, sorgen dann im Falle eines tatsächlichen Absturzes dafür dass ein bestätigter Schreibvorgang wirklich auf Platte ist.

Die Kombination machts. Auch sind die Rahmenbedingungen und Massnahmen je nach Systemumgebung unterschiedlich und Massnahmen daher auch unterschiedlich wichtig oder anders umzusetzen.

 

[fax668]

Bei neueren CopyOnWrite Dateisystemen kann zwar ein plötzlicher Absturz nicht mehr zu einem korrupten Dateisystem führen

Hatte ich auch gedacht, bis sich vor 1 1/2 Jahren meine btrfs Partition bei einem Absturz (wegen Überspannung durch Blitz) zerlegt hat. Das schönste Konzept nutzt nichts, wenn die Implementierung fehlerhaft ist. Ein aktuelles Backup war zwar vorhanden, aber die Wiederherstellung hat trotzdem keinen Spaß gemacht. Seitdem habe ich auch eine USV.

 

[pumuckel]

atm kosten 32 GB non ecc DDR4 110€ und 32GB ECC (reg oder unbuff) 200€

bitte also die "kost kaum mehr" Argumente weglassen

 

[Digi-Quick]

Den einfachen "Value" Speicher für 110 € setzt doch kaum einer ein, es wird ja eher SupaDupa HyperX Ballistic Schießmichttot Speicher gekauft, weil die ja unheimlich viel schneller sind *scnr*

ECC Speicher kostet mehr als normaler Speicher, das ist Fact, in Summe sind das grundsätzlich mind. 150 € Mehrkosten (bei 16GB Ram) ggü einen System ohne ECC - Mainboard +100 €, RAM +50 € - so Pi mal Daumen.

 

[pumuckel]

Den einfachen "Value" Speicher für 110 € setzt doch kaum einer ein, es wird ja eher SupaDupa HyperX Ballistic Schießmichttot Speicher gekauft, weil die ja unheimlich viel schneller sind *scnr*

ECC Speicher kostet mehr als normaler Speicher, das ist Fact, in Summe sind das grundsätzlich mind. 150 € Mehrkosten (bei 16GB Ram) ggü einen System ohne ECC - Mainboard +100 €, RAM +50 € - so Pi mal Daumen.

ich verglich 2133er (da ecc/reg auch 2133 ist) und da 16GB Module/Dimms

 

[Digi-Quick]

Das weiss ich doch.... - dafür braucht man im Preisvergleich nur die 32GB Kits nach Preis aufsteigend sortieren lassen

 

[pumuckel]

wie wäre es mal vergleichbar zum kaufberatungsforum einfach ein paar Beispielconfigs in einen Sticky zu packen ?

sowas z.B. :



Homelab mit virtualisiertem Storage von ca 650€ an je nach Ausbau



Platz für (einige Optionen)
4-6* 2,5" und 8*3,5"
bzw 4*2,5" und 1*3,5" (5,25" Wechselrahmen) und 8*3,5"
bzw 3*3,5" (3in2 3,5" Wechselrahmen) und 8*3,5"




Hardware:

Supermicro X11SSL-CF retail (MBD-X11SSL-CF-O) ab € 308,78

Intel Pentium G4400, 2x 3.30GHz, boxed (BX80662G4400) ab € 59,34 (hat VT_D, ECC, AES - reicht oft weit aus)
oder
Intel Core i3-6100, 2x 3.70GHz, boxed (BX80662I36100) ab € 113,86 (hat VT_D, ECC, AES) - mein Tip
oder
Intel Xeon E3-1230 v5, 4x 3.40GHz, boxed (BX80662E31230V5) ab € 268,82 (für den E-Peniz)

1-4 * Samsung DIMM 16GB, DDR4-2133, CL15, ECC (M391A2K43BB1-CPB) ab € 95,50 (einer reicht erstmal)

Fractal Design Define R4 Black Pearl, schallgedämmt (FD-CA-DEF-R4-BL) ab € 81,51
LogiLink 5.25" Einbaurahmen (UA0208) ab € 25,28 (für weitere 4* 2,5" am Intel SATA)
EVGA 650 GQ 650W ATX 2.3 (210-GQ-0650) ab € 74,65

12-14* ordentliche Sata Kabel in passenden Längen
ruhige Casefans (vorn ansaugend, hinten und oben ausblasend)




Platten z.B.

SSD:
Seagate 600 Pro SSD 240GB, SATA (ST240FP0021) ab € 103,38

2,5":
HGST Travelstar 7K1000 1TB, SATA 6Gb/s (HTS721010A9E630/0J22423) ab € 51,90

3,5":
2/4/6/8 * Seagate Surveillance HDD 5900rpm 3TB (8-Bay Support), SATA 6Gb/s (ST3000VX006) ab € 98,98
... z.B. als 4*(2*3TB Mirrors) = 12 TB (ideal um mit 2 Platten zu beginnen und mit immer 2 mehr aufzustocken
... oder 2*(4*3TB Z1) = 18 TB (4 zu Beginn, dann 4 dazu)




optional für NVMe verliebte
Samsung SSD SM951-NVMe 256GB, M.2 (MZVPV256HDGL-00000) ab € 128,54
mit z.B. http://www.amazon.de/dp/B00IM8L6XW zu 24€



Verwaltungshilfen :

https://play.google.com/store/apps/...iview&pcampaignid=APPU_1_84H0VqXWMcX2O9KGkogL

https://play.google.com/store/apps/...ndroid&pcampaignid=APPU_1_k4L0VumsAcfbO_LVhhA





natürlich etwas ausgearbeiteter

 

[Fischje]

Ich hab mir vor 2 Jahren mal ein kleines DIN A4-Blatt in mein Büro gehangen, mit diesen Schild drauf:



Darunter das Tao des Backups:

Grundsätzliches

1. Eine Datensicherung muss überwacht werden
   Jede Datensicherung kann Probleme bereiten: Softwareprobleme, Kabel, Speicher voll … was auch immer. Probleme kommen auch bei vollautomatischen Datensicherungen immer wieder mal vor – deshalb muss man eine Datensicherung auch überwachen und prüfen, ob sie funktioniert.
   
2. Die Verwendungsfähigkeit der Daten in der Datensicherung muss überprüft werden
   Weil die Dateien in der Datensicherung unter Umständen defekt sein können. Eine Datensicherung, die nicht auf Verwendbarkeit der Dateien nach Wiederherstellung geprüft wurde, ist unter Umständen nichts wert … nämlich dann, wenn sich herausstellt, dass die wiederhergestellten Dateien beschädigt sind.
   
3. Jedes Backup kann defekt werden
   Deshalb ist es besser, zwei oder drei voneinander unabhängige Backups zu haben. Jede Festplatte und jedes Band ist einmal voll, jede Backup-Software kann mal ausfallen. Deshalb sind mehrere voneinander unabhängige Datensicherungen essentiell wichtig, wenn sie verlässlich funktionieren sollen.
   
4. In ein Backup gehören ALLE Daten
   Arbeitsdateien, Betriebssystemdateien und Programmdateien – einfach ALLE Dateien sollten gesichert werden. Es ist eine häufig anzutreffende Illusion, dass man nur wenige wichtige Dateien sichern muss. Selbst die privaten Fotos haben einen unschätzbaren Wert und es nicht schön, immer wieder einmal zu sehen, dass die Familienfotos mit der Festplatte in die ewigen Jagdgründe eingegangen sind.
   
5. Vollautomatisch
   Eine Datensicherung sollte vollautomatisch erfolgen, damit sie dauerhaft funktioniert. Wenn man eine Datensicherung von Hand starten muss, dann wird sie nicht verlässlich funktionieren.

Kaum weniger wichtig


6. Frequenz
Wenn man arbeitet, dann macht man ein Backup. Arbeitet man täglich, dann macht man ein tägliches Backup. Je wichtiger die Daten für die Arbeit sind, desto häufiger und desto sicherer sollte das Backup-Konzept sein. Je mehr Dateien man erstellt, desto häufiger sollte die Datensicherung erfolgen.

7. Sichere Aufbewahrung
Die Aufbewahrung der Datensicherung sollte an einem sicheren Ort erfolgen, aber nicht am selben Ort wie die Quelle der Daten. Nur durch Lagerung außerhalb erreicht man Schutz vor elementaren Schäden wie Feuer, Wasser, etc.

8. Aufbewahrungszeit
Je länger man die Datensicherung aufbewahrt, desto höher ist die Sicherheit. Man hüte sich vor der Wiederverwendung der Backup-Medien.

9. Sicherheit
Bewahre Dein Backup an einem sicheren Ort auf und kontrolliere den Zugang zur Datensicherung. Nutze die Verschlüsselung Deiner Datensicherung, wann immer sie möglich ist.



Angepasst aus der Quelle: Das Tao des Backups | Apfelwerk - Apple Support aus Stuttgart
Anpassungen und Kritik gewünscht. Sicherlich muss man nicht jeden Grundsatz daraus so leben. Aber ich hab's halt jetzt erst mal so kopiert.

 

[pumuckel]

für "daheim" reicht es imho völlig evtl ausgemusterte kleine HDDs als Backup medien zu nutzen (verkauft bekommt man die eh nicht)

hier liegt ein Stapel 1-2TB 3,5" Platten welche zum großteil >3-5 Jahren sind (Austausch nach 3 Jahren)
grad nu zur umstellung auf 2,5" fällt da viel an

 

[Holt]

Naja, es muss ja jeder selbst wissen wie praktisch es ist meinere TB auf einem Dutzend kleiner HDDs zu sichern und diese Sicherungen dann auch regelmäßig zu Prüfen und zu Aktualisieren.

 

[craxity]

@Fischje: Nr 5 in der Liste ist ziemlicher Mist. Bevor man sich ein Backup-Konzept entwirft, muss man sich genau überlegen, welche Daten wichtig sind und wie schnell sie wiederhergestellt werden müssen. Alles blind zu sichern kostet so viel, dass viele es einfach lassen. Für Privatnutzer ist der Tipp folglich Mist.

 

[besterino]

Ich glaub du meinst Nr 4 (alle Daten gehören ins Backup)...?