Ich würde direkt die beiden auffälligen Platten entfernen, das RAID neu aufsetzen und die Daten vom BackUp einspielen.
War am Ende des Tages auch die Lösung.
Wo wird das Teil eingesetzt wenn es kein Zeitfenster für ein Raid Neuaufbau (24h) gibt und Backup Rückspielen (24h) gibt?
Bei mir Zuhause - Always On lautet hier die Devise. Interne SLAs müssen eingehalten werden 
Danke für eure Mühen! 
Das sind die Spanning RAID1 md9 und md13, die kann man auch noch mit nur einer funktionierenden Platte wiederherstellen. Da sind aber keine Userdaten drauf.
nene, er liest die alte 3TB Platte (das RAID1 besteht aus zwei SSDs 128GB)
Edit: achso sorry hatte ich wahrscheinlich falsch verstanden. D.h. über eine Platte werden immer mehrere RAID gelegt, aufgrund der Systemdaten etc.?
Wenn ich die Platte heraus nehme, dann sehe ich auch, dass diese partitioniert wurde.
Ich denke über den richtigen mdadm Befehl lässt sich das wieder fixen, werde heute Abend mal die Manpage durchgehen.
2023-01-20 20:31:56 +01:00 <5> [47925.796365] sd 2:0:0:0: [sdg] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)Ziemlich seltsam alles. Finds eigentlich etwas schade, RAID wiederherstellen sollte eigentlich default sein. Es steht derzeit noch ein SoftwareUpdate an. Das führe ich mal durch und berichte anschließend. Ich gehe jedoch davon aus, dass sich hier nichts ändert, am generellen RAID Handling wird sich nichts geändert haben.
Bin gerne für weitere Tipps bereit 
moejoe : sieh mal, ob Du in /mnt/HDA_Root eine Zuordnung von Platten zu devices findest.
sorry, kenn mich im QNAP Filesystem nicht so gut aus aber im kmesq habe ich dieses interessante log gefunden, schaut so als ob rebuild complete wäre, an der UI kommt das jedoch nicht an.
/mnt/HDA_ROOT/.logs/kmsg
2023-01-20 20:30:00 +01:00 <2> [47810.121430] md/raid1:md13: Disk failure on sdg4, disabling device.
2023-01-20 20:30:00 +01:00 <2> [47810.121430] md/raid1:md13: Operation continuing on 5 devices.
2023-01-20 20:30:00 +01:00 <6> [47810.133401] md/raid:md13: report qnap hal event: type = HAL_EVENT_RAID, action = SET_RAID_PD_ERROR
2023-01-20 20:30:00 +01:00 <6> [47810.142429] md/raid:md13: report qnap hal event: raid_id=13, pd_name=/dev/sdg4, spare=/dev/(null), pd_repair_sector=0
2023-01-20 20:30:06 +01:00 <4> [47816.725062] Check proc_name[ahci].
2023-01-20 20:30:06 +01:00 <4> [47816.728923] Check proc_name[ahci].
2023-01-20 20:30:10 +01:00 <4> [47820.052220] ---- NAS_Disk_Hot_Remove(enc_id=0, port_id=3) finished.
2023-01-20 20:31:43 +01:00 <4> [47913.742253] ata3: SERR_PHYRDY_CHG SERR_DEV_XCHG. Clear the bit/burst error record
2023-01-20 20:31:43 +01:00 <4> [47913.749799] ata3: SERR_PHYRDY_CHG SERR_DEV_XCHG. Clear the bit/burst error record
2023-01-20 20:31:54 +01:00 <3> [47924.515044] ata3: softreset failed (device not ready)
2023-01-20 20:31:54 +01:00 <4> [47924.520169] ata3: SERR_PHYRDY_CHG SERR_DEV_XCHG. Clear the bit/burst error record
2023-01-20 20:31:55 +01:00 <6> [47925.677229] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 330)
2023-01-20 20:31:55 +01:00 <6> [47925.729638] ata3.00: ATA-9: WDC WD30EZRX-00SPEB0, 80.00A80, max UDMA/133
2023-01-20 20:31:55 +01:00 <6> [47925.736400] ata3.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 32), AA
2023-01-20 20:31:55 +01:00 <6> [47925.744084] ata3.00: configured for UDMA/133
2023-01-20 20:31:55 +01:00 <4> [47925.748634] Check proc_name[ahci].
2023-01-20 20:31:55 +01:00 <5> [47925.752103] scsi 2:0:0:0: Direct-Access WDC WD30EZRX-00SPEB0 80.0 PQ: 0 ANSI: 5
2023-01-20 20:31:55 +01:00 <6> [47925.760579] ata3.00: set queue depth = 32
2023-01-20 20:31:55 +01:00 <5> [47925.764847] scsi 2:0:0:0: Serial Number: WD-WCC4E2XD1L2X
2023-01-20 20:31:55 +01:00 <4> [47925.774679] Check proc_name[ahci].
2023-01-20 20:31:55 +01:00 <4> [47925.774815] Check proc_name[ahci].
2023-01-20 20:31:55 +01:00 <5> [47925.782279] sd 2:0:0:0: Attached scsi generic sg6 type 0
2023-01-20 20:31:55 +01:00 <4> [47925.782692] Check proc_name[ahci].
2023-01-20 20:31:55 +01:00 <4> [47925.791107] Check proc_name[ahci].
2023-01-20 20:31:56 +01:00 <5> [47925.796365] sd 2:0:0:0: [sdg] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
2023-01-20 20:31:56 +01:00 <5> [47925.804189] sd 2:0:0:0: [sdg] 4096-byte physical blocks
2023-01-20 20:31:56 +01:00 <5> [47925.814079] sd 2:0:0:0: [sdg] Write Protect is off
2023-01-20 20:31:56 +01:00 <7> [47925.818957] sd 2:0:0:0: [sdg] Mode Sense: 00 3a 00 00
2023-01-20 20:31:56 +01:00 <5> [47925.819267] sd 2:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
2023-01-20 20:31:56 +01:00 <6> [47925.913980] sdg: sdg1 sdg2 sdg3 sdg4 sdg5
2023-01-20 20:31:56 +01:00 <5> [47925.922610] sd 2:0:0:0: [sdg] Attached SCSI removable disk
2023-01-20 20:31:56 +01:00 <4> [47925.928147] Check proc_name[ahci].
2023-01-20 20:31:56 +01:00 <4> [47925.931577] Check proc_name[ahci].
2023-01-20 20:31:56 +01:00 <3> [47925.935140] gpio-keys gpio-keys: Failed to request GPIO 399, error -517
2023-01-20 20:32:24 +01:00 <4> [47954.222584] ---- NAS_Disk_Hot_Add(enc_id=0, port_id=3) start.
2023-01-20 20:32:29 +01:00 <6> [47959.125566] md: recovery of RAID array md9
2023-01-20 20:32:29 +01:00 <6> [47959.129711] md: Recovering started: md9
2023-01-20 20:32:29 +01:00 <6> [47959.133611] md/raid:md9: report qnap hal event: type = HAL_EVENT_RAID, action = REBUILDING_START
2023-01-20 20:32:29 +01:00 <6> [47959.142462] md/raid:md9: report qnap hal event: raid_id=9, pd_name=/dev/(null), spare=/dev/(null), pd_repair_sector=0
2023-01-20 20:32:30 +01:00 <6> [47960.476987] md: recovery of RAID array md13
2023-01-20 20:32:30 +01:00 <6> [47960.481241] md: Recovering started: md13
2023-01-20 20:32:30 +01:00 <6> [47960.485200] md/raid:md13: report qnap hal event: type = HAL_EVENT_RAID, action = REBUILDING_START
2023-01-20 20:32:30 +01:00 <6> [47960.494104] md/raid:md13: report qnap hal event: raid_id=13, pd_name=/dev/(null), spare=/dev/(null), pd_repair_sector=0
2023-01-20 20:32:36 +01:00 <4> [47966.574030] ---- NAS_Disk_Hot_Add(enc_id=0, port_id=3) finished.
2023-01-20 20:32:51 +01:00 <6> [47981.435507] md: md13: recovery done.
2023-01-20 20:32:51 +01:00 <6> [47981.439154] md: Recovering done: md13
2023-01-20 20:32:51 +01:00 <6> [47981.442866] md/raid:md13: report qnap hal event: type = HAL_EVENT_RAID, action = REBUILDING_COMPLETE
2023-01-20 20:32:51 +01:00 <6> [47981.452020] md/raid:md13: report qnap hal event: raid_id=13, pd_name=/dev/(null), spare=/dev/(null), pd_repair_sector=0
2023-01-20 20:33:00 +01:00 <6> [47990.547310] md: md9: recovery done.
2023-01-20 20:33:00 +01:00 <6> [47990.550856] md: Recovering done: md9
2023-01-20 20:33:00 +01:00 <6> [47990.554477] md/raid:md9: report qnap hal event: type = HAL_EVENT_RAID, action = REBUILDING_COMPLETE
2023-01-20 20:33:00 +01:00 <6> [47990.563572] md/raid:md9: report qnap hal event: raid_id=9, pd_name=/dev/(null), spare=/dev/(null), pd_repair_sector=0[/mnt/HDA_ROOT] # cat .conf
hw_addr = 24:5E:BE:26:67:2A
QNAP = TRUE
mirror = 0
hal_support = yes
sm_v2_support = yes
pd_dev_wwn_50025388A043DF37 = 0x1
pd_dev_wwn_50014EE261688CD1 = 0x2
pd_dev_wwn_50014EE261D345B8 = 0x3
pd_dev_wwn_50014EE26338807D = 0x4
pd_dev_wwn_50025388A043E5B2 = 0x6
nas_capability = 0x1
pd_dev_wwn_5000C500C415C24F = 0x5
pd_dev_wwn_5000C500ED63E68E = 0x3
pd_dev_wwn_5000C500ED63AD26 = 0x3
[SSD_SETTING]
ssd_warned_wwn_50014EE261D345B8 = 0
ssd_warned_wwn_5000C500ED63E68E = 0
ssd_warned_wwn_5000C500ED63AD26 = 0Oder was genau wollt ihr sehen?
pasted-from-clipboard.png
Mod: Unnötiges Volltext-/Direktzitat gekürzt! 
Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
Wie jetzt? Du hast beide gemeldete Platten aus dem Raid?
Nein, ich teste derzeit nur mit dem SLOT3, SLOT4 wird nicht angefasst.
Mir ist klar, dass sobald die zweite Platte ausfällt alles weg ist.
Gute Idee, leider negativ, selbes Fehlerbild.
Mod: Zitat ohne Quellenangabe ... korrigiert! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
S.M.A.R.T. - Werte dienen ja erst einmal nur zur Information. Defekte Sektoren sind erst einmal auch nicht schlimm, HDDs haben Ausweichsektoren.
Danke du sprichst mir aus der Seele
RAID Gruppe neu aufbauen verlangt zwei neue Datenträger. Soweit ich das verstanden habe wäre dies wenn ich aus einen RAID5 ein RAID 6/RAID60/whatever machen würde. Ich bin mir nicht sicher ob ich externe Links teilen darf. Wenn man nach den Stichworten "raid mdadm qnap" googelt, dann kommt man auf eine PDF welche ähnliches erklärt, allerdings bin ich mir nicht sicher wie bei mir der korrekte Befehl lauten würde.
Im Beispiel ist folgendes erklärt.
Mod: Zitat ohne Quellenangabe ... bitte nachreichen, ansonsten wird das Zitat gelöscht! Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
Zitat# mdadm –CfR /dev/md0 –l 5 –n 4 missing /dev/sdb3 /dev/sdc3 /dev/sdd3”
Zwingt das RAID md0 mit Level = RAID 5; Festplatten Anzahl = 4 und ohne die erste
Festplatte zu starten
Bei mir handelt es sich jedoch nicht um die erste Platte die nicht korrekt erkannt wird, sondern um die dritte.
Okay, wie kannst du dir das erklären, dass die Festplatte 3 nicht im Raid Verbund ist, auch kann ich mit der Fesplatte keinen neuen Speicherpool erstellen!?
Die Platte ist neu, wurde geprüft über das QNAP NAS (Datenträgerprüfung), dennoch kann ich diese nirgends einbinden.
Das hat aus meiner Sicht nichts mit SMART Werten zu tun.
Anbei der Screenshot
pasted-from-clipboard.png
Das RAID ist nicht hin - seit der ersten Meldung und dem Einbau sind 3 Wochen vergangen. Das RAID war in der Zeit weder herabgestuft noch auf Warning (mehrere Neustarts zwischendurch waren problemlos möglich).
Das einzige Problem das ich aktuell habe, ist dass die Platte 3 nicht erkannt wird (siehe Screenshot). Fraglich ist lediglich wie ich die Platte wieder aufnehmen kann, sodass der Rebuild starten kann.
Würde ich die Platte 4 raus nehmen wäre das RAID hin 
Danke für die schnelle Antwort!
Backup ist da, 8TB Daten will ich nur ungern wieder zurücksichern.
Die Festplatten sind noch in Ordnung, lediglich SMART Werte waren auf Warning. Das heißt nicht zwingend dass die Platte morgen kaputt geht.
Die Daten sind auch noch da, das RAID ist derzeit auf "herabgestuft", nicht auf "Fehler".
Evtl. könnte man versuchen mit mdadm -a und den devices sdb, sdc und sdd versuchen das Raid wiederherzustellen.
Fraglich ist nur welches die vierte Platte ist?
Hier noch in Paar Screenshot
pasted-from-clipboard.png
pasted-from-clipboard.png
Datenträger 3 ist getauscht, Datensträger 4 hat noch die SMART Wert auf Warning und muss anschließend getauscht werden
pasted-from-clipboard.png
Hallo zusammen,
ich habe ein TS-653A mit zwei Speicherpools am Laufen. Raid1 (SSD 1&6), Sowie RAID5 (HDD2-5). Das Raid5 macht aktuell Probleme. Zwei der Platten (HDD3,HDD4) standen aufgrund der SMART Werte auf Warning. Daraufhin habe ich zwei neue Platten bestellt.
Im Laufenden Betrieb habe ich dann Festplatte 3 entfernt, kurz gewartet und die neue wieder eingesetzt. Raid wurde herabgestuft, ein Rebuild fand jedoch nicht statt. Nach einiger Wartezeit habe ich das NAS neu gestartet. Jetzt ist das Raid immer noch herabgestuft und die Platte wird in der GUI als "Kein Mitglied angezeigt".
Ich habe schon einiges versucht, leider ohne Erfolg.
- Unzählige Neustarts
- Alle Partitionen auf der neuen Platte gelöscht
- die zweite neu gekaufte Platte eingesetzt - auch ohne Erfolg.
Die neuen Platten sind 4TB Seagate IronWolf NAS Platten
Anbei einige Daten vom Script (IP Konfigurationen habe ich entfernt).
Habt ihr eine Idee was ich noch machen kann?
Gerne auch CLI Befehle, bin mit Unix nicht auf Kriegsfuß.
Danke schonmal vorab!
Viele Grüße
MoeJoe
[/tmp] # md_checker
Welcome to MD superblock checker (v2.0) - have a nice day~
Scanning system...
RAID metadata found!
UUID: 8e6e51d2:960e9d53:7a9d553a:be830e86
Level: raid0
Devices: 2
Name: md2
Chunk Size: 512K
md Version: 1.0
Creation Time: Sep 9 14:59:41 2019
Status: ONLINE (md2) raid0
===============================================================================================
Enclosure | Port | Block Dev Name | # | Status | Last Update Time | Events | Array State
===============================================================================================
NAS_HOST 1 /dev/sda3 0 Active Sep 9 14:59:41 2019 0 AA
NAS_HOST 6 /dev/sde3 1 Active Sep 9 14:59:41 2019 0 AA
===============================================================================================
RAID metadata found!
UUID: 68e72fca:bbefa00f:7b9b42a3:c33d9226
Level: raid5
Devices: 4
Name: md1
Chunk Size: 512K
md Version: 1.0
Creation Time: Sep 9 13:57:00 2019
Status: ONLINE (md1) [U__U]
===============================================================================================
Enclosure | Port | Block Dev Name | # | Status | Last Update Time | Events | Array State
===============================================================================================
NAS_HOST 2 /dev/sdb3 0 Active Jan 20 18:05:22 2023 224217 A.AA
---------------------------------- 1 Missing -------------------------------------------
NAS_HOST 4 /dev/sdc3 2 Active Jan 20 18:05:22 2023 224217 A.AA
NAS_HOST 5 /dev/sdd3 3 Active Jan 20 18:05:22 2023 224217 A.AA
===============================================================================================
*********************
** QNAP NAS Report **
*********************
NAS Model: TS-653A
Firmware: 5.0.0 Build 20211221
Workgroup: NAS
Base Directory: /share/CACHEDEV1_DATA
HDD Information:
/dev/sda Model=SAMSUNG MZ7TE128HMGR-00000 , FwRev=EXT0100Q, SerialNo=S1FCNSAF502093
/dev/sdb Model=WDC WD30EZRX-00SPEB0 , FwRev=80.00A80, SerialNo= WD-WCC4E3CHSAPK
/dev/sdc Model=WDC WD30EZRX-00SPEB0 , FwRev=80.00A80, SerialNo= WD-WCC4E1SYAK7V
/dev/sdd Model=ST6000DM003-2CY186 , FwRev=0001 , SerialNo= ZCT1LQ9M
Disk Space:
Filesystem Size Used Available Use% Mounted on
none 400.0M 283.7M 116.3M 71% /
devtmpfs 7.8G 4.0K 7.8G 0% /dev
tmpfs 64.0M 620.0K 63.4M 1% /tmp
tmpfs 7.8G 156.0K 7.8G 0% /dev/shm
tmpfs 16.0M 0 16.0M 0% /share
/dev/sdf5 7.8M 28.0K 7.8M 0% /mnt/boot_config
tmpfs 16.0M 0 16.0M 0% /mnt/snapshot/export
/dev/md9 493.5M 205.2M 288.3M 42% /mnt/HDA_ROOT
cgroup_root 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/mapper/cachedev1
396.7G 154.7G 241.5G 39% /share/CACHEDEV1_DATA
/dev/mapper/cachedev2
6.0T 4.9T 1.0T 83% /share/CACHEDEV2_DATA
/dev/mapper/cachedev3
149.4G 15.7G 133.2G 11% /share/CACHEDEV3_DATA
/dev/md13 417.0M 400.0M 17.0M 96% /mnt/ext
tmpfs 32.0M 27.2M 4.8M 85% /samba_third_party
tmpfs 4.0K 0 4.0K 0% /tmp/default_dav_root
tmpfs 48.0M 48.0K 48.0M 0% /share/CACHEDEV1_DATA/.samba/lock/msg.lock
tmpfs 16.0M 0 16.0M 0% /mnt/ext/opt/samba/private/msg.sock
/dev/mapper/vg1-snap20001
6.0T 4.9T 1.0T 83% /mnt/snapshot/2/20001
/dev/mapper/vg1-snap20014
6.0T 4.9T 1.0T 83% /mnt/snapshot/2/20014
/dev/mapper/cachedev1
396.7G 154.7G 241.5G 39% /lib/modules/5.10.60-qnap/container-station
tmpfs 100.0K 0 100.0K 0% /share/CACHEDEV2_DATA/Daten/VMs/Container/container-station-data/lib/lxd/shmounts
tmpfs 100.0K 0 100.0K 0% /share/CACHEDEV2_DATA/Daten/VMs/Container/container-station-data/lib/lxd/devlxd
Mount Status:
none on /new_root type tmpfs (rw,mode=0755,size=409600k)
/proc on /proc type proc (rw)
/proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /tmp type tmpfs (rw,size=64M)
tmpfs on /dev/shm type tmpfs (rw)
tmpfs on /share type tmpfs (rw,size=16M)
/dev/sdf5 on /mnt/boot_config type ext2 (rw)
tmpfs on /mnt/snapshot/export type tmpfs (ro)
/dev/md9 on /mnt/HDA_ROOT type ext3 (rw,data=ordered)
cgroup_root on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/cgroup/memory type cgroup (rw,memory)
/dev/mapper/cachedev1 on /share/CACHEDEV1_DATA type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv1,user_xattr,data=ordered,data_err=abort,delalloc,nopriv,nodiscard,noacl)
/dev/mapper/cachedev2 on /share/CACHEDEV2_DATA type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv1,user_xattr,data=ordered,data_err=abort,delalloc,nopriv,nodiscard,noacl)
/dev/mapper/cachedev3 on /share/CACHEDEV3_DATA type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv1,user_xattr,data=ordered,data_err=abort,delalloc,nopriv,nodiscard,noacl)
cpu on /sys/fs/cgroup/cpu type cgroup (rw,cpu)
/dev/md13 on /mnt/ext type ext4 (rw,data=ordered,barrier=1,nodelalloc)
tmpfs on /samba_third_party type tmpfs (rw,size=32M)
tmpfs on /tmp/default_dav_root type tmpfs (rw,size=1k)
tmpfs on /share/CACHEDEV1_DATA/.samba/lock/msg.lock type tmpfs (rw,size=48M)
tmpfs on /mnt/ext/opt/samba/private/msg.sock type tmpfs (rw,size=16M)
/dev/mapper/vg1-snap20001 on /mnt/snapshot/2/20001 type fuse (ro,nosuid,nodev,allow_other,default_permissions)
/dev/mapper/vg1-snap20014 on /mnt/snapshot/2/20014 type fuse (ro,nosuid,nodev,allow_other,default_permissions)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,none,name=systemd)
RAID Status:
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md2 : active raid0 sda3[0] sde3[1]
230147072 blocks super 1.0 512k chunks
md1 : active raid5 sdb3[0] sdd3[3] sdc3[2](F)
8760933888 blocks super 1.0 level 5, 512k chunk, algorithm 2 [4/2] [U__U]
md322 : active raid1 sdg5[3](S) sdd5[2](S) sdc5[1] sdb5[0]
7235136 blocks super 1.0 [2/2] [UU]
bitmap: 0/1 pages [0KB], 65536KB chunk
md256 : active raid1 sdg2[3](S) sdd2[2](S) sdc2[1] sdb2[0]
530112 blocks super 1.0 [2/2] [UU]
bitmap: 0/1 pages [0KB], 65536KB chunk
md321 : active raid1 sde5[2] sda5[0]
8283712 blocks super 1.0 [2/2] [UU]
bitmap: 0/1 pages [0KB], 65536KB chunk
md13 : active raid1 sdg4[33] sda4[0] sdd4[32] sde4[4] sdc4[3] sdb4[1]
458880 blocks super 1.0 [32/6] [UUUUUU__________________________]
bitmap: 1/1 pages [4KB], 65536KB chunk
md9 : active raid1 sdg1[33] sda1[0] sdd1[32] sde1[4] sdc1[3] sdb1[1]
530048 blocks super 1.0 [32/6] [UUUUUU__________________________]
bitmap: 1/1 pages [4KB], 65536KB chunk
unused devices: <none>
Memory Information:
MemTotal: 16302076 kB
MemFree: 9058432 kB
MemAvailable: 12515204 kB
NASReport completed on 2023-01-20 18:15:29 (./nasnotify.sh)Lesson learned - ab jetzt werden nur noch externe Platten ohne SMR gekauft 
. SMR scheint nicht ideal für ein NAS zu sein. Ich habe die Diskussion über SMR bisher nur am Rande verfolgt und dachte immer die Leute würden hier deutlich überreagieren, allerdings scheint es einen nicht zu unterschätzenden Anwendungsfall zu geben. Ich meine ein NAS das keine Reaktion mehr zeigt und bei dem man nur hoffen kann, dass ein reboot alles wieder repariert will hier wohl keiner haben.
Hier der genaue Typ:
ST6000DM003-2CY186
Anhand der Cache Größe müsste es eine HDD mit SMR sein (übrigens in der externen Version ca. 20€ günstiger als intern).
Hast du mir hierzu eine Erklärung (Link o.ä.). Würde das Verhalten gerne technisch verstehen.
lässt sich das technisch erklären oder ist das lediglich ein Bug von QNAP?
Hallo zusammen,
hier mal ein kurzer Erfahrungsbericht zur Erweiterung eines Raid 5 um eine weitere Festplatte (zugegeben, die Festplatten Konstellation ist nicht unbedingt ideal, dürfte jedoch meiner Meinung nach trotzdem nicht zu einem solchen "Ausfall" führen). Der Speicherpool war zu 95% voll und musste erneuert werden.
In der heutigen Zeit sind externe Festplatten günstiger als interne - da ich bereits gute Erfahrungen mit externen Festplatten im Dauereinsatz habe, wurde es auch dieses mal eine externe Festplatte.
Gehäuse entfernt und Platte ins laufende NAS gebaut. Aktuell läuft ein RAID 5 mit 3x3TB Platten (7200 RPM). Hinzu kommt nun eine 6TB Platte (5400 RPM). Aufgrund der Umdrehungszahl war mir bewusst, dass es hier zu Performance einbußen kommt. Dass diese Konstellation eigentlich nicht empfohlen wird, war mir auch klar.
Ich habe also die RAID Gruppe erweitert. Laut Statusanzeige migriert das RAID mit <10kb/s und braucht entsprechend 24594734 Stunden (Zunächst dachte ich das sich die Geschwindigkeit in kürze sicherlich deutlich erhöht). Kurze Zeit später war ich aus der Web UI geflogen und konnte mich nicht mehr einloggen. Per SSH war das NAS noch erreichbar, über die Passwort Abfrage kam ich jedoch nicht hinaus -> einloggen auch nicht möglich. Zugriff auf die Shares war auch nicht mehr möglich.
Nachdem 5 Tage später das NAS immer noch im selben Zustand war (Web UI & SSH war zwar erreichbar, allerdings war bei beiden das Einloggen nicht möglich (WEB UI lief irgendwann in einen Timeout, SSH selbst nach 2 Stunden kein Timeout/Fortschritt)), musste ich das NAS hart ausschalten. Nach ca. 10 Minütiger Startzeit war das NAS nun auch wieder voll erreichbar. Die RAID Gruppe migriert nun fröhlich und ist in unter 20h fertig.
Die restlichen 3TB Platten sollen zukünftig auch durch 6TB Platten (5400 RPM) ersetzt werden, sodass hier wieder eine ähnliche Festplatten Konstellation vorherrscht.
Aber kann mir jemand erklären, warum sich das NAS in einen solchen Zustand versetzt hat & wie man hier am besten vorgeht (wäre es evtl. besser gewesen die neue Platte wieder zu entfernen?).
Viele Grüße
Moejoe
Mod: Zitat ohne Quellenangabe ... korrigiert! Die Zitat Funktion des Forums richtig nutzen
Es ist nun mal nicht einfach, ein Backup (Snapshot) des Systems zu machen.
Mit Debian als OS und Veeam als Backup gelingt das grandios, selbst getestet.
Im nachfolgenden hast du deine Aussage ja quasi revidiert.
Mittlerweile ist jedes Linux/Windows System in der Lage ein Systemabbild zu erzeugen, inkl Application Awareness (wie es bei Veeam so schön heißt)
Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! Die Zitat Funktion des Forums richtig nutzen
Dann brauchst du auch kein QNAP, eher Proxmox.
Ich habe mir durch die "Appliance" Lösung eine Arbeitserleichterung erhofft. Qnap hat nichts desto trotz Vorzüge (Klicki Bunti, einfacher Sync zw. mehreren NAS Systemen, OVPN Integration, etc.), wird nun bei mir halt deutlich weniger Dienste verwalten als ursprünglich gedacht.
Jeder der eine App auf der QNAP verwendet muss sich nunmal bewusst sein, dass hiervon keine Datensicherung existiert.
Syno soll das doch können.
Nach nochmaliger Recherche gibt es das tatsächlich, soll jedoch aktuell noch nicht alles abdecken. Mittelfristig werde ich mir wohl die Mitbewerber genauer anschauen, sofern sich hier bei QNAP nichts tut.
Schade, eigentlich ein nogo. Es scheint so als ob Mitbewerber das auch nicht können soweit ich das aus diversen Foren entnehmen kann oder wisst ihr hier was gegensätzliche!?
Für mich die einzig sinnige Lösung ist auf möglichst viele Dienste seitens qnap zu verzichten und alles in VMs auszulagern.
Beispielsweise das Backup der Mails mittels qmailAgent bringt mir so herzlich wenig wenn die Bude brennt...
Hallo zusammen,
auf meinem QNAP laufen mittlerweile einige Dienste/Apps.
Ich habe diverse Einstellungen getätigt - Volumes erstellt, regelmäßige Snapshots, OVPN, etc.
Nun würde ich gerne ein regelmäßiges Backup vom kompletten NAS erstellen.
Beispielsweise sichere ich mittels QMailAgent meine Emails zusätzlich noch aufs NAS. Die Bilder vom Handy werden mittels Syncthing synchronisiert. Ein Emby Server läuft als Medienserver.
Gibt es eine Möglichkeit, sowohl Einstellungen, Apps als auch die Daten der Apps zu sichern und im Notfall wieder zu restaurieren?
Danke schonmal!
MoeJoe
Lassen wir den Portscanner bei Seite und nehmen an, ich nenne Dir direkt die URL um auf mein NAS zu kommen.
Du hast die QTS Anmeldemaske vor Dir ... und jetzt?
Gruß!Tim
ich melde mich mit dem Standard Admin Kennwort bei dir an!?
Falls es fehl schlägt, Kali Linux anwerfen, zunächst bruteforce starten, parallel Webserver version checken und nach bekannten Exploits suchen, ...
Freundlicherweise zeigst du auf der Login Seite die QNAP Version, ich suche mir ein passendes Exploit und auf gehts.
https://www.cvedetails.com/vul…ct_id-26806/Qnap-QTS.html
Standard Prozedere eines Angriffs halt, solange bis sich eine Lücke auftut.
Versteh ehrlich gesagt deine Aussage nicht aber hat ja eigentlich auch nichts mit dem Thema zu tun.
Zurück zum Thema.
Es gibt eigentlich mehrere Wege ein System sicher zu machen (abhängig von der Sicherheitsstufe).
1. Alles abschotten und von außen nicht erreichbar machen (am sichersten)
2. Alles abschotten und von außen nur via VPN erreichbar machen (relativ sicher)
3. Nur die notwendigsten Dienste nach außen erreichbar machen, rest entsprechend abschotten (je nach Konfig immer noch relativ sicher)
4. Alles nach außen hin erreichbar machen. (relativ unsicher)
Ich denke der Threadersteller will hier Stufe 3.
Dies erreicht er IMHO nur via Reverse Proxy+Firewall+ stets Upgedatete Software
In jedem halbwegs gut organisierten Unternehmen wird das so gelebt. Dienste ins Netz stellen ist immer ein Risiko, manchmal jedoch notwendig/gewünscht. Es wird jedoch versucht das Risiko möglichst zu minimieren, indem nur die notwendigsten Dienste public gemacht werden.
die einzige Möglichkeit ist ein Reverse Proxy + Firewall.
Ich habe bei mir eine opnsense am laufen, welche eine VPN Verbindung zu mir ins Netz macht.
Wenn mein Notebook via VPN verbunden ist, kann ich auf alles zugreifen (im internen Netz).
Die interne Domäne ist eine Subdomain meiner Toplevel Domain -> hier share.example.com.
Jeder hat Zugriff auf das share.example.com. Einloggen kann sich darauf jedoch niemand (da via Firewall sowieso nur Port 80/443 offen sind). Im Reverseproxy habe ich eine ganze Latte voller Deny Regeln gemacht, sodass niemand auf das Loginfenster kommt.
Reverseproxy ist bei mir der HA Proxy (opnsense Plugin).
Zusätzlich ist ein LetsEncrypt Zertifikat (eher der Schönheit wegen).
Via iPhone aufs NAS zugreifen klappt dank Bonjour/ZeroConf/mDNS leider aktuell noch nicht. Ich arbeite mich jedoch gerade an einem mdns Proxy ein^^
Zusätzlich ein sicheres Passwort + 2FA.
Nur via Reverseproxy + Firewall halte ich das Ganze für halbwegs sicher. Mit Ports "verstecken" (a la Port 52123) ist das IMHO nur eine Frage der Zeit bis ein Scanner mal auf den versteckten Port kommt.
Niemand kann sich ohne VPN anmelden, nur auf Shares zugreifen. Möglicherweise habe ich noch nicht alle URLs denied, die wirklich Sicherheitsrelevant sind, wir können jedoch gerne eine Liste anfertigen mit Deny-Regeln.
Apple/Android Diskussion würde ich mir hier gerne ersparen.
Es muss doch technisch möglich sein (wenigstens vom Browser) via iOS auf die Kiste zu kommen ohne Bonjour, sondern nur via IP. Irgendwer hier im Forum wird eine solche Konstellation ja sicher am laufen habe. Selbst mit aktiviertem Bonjour komme ich nicht per IP auf das Gerät. Nur die QNAP verhält sich so, alle anderen Geräte funktionieren taddellos. Deswegen vermute ich lediglich eine Einstellung auf der QNAP ist aktuell falsch.
Nächster Test wird mit Android gemacht, ich befürchte jedoch hier kommt dasselbe raus.
