Datenbackup: Bei Sicherungs-PC auf ECC verzichten?

[ebniv]

Mir ist bewusst, dass ECC oder nicht ECC ein heiß diskutiertes Thema ist.
Auf meinem Homeserver läuft TrueNAS mit ECC.

Jetzt möchte ich noch einen zusätzlichen Backup Server/PC ohne ECC einrichten (es geht wirklich nur um ein Backup der Daten falls das andere Gerät abraucht, um Datenverlust vorzubeugen). Hier sollte ich doch wirklich ruhigen Gewissens auf ECC verzichten könne, selbst wenn ich auf dem Backupgerät ZFS einsetze. Oder würdet ihr mir davon abraten?

Den Office PC, welchen ich für die Backups einsetzen wollte (1150 oder sogar 1155 Plattform, muss ich mir nochmal überlegen) würde ich eh kaum noch los werden. Die ECC Lösung (i3 7100, ECC, MSI C236M) ließe sich sicher noch gut verkaufen und finde ich irgendwie auch zu schade für gelegentliche Backups (möchte ich eigentlich automatisieren) und denke mir so ein System kann woanders noch sinnvolleres verrichten.

 

[underclocker2k4]

Die Frage ist leicht beantwortet. Was hilft dir nen Backup, wenn du es im Zweifel eh nicht verwenden kannst?
ZFS verlässt sich darauf, dass die Daten im RAM, korrekt sind. Sind sie das nicht, können die Daten auf dem Storage korrupt werden.
ECC braucht der Server nicht, damit er stabil läuft (das zwar auch) primär braucht es erstmal ZFS, also dein RAID.

EDIT: Gerade beim Backup ist es besonders kritisch, da das in der Regel nicht so häufig läuft und daher aufgrund der Unschärfe ein Defekt im Zweifel erst dann auffällt, wenn du es braucht, weil das Mainstorage defekt ist.

 

[asche77]

ECC braucht es mE nicht (edit: für den Backup Server; generell würde ich aber immer für ECC plädieren).

ZFS macht haufenweise checksums, Fehler durch RAM würden also deutlich schneller gefunden(!) als mit anderen filesystems.

Regelmäßig Scrubs machen hilft.

Der "scrub of death" ist eine urban myth.

 

[Stueckchen]

Würde es einfach so sehen:
Backup ist besser als kein Backup mit oder ohne ECC. Wobei mit ECC erhöht es natürlich die Sicherheit noch weiter.
Wenn man ZFS per send/rcv Backuped ist es auch auch nicht so das durch einen RAM Fehler alles unbrauchbar ist: Daher besser 9999/10000 Daten wieder bekommen als keine.

 

[underclocker2k4]

Der "scrub of death" ist eine urban myth.

Findest du oder hast du ne Statistik, die das untermauert?

Hier mal ein Beispiel, dass es kein myth ist.

ZFS checksum error (on scrub) – how do I see affected files?

This is the first time I've ever gotten this kind of error across the board, I've only experienced bad drives before. zpool status pool: datapool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications...

forums.servethehome.com

Muss jeder selber wissen. Am Ende reden wir hier von sehr wenigen 100EUR und man muss dann für sich bewerten, was einem die Daten Wert sind.
Ich habe selbst im Office Rechner ECC, klingt komisch, ist aber so.

 

[besterino]

Noch nicht mal (wenn’s nur um den RAM geht): fürn Backup reicht m.E. auch der langsamste Riegel und 16GB sind schon mehr als genug. Da ist man noch unter 100 Euro und mit RDIMMs bei nem Fuffi.

Der TE hat den Kram ja sogar da, wenn ich das richtig verstehe?

 

[underclocker2k4]

Der TE hat den Kram ja sogar da, wenn ich das richtig verstehe?

So verstehe ich das.
1x OfficePC über
1x 2. ECC Plattform über

Das Delta zwischen dem Verkauf beider Plattformen macht <100EUR aus, ohne die SPEC zu kennen, beide sind ähnlich. Sprich also, ECC kostet quasi 100EUR.
Das wäre mir das 3x wert. Aber wie gesagt, muss jeder selber wissen.
ECC kann man bei einem normalen Server @home verzichten, wenn der steht, dann gehts halt später weiter. Sind die Daten kaputt, dann wars das, da gibt es oftmals kein später mehr.

 

[sch4kal]

Will man sich das angesichts sehr geringer Aufpreise zu einer ECC-Plattform denn wirklich antun ?

 

[besterino]

Glaub die meisten von uns würden ECC für die Backup-Maschine nehmen, einfach weil "besser so" und kaum Aufpreis.

Eine echte Risikoabwägung ist halt schwierig: ich hab keine Ahnung wie hoch die Wahrscheinlichkeit eines RAM-Fehlers ist und mit ZFS auf'm Backup würde wohl auch ein RAM-Fehler auf der Backup-Maschine aufgrund der Checksummen beim Sicherungsvorgang bemerkt und ggf. korrigiert / wiederholt bis die Checksumme zu den Daten passt. Wenn die Daten einmal geschrieben sind, sollte aufgrund der Snaps bei jedem Sicherungsvorgang auch nicht allzuviel schiefgehen, wenn sich später RAM-Fehler realisieren...

Ich würde aber wohl in jedem Fall ein 2. Backup der wichtigen Daten auf eine externe Festplatte (per USB z.B.) vorsehen, die ich an den Mainserver anschließe, demnach dort die Daten "mit ECC" repliziere und ggf. auf der USB-Platte wenn möglich auch gleich "copies=2" setzen.

So'ne USB-Platte nutze ich auch für mein "offsite" bzw. "out of home" backup alle paar Wochen/Monate.

 

[ebniv]

Schade, ich hatte gehofft von den meisten würde ein schnelles "kann man dort wohl vernachlässigen" kommen
Aber damit, dass die meisten, welche sich damit professioneller beschäftigen, zu ECC raten, hätte ich ja auch rechnen können. 😅

Bringt es etwas beim Backup auf ZFS zu verzichten, ist damit ein Verzicht auf ECC auch weniger kritisch?








---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
@underclocker2k4 zur Hardware:
Ich habe bei der Zusammenstellung eines günstigen Homeservers aus gebrauchter HW (300€ waren ohne HDDs angepeilt) jetzt vermutlich schon ~700€ ausgegeben und kann defakto 3 "Homeserver" bauen. Dazu kommt noch office Hardware die ich die Jahre davor in Betrieb hatte und es soll jetzt wieder alles Weg bis auf Position 1. Homeserver und irgendwas für Backups


Ich habe bisher zu B) P920 oder C) E710 mit 8 bzw. 16GB RAM als vermutlich billigste Lösung für die Backups tendiert. Vielleicht wäre nach euren Ratschlägen Build 3 ein guter Kompromiss zwischen Kosten, Leistung und ECC. Build 2 kann man sicherlich noch mit am besten (auch in Einzelteilen) wieder verkaufen und ist denke ich auch überdimensioniert für lediglich Backups.


1. "Homeserver" <- Das ist das finale "Build" aus dem ganzen gekauften Gerümpel
Xeon 1270v5
P10S-M-DC
1x 16GB DDR4 ECC 2166 UDIMM
1x 16GB DDR4 ECC 2666 UDIMM
//Diese Ram Kombination ist sicherlich etwas langsamer als 4x8GB 2400MHz mit unschön kombinierten Riegeln, aber durch 2x16GB verbaue ich mir nicht sofort den Upgradepfad zu 64GB und bisher lief die Kombination auch einwandfrei.
Pure Power 11 400W
(2x WD Red 3TB CMR)
(2x 256GB 850 Pro)
(Fractal Define R6)

2. Build
Xeon 1245v5
P10S WS
4x 8GB DDR4 ECC 2400 UDIMM
Pure Power 10 300W
(Fractal Define C)

3. Build
i3 7100
MSI C236M
2x 4GB DDR4 ECC 2400 UDIMM
Pure Power L8 300W
(NoName Case)

------------------------------------------------------------------------
Office PCs:
A Fujitsu P720 komplett
i3 4160
2x 8GB DDR3 1600
2x 4GB DDR3 1600

B Fujitsu P920 ohne Gehäuse
original OEM Netzteil
i3 4130

C Fujitsu E710 komplett
i5 3570T (alternativ i3 3240 ohne AES NI)
2x 8GB DDR3 1600

Sontiges (um Build zu komplettieren und besser verkaufen zu können):
2GB DDR3 1600MHz
4GB DDR3 1600MHz
SSD 128GB Sata 840 Pro
SSD 250GB Sata 840 evo
SSD 128GB Sata SanDisk
(SSD 250GB Sata M100 Crucial)
3TB Seagate Consumer

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Für Backups oder auch Ersatz zurückgelegt:
2x WD Red 3TB CMR
1x HGST 3TB irgendwas mit NAS
Vermutlich die obere 128GB 840 Pro als Bootlaufwerk

 

[besterino]

Ich würd Build 1 und 3 behalten und den Rest verscherbeln.

Aber ich bin vermutlich auch nicht das Mass der Dinge bzw. ist leicht gesagt. Bei mir langweilen sich insgesamt zig (ECC-fähige) Kisten, von denen ich aktuell eigentlich nur noch eine im Dauerbetrieb benötige und mir aktuell auch überlege, wie ich nun dauerhaft mein Backup gestalte.

Müsste wohl auch mal ausmisten und könnte diverses verkaufen... aber bevor ich das mache, schaffe ich lieber erstmal noch weiteren Krempel an... Aktuell bin ich auf dem Trichter, nicht mehr eine ganze Backup-Kiste zu betreiben, sondern wirklich nur noch mit externen Platten und z.B. einem SAS-Gehäuse zu arbeiten, das man hotswap-artig anstöpseln/-werfen kann. Dann geht zwar so ohne Weiteres kein automatisiertes/systemübergreifendes Backup mehr, aber mit 'ner Schaltsteckdose und 'nem Script zum zeitgesteuerten ein-/aushängen eines ZFS-Pools könnte man selbst das noch realisieren. Am Ende steht und fällt jede Lösung mit der ganz persönlichen Mischung aus Risiko-Appetit, Faulheit (oder nennen wir es "Komfortbedarf") und Umsetzungs-KnowHow. Ich hab immerhin in den letzten 15 Jahren keine Daten verloren *3xaufHolzklopf*- eher zu viele Kopien und dann irgendwann den Überblick verloren, wo überall...

 

[asche77]

Bringt es etwas beim Backup auf ZFS zu verzichten, ist damit ein Verzicht auf ECC auch weniger kritisch?

Ich sehe keinen Grund, auf ZFS zu verzichten. Im Gegenteil.

Nur weil ein Auto keinen Airbag (ECC) hat, verzichtest Du ja auch nicht auf den Sicherheitsgurt (checksums).

Backup ohne ECC und ohne ZFS = Du bemerkst etwaige bitfehler einfach nicht.

Backup ohne ECC aber mit ZFS = Du hast gute Chancen, etwaige bitfehler aufgrund von checksums zumindest zu bemerken.

 

[ebniv]

Ich würd Build 1 und 3 behalten und den Rest verscherbeln.

Danke. Diese Idee lasse ich mir noch mal durch den Kopf gehen. 16GB Ram könnte man nötigenfalls ja auch noch vom Build 2 abzwacken, aber ob man das braucht?

 

[besterino]

Für reines Backup ohne Virtualisierung oder sonstiges Gedöns tät's sicherlich auch weniger. Glaub unter 8GB würde ich heute aber nicht mehr starten.

 

[gea]

Ich glaube die wichtigste Aussagen sind:
-Besser ein Backup ohne ECC als kein Backup
-ZFS ohne ECC ist meist besser als andere Systeme mit ECC
-Es können ohne ECC unentdeckte Fehler im Backup sein gegen die auch ZFS nicht schützen kann (was man bei kritischen Daten sicher vermeiden möchte)

"Scrub to Death" ist die Annahme dass ein System mit unentdeckten Ramfehlern (ohne ECC) Daten liest und aufgrund eines Ramfehlers eine (fehlerhafte) Korrektur auf Platte startet, genau wie bei folgenden (auch fälschlicherweise als falsch erkannten) Lesefehlern. Vor allem aus einem bestimmten Forum oft geäußert.

Ich halte das auch für einen Mythos. Ich beschäftige mich seit ca 13 Jahren intensiv mit ZFS. Mir ist seither kein einziger Fall bekannt, in dem dieser Ablauf glaubhaft bestätigt wurde, Dateisystemfehler wegen RAM Fehlern ohne ECC können aber durchaus im worst case einen ZFS Pool irreparabel schädigen. Das ist aber sehr unwahrscheinlich. Häufiger sieht man Disk offline oder Pool offline wegen too many error. Das ist die übliche Reaktion bei ZFS auf viele Fehler - Deaktivieren anstatt Totreparieren.