Verschlüsseltes Backup auf NAS machen?

SG1

Datengrab klingt schon sehr nach Langzeitarchiv. IMHO.

Also wenn ich Daten im Terabyte Bereich lagere muß ich es hinnehmen das dort Änderungen passieren? Die Festplatte ist dann nicht im Sinne des "Raid 1" kaputt. Wenn ich Änderungen komplett ausschließn will, dann brauche ich ein Raid mit Fehlerkorrektur und das von nman benannte Scrubbing um die Fehler zu finden?

Ich habe mir einen Netgear NAS ausgeliehen und mit Truecrypt über Nacht ein 200GB Volumen als File angelegt. Ein Terabyte Volumen hätte 30 Stunden zum Anlegen gebraucht. Ich habe zuerst einen 2GB Ordner mit Mp3s in das TC-Volumen gelegt und einmal neben das Volumen (also ohne TC). In beiden Fällen wurden mit einem Gigabit Network 140 Sekunden benötigt. Dann habe ich einen Anwendungsordner mit 3000 Dateien und 1GB Größe verschoben und da war das Schreiben in das TC-Volumen sogar in Sekunden fertig, das Volumen ließ sich dann jedoch für 20 Sekunden dismounten. Ich denke da ist irgendein Cache im Hintergrund. Auf jeden Fall ist der Geschwindikeitsunterschied nicht bemerkbar und für meinen Fall wirklich ausreichend.

Was passiert nun wenn in einem großen TC-Volumen ein Bit kippt:
*What will happen when a part of a TrueCrypt volume becomes corrupted?

In encrypted data, one corrupted bit usually corrupts the whole ciphertext block in which it occurred. The ciphertext block size used by TrueCrypt is 16 bytes (i.e., 128 bits). The mode of operation used by TrueCrypt ensures that if data corruption occurs within a block, the remaining blocks are not affected. See also the question 'What do I do when the encrypted filesystem on my TrueCrypt volume is corrupted?*
Es wird also nur ein 16 Bytes Block unbrauchbar.

Jetzt wäre es optional in das Volumen ein Dateisystem zu schreiben das das Kippen einzelner Blöcke abfängt. So eine Art Hamming Code der alle 1000 Blöcke einen gekippten Block abfangen kann. Bei TC kann ich leider nur Fat und NTFS formatieren. Zu NTFS+Fehlerkorrektur finde ich im Internet nur das sie stattfindet und von Version zu Version verbessert wurde, jedoch nicht konkret die Leistungsfähigkeit.

Wenn ich Zeit habe werde ich mit einem Hex Editor im Volumen mal hier und da ein paar Bytes verändern. Mal sehen ob NTFS das repariert oder ob sich die Checksummen der gespeicherten Dateien dann unterscheiden.

Scrubbing: Bei den billigen NAS Systemen < 100 EUR steht nichts von Scrubbing. Bei 1000 Euro Systemen wird Scrubbing angeboten, so viel wollte ich aber nicht ausgeben. Heute Abend muß ich dazu mal mehr im Internet suchen.

Datengrab heißt das ich alle paar Tage/Wochen neue Dateien hinzufüge. Das die Festplatten aber 99% der Zeit ausgeschaltet sind.

hustbaer

@SeppJ
Was soll es bringen wenn die Platten laufen?
Und... guck dir mal die Zahlen an die die HDD Hersteller veröffentlichen. Unrecoverable Read Error Rate und so.

@abcd
Wenn du ne gute NAS willst, dann kauf dir nen billigen Server!
Nen Server mit Xeon und ECC RAM bekommst du für unter €400 (z.B. den T20 von DELL). Bzw. mit Pentium und ECC RAM sogar schon für unter €300. Der kann 10x mehr als ne €700 NAS.
Für €100 kann ich dir aber leider nix empfehlen was Scrubbing könnte.
Minimum wird wohl eher so im Bereich €200~€250 sein, wenn man auf ECC verzichtet und sich nen superbilligsparmeister-PC holt.

Der NAS den ich mir gerade von meiner Firma ausgeliehen habe (Netgear ReadyNAS 102 RN10200) unterstützt Scrubbing:
https://geizhals.de/netgear-readynas-102-rn10200-rn10200-100eus-a916218.html?hloc=at&hloc=de
Datenblatt:
http://www.downloads.netgear.com/files/GDC/datasheet/de/RN100.pdf

Die Buffalo LinkStation 421e (LS421DE-EU) für ~82 Eur scannt das Raid auch regelmäßig auf Fehler:
https://geizhals.de/buffalo-linkstation-421e-ls421de-eu-a945052.html?hloc=at&hloc=de
http://manual.buffalo.jp/buf-doc/35020812-04_DE.pdf

Bei den teueren NAS Systemen steht auch nicht immer Scrubbing sondern irgendwas mit Partol. Ich denke es sind unterschiedliche Namen für die gleiche Fehlerkontrolle?

hustbaer

@abcd
Aber was machen die dann wenn sie beim Scrubbing nen Fehler gefunden haben? Weinen?
Oder können sie den auch irgendwie reparieren? Würde mich sehr wundern.

Wenn man sich selbst nen Server hin stellt kann man halt ZFS bzw. ReFS verwenden. Die haben dann Parity-Streams, und mittels derer können sie die gefundenen Fehler dann reparieren.

https://en.wikipedia.org/wiki/RAID#URE
Unrecoverable read errors (URE) present as sector read failures, also known as latent sector errors (LSE). The associated media assessment measure, unrecoverable bit error (UBE) rate, is typically guaranteed to be less than one bit in 10^15 for enterprise-class drives (SCSI, FC, SAS or SATA), and less than one bit in 10^14 for desktop-class drives

Wenn man alle 10^14 Bits ein Lesefehler hat, dann würde er alle 10^14/(10244*8) = 11 Terabyte auftreten. Wenn ich eine 2 TB Platte also 6 Mal beschreibe, dann sollte im Consumer Bereich im Mittel irgendwo ein Bit gekippt sein. Jetzt die Platte wegschmeissen zu müssen wäre schlecht. Ich würde die Datei neu schreiben und nur wenn mehr Fehler auftreten die Platte austauschen. Raid ließt kein NTFS, der Fehler wird eine Ebene darunter schon beim Scrubben/Scannen/Patrol bemerkt. Sonst gäbe es ja die Smart Auswertung auch nicht.

Jetzt löse ich das Raid auf und repariere mit chkdsk die korrupte Platte und hänge sie danach wieder in das Raid. Das geht nicht, weil Raid so nicht funktioniert? Dann muß ich die korrupte Platte raus nehmen und neu reinhängen und von der anderen Platte komplett neu beschreiben lassen aka Raid neu erstellen.

Ich will für Dateien die ich irgendwann mal vielleicht noch brauche keine 1000 Euro ausgeben. ~100 Euro + 2*100 Euro für die beiden Platten müssen reichen.

nman

SeppJ: Siehe hustbaer.

abcd schrieb:

~100 Euro + 2*100 Euro für die beiden Platten müssen reichen.

Mach daraus ~220€ + 2*100€ für Festplatten und du kannst dir von Amazon einen HP Microserver mit 4GB ECC-RAM kaufen und darauf NAS4Free installieren und ZFS verwenden.

abcd schrieb:

Ich würde die Datei neu schreiben und nur wenn mehr Fehler auftreten die Platte austauschen.

Wenn du den Fehler bemerkst, ja. Das Scrubben sagt dir aber nicht "Datei X ist vielleicht kaputt", das RAID weiß ja nichts von Dateien, das kennt nur Blöcke. Ergo ZFS oä.

Wenn du dich gerade erst ganz frisch in das Thema einliest, machst du dir übrigens wahrscheinlich zu viele Sorgen. Um welche Daten geht es denn überhaupt?

Sonst gäbe es ja die Smart Auswertung auch nicht.

Es gibt keine Smart-Auswertung. Wenn du an Smart-Daten interessiert bist, musst du sie selbst auslesen. Was soll dein Raid-Controller spannendes mit Smart-Daten machen? Und mit welchen?

Jetzt löse ich das Raid auf und repariere mit chkdsk die korrupte Platte

Geht nicht, chkdsk repariert Dateisysteme, keine Festplatten.

Dann muß ich die korrupte Platte raus nehmen und neu reinhängen und von der anderen Platte komplett neu beschreiben lassen aka Raid neu erstellen.

Woher weißt du denn ohne Checksumme, welche der beiden Platten die kaputte ist?

Achtung, komplett kaputte Sektoren sind etwas ganz anderes als Bitrot, du würfelst da gerade viel durcheinander. Wenn dir gerade nicht klar ist, worum es wobei geht, machst du dir zu viele Sorgen. Du wirst dich vmtl. nicht innerhalb von zwei Tagen in das Thema einlesen können.

hustbaer

@nman
Ich hatte irgendwann mal nen coolen Artikel gelesen zu dem Thema.
Speziell zu ZFS und echten Erfahrungswerten zum Thema UREs und Zuverlässigkeit von HDDs im allgemeinen, URE-Rate und die Chancen ein multi-Terabyte single-parity RAID Set überhaupt noch rebuilden zu können. (Und warum Double- und Triple-Parity bei ZFS ne tolle Sache ist.)

Darin wurde auch das Thema BitRot* erwähnt, und IIRC gab's auch ein paar reale Zahlen, also Statistiken aus dem Alltag, nicht irgendwas was irgendwer irgendwo angegeben oder ausgerechnet hat.

Leider hab' ich den Link wohl "verlegt" und konnte den Artikel auch auf die Schnelle nicht wieder finden.

Wäre ein Zufall, aber wenn's bei der Beschreibung oben bei dir geklingelt hat, und du den Link noch hast, wäre ich dankbar wenn du den Link hier posten könntest

*:
Wobei mir gerade auffällt... mein "siehe URE" an SeppJ war wohl etwas unpassend - weil eben URE != BitRot. Weil URE eben typischerweise nicht "silent".

Sorry SeppJ

SeppJ

hustbaer schrieb:

*:
Wobei mir gerade auffällt... mein "siehe URE" an SeppJ war wohl etwas unpassend - weil eben URE != BitRot. Weil URE eben typischerweise nicht "silent".

Eben. Irgendwie habe ich das Gefühl, alle reden in diesem Thread aneinander vorbei. Ich bestreite nicht, dass Festplatten ungeeignet für Langzeitarchive sind oder dass selbst kurzzeitig Daten verschwinden können. Aber der Threadersteller hat Angst, dass er diese Fehler eventuell nicht bemerken könnte. Das ist völlig unrealistisch.

Ich muß Rechnungen die ich als Selbstständiger schreibe lange aufbewahren. Und natürlich alte SW-Projekte und den Schriftverkehr.

Deine Idee gefällt mir sehr gut:
http://www.heise.de/preisvergleich/hp-proliant-microserver-gen8-819185-421-a1322637.html

Für 205 Euro + die Platten. Dann ein bißchen in OpenMediaVault einlesen. Dafür habe ich dann die Daten unter Kontrolle und könnte vielleicht sogar aus alten Platten ein Array zum Probieren&Testen zusammenstecken, weil ich hier 5 Sata Anschlüsse habe.
http://www.bastis-blog.com/2015/07/nas-einrichten-und-konfigurieren-mit-debian-und-openmediavault/
http://www.och-group.de/2013/05/15/hp-proliant-n40l-microserver-mit-openmediavault-und-debian-installieren/

Vor 10 Jahren hast du mir einen Brother Laser Drucker empfohlen und der steht hier immer noch auf dem Tisch*g*

hustbaer

SeppJ schrieb:

Aber der Threadersteller hat Angst, dass er diese Fehler eventuell nicht bemerken könnte. Das ist völlig unrealistisch.

Naja ne, eben auch nicht.
Deswegen würde ich gerne erwähnten Artikel wiederfinden - bisher aber kein Glück. Da stand nämlich 'was zum Thema "silent data errors" drinnen. Also Daten aus der Praxis.

Meine Bemerkung bezüglich "URE" ist aber natürlich trotzdem nicht passend

hustbaer

Ist zwar nicht der Artikel den ich gesucht habe, aber auch ganz OK:
http://queue.acm.org/detail.cfm?id=1866298

Das viel zitierte CERN Paper:
http://indico.cern.ch/event/13797/session/0/contribution/3/attachments/115080/163419/Data_integrity_v3.pdf

Und natürlich Wikipedia:
https://en.wikipedia.org/wiki/Data_corruption#SILENT

SeppJ

Also Bestätigung, dass diese Art von Fehler sehr selten auftritt und VIEL eher irgendetwas anderes kaputt geht? Es ist Zeitverschwendung sich über diese Fehler den Kopf zu zerbrechen, wenn die Chance, dass etwas irreparabel und mit großem Knall kaputt geht, so ungleich größer ist^*. Der Threadersteller sollte sich Gedanken machen, ob er mit einem mechanischen oder elektronischen Totalausfall einer Platte (oder eines Teils davon) leben kann, nicht, ob ihm alle 100 TB mal ein falsches Bit untergejubelt werden könnte (was ihm dem Bericht nach genau so gut durch Störungen im RAM/CPU passieren kann).

^*: Das mag anders aussehen, wenn man Datenmengen im Stil des CERNs oder Amazons verarbeitet und sich gegen die häufig auftretenden Ausfallszenarien bereits abgesichert hat. Priorität sollte aber zuerst einmal sein, sich gegen diese abzusichern.

nman

SeppJ: Ich schätze deine Meinung sehr, aber ich weiß nicht genau, worauf du hier hinauswillst. Dass der OP sich über andere Sachen Gedanken machen sollte, habe ich doch selbst gesagt. Ist nur ohne genaue Beschreibung der Daten und der Erfahrung des OP schwer einzuschätzen, was das Hauptproblem ist.

Deine Behauptung war IIRC "Bitrot ist mit Festplatten kein Problem" und das stimmt nicht. Du musst auch nicht das CERN sein, damit Fehlerraten in dieser Größenordnung ein Problem werden können. Ganz normaler Wissenschaftsbetrieb reicht aus. Oder Datenbank-Backups von Unternehmen, die wichtige Daten produzieren. (Ja, teilweise auch zur langfristigen Archivierung, aber durchaus nicht nur.)

edit: Daten zu diesem Thema produzieren CERN und Amazon, weil sie die Infrastruktur und das Interesse haben, das Problem an sich zu untersuchen. Das heißt nicht, dass nur CERN und Amazon betroffen sind. Ich produziere auch keine epidemiologischen Daten zu verschiedenen Schnupfen-Arten, habe trotzdem aber regelmäßig Schnupfen.

Klar kannst du jetzt sagen "normale Leute haben nur kleine Office-Files und große unwichtige Mediensammlungen", aber ich hatte schon mit einigen Situationen zu tun, wo ich als Kunden normale Leute hatte, die eben das Pech hatten, bei Versicherungen, als Ärzte oder Rechtsanwälte oder eben Wissenschafter zu arbeiten.

Wir sprechen doch auch nicht davon, dass nicht andere Sachen kaputtgehen könnten, aber nur weil wir beide zuhause keine Daten bzw. Datenmengen haben, die davon betroffen wären, heißt das doch nicht dass Bit Rot kein Problem ist.

nman

hustbaer: Sorry, ich archiviere nur akademische Papers, die für eigenes Forschungszeug interessant sein könnten oder solche, die ich als Referenz verwenden möchte bzw. noch in meiner TOREAD-Queue habe.

abcd schrieb:

Ich muß Rechnungen die ich als Selbstständiger schreibe lange aufbewahren. Und natürlich alte SW-Projekte und den Schriftverkehr.

Dann wird Bit Rot vmtl. kein Problem sein. Wenn du irgendetwas nur lange archivieren und selten lesen musst, aber gerne auf Nummer sicher gehen würdest, kannst du es ja in ein Rar-Archiv mit ausreichend Recovery-Records packen oä.

Vor 10 Jahren hast du mir einen Brother Laser Drucker empfohlen und der steht hier immer noch auf dem Tisch*g*

Freut mich. (Habe meinen auch noch immer in Verwendung.)

Dann lass mich dir noch zwei Empfehlungen geben:

Bevor du deine Festplatten in Betrieb nimmst, mach einen ausgiebigen Burn-In-Test. Hier wird eine brauchbare Variante beschrieben (schreibendes badblocks, nicht nur lesendes): https://forums.freenas.org/index.php?threads/how-to-hard-drive-burn-in-testing.21451/
Aktuell kaufe ich HGST-Platten und fahre damit recht gut.

Falls du HP+OMV nimmst (kann ich an sich empfehlen): Du wirst vmtl. noch eine Micro-SD-Karte oder einen USB-Stick brauchen für die OMV-Systempartition. Und du solltest im BIOS den Hardware-RAID-Controller ausschalten (Controller auf AHCI-Modus umschalten) und checken ob die Write-Caches aktiviert sind.

Ich habe den Server, die SD Karte (für das Betriebssystem) und die Platten gekauft und bin jetzt am Rumexperiementieren. OpenMediaVaul und Zfs Plugin sind drauf. Jetzt wird gerade zuhause mit Zfs ein Raid Mirror Volumen mit beiden Platten erstellt. Allerdings unverschlüsselt. Das mit der Verschlüsselung scheint nicht so einfach zu sein bzw nicht generisch vorgesehen sein. Wenn ich dmcrypt verwenden möchte, dann müsste ich das Zfs Volumen nochmal auflössen und Dmcrypt dazwischen schieben. Ich habe im OMV Forum gefragt, für diese Lösung gibt es noch kein Tutorial. Ich habe jetzt von anderen *nix Betriebssystemen Anleitungen gefunden. Mal sehen wie man sie anwenden kann.

nman

OpenMediaVault mit ZFS habe ich noch nie verwendet, habe ZFS bis dato immer nur auf FreeBSD-basierten verwendet. Schau dir am besten mal die LUKS-Doku von Arch oä. an, die sollte alles wichtige erklären.

Installationsanleitung/Erfahrungen

Die verbaute Hardware ist:
-- HP ProLiant MicroServer Gen8, Celeron G1610T 2*2.3GHz, 4GB RAM für 205 Euro
-- 2*2 TB Hitachi Ultrastar 7K3000 HUA723020ALA641 für 2*60 Euro
-- 32 GB MicroSD für 10 Euro

Installation:
Das OpenMediaVault ISO auf ein USB Stick schreiben und damit den MicroServer starten. Es ist eine normale Debian Installation mit wenigen Konfigurationsmöglichkeiten. Die Datenplatten waren dabei nicht eingehängt. Problem: Debian startet beim nächsten Neustart nicht. Laut Internet Recherche soll man sich die "Boot repair disk" herunter laden und es automatisch fixen lassen. Ich denke Grub wurde nochmal installiert, möglicherweise auf dem MBR von einer der Datenplatten. Für Verschlüsselung und ZFS muß das OMV Extra Plugin installiert werden. Nach der Installation gibt es ein neues "OMV Extra" Menu und hier kann dann LUKS und ZFS nachinstalliert werden.

Konfiguration:
Ich habe zuerst die Festplatten einzeln über die Weboberfläche verschlüsseln lassen und danach mit ZFS ein Mirror Raid erstellt. Angeblich soll es auch anders herum gehen, also zuerst mit ZFS den Mirror erstellen und oben drauf Luks. Außerdem habe ich 2 externe baugleiche USB Platten angeschlossen und auf die gleiche Weise zu einem verschlüsseltem ZFS Mirror gekoppelt. Unannehmlichkeit: Nach dem Starten des MicroServers muß ich nun das Passwort 4* in der OMV Weboberfläche eingeben (Copy&Paste) und danach die ZFS Pools importieren lassen. Weil ich einmal bei einem Experiment den MicroSD Systemdatenträger zerschossen habe hat diese ZFS/LUKS Konfiguration sogar eine Neuinstallation von OMV überlebt.
Außerdem gibt es ein OMV-Plugin mit dem man den Zugriff auf die Systempartition und SWAP stark reduzieren kann. (MicroSD Lebensdauer erhöhen.)

OMV läßt sich sehr gut über die Oberfläche bedienen, Shellzugriff ist vorhanden, war bisher aber weder bei der Installation noch der Konfiguration notwendig. Die Option mit dem ZFS Scrubben habe ich gefunden aber noch nicht getestet. Es läuft. Danke nman

hustbaer

Wie tut denn das Ding (ProLiant MicroServer) von der Lautstärke her?