Beiträge von o.haensel

wie äußert sich das?

Hallo zusammen,

bei äteren QTS Versionen war es möglich, bei Fehlern ein Firmwaredowngrade durchzuführen. Wir wollen bei einem Kd. ein Firmwaredowngrade von 4.5.3.1652 auf 4.5.1.1547 durchführen. Kunde hat ein Firmwareupgrade durchgeführt und festgestellt, dass die Backup Synchronisation nun bedeutend träger läuft als vorher. Beim Downgrade erhält man allerdings die Meldung, dass die QTS kein Downgrade unterstützt und man wird über die möglichen Folgen aufgeklärt. Dies könnte man bestätigen und das Downgrade dennoch durchführen. Jemand Erfahrung?

Gruß Oliver

Also der Abbruch hing nicht an dem parallelen Übertragen, als die Sychronisation nich nocht abgeschlossen war. Der Fehler kam nach ca. 20 min wieder.

Nun habe ich auf die Firmware 4.3.4.1463 build 20201006 vom 11.10.2020 gedowngradet und scheint die Filestation zuverlässig die Daten zu kopieren. Schauen wir mal.

Update 04.05.2021

Heute früh hatte sich QNAP gemeldet. Lt. Log war mit dem RAID wohl alles in Ordnung. Beim kopieren der Daten on der Backup NAS (TS 439 Pro II+) auf die TS 469 Pro über die Filestation, rutscht die 469er regelmäßig auf Schreibschutz. Angeblich wäre das Laufwerk nicht clean?! Könnte es doch die Backplane sein? Wenn ja was nimmt man aktuell für ein neues Gerät? TS-473A?

Ich habe nagelneue Platten (WD2005FBYZ-01YCBB3) eingebaut. Da das RAID scheinbar defekt war, habe ich die NAS gleich komplett neu initialisiert. Firmware habe ich gleich geupdetet auf 4.3.4.1652 (TS-469 Pro). Eine Datensicherung ist größtenteils auf einer 2. QNAP vorhanden. Ich habe die Initialisierung nochmal neu begonnen. Ich hatte zwar gelesen, dass mann theeoretisch die Daten bereits übertragen kan, wenn die QNAP das RAID noch synchronisiert, aber vielleicht war genau das das Problem.

Ich habe heute die veremeintlich defekten HDDs gegen 4 neue ausgetauscht und sychronisiert. Die wichtigsten Daten liegen auf einer Backup NAS im selben Netzwerk. Ich habe die Daten begonnen über die Filestation über die Ferneinbindung auf die NAS mit den neuen HDDs zu koperen. Das lief anfangs auch problemlos, aber nun ist die alte NAS mit den neuen HDDs wieder in den Schreibschutz Modus gewechselt. Allerdings habe ich keine Idee warum?!

Das ist der aktuelle Log:

Typ    Datum    Uhrzeit    Benutzer    Quellen-IP    Computername    Inhalt
Informationen    29.04.2021    07:49:57    System    127.0.0.1    localhost    [UPS] USB UPS device unplugged.
Informationen    29.04.2021    07:49:36    System    127.0.0.1    localhost    System was shut down on Thu Apr 29 07:49:36 CEST 2021.
Informationen    29.04.2021    07:49:29    System    127.0.0.1    localhost    [RTRR Server] Stopped.
Informationen    29.04.2021    03:01:10    System    127.0.0.1    localhost    [Malware Remover] Scan completed.
Informationen    29.04.2021    03:00:11    System    127.0.0.1    localhost    [Malware Remover] Started scanning.
Informationen    28.04.2021    23:57:24    System    127.0.0.1    localhost    [Malware Remover] Scan completed.
Informationen    28.04.2021    23:57:04    System    127.0.0.1    localhost    [Volume Volume, Pool 1] Examination completed.
Informationen    28.04.2021    23:56:29    System    127.0.0.1    localhost    [Malware Remover] Started scanning.
Informationen    28.04.2021    23:44:07    System    127.0.0.1    localhost    [App Center] Qsync Central 3.0.3.01 installation succeeded.
Informationen    28.04.2021    23:44:06    System    127.0.0.1    localhost    [App Center] Qsync Central enabled.
Informationen    28.04.2021    23:43:23    System    127.0.0.1    localhost    [UPS] USB UPS device plugged in.
Informationen    28.04.2021    23:43:14    System    127.0.0.1    localhost    [Volume Volume, Pool 1] Started examination.

Kurios ist, dass die Qnap seit dem 29.04. nichts mehr protokolliert. Der vermeintliche RAID Ausfall war erst am 29.04. gegen 15.30. Im Log wurde auch nichts geleert.

Ist hier jemand von QNAP im Forum, der uns bei der genauen Analyse unterstützen kann. Wiebereits geschrieben, sind die wichtigsten Daten auf einer weiteren syncronisiert. Wenn sich das RAID dennoch retten lässt, wäre das natürlich klasse. Weiterhin wäre zu prüfen, ob es nicht irgendein Defekt der QNAP ist, da es erst nach dem Firmwareupdate diese massiven Probleme gab, wie bereits im anderen Beitrag geschrieben: Apps lassen sich teiweise nicht starten, der SMB Dienst startet nicht oder es sporadisch nur SMB 1 im Dropdown verfügbar.

Kurios ist, dass techn. alles in Ordnung zu sein scheint, die Qnap aber meldet 2 Datenträger wären ausgefallen. Aber ich müstte doch irgendwo sehen, was ausgefallen ist. Wenn mal eine HDD ausgefallen ist, zeigt sie es doch auch an. Jemand eine Idee wie man das auslesen kann oder wieder hinbekommt?

Hallo zusammen,

nachdem wir seit einer Woche dir kuriosesten Fehler mit unserer TS-469Pro haben, siehe hier SMB Zugriff und andere kuriose Fehler, ist gestern Nachmittag das RAID ausgefallen. Leider kann ich in dem Beitrag keine neue Antwort anhängen sondern nur editieren. Wir vermuten im Zuge der autom. RAID-Bereinigung. Kurios ist, dass die Qnap meldet, dass 2 HDDs angeblich ausgefallen wären, aber es keinerlei Hinweise hierauf gibt (siehe Bilder). Das RAID läuft nicht, und lässt sich auch nicht wiederherstellen. Kurios ist, dass die QNAP gestern Vormittag kurz angezeigt hat, dass angeblich HDD3 entfernt wurde, die Meldung verschwand aber wieder. Die HDDs wurden, wie bereits in dem anderen Post beschrieben, alle mit dem WD Diagnostics Tool getestet - Keine Auffälligkleiten. Ich habe bei der QNAP über SSH mal die mdadm -E /dev Staties abgefragt. Hier ist auffällig, dass bei 3/4 der Stauts-Level RAID 1 statt RAID 5 ist.

Hier der Log:

[~] # mdadm -E /dev/sda1
/dev/sda1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : 88bda7c3:d3bb9a31:1d648b82:bac48096
Name : 9
Creation Time : Wed Jul 30 20:28:29 2014
Raid Level : raid1
Raid Devices : 24

Avail Dev Size : 1060224 (517.77 MiB 542.83 MB)
Array Size : 530112 (517.77 MiB 542.83 MB)
Super Offset : 1060232 sectors
State : clean
Device UUID : 5f1a562c:eb9df263:f8f5b0b6:c6bbf059

Internal Bitmap : -8 sectors from superblock
Update Time : Fri Apr 30 12:13:12 2021
Bad Block Log : 512 entries available at offset -8 sectors
Checksum : d68eae0 - correct
Events : 10548470

Device Role : Active device 0
Array State : AAAA.................... ('A' == active, '.' == missing, 'R' == replacing)
[~] # mdadm -E /dev/sda2
/dev/sda2:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : 0c1755e6:00a1c3fd:41a36866:5e0ce777
Name : 256
Creation Time : Fri Apr 30 11:50:34 2021
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 1060248 (517.79 MiB 542.85 MB)
Array Size : 530112 (517.77 MiB 542.83 MB)
Used Dev Size : 1060224 (517.77 MiB 542.83 MB)
Super Offset : 1060264 sectors
Unused Space : before=0 sectors, after=24 sectors
State : clean
Device UUID : 9f08ef5f:3292425b:f4465e54:b573c8da

Internal Bitmap : -16 sectors from superblock
Update Time : Fri Apr 30 11:50:35 2021
Bad Block Log : 512 entries available at offset -8 sectors
Checksum : 17357021 - correct
Events : 2

Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
[~] # mdadm -E /dev/sda3
/dev/sda3:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : 5fb0bacc:e6246497:c27640c9:9b52b42d
Name : 1
Creation Time : Thu Jul 31 05:28:30 2014
Raid Level : raid5
Raid Devices : 4

Avail Dev Size : 3887119240 (1853.52 GiB 1990.21 GB)
Array Size : 5830678848 (5560.57 GiB 5970.62 GB)
Used Dev Size : 3887119232 (1853.52 GiB 1990.21 GB)
Super Offset : 3887119504 sectors
Unused Space : before=0 sectors, after=264 sectors
State : clean
Device UUID : 538573ab:b647b2b5:e2d122e7:5020ce2c

Update Time : Thu Apr 29 14:42:35 2021
Bad Block Log : 512 entries available at offset -8 sectors
Checksum : e4968c2b - correct
Events : 18718

Layout : left-symmetric
Chunk Size : 64K

Device Role : Active device 0
Array State : AA.. ('A' == active, '.' == missing, 'R' == replacing)
[~] # mdadm -E /dev/sda4
/dev/sda4:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : 6cee014b:82b13974:f7273b06:c71f0c15
Name : 13
Creation Time : Wed Jul 30 20:28:35 2014
Raid Level : raid1
Raid Devices : 24

Avail Dev Size : 1060256 (517.79 MiB 542.85 MB)
Array Size : 458880 (448.20 MiB 469.89 MB)
Used Dev Size : 917760 (448.20 MiB 469.89 MB)
Super Offset : 1060272 sectors
Unused Space : before=0 sectors, after=142504 sectors
State : clean
Device UUID : a9821b24:4b91d919:944380f2:666790b9

Internal Bitmap : -8 sectors from superblock
Update Time : Fri Apr 30 12:09:36 2021
Bad Block Log : 512 entries available at offset -8 sectors
Checksum : 2216ef02 - correct
Events : 88267

Device Role : Active device 0
Array State : AAAA.................... ('A' == active, '.' == missing, 'R' == replacing)
[~] # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md322 : active raid1 sdd5[3](S) sdc5[2](S) sdb5[1] sda5[0]
7235136 blocks super 1.0 [2/2] [UU]
bitmap: 0/1 pages [0KB], 65536KB chunk

md256 : active raid1 sdd2[3](S) sdc2[2](S) sdb2[1] sda2[0]
530112 blocks super 1.0 [2/2] [UU]
bitmap: 0/1 pages [0KB], 65536KB chunk

md13 : active raid1 sda4[24] sdd4[27] sdc4[26] sdb4[25]
458880 blocks super 1.0 [24/4] [UUUU____________________]
bitmap: 1/1 pages [4KB], 65536KB chunk

md9 : active raid1 sda1[24] sdd1[27] sdc1[26] sdb1[25]
530112 blocks super 1.0 [24/4] [UUUU____________________]
bitmap: 1/1 pages [4KB], 65536KB chunk

Von den wichtigesten Daten ist ein Backup vorhanden. Neue HDDs habe ich auch bestellt und bereits erhalten. Die Frage ist, liegt es an der QNAP, Firmware oder doch einer oder mehrerer HDDs? Wir haben bei QNAP zwar ein Ticket erstellt und sollten den Log schicken, allerdings soll die Bearbeitung aktuell recht lange dauern.

Wir haben alle HDDs mit dem Hersteller Tool geprüft. Alle Test ohne Fehler. Also meinste, Daten sichern, HDDs formatieren und alles neu aufspielen?

Die Smartwerte sind alle gut. Das Herstellertest-Tool zeigt keine Fehler bei allen 4 HDDs. Die umfassenden Tests über die Qnap sind alle erfolgreich. Da sporadisch SMB 2, 3 auswählbar ist, dann wieder nicht und auch die Datenträgerprüfung mal durchläuft und mal nicht, vermute ich eher die Qnap selbst als Problem. Ich habe die Firmware in Verdacht. Neu aufsetzen kann ich die nur mit einen bootfähigen Linux Stick oder gibt es einen anderen Weg. Auf Verdacht hin würde ich ungern das Raid platt machen und dann feststellen, dass es daran nicht lag.

Ja den Test auf defekte Blöcke haben alle bestanden. Das sin keine Red HDDs sondern die noch hochwertigeren Datencenter HDDs. Ja den Test auf defekte Blöcke haben alle bestanden. Ich bekomme aber nicht raus, welche HDD von den 4en eine Macke haben könnte oder. Weil 4 Stck. beim Hersteller reklamieren, machen die bestimmt nicht mit auf Verdacht.

Hallo zusammen,

wir nutzen eine QNAP TS 469 Pro, die bis vor eine Woche problemlos lief. Seither haben wir erhebliche Probleme. Zum einen können wir per Netzlaufwerk nicht mehr zugreifen. Die Probleme fingen eigentlich im Zuge eines Firmwareupgrades auf 4.3.4.1652 an. seither stand das Dateisystem mittlerweile mehrfach auf schreibgeschützt. Wir haben nun in 2 Schritten auf die letzten beiden niedrigeren gedowngradet. Bei den zig Neustarts kommt hin und wieder "Dateisystem nicht clean". Nach einer Dateisystemüberprüfung waren beide Meldungen wieder verschwunden. Soweit so gut. Seit Samstag können wir über die Netzlaufwerke nicht mehr zugreifen. Ich kann in der Qnap aber unter Microsoft Netzwerk > erweitert nur bei "Höchste Version" SMB 1 wählen. Zwischenzeitlich bei einem Neustart konnte ich hier 2.1 und 3 per Dropdown wählen, aber nur 1 Mal. Die Platten ( 4 x WDC WD2005FBYZ-01YCBB3 RR09) haben erst 250 Betriebsstunden. Kurios ist weiterhin, dass der Malwarescanner auch hin und wieder nicht startet, weil angeblich Python nicht installiert ist. Jemand eine Idee?

Gruß Oliver