Beiträge von tychen

    Hallo zusammen,


    bei einer etwas größeren Backupaktion von Daten auf eine externe Festplatte kam es anscheinend vor 3 Wochen dazu, dass der interne Speicher in meiner TS-569L ausging und die Shares nicht mehr beschrieben werden konnten, weil nur noch read-only.

    Habe die NAS dann neu gestartet und dachte bis heute, dass alles wieder funktioniert.


    Per Zufall habe ich herausgefunden, dass die internen NAS to NAS Backups (auf die gleiche QNAP) nicht mehr gelaufen sind (hatte Jahrelang super funktioniert).


    Startet man Sicherungsmanager eines der Backups manuell kommt nach ein paar Sekunden die Fehlermeldung, dass das Backup nicht funktioniert hat. In der Übersicht klickt man auf "Suchen sie im Log nach Einzelheiten" und bekommt die Fehlermeldung

    Code
    "Rsync-Protokoll: @ERROR: Unknown module 'Backup1'". 

    Backup1 ist das Volume, das ich für die Backups nutze.


    In den Ereignisbenachrichtigungen steht:

    Code
    "[Remote Replication] (Sync) Audio failed: The destination folder path does not exist."

    Versucht man einen neuen NAS to NAS-Replikationsauftrag anzulegen füllt man zuerst die Einstellungen für den externen Ort aus (localhost, Port 873, etc) und drückt auf "Remote-Host-Test" kommt erst "Erfolg" und dann "Verarbeitung ..." was aber nicht beendet wird.


    netstat sagt, dass die Nas auf den Port 873 hört. Die Volumes sind auch da, da ich über nfs und CIFS darauf zugereifen und sichern kann.


    Leider bin ich etwas ratlos, zudem ein zweimaliger Neustart auch keine Abhilfe verschafft hat.


    Hat jemand noch ne Idee? Wo finde ggf. Logfiles? Unter /var/log hab ich nix brauchbares gefunden.


    VG, Rainer

    Moin,


    nein, ist nicht die einzige Platte. Geht um Speicherpool 2, siehe Screenshot.

    qnap01.png


    Wenn ich das richtig sehe, gibt es eine 4.4.1 für die Box.
    Ich meine allerdings irgendwann gelesen zu haben, dass ab 4.3. die Lizenz für den TwonkyMedia nicht mehr gültig ist, welchen ich unter 4.2. noch nutze.


    Grüße, Rainer

    Hi zusammen,


    im Vorfeld ne Frage zum Forum: Gibt's eigentlich sowas wie ne FAQ hier?

    Nun zum Thema: Ich möchte eine Single Disk durch eine größere ersetzen. Die darauf befindlichen Daten sind nochmal an anderer Stelle gesichert.

    Welche Schritte müssen ausgeführt werden?


    Erst innerhalb des Storage Pools den Share löschen?

    Dann sehe ich Im Storage Pool Management zwei Optionen:

    • Remove Pool
    • Safely detach pool

    Leider wird das im mir vorliegenden User Manual auf den 700 Seiten nicht beschrieben, was genau "Safely detach Pool" macht.


    Falls jemand Muse hat und mir die notwendigen Schritte aufschreiben könnte wäre ich echt dankbar.
    Nach Anleitunge habe ich schon gesucht, aber zumeist nur welche für Raids gefunden.


    Ist eine TS-569L mit 4.2.2


    Grüße, Rainer

    Tach zusammen,


    habe einen Share namens Images, auf dem ich heute mal ein bisschen aufgeräumt habe.

    Der frei gewordene Platz könnte so ca. 150 GB sein.

    Allerdings wird mir das bei df nicht angezeigt. Laut du sind 142 GB belegt, der Papierkorb sollte leer sein, aber df zeigt mir 332 GB in Benutzung.

    Any ideas?

    Hi zusammen,


    wir haben vor einigen Wochen eine TS-563 in Betrieb genommen. Läuft auch alles prima mit Ausnahme einer Sache:

    Nach einigen Firmwarupdates habe ich festgestellt, dass in der GUI unter Systemsteuerung -> Netzwerk- und Dateiservices das Fenster "Netzwerk- und virtueller Switch" zwar aufgerufen werden kann, aber keine Inhalte angezeigt werden (siehe Anhang). Eigentlich sollten doch hier z.B. IP-Adresse, Nameserver, etc. konfiguriert werden können, oder?


    Haben noch zwei weitere FW-Updates probiert, was aber an dem leeren Fenster nichts geändert hat.

    Aktuelle Firmware: 4.3.4.0597 vom 28.5.2018


    Grüße

    Rainer

    Vielen Dank für die Tipps. Schau ich mir mal an!


    Grüße

    Rainer

    War auf der Seite und hab's runtergeladen. Mal unabhängig davon, dass bei meinen Win 7 32-bit Maschine die Installation mit dem Satz "This machine does not meet the requirements" (möglicherweise weil 32-bit, aber das verrät mir veeam nicht :)) abbricht, habe ich auf der Veeam Homepage noch folgenden Satz zur Veeam Backup Free Edition gelesen:


    Hinweis: Der kostenlose VMware vSphere-Hypervisor (kostenlose Version von ESXi) wird nicht unterstützt. Lizenz für vSphere Essentials oder höhere Version erforderlich.

    vSphere Essentials oder teurer haben wir leider nicht.


    btr402 Sichert der veeam mit dem Linux-Agent die komplette Maschine auch als Image oder auf Fileebene?


    Gibt's sonst Alternativen zu dem von mir beschriebenen Szenario?


    Grüße

    Rainer

    Hallo zusammen,


    ich bräuchte mal eine Rat in Bezug auf das Backup von virtuellen Maschinen.


    Wir haben einen ESXi 6.5 Server aufgesetzt. Dieser zieht sich von einer TS-563 über nfs einen Share (ESX-Images), auf dem letztendlich der Datastore des ESX liegt (sprich alle vmdk-Files der virtuellen Maschinen).


    Aktuell (aber das ist sicher so nicht richtig) mache ich über NAS-to-NAS mit dem Backupmanager nächtens eine Kopie auf Fileebene aus dem Share ESX-Images in ein auf der gleichen NAS befindlichen anderen Share namens Backup. An sich hätte ich da auch keine Bedenken, wenn da nicht die Tatsache wäre, dass die VMs (die natürlich laufen) in der Zeit, während das vmdk-File kopiert wird, dort auch Änderungen schreiben.

    Das heißt für mich, dass erstmal die Gefahr gegeben ist, dass das vmdk-File auf dem Backup-Share nicht notwenidgerweise konsistent sein muss.


    Wie macht ihr das?


    Grüße

    Rainer

    Hi und danke für Deine Antwort.


    Bei Nas-to-Nas sehe ich leider keine Ereignisprotokolle. Ich seh halt bei den Systemprotokollen, dass die eine Sicherung gestartet ist und wann sie beendet wurde. Leider kann ich weger sehen, wieviel Files oder welches Volumen kopiert wurde.
    Die Logs, wie bei Dir rot umrandet, scheint es bei Nas-to-Nas nicht zu geben.


    Grüße
    Rainer

    Hi zusammen,


    ich nutze seit längerem neben den Platten für die Daten 2 Backup-Platten, die über NAS-to-NAS mit Daten versorgt werden.
    Auf Backup1 kommt jeden Tag eine 1:1 Kopie der zu sichernden Filesysteme (Zusatzdateien auf dem Backup1 werden gelöscht).
    Auf Backup2 kommen einmal die Woche die Daten von Backup1, allerdings werden hier die Zusatzdaten nicht gelöscht.


    Nun hatte ich die Tage zweimal den Fall, dass Sicherungen extrem langsam gingen (10 GB in 20 Minuten o.ä.)


    Ich würde gerne die Sicherungslogs einsehen können, weiss aber nicht, ob überhaupt welche erstellt werden und falls ja, wo diese zu finden sind.


    Für einen Tipp wäre ich sehr dankbar.


    Grüße
    Rainer

    Problem ist gelöst.
    Nachdem ich zweimal das Volume mit unterschiedlichen Platten als thick angelegt hatte und beide Male von der NAS-Box letztendlich gesagt bekommen habe, dass die Platten jeweils kaputt seien (s.o.), habe ich mit der zweiten Platte das Volume mit thin-provisioning eingerichtet und siehe da: Keinerlei Fehlermeldungen und die 2,6TB Daten konnte ich auch problemlos auf die neue Platte schieben.

    Moin nochmal,


    jetzt wird's allerdings seltsam: Hatte ja die Platte zurückgesendet und mir von einem anderen Lieferanten eine neue Platte bestellt (gleicher Typ).
    Heute früh hab ich das Teil in den Einschub geschraubt und rein damit ins NAS. Neuer Speicherpool angelegt und auch ein neues Volume. Hat genauso formatiert wie bei der ersten Platte auchund begann dann mit der "Optimierung" (was auch immer da gemacht wird und dann fingen die Fehlermeldungen wieder an. Also an genau der gleichen Stelle. Diesmal aber nur 7 statt 10 Seiten.


    Neue Platte2.jpg


    Nach wenigen Sekunden meldet das System, das neue Raid sei im degraded mode und hat mir die neue Platte wieder ausgeschmissen, weil kaputt.


    Im Betreffenden Slot 5 des NAS liefer vorher problemlos eine Platte 3 Jahre lang, daher gehe ich nicht davon aus, dass der Slot kaputt ist.


    Was tun?


    Grüße und Danke
    Rainer


    EDIT: Habe die Platte rausgenommen und in einer Dockingstation an meinen Windows-PC gehängt und einen Kurztest mit WinDFT gemacht und habe das Ergebnis, dass die Platte in Ordnung sei. Mach jetzt noch einen ausführlichen Test.
    EDIT2: Kann das an der Größe liegen? Platte ist 5 TB und ich hab's als Thick-Volument mit maximaler Größe angegeben. sollte eigentlich nicht, oder?


    Jetzt hab ich nochmal eine Zusatzinfo.
    Die erste Platte, die auch nicht funktioniert hatte, war vom Modell HGST Deskstar NAS 5TB und hatte die HDD model# HDN726050ALE610 (ist in der Kompatibilitätsliste drin)
    Die zweite Platte hat die Model# HDN726050ALE614 (also 614 statt 610 am Ende) und die finde ich nicht in der Liste. Allerdings ist der SKU der zweiten Platte (0S03940) wieder in der Kompatibilitätsliste drin, allerdings mit einer anderen Model# (H3IKNASN500012872SE).



    Nun bin ich doch etwas verwirrt :)


    So, hab mal den Log aus dem kmsg rausgefieselt. Vielleicht kann ja damit jemand was anfangen:


    Code
    <3>Sat Jan 21 09:15:01 2017 ata11: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen<3>Sat Jan 21 09:15:01 2017 ata11: irq_stat 0x80000040, connection status changed<3>Sat Jan 21 09:15:01 2017 ata11: SError: { DevExch }<6>Sat Jan 21 09:15:01 2017 ata11: hard resetting link<3>Sat Jan 21 09:15:11 2017 ata11: softreset failed (device not ready)<6>Sat Jan 21 09:15:11 2017 ata11: hard resetting link<6>Sat Jan 21 09:15:19 2017 ata11: SATA link up 6.0 Gbps (SStatus 133 SControl 330)<6>Sat Jan 21 09:15:19 2017 ata11.00: ATA-9: HGST HDN726050ALE614, APGNW7JH, max UDMA/133<6>Sat Jan 21 09:15:19 2017 ata11.00: 9767541168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA<6>Sat Jan 21 09:15:19 2017 ata11.00: configured for UDMA/133<6>Sat Jan 21 09:15:19 2017 ata11: EH complete<5>Sat Jan 21 09:15:19 2017 scsi 10:0:0:0: Direct-Access     HGST     HDN726050ALE614  APGN PQ: 0 ANSI: 5<6>Sat Jan 21 09:15:19 2017 ata11.00: set queue depth = 31<4>Sat Jan 21 09:15:19 2017 Check proc_name[ahci].<5>Sat Jan 21 09:15:19 2017 sd 10:0:0:0: [sdf] 9767541168 512-byte logical blocks: (5.00 TB/4.54 TiB)<5>Sat Jan 21 09:15:19 2017 sd 10:0:0:0: [sdf] 4096-byte physical blocks<5>Sat Jan 21 09:15:19 2017 sd 10:0:0:0: [sdf] Write Protect is off<7>Sat Jan 21 09:15:19 2017 sd 10:0:0:0: [sdf] Mode Sense: 00 3a 00 00<5>Sat Jan 21 09:15:19 2017 sd 10:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA<5>Sat Jan 21 09:15:19 2017 sd 10:0:0:0: Attached scsi generic sg5 type 0<6>Sat Jan 21 09:15:19 2017  sdf: unknown partition table<5>Sat Jan 21 09:15:19 2017 sd 10:0:0:0: [sdf] Attached SCSI disk<6>Sat Jan 21 09:16:53 2017  sdf:<6>Sat Jan 21 09:16:53 2017  sdf: sdf1<6>Sat Jan 21 09:16:53 2017  sdf: sdf1 sdf2<6>Sat Jan 21 09:16:53 2017  sdf: sdf1 sdf2 sdf3<6>Sat Jan 21 09:16:53 2017  sdf: sdf1 sdf2 sdf3 sdf4<6>Sat Jan 21 09:16:53 2017  sdf: sdf1 sdf2 sdf3 sdf4 sdf5<6>Sat Jan 21 09:16:54 2017 md: bind<sdf1><7>Sat Jan 21 09:16:54 2017 RAID1 conf printout:<7>Sat Jan 21 09:16:54 2017  --- wd:4 rd:24<7>Sat Jan 21 09:16:54 2017  disk 0, wo:0, o:1, dev:sda1<7>Sat Jan 21 09:16:54 2017  disk 1, wo:0, o:1, dev:sdb1<7>Sat Jan 21 09:16:54 2017  disk 2, wo:1, o:1, dev:sdf1<7>Sat Jan 21 09:16:54 2017  disk 3, wo:0, o:1, dev:sdd1<7>Sat Jan 21 09:16:54 2017  disk 4, wo:0, o:1, dev:sdc1<6>Sat Jan 21 09:16:54 2017 md: recovery of RAID array md9<6>Sat Jan 21 09:16:54 2017 md: minimum _guaranteed_	speed: 5000 KB/sec/disk.<6>Sat Jan 21 09:16:54 2017 md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.<6>Sat Jan 21 09:16:54 2017 md: Recovering started: md9<6>Sat Jan 21 09:16:54 2017 md: using 128k window, over a total of 530112k.<6>Sat Jan 21 09:16:55 2017 md: bind<sdf4><7>Sat Jan 21 09:16:55 2017 RAID1 conf printout:<7>Sat Jan 21 09:16:55 2017  --- wd:4 rd:24<7>Sat Jan 21 09:16:55 2017  disk 0, wo:0, o:1, dev:sda4<7>Sat Jan 21 09:16:55 2017  disk 1, wo:0, o:1, dev:sdb4<7>Sat Jan 21 09:16:55 2017  disk 2, wo:1, o:1, dev:sdf4<7>Sat Jan 21 09:16:55 2017  disk 3, wo:0, o:1, dev:sdd4<7>Sat Jan 21 09:16:55 2017  disk 4, wo:0, o:1, dev:sdc4<6>Sat Jan 21 09:16:55 2017 md: recovery of RAID array md13<6>Sat Jan 21 09:16:55 2017 md: minimum _guaranteed_	speed: 5000 KB/sec/disk.<6>Sat Jan 21 09:16:55 2017 md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.<6>Sat Jan 21 09:16:55 2017 md: Recovering started: md13<6>Sat Jan 21 09:16:55 2017 md: using 128k window, over a total of 458880k.<6>Sat Jan 21 09:16:57 2017 md: bind<sdf2><7>Sat Jan 21 09:16:57 2017 RAID1 conf printout:<7>Sat Jan 21 09:16:57 2017  --- wd:2 rd:2<7>Sat Jan 21 09:16:57 2017  disk 0, wo:0, o:1, dev:sda2<7>Sat Jan 21 09:16:57 2017  disk 1, wo:0, o:1, dev:sdb2<7>Sat Jan 21 09:16:57 2017 RAID1 conf printout:<7>Sat Jan 21 09:16:57 2017  --- wd:2 rd:2<7>Sat Jan 21 09:16:57 2017  disk 0, wo:0, o:1, dev:sda2<7>Sat Jan 21 09:16:57 2017  disk 1, wo:0, o:1, dev:sdb2<7>Sat Jan 21 09:16:57 2017 RAID1 conf printout:<7>Sat Jan 21 09:16:57 2017  --- wd:2 rd:2<7>Sat Jan 21 09:16:57 2017  disk 0, wo:0, o:1, dev:sda2<7>Sat Jan 21 09:16:57 2017  disk 1, wo:0, o:1, dev:sdb2<4>Sat Jan 21 09:16:58 2017 mdadm: sending ioctl 80480911 to a partition!<6>Sat Jan 21 09:16:59 2017 md: bind<sdf3><6>Sat Jan 21 09:16:59 2017 md/raid1:md2: active with 1 out of 1 mirrors<6>Sat Jan 21 09:16:59 2017 md2: detected capacity change from 0 to 4990787190784<6>Sat Jan 21 09:16:59 2017  md2: unknown partition table<3>Sat Jan 21 09:17:03 2017 device-mapper: thin metadata: sb_check failed: magic 0: wanted 27022010<3>Sat Jan 21 09:17:03 2017 device-mapper: thin metadata: sb_check failed: magic 0: wanted 27022010<6>Sat Jan 21 09:17:03 2017 device-mapper: thin metadata: bm_get_thin_metadata_block_size 0, set MetaBlkSize as 8192 for the dm-thin pool<6>Sat Jan 21 09:17:03 2017 device-mapper: space map metadata: dm_sm_metadata_init, sm_ll_allocate_disk_metadata done, version is 2<6>Sat Jan 21 09:17:03 2017 device-mapper: space map disk: dm_sm_disk_create_real, sm_ll_allocate_disk_metadata with version 2<4>Sat Jan 21 09:17:03 2017 device-mapper: thin: Data device (dm-32) discard unsupported: Disabling discard passdown.<6>Sat Jan 21 09:17:27 2017 md: md9: recovery done.<6>Sat Jan 21 09:17:27 2017 md: Recovering done: md9, degraded=20<7>Sat Jan 21 09:17:27 2017 RAID1 conf printout:<7>Sat Jan 21 09:17:27 2017  --- wd:5 rd:24<7>Sat Jan 21 09:17:27 2017  disk 0, wo:0, o:1, dev:sda1<7>Sat Jan 21 09:17:27 2017  disk 1, wo:0, o:1, dev:sdb1<7>Sat Jan 21 09:17:27 2017  disk 2, wo:0, o:1, dev:sdf1<7>Sat Jan 21 09:17:27 2017  disk 3, wo:0, o:1, dev:sdd1<7>Sat Jan 21 09:17:27 2017  disk 4, wo:0, o:1, dev:sdc1<6>Sat Jan 21 09:17:29 2017 md: md13: recovery done.<6>Sat Jan 21 09:17:29 2017 md: Recovering done: md13, degraded=20<7>Sat Jan 21 09:17:29 2017 RAID1 conf printout:<7>Sat Jan 21 09:17:29 2017  --- wd:5 rd:24<7>Sat Jan 21 09:17:29 2017  disk 0, wo:0, o:1, dev:sda4<7>Sat Jan 21 09:17:29 2017  disk 1, wo:0, o:1, dev:sdb4<7>Sat Jan 21 09:17:29 2017  disk 2, wo:0, o:1, dev:sdf4<7>Sat Jan 21 09:17:29 2017  disk 3, wo:0, o:1, dev:sdd4<7>Sat Jan 21 09:17:29 2017  disk 4, wo:0, o:1, dev:sdc4<6>Sat Jan 21 09:18:15 2017 md: bind<sdf5><6>Sat Jan 21 09:18:15 2017 md/raid1:md321: active with 1 out of 2 mirrors<6>Sat Jan 21 09:18:15 2017 created bitmap (1 pages) for device md321<6>Sat Jan 21 09:18:15 2017 md321: bitmap initialized from disk: read 1/1 pages, set 110 of 110 bits<6>Sat Jan 21 09:18:15 2017 md321: detected capacity change from 0 to 7340032000<6>Sat Jan 21 09:18:15 2017  md321: unknown partition table<6>Sat Jan 21 09:18:15 2017 Adding 7167996k swap on /dev/md321.  Priority:-3 extents:1 across:7167996k <4>Sat Jan 21 09:20:30 2017 EXT4-fs (dm-35): Mount option "noacl" will be removed by 3.5<4>Sat Jan 21 09:20:30 2017 Contact linux-ext4@vger.kernel.org if you think we should keep it.<4>Sat Jan 21 09:20:30 2017 <4>Sat Jan 21 09:20:32 2017 ext4_init_reserve_inode_table0: dm-35, 0<4>Sat Jan 21 09:20:32 2017 ext4_init_reserve_inode_table2: dm-35, 36677, 36677, 18778623, 4096<6>Sat Jan 21 09:20:32 2017 EXT4-fs (dm-35): mounted filesystem with ordered data mode. Opts: usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,delalloc,noacl<4>Sat Jan 21 09:20:32 2017 EXT4-fs (device dm-35): ext4lazyinit start (start from 0, total 36677)<6>Sat Jan 21 09:20:33 2017 EXT4-fs (dm-35): re-mounted. Opts: (null)<6>Sat Jan 21 09:20:33 2017 EXT4-fs (dm-35): re-mounted. Opts: (null)<4>Sat Jan 21 09:20:33 2017 EXT4-fs (device dm-35): ext4lazyinit start (start from 20, total 36657)<6>Sat Jan 21 09:20:43 2017 md321: detected capacity change from 7340032000 to 0<6>Sat Jan 21 09:20:43 2017 md: md321 stopped.<6>Sat Jan 21 09:20:43 2017 md: unbind<sdf5><6>Sat Jan 21 09:20:43 2017 md: export_rdev(sdf5)


    Teil 2:

    Code
    <3>Sat Jan 21 09:21:19 2017 ata11.00: exception Emask 0x10 SAct 0x3 SErr 0x190002 action 0xe frozen<3>Sat Jan 21 09:21:19 2017 ata11.00: irq_stat 0x80400000, PHY RDY changed<3>Sat Jan 21 09:21:19 2017 ata11: SError: { RecovComm PHYRdyChg 10B8B Dispar }<3>Sat Jan 21 09:21:19 2017 ata11.00: failed command: READ FPDMA QUEUED<3>Sat Jan 21 09:21:19 2017 ata11.00: cmd 60/08:00:88:5b:20/00:00:00:00:00/40 tag 0 ncq 4096 in<3>Sat Jan 21 09:21:19 2017          res 40/00:00:88:5b:20/00:00:00:00:00/40 Emask 0x10 (ATA bus error)<3>Sat Jan 21 09:21:19 2017 ata11.00: status: { DRDY }<3>Sat Jan 21 09:21:19 2017 ata11.00: failed command: WRITE FPDMA QUEUED<3>Sat Jan 21 09:21:19 2017 ata11.00: cmd 61/00:08:88:38:b0/03:00:18:00:00/40 tag 1 ncq 393216 out<3>Sat Jan 21 09:21:19 2017          res 40/00:00:88:5b:20/00:00:00:00:00/40 Emask 0x10 (ATA bus error)<3>Sat Jan 21 09:21:19 2017 ata11.00: status: { DRDY }<6>Sat Jan 21 09:21:19 2017 ata11: hard resetting link<6>Sat Jan 21 09:21:19 2017 ata11: SATA link down (SStatus 0 SControl 330)<6>Sat Jan 21 09:21:20 2017 ata11: hard resetting link<6>Sat Jan 21 09:21:30 2017 ata11: SATA link up 6.0 Gbps (SStatus 133 SControl 330)<7>Sat Jan 21 09:21:30 2017 ata11.00: both IDENTIFYs aborted, assuming NODEV<3>Sat Jan 21 09:21:30 2017 ata11.00: revalidation failed (errno=-2)<6>Sat Jan 21 09:21:34 2017 ata11: hard resetting link<6>Sat Jan 21 09:21:35 2017 ata11: SATA link up 6.0 Gbps (SStatus 133 SControl 330)<7>Sat Jan 21 09:21:35 2017 ata11.00: both IDENTIFYs aborted, assuming NODEV<3>Sat Jan 21 09:21:35 2017 ata11.00: revalidation failed (errno=-2)<4>Sat Jan 21 09:21:35 2017 ata11.00: disabled<6>Sat Jan 21 09:21:40 2017 ata11: hard resetting link<6>Sat Jan 21 09:21:40 2017 ata11: SATA link up 6.0 Gbps (SStatus 133 SControl 330)<7>Sat Jan 21 09:21:40 2017 ata11.00: both IDENTIFYs aborted, assuming NODEV<6>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE<6>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf]  Sense Key : Aborted Command [current] [descriptor]<4>Sat Jan 21 09:21:40 2017 Descriptor sense data with sense descriptors (in hex):<6>Sat Jan 21 09:21:40 2017         72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 <6>Sat Jan 21 09:21:40 2017         00 20 5b 88 <6>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf]  Add. Sense: No additional sense information<6>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf] CDB: Read(10): 28 00 00 20 5b 88 00 00 08 00<3>Sat Jan 21 09:21:40 2017 end_request: I/O error, dev sdf, sector 2120584<1>Sat Jan 21 09:21:40 2017 raid1: sdf3: unrecoverable I/O read error for block 0<3>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: rejecting I/O to offline device<6>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf] killing request<6>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE<6>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf]  Sense Key : Aborted Command [current] [descriptor]<4>Sat Jan 21 09:21:40 2017 Descriptor sense data with sense descriptors (in hex):<6>Sat Jan 21 09:21:40 2017         72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 <6>Sat Jan 21 09:21:40 2017         00 20 5b 88 <6>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf]  Add. Sense: No additional sense information<6>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf] CDB: Write(10): 2a 00 18 b0 38 88 00 03 00 00<3>Sat Jan 21 09:21:40 2017 end_request: I/O error, dev sdf, sector 414201992<6>Sat Jan 21 09:21:40 2017 ata11: EH complete<3>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: rejecting I/O to offline device<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-5, uptodate=0<1>Sat Jan 21 09:21:40 2017 md/raid1:md9: Disk failure on sdf1, disabling device.<1>Sat Jan 21 09:21:40 2017 md/raid1:md9: Operation continuing on 4 devices.<3>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: rejecting I/O to offline device<3>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: rejecting I/O to offline device<6>Sat Jan 21 09:21:40 2017 ata11.00: detaching (SCSI 10:0:0:0)<3>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: rejecting I/O to offline device<5>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf] Synchronizing SCSI cache<6>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK<5>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf] Stopping disk<4>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf] START_STOP FAILED<6>Sat Jan 21 09:21:40 2017 sd 10:0:0:0: [sdf]  Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<3>Sat Jan 21 09:21:40 2017 Buffer I/O error on device dm-35, logical block 16<4>Sat Jan 21 09:21:40 2017 lost page write due to I/O error on dm-35<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<3>Sat Jan 21 09:21:40 2017 Buffer I/O error on device dm-35, logical block 17<4>Sat Jan 21 09:21:40 2017 lost page write due to I/O error on dm-35<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<3>Sat Jan 21 09:21:40 2017 Aborting journal on device dm-35-8.<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<3>Sat Jan 21 09:21:40 2017 Buffer I/O error on device dm-35, logical block 600866816<4>Sat Jan 21 09:21:40 2017 lost page write due to I/O error on dm-35<3>Sat Jan 21 09:21:40 2017 JBD2: Error -5 detected when updating journal superblock for dm-35-8.<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<4>Sat Jan 21 09:21:40 2017 md: super_written gets error=-19, uptodate=0<7>Sat Jan 21 09:21:40 2017 RAID1 conf printout:<7>Sat Jan 21 09:21:40 2017  --- wd:4 rd:24<7>Sat Jan 21 09:21:40 2017  disk 0, wo:0, o:1, dev:sda1<7>Sat Jan 21 09:21:40 2017  disk 1, wo:0, o:1, dev:sdb1<7>Sat Jan 21 09:21:40 2017  disk 2, wo:1, o:0, dev:sdf1<7>Sat Jan 21 09:21:40 2017  disk 3, wo:0, o:1, dev:sdd1<7>Sat Jan 21 09:21:40 2017  disk 4, wo:0, o:1, dev:sdc1<7>Sat Jan 21 09:21:40 2017 RAID1 conf printout:<7>Sat Jan 21 09:21:40 2017  --- wd:4 rd:24<7>Sat Jan 21 09:21:40 2017  disk 0, wo:0, o:1, dev:sda1<7>Sat Jan 21 09:21:40 2017  disk 1, wo:0, o:1, dev:sdb1<7>Sat Jan 21 09:21:40 2017  disk 3, wo:0, o:1, dev:sdd1<7>Sat Jan 21 09:21:40 2017  disk 4, wo:0, o:1, dev:sdc1<4>Sat Jan 21 09:21:41 2017 EXT4-fs (dm-35): Mount option "noacl" will be removed by 3.5<4>Sat Jan 21 09:21:41 2017 Contact linux-ext4@vger.kernel.org if you think we should keep it.<4>Sat Jan 21 09:21:41 2017 <4>Sat Jan 21 09:21:41 2017 EXT4-fs (dm-35): Mount option "noacl" will be removed by 3.5<4>Sat Jan 21 09:21:41 2017 Contact linux-ext4@vger.kernel.org if you think we should keep it.<4>Sat Jan 21 09:21:41 2017 <6>Sat Jan 21 09:21:41 2017 EXT4-fs (dm-35): re-mounted. Opts: usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,delalloc,noacl,delalloc,noacl<4>Sat Jan 21 09:21:41 2017 md: super_written gets error=-19, uptodate=0<3>Sat Jan 21 09:21:43 2017 Buffer I/O error on device dm-30, logical block 0<3>Sat Jan 21 09:21:43 2017 Buffer I/O error on device dm-30, logical block 1202075632<3>Sat Jan 21 09:21:43 2017 Buffer I/O error on device dm-30, logical block 66<3>Sat Jan 21 09:21:43 2017 Buffer I/O error on device dm-30, logical block 66<3>Sat Jan 21 09:21:43 2017 Buffer I/O error on device dm-30, logical block 1202075632<3>Sat Jan 21 09:21:43 2017 Buffer I/O error on device dm-30, logical block 0<3>Sat Jan 21 09:21:43 2017 Buffer I/O error on device dm-30, logical block 66<6>Sat Jan 21 09:21:45 2017 md: unbind<sdf1><6>Sat Jan 21 09:21:45 2017 md: export_rdev(sdf1)


    Teil 3:


    Bitte @admin ergänzen


    "EDIT3: WinDFT sagt auch bei dem ausführlichen Test, dass alles ok ist."


    Kann ich selbst nicht, da die 10000 Zeichen Meldung beim Editen meines Postings kommt.

    Konnte man im System leider nicht mehr entfernen.
    Hab die Platte dann physikalisch entfernt, was das NAS aber ins Stottern gebracht hatte. Speicherpool wurde noch angezeigt, konnte aber auch nicht entfernt werden.
    Neustart hat auch nix gebracht. Erst ein Herunterfahren und ne Minute Warten hat dann den erhofften Erfolg gebracht. Dann konnte man auch den Speicherpool wieder entfernen.
    Platte hab ich vorhin zurückgesendet.


    Wundert mich eigentlich, dass bei einer defekten Platte gleich die ganze NAS-Box ins Husten kommt.

    Sehe mit mount:
    /dev/md9 on /mnt/HDA_ROOT type ext3 (rw,data=ordered)


    und


    Code
    # cat /proc/mdstat
    ...
    md9 : active raid1 sda1[0] sdc1[25] sdd1[26] sdb1[24]
                     530112 blocks super 1.0 [24/4] [UU_UU___________________]
                     bitmap: 1/1 pages [4KB], 65536KB chunk


    Hab ja die eine Platte freigemacht und aus der Systemplatte und der freien Platte ein Raid 1 gemacht. Sollte jetzt schon passen, denke ich mal :)