Data Scrubbing bald nativ über Webinterface unterstützt

  • An die Moderatoren: Ich wusste nicht genau in welches Thema dieser Post passt, sodass ich Backup gewählt habe,
    weil es für mich der Thematik am ehesten entspricht.


    Guten Morgen,


    da ich mich derzeit um eine NAS-Lösung kümmere habe ich mich auch mit dem Phänomen der "silent data corruption" beschäftigt.
    http://en.wikipedia.org/wiki/Data_corruption


    Bisher konnte man einen Data scrub nur per Kommandozeile ausführen bzw. automatisch per cron-Trigger.
    http://www.vestergaard.it/cms/…-sanitizeraidonqnapts419p


    Bei meinen Recherchen bin ich mit QNAP selbst in Kontakt getreten und mir wurde mitgeteilt,
    dass wohl ab QTS 4.2.2 ein data scrubbing über das Webinterface möglich sein soll. Dies aber nur bei den QNAPS,
    ab Intel CPU. Welche QNAPs genau diesen Feature erhalten sollen und ,ob insbesondere der 453 Pro, konnte mir nicht gesagt werden,
    weil keine Produktdetails vorliegen, oder QNAP sich noch ausschweigt.


    Viele Grüße


    BanneJim

  • Fast 1 Jahr vergangen und weiterhin kein Scrubbing möglich. An anderer Stelle ist zu lesen dass es nun für QTS 4.3 vorgesehen wäre angeblich...


    Wirklich unglaublich wie lang QNAP für solch absolute elementare Grundfunktionen sich Zeit lässt.

  • Eine "Dateibereinigung" kann ja wohl kein Scrubbing sein. Denn die hat absolut gar nichts mit Dateien zu tun sondern arbeitet auf dem mdraid Volume Sektorbasiert.
    In einer Diskussion zu QTS 4.3 Beta habe ich gefunden dass es evtl. ein "Speichermanager - Volume - Verwalten - Datenbereinigung Starten" geben soll. Vielleicht meinst du ja eine Datenbereinigung und keine Dateibereinigung?


    Davon ist aber nichts zu sehen am QNAP TS-659 Pro+ mit QTS 4.2.2 build 20160901 - siehe zwei angehängte Screenshots.

  • "Speichermanager - Volume - Verwalten - Datenbereinigung Starten"

    Genau das gibt es schon.
    Datenbereinigung.jpg
    Allerdings nicht für die nicht-SMB-NAS. Und mach dir keine Illusionen - für die nicht-SMB-NAS wurde schon vor langer Zeit angekündigt, dass die 4.2 das letzte Masterrelease ist. Es wird für die TS-659 Pro+ also sehr wahrscheinlich keine 4.3 mehr geben. Näheres müsste @christian in Erfahrung bringen können.


    Eine "Dateibereinigung" kann ja wohl kein Scrubbing sein.

    Du hast dich wahrscheinlich in deinem Leben noch nie vertippt. :thumbup:

  • Ich saß eben etwas erstaunt auf meiner Couch weil sich plötzlich das QNAP akustisch bemerkbar machte...


    Ich habe dann, da ich was davon in den ChangeLogs zur 4.3.3 gelesen hatte, gleich die Vermutung auf das Scrubbing gehabt. ( was hast Du geändert... ;) )
    Ich hatte es gerade erst letzte Woche oder so aktiviert...


    Unbenannt.JPG


    Wo ich aber jetzt stutzig geworden bin, das Piepen...
    Und siehe da...


    Unbenannt1.JPG


    Macht der jetzt jedes mal eine Resynchronisierung?
    Wahrscheinlich, oder? Um das Raid wieder komplett abzugleichen...


    Das würde aber auch zeigen, das dies sauber aufgebaut ist.
    Daten-Analyse, Qualitätsprüfung, korrupte Daten aussortieren und schlussendlich muss das RAID neu synchronisiert werden...
    Welchen Sinn würde sonst die Resynchronisierung machen...

  • RAID Bitmap ist nur für schnelleren RAID rebuild, ich hatte vergessen das f** manual zu lesen ;)
    Auch wenn ich in meiner laienhaft Annahme davon ausgehe, dass dieses Bit auch dazu verwendet werden könnte, Data corruption zu erkennen.

  • Moin zusammen,


    wie lange dauert denn so ein "Data Scrubbing"-Durchlauf?
    Klar, das ist abhängig von der Datenmenge auf dem NAS, aber gibt es schon irgendwelche Erfahrungswerte?


    Grüße,
    Christian

  • Kann einmal jemand bitte in verständlichen Worten schreiben, was dieses Data scrubbing genau macht. Aus den bisherigen Beschreibungen bin ich nicht so ganz schlau geworden. Danke!


    Zu der Frage der Zeit:


    Code
    Typ	Datum	Uhrzeit	Benutzer	Quellen-IP	Computername	Inhalt	
    Informationen	11.06.2017	09:41:42	System	127.0.0.1	localhost	[Pool 1] Resyncing done with RAID Group 1.	
    Informationen	11.06.2017	00:00:01	System	127.0.0.1	localhost	[Pool 1] Started resyncing with RAID Group 1.	
    Informationen	11.06.2017	00:00:00	System	127.0.0.1	localhost	[Pool 1] Started data scrubbing for RAID Group 1.

    Das Data Scrubbing dauert also 1 Sekunde bei einem 4x4TB Raid 5. Das resyncing dauert dann 9 Stunden 42 Minuten.
    Ist das jetzt jede Woche so?

  • Daten-Analyse, Qualitätsprüfung, korrupte Daten aussortieren und schlussendlich muss das RAID neu synchronisiert werden...

    Eigentlich das... In Kurzform...


    Bei Dir war das eine Sekunde, bei mir waren es gut 18...
    Bei meinem RAID5 mit eben den selben 4x4TB WD Red...


    Das Resync ist eigentlich das zeitintensive... Bei mir waren es ja ca. 10.30h


    Beim Resync spielt sicher auch ne Rolle wie schnell sich die FP drehen, wieviel Cache die Platten haben und wie schnell der ist. Und halt wie groß das RAID ist...
    Ich habe nicht den gesamten Platz freigegeben. Von den theoretisch 12TB habe ich gut 6TB dem RAID zugewiesen.

  • [...] Das Resync ist eigentlich das zeitintensive... Bei mir waren es ja ca. 10.30h [...]

    Alles klaro, ist für größere RAIDs also nicht geeignet. Wenn jedes Mal das gesamte RAID neu resynct werden muss, dann macht das bei meinen beiden QNAPs keinen Sinn.
    Wozu soll ein regelmäßiges Resync des RAIDs eigentlich gut sein? Bei mir dauert das 3 Tage...

  • Alles klaro, ist für größere RAIDs also nicht geeignet.

    Naja, nicht geeignet würde ich mal nicht sagen...
    Eher notwendig wenn man Wert auf saubere Daten legt.
    Geht halt einher mit Datensicherheit und Datenqualität...


    Es kommt ja in den besten Häusern vor, das mal, und mit Häusern meine ich jetzt Festplattenmodelle oder Hersteller, Bereiche einer Festplatte physikalisch oder durch fehlerhafte Schreibvorgänge oder was weiß ich, beschädigt werden.
    Auf "normalen" Festplatten werden dann sinnvollerweise Dinge wie CheckDisk, o.ä. genutzt um nach Möglichkeit Daten die durch die Beschädigung korrupt geworden sind, wiederherzustellen oder zumindest einen Teil davon zu retten und dann diese Sektoren/Bereiche als defekt zu markieren und auf ReserveSektoren zuzugreifen.


    In einem RAID stecken die Daten ja nicht nur in verschiedenen Bereichen oder Sektoren einer Festplatte sondern sogar in verschiedenen Bereichen und Sektoren verschiedener Festplatten. Es kommt dabei zu einer Verteilung der Daten bzw. eben ab dem RAID 5 zu einer Anlage von Prüfbytes richtigerweise heißen die hier Paritätsbytes.


    Diese Parität-Bytes kommen zwar schon ab einem RAID3 zum Einsatz, aber erst ab einem RAID5 werden die auch auf allen (min. 4 FP) Festplatten verteilt.
    Jetzt kommt das Daten-"Schrubben" zum Einsatz...


    Dabei wird u.U. festgestellt, das auf Platte x korrupte Daten vorhanden sind. Diese werden u.U. über die verteilten Paritätsbytes, die die Wiederherstellungsinformationen beinhalten, wieder hergestellt.
    Damit diese wiederhergstellten oder reparierten Daten dann auch wieder mit den richtigen Informationen in die verteilten Paritätsbytes geschrieben werden ist eine Resynchronisierung eigentlich zwingend notwendig.


    Ich hoffe ich konnte das jetzt so einfach wie möglich beschreiben... ;)

  • Ich hoffe ich konnte das jetzt so einfach wie möglich beschreiben...

    Ja, jetzt habe ich es besser verstanden. Danke!


    Aber warum dauert dann das Scrubbing nur 1 Sekunde und das Resync 9 Stunden. Oder wird hier als Scrubbing nur die Aktion gesehen ein Resync mit komplettem Test anzustoßen?

  • Beim Scrubbing wird nur geschaut, welche Datenblöcke als event. defekt markiert wurden, nicht mehr benötigte Daten gelöscht und dann die Infos in die Paritätbytes geschrieben.
    Deshalb waren das bei Dir nur eine Sekunde. Scheinbar war bei mir mehr kaputt, da mein System dafür 18 sec brauchte.
    Bei Dir war vermutlich nicht so viel kaputt.
    Und das ganze läuft relativ schnell ab.


    Das Resync hat nichts mehr mit einem Test zu tun. Dabei werden die Daten nur wieder auf allen Festplatten erneut abgeglichen. Dabei erfolgen die eigentlichen Schreib- und Lesezugriffe.


    Die Paritätbytes musst Du Dir in etwa wie ein (erweitertes) Inhaltsverzeichnis vorstellen.
    Das hat man schnell zusammengeschrieben, da wird nur festgehalten das auf Seite 1 der Buchstabe A und B steht und auf Seite 2 C und D usw...
    Wenn nun aber der Autor die ganzen Seiten neu schreiben muss, das dauert lange...
    Das Inhaltsverzeichnis... pfff...


    Wie gesagt, für die Spezis hier, mich nicht wörtlich nehmen. Ich versuche es nur bildlich zu erklären... ;)


  • Beim Resync spielt sicher auch ne Rolle wie schnell sich die FP drehen, wieviel Cache die Platten haben und wie schnell der ist.

    Selbstverständlich ist bei einem Raid Resync die Größe und die Geschwindigkeit des Caches völlig irrelevant, da hier Daten sequentiell gelesen werden.
    Die Geschwindigkeit des Caches ist sowieso IMMER irrelevant da jeglicher Ram Cache IMMER schneller sein wird als ein SATA oder SAS Interface.


    Die Drehzahl der Festplatte ist auch nicht sonderlich relevant, denn es zählt ausschließlich der Datendurchsatz = Drehzahl * Datendichte.
    Der Durchsatz KANN bei einer höheren Drehzahl auch höher sein, muss aber nicht (es könnte z.B. nötig sein die Datendichte zu reduzieren damit der Kopf auch bei erhöhter Drehzahl es noch schafft die Daten zu lesen).

    Auf "normalen" Festplatten werden dann sinnvollerweise Dinge wie CheckDisk, o.ä. genutzt um nach Möglichkeit Daten die durch die Beschädigung korrupt geworden sind, wiederherzustellen oder zumindest einen Teil davon zu retten und dann diese Sektoren/Bereiche als defekt zu markieren und auf ReserveSektoren zuzugreifen.

    chkdsk macht dies im Normalfall nie. chkdsk repariert Inkonsistenzen im Dateisystem (üblicherweise entstanden durch Abstürze oder Stromausfall), und kümmert sich nicht um Hardware Probleme der Festplatte.


    Beim Scrubbing wird nur geschaut, welche Datenblöcke als event. defekt markiert wurden, nicht mehr benötigte Daten gelöscht und dann die Infos in die Paritätbytes geschrieben.
    Das Resync hat nichts mehr mit einem Test zu tun.

    Unter Scubbing versteht man normalerweise einen Resync. Wieso im QNAP log hier zwei verschiedene Begriffe auftreten ist seltsam.