RAID5 zerschossen - was kann ich noch tun?

    Hallo liebe QNAP Experten!


    Habe ein unschönes Problem.

    Vor zwei Wochen QNAP Shares nicht mehr erreichbar - Einzige Warnung - SSD Cache Modul Problem - SMART Attribut unter Schwellenwert.

    Cache war im Read-Only Modus. Ließ sich aber weder ausschalten/deaktivieren noch löschen.


    QNAP runter gefahren, Cache SSDs ausgebaut. Hochgefahren, Filesystem Check nicht möglich:

    Code
    System 127.0.0.1 Storage & Snapshots Volume [Storage & Snapshots] Failed to check file system. Storage pool: 1.


    Ticket bei QNAP aufgemacht, bisher nur weitere Fragen aber noch keine Lösungsansätze. Remote Support nicht möglich, wahrscheinlich eine der Firmenfirewalls.

    Auf Anfrage vom QNAP Support die defekten SSD Cache Module wieder eingebaut (diesmal aber anders rum, SSD1 ist nun das defekte, SSD2 noch i.O.)


    Stand jetzt:




    Code
    /mnt/HDA_ROOT/.logs$ cat /etc/config/raidtab

***LEER****



    Code
    /mnt/HDA_ROOT/.logs$ fdisk -l /dev/md2
Disk /dev/md2 doesn't contain a valid partition table

Disk /dev/md2: 229784.6 GB, 229784689311744 bytes
2 heads, 4 sectors/track, -1 cylinders
Units = cylinders of 8 * 512 = 4096 bytes



    Die Daten haben natürlich kein Backup - die QNAP ist der Backup. :rolleyes:

    Zustand aktuell - alle RAID Festplatten zeigen "Grün" - Speicher ist "Entladen", ein Mounten oder Prüfen des Dateisystems ist nicht möglich - alles wird mit einem Fehler quittiert.


    Hoffe auf eine Hilfestellung hier im Forum.


    Gruß,

    Andy

    Wenn QNAP das (der) Backup ist, dann liegen die Daten doch noch im Original woanders?

    In diesem Fall würde ich das System neu initialisieren und von vorne anfangen.

    Die SSD Cache haben jetzt schön öfters solche Probleme verursacht, ich persönlich habe keinen Cache im NAS und würde ich aufgrund der Meldungen hier auch nicht nehmen.


    Gruss

    SSD Cache halte ich für ein Backupsystem auch nicht unbedingt als erforderlich...

    Wenn es aber ein versioniertes Backup ist, wäre neu anfangen schon etwas doof, zumindest wäre die Versionierung dann futsch...

    FSC830 - Danke, aber die OriginalDaten werden monatlich gelöscht um Speicher freizugeben, somit ist die QNAP Backup und Original in einem - nicht meine Entscheidung.


    tiermutter - auf der QNAP liegen hauptsächlich TIFF, BMP und PNG Bilder. Die QNAP wurde über freigegeben Shares von Windows aus benutzt. Da ist keine Versionierung oder ähnliches, nur tausende von Prozess-Bildern.

    Das ist die Quadratur des Kreises! Backup und Original in einem ist nicht möglich!
    Jedenfalls aus IT Sicht! Aus "Geiz"sicht sicherlich, aber dabei kommt so etwas heraus!

    Und wenn ich sehe: Cache (auch wenn es nur lese Cache ist) im Raid0 und 24 HDDs im Raid5, das ist für mich absolut unverständlich.

    Bei einer solchen Raidgröße mind. Raid6, besser in mehrere, kleinere Raids die Daten verteilen.

    Und dann als Sahnehäubchen die Daten periodisch löschen ohne externes Backup... der GAU war vorprogrammiert!


    Wenn der Support keine zündende Idee hat... :/


    Gruss

    FSC830 - Danke und ich stimme dir vollkommen zu, das Konzept ist falsch. Und trotzdem bin ich im Moment in der Situation in der ich versuche den Prozessleuten ihre Daten wieder zugänglich zu machen.

    Solange das RAID an sich noch vorhanden und unverändert ist, sollte es doch möglich sein die Partitionstabelle zu erstellen und das Raid zu mounten, oder bin ich da zu blauäugig?


    Wäre das manuelle aufsetzen der Raidtabelle vielleicht ein Anfang?
    Re: Raid 5 macht Ärger

    Ich weiß nicht, was im Cache noch alles für Meta(?) Daten liegen.

    Das Raid5 ist "Online", aber das Volume nicht zugreifbar. Der Cache selbst Offline, was bei einer defekten SSD im Raid0 alleine schon ein Problem darstellt (Raid 0 -> Ausfall eines Mediums -> Daten weg).

    Mit welchen Tricks und Spielereien man das Volume mounten könnte ist mir so nicht bekannt, dann ist da auch noch die LVM Ebene, die die entsprechenden Metadaten haben muss.


    Damit habe ich mich bisher nicht befasst, ein einfaches init_lvm dürfte hier aber nicht ausreichen oder aber eher kontraproduktiv sein.

    Daher würde ich tatsächlich auf den Support warten, der leider nicht für seine schnellen Bearbeitungszeiten bekannt ist. :(


    Gruss

    FSC830 - Dankeschön, das hört sich logisch an. Ich hatte eigentlich gehofft, dass das Cache nur Performancerelevant aber nicht Datenrelevant wäre. Anscheinend ist das aber nicht unbedingt gewährleistet.

    laut Doku ist eine Platte, für die ein SSD Cache aktiviert ist, ohne ihn NICHT zugreifbar.

    Zum Abschalten des Cache muß er IMHO vorhanden sein, also kannst du ihn auch nicht abschalten.


    Es mag ziemlich schitzo klingen, aber nach meiner (kurzen) Erfahrung mit SSD Cache


    <Ratemodus: an>

    wirst Du wohl die kaputte M2 ersetzen müssen.

    Dann sollte auch das Raid wieder da sein, und DANN kannst du den Cache auch wieder abschalten (rofl).

    <Ratemodus: aus>

    Synopsis - Danke, aber wie FSC830 schon anmerkte - RAID 0 - ein Datenträger weg = Datenverlust.


    Eben zwei neue mSata SSDs eingebaut. Wollte das Cache wieder aufsetzen in der Hoffnung "Cache wieder da = QNAP wieder da". Doch beim letzten Schritt der Einrichtung des Cache kommt die Meldung: ... das Entfernen einer Read-Only Cache SSD auch im ausgeschalteten Zustand der NAS führt zu Datenverlust. Na toll...


    Die beiden original SSDs sind wieder drin. Warte auf QNAP Support ob die noch eine Idee haben. Wie schon geschrieben. Das Cache konnte ich nicht deaktivieren, was aber zwingen erforderlich ist um die Cache SSDs ohne Datenverlust auszubauen.

    Raid0 ist ausschließlich zum schnell machen. Das hat mit Sicherheit nichts zu tun ... im Gegenteil: dein Volume hat ab sofort die doppelte Ausfallwahrscheinlichkeit, weil es zum Datenverlust ausreicht, wenn >eine von zwei< Platten das Handtuch wirft.


    Was willst Du mit Raid0? der limitierende Faktor ist sicherlich das Netzwerk ... oder Du hast nen Fiberanschluß.


    Entweder volle Kapazität (nicht gut) oder Raid1.

    Zitat von Synopsis

    Was willst Du mit Raid0?

    Es geht um die beiden eingebauten Cache Module - die liefen im RAID 0. Hab ich nicht aufgesetzt, nur übernommen. Die Datenfestplatten sind im RAID 5, was wohl auch nicht optimal bei der Größe ist.



    Habe noch online Forumbeiträge gefunden, wo es bei Benutzern doch möglich gewesen wäre ohne das Cache das RAID zu mounten.

    Wenn die Unterstützung vom QNAP-Support so weiter läuft, dann wird das sowieso nichts.


    Nochmal meine Frage, ist es wirklich sehr Risikobehaftet nach dem Schema von hier:Re: Raid 5 macht Ärger

    das Raid zu mounten zu versuchen?


    Ich kann doch vorher noch einiges von den QNAP Konfigs wegspeichern.


    Das RAID sieht doch gut aus.


    Doch die /mnt/HDA_ROOT/.conf verweist noch auf den Cache:


    Ebenso die /etc/volume.conf


    Zitat von AndySchonVergeben

    Nochmal meine Frage, ist es wirklich sehr Risikobehaftet nach dem Schema von hier:Re: Raid 5 macht Ärger

    das Raid zu mounten zu versuchen?

    Wenn du irgendwann an deine Daten nochmal rankommen möchtest - ja.

    Du hast nunmal kein legacy RAID sondern ein LVM2/DRBD - verwaltetes Volume.

    Zitat von binam

    Wusste garnicht, dass das geht...

    Das ging mal, geht (auf diese Weise) aber nicht mehr...

    Zitat von QNAP Software-Specs (RAID Group // alle Modelle)

    To ensure data security, system stability, and storage performance, the maximum number of drives for a single RAID group is now 16 (applicable to RAID 5, RAID 6, RAID TP, and subgroups of RAID 50 and RAID 60). Nevertheless, users can combine multiple RAID groups into a large storage pool that contains more than 16 drives, using RAID 50, RAID 60, or RAID 10 as the RAID configuration. This enhancement will only be applied to new RAID groups. All existing RAID groups and storage systems will not be affected.



    Edit: Hier nochmal aus den FAQ https://www.qnap.com/en/how-to…-number-of-hdds-in-a-raid

    Ein RAID5 mit 24 Laufwerken widerspricht auch jedweder best practise. Selbst ein RAID5 mit 16 Laufwerken, wird man, wenn man darüber nachdenkt nicht wirklich machen.

    Lieber macht man mehrere RAIDs und fügt sie zu RAID-Gruppen zusammen.

    Kurzes Update:

    QNAP support hat mir eine Anleitung geschickt und, juhu, komme zumindest wieder an die Daten.

    Folgende Aktionen waren notwendig:


    Die Poolkonfig musste geändert werden, damit das (defekte) Cache nicht mehr angesprochen wird:

    cd /dev/mapper

    Edit vg1


    1. vg1 cacheversion auf 2 setzen
      tags = ["PV:DRBD", "snap_reserved:10", "cacheVersion:2"]


    2. tp1_tierdata_2 bearbeiten um das Cachemapping rauszunehmen - exakt folgender Bereich wurde gelöscht:


    Speichern.


    Dann Poolheader neu setzen:

    vgcfgrestore vg1 -f vg1.lvm --force

    Online stellen:
    lvchange -ay vg1

    Und mounten wobei {ID} aus dem Mapperverzeichnis ausgelesen wurde, bei mir war es dann die 2 => vg1-lv2:
    # mount -t ext4 /dev/mapper/vg1-lv{ID} /mnt/test -o ro,noload


    Danach sollte der folgende Befehl das Pool noch automounten, doch das hat dann nicht geklappt. Aber zumindest komme ich über das manuelle Mount an die Daten. Den --volume_scan habe ich noch nicht probiert, warte noch auf eine Rückmeldung vom Support.

    Code
    3) Last step, using --sys_startup_p2 to bring volumes online
# storage_util --sys_startup_p2

NOTE:
if volume isn't mounted yet, you could issue below command instead
# storage_util --volume_scan do_scan_raid=0,force=1