Beiträge von Sonnabend

    Das Problem liegt daran, das wohl die Inhalte der Symlinks nicht mit gesichert werden. Das mag bei den Netzwerk-Papierkörben ja noch OK sein, aber für die Inhalte der Webseiten, etc. unter /Web/ ist das nicht so toll.


    z.B. Dokuwiki /Web/dokuwiki/ liegt aber unter: /share/CACHEDEV1_DATA/.qpkg/DokuWiki/web/


    Das löst dann nur eine Fehlermeldung im Protokoll aus, das die Sicherung der Symlinks nicht möglich ist.


    Oder mache ich das was generell falsch?

    Hallo,


    nachdem ich kürzlich ein RAID5 verloren hatte bin ich gerade dabei die Sicherung zu überprüfen, bzw. zu überarbeiten.


    Ich habe bei QTS 4.1 bereits erfolglos versucht die Dateien unter /Web/* mit den eingebauten Möglichkeiten zu sichern. Genau die sind mir jetzt aber beim Crash verloren gegangen. Ich habe das immer mal per Hand gemacht, aber das muss ich jetzt täglich automatisieren.


    Ein Versuch die Daten auf eine externe USB-Platte zu übertragen scheint mit dem Sicherungsmanager nicht zu gehen, egal ob die Platte mit NTFS oder EXT4 formatiert ist.


    Gibt es dafür eine andere Lösung?



    Gruß Joachim

    Wenn ich den Post richtig lese, sind noch die 1 TB Platten drinnen. Dann kann man auch nicht erweitern, zuerst müssen ja die 3 TB Platten rein.


    Also ich würde zuerst die Spare Platte aus der Konfiguration nehmen. Dann erste Platte durch 3 TB ersetzen, und warten bis das RAID1 wieder aktiv ist. Dann die 2. Platte ersetzen und wieder warten. Danach sollte die Option mit der Kapazitätserweiterung funktionieren.

    Nein, die pysischen Platten 2,3,4 waren ja immer drinnen.


    Nach dem ersten Wechel der Disk 1 von 3TB auf 4TB, war das auch noch die sda. Die neue 4TB hatte dann ja plötzlich die Bad Blocks. Zu dem Zeitpunkt war Disk 1 auch noch sda.
    Nachdem ich diese aber durch eine andere neue 4TB ersetzt hatte, und neu gestartet hatte war diese Platte plötzlich sdb, und die physische Disk 2 war dann sda. Nur sdc blieb die ganze Zeit konstant.


    Aber egal, ich habe das jetzt an dem Punkt aufgegeben, da ich das System wieder brauche. Ich habe die verbliebenen 2 Platten beschriftet und beiseite gelegt.
    Ich initialisiere gerade das NAS neu mit 3*4 TB im RAID5.

    Tja, genau das ist das kuriose an der Geschichte.

    Die Platte 2 hat keine fehlerhaften Sektoren. Ein vollständiger Scan brachte keinen Fehler und die SMART Werte sind alle in Ordnung, das sagt die NAS nach dem Scan ja auch und der PC mit dem ich das gegengeprüft habe auch. Ich habe ein vollständiges Image der Platte gemacht, keine Lesefehler, keine getauschten Sektoren, nix.


    Irgend etwas ist aber durch den Defekt der neuen ersten Platte passiert, denn aus welchem Grund auch immer ist die alte Reihenfolge


    Disk1 = sda
    Disk2 = sdb
    Disk3 = sdc


    jetzt


    Disk1 = sdb
    Disk2 = sda
    Disk3 = sdc


    Schlechter als jetzt kann der Zustand ja nicht mehr werden, ich werde gleich mal versuchen das md1 per Hand mit mdadm --create neu zu erstellen, da müsste es Optionen geben bei dem die Platten nicht überschrieben werden. Ich suche mir das mal zusammen.


    --- ModEdit ----


    So, ich bin einen kleinen Schritt weiter ... :)


    Ich habe mal die 4. Platte mit dem SingleVolume sauber gelöscht und aus der NAS entnommen. Ebenfalls entnommen habe ich 1. Platte, die ja zum wiederaufbau des Raid5 bestimmt war. Also sind jetzt nur noch die zwei Platten im System, die ein Teil des alten RAID5 sind.


    Ein Neustart brachte keine Veränderung, wäre ja auch zu schön gewesen. Aber das mauelle starten des RAID schien dann doch zu gehen:


    Code
    [~] # mdadm --assemble /dev/md1 /dev/sda3 /dev/sdb3mdadm: failed to get exclusive lock on mapfile - continue anyway...mdadm: /dev/md1 has been started with 2 drives (out of 3).[~] # cat /proc/mdstatPersonalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]md1 : active raid5 sda3[0] sdb3[1]      5840622592 blocks super 1.0 level 5, 512k chunk, algorithm 2 [3/2] [UU_]      bitmap: 0/22 pages [0KB], 65536KB chunkmd256 : active raid1 sdb2[1] sda2[0]      530112 blocks super 1.0 [2/2] [UU]      bitmap: 0/1 pages [0KB], 65536KB chunkmd13 : active raid1 sda4[1] sdb4[2]      458880 blocks super 1.0 [24/2] [_UU_____________________]      bitmap: 1/1 pages [4KB], 65536KB chunkmd9 : active raid1 sda1[1] sdb1[2]      530048 blocks super 1.0 [24/2] [_UU_____________________]      bitmap: 1/1 pages [4KB], 65536KB chunkunused devices: <none>[~] #


    In der GUI sehe ich jetzt schon meine beiden LVM Volumes, auch mit der richtigen Belegung, aber sie starten nicht.
    Mal sehen ob das noch irgendwie zu kitten ist.





    --- ModEdit ---


    OK, das war es. Das RAID5 ist zwar als md1 wieder da, aber was da drinnen steht (mit dd geschaut) ist nicht annähernd so wie es sein soll.


    Damit sind die LVM verloren denke ich mal, und damit die Daten.


    Code
    [~] # vgscan
      Reading all physical volumes.  This may take a while...
      No volume groups found
    [~] #


    Also nachher ein frisches RAID5 mit frischen Platten aufsetzen. Danke fürs helfen, dr_mike.

    OK, dann hier das Log, beginnend kurz vor dem dem ersten Plattenwechsel bis eben.



    Vielen Dank für die Antwort.


    Mit Systemprotokoll meinst Du das Systemereignissprotokoll im Web-Interface, oder ein anderes?



    Hallo Gemeinde,


    ich habe nach einem Plattenwechsel ein kurioses Problem mit der QNAP und meinem RAID5. Eigentlich sind da noch ein paar Daten drauf, die ich gerne wieder hätte, daher der Versuch das RAID5 wieder zu mounten. Vielleicht kann mir ja jemand helfen.


    Konfiguration:
    Gerät: QNAP TS-453pro
    OS: QTS 4.2.0 - build 1118
    HDD: 4 * 3 TB WD30ERFX
    RAID5: Disks 1,2,3 (Zwei Volumes je ca. 2,7 TB)
    SingleDisk: Disk 4 (Ein Volume ca. 2,7 TB)


    Was passiert ist:
    Da das RAID5 schon ziemlich voll war (> 85%) wollte ich die 3TB Festplatten durch 4TB Festplatten ersetzen. Das habe ich in diversen Varianten schon ein paar mal gemacht, bisher ohne Probleme.
    Ich habe dann die 3TB Disk im Schacht 1 gezogen, gewartet bis das Raid als Zurückgestuft angezeigt wurde, dann die neue 4 TB Disk rein und gewartet bis die Wiederherstellung anlief. Soweit alles nach Plan. Am nächsten Tag (hat ja alles etwas gedauert) war das dann fertig. Der Zugriff auf das Raid war auch OK, ein Backup von DataVol1 lief auch durch. (DataVol2 wäre schön, aber nicht Lebenswichtig).


    Ich wollte gerade die 2. Platte ziehen, da ist mir aufgefallen das die 1. Platte "rot" war. Also zurück ins Web-Interface und nachgesehen, da steht die neue 4TB auf "Anormal". Ich habe dann noch einen Plattentest und einen Scan angeworfen und da tauchten dann Bad Blocks auf.
    An diesem Punkt wird es spannend.... Da die GUI nicht mehr reagiert habe, habe ich über QFinder die 453pro neu gestartet, bzw. wollte das machen. Runter gefahren ist das ganze nach einer gefühlten Ewigkeit, aber neu booten ging nicht mehr.
    OK, also ausschalten, Festplatten raus, einschalten.... nix. Reset-Taster betätigt, keine Beeps.... Tilt.
    Nun habe ich Foren gewältzt und das Support Wiki, dort habe ich die Anleitung gefunden um die Firmware wieder herzustellen. Nach ein paar Anläufen mit kleinen Problemen hat es dann geklappt, die 453pro war via Web-Interface wieder zu erreichen. Somat habe ich den Zustand wieder, wie oben.


    Kein Zugriff auf das RAID5, die SingleDisk läuft ohne Probleme. Mittlerweile habe ich eine andere leere 4TB Platte in Schacht 1 eingesetzt, aber über das Web-Interface kann man das RAID5 nicht wiederbeleben. So sieht das aktuell aus:




    Ich habe dann verschiedene Versuche auf der Shell durchgeführt, die aber irgendwie alle nicht dazu führen das RAID5 für ein kurzes Backup zu reaktivieren. Ja, ich hätte gerne ein paar Dateien, die nicht gesichert wurden aus dem /Web Verzeichnis :x


    Wie man sieht fehlt das MD1 Raid

    Code
    [~] # cat /proc/mdstatPersonalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]md2 : active raid1 sdd3[0]      2920311616 blocks super 1.0 [1/1] [U]md256 : active raid1 sdd2[3](S) sdc2[2](S) sda2[1] sdb2[0]      530112 blocks super 1.0 [2/2] [UU]      bitmap: 1/1 pages [4KB], 65536KB chunkmd13 : active raid1 sdb4[24] sdd4[25] sdc4[2] sda4[1]      458880 blocks super 1.0 [24/4] [UUUU____________________]      bitmap: 1/1 pages [4KB], 65536KB chunkmd9 : active raid1 sdb1[25] sdd1[24] sdc1[2] sda1[1]      530048 blocks super 1.0 [24/4] [UUUU____________________]      bitmap: 1/1 pages [4KB], 65536KB chunkunused devices: <none>


    Aber ein Scan zeigt es schon noch:

    Code
    [~] # mdadm --examine --scanARRAY /dev/md/2  metadata=1.0 UUID=30bf7fb6:f430cc75:527311a2:830e4942 name=2ARRAY /dev/md/321  metadata=1.0 UUID=2b2a3d67:e961f0e1:da2766e9:bee38ff4 name=321ARRAY /dev/md/9  metadata=1.0 UUID=4140f2ac:e246fc5c:0a6705b4:c5761c9f name=9ARRAY /dev/md/256  metadata=1.0 UUID=383f3add:4c1cce43:65233f08:4327e671 name=256   spares=2ARRAY /dev/md/1  metadata=1.0 UUID=0bba8f98:33e50222:00494ea9:c95c0bbe name=1ARRAY /dev/md/13  metadata=1.0 UUID=352d4294:27dc97ea:85e3762c:f69e09c5 name=13ARRAY /dev/md/321  metadata=1.0 UUID=e3eeecb6:4e9dc77b:aed3078f:d67f06e1 name=321


    Manuelles hinzufügen scheitert, vermutlich daran das die neue Platte noch nicht aufgebaut ist:
    (Warum die 1. Platte auch immer sdb3 ist, die 2. Platte sda3 und die 3.Platte sdc3)

    Code
    [~] #  mdadm -A /dev/md1 /dev/sd[a-c]3
    mdadm: no RAID superblock on /dev/sdb3
    mdadm: /dev/sdb3 has no superblock - assembly aborted


    Wie bekomme ich das denn jetzt wieder zusammen gestartet?


    An mdadm --create habe ich auch schon gedacht, sollte ja eigentlich auch nichts passieren, oder? An dem Punkt brauche ich aber dann mal einen Rat wie ich das anstelle. Ein RAID5 sollte ich doch auch starten können mit 2 Disks, zumindest read-only sollte das doch gehen, oder?


    Grüße aus Südhessen
    Jochen