Qnap TS-1635AX startar inte längre.

Vad körde diskarna för filsystem? Är det btrfs så kan man rädda data genom en recovery av diskarna då btrfs har inbyggd sådan i filsystemet. Det viktiga är att vara säker på att det är strul i filsystemet och inte något huvud som slirar på spåren dock. Sedan så ska man köra diskarna i read only mode. Helst så ska man använda sig av avbilder så man kan göra om om man gör fel.

Hur stora är diskarna? En ide är att ta en avbild av dom och sedan återskapa dom.
En maskin med Linux kan återskapa dom eller montera dom då det är samma RAID-system.

Hoppas att du tog diskimage på alla diskarna och SSD innan du börja prova med olika omstarter... och efter hoppas att alla SSD var satta som write-trough och inte satta som write-back... för ett företag så är att köpa 10 nya diskar för att göra diskimage av alla befintliga diskar den lilla kostnaden i jämförelse med en havererad filsystem (som man inte har backup på) som kanske blev ej räddningsbar för att man var lite för snabb med on/off-knappen ala norsk reset...

är SSD/NVMe-cache inblandat så blir jag nervös då jag sett vad som händer med bcache när en dylig sådan SSD havererade i en hårdlast-prov och var satta i write-back-mode - inget var räddningsbart på backbone-diskarna bara för att en stor del av filsystemets metadata hade aldrig skrivits ut på disken och det som fans var väldigt inkonsistent och utdaterat. nu arbetar inte ZFS på samma sätt men de är väldigt känsliga ifall sådana saker går sönder när felen är mer än var partitetsdiskarna kan täcka upp.

QSNAP använder inte BTRFS då de brände på sig denna innan filsystemet var riktigt moget (eller mer egen klanteri som att de inte har provat det ordentligt med massor av olika felsceniario innan det gick in i produktion) och företaget har varit rent hatiska mot det sedan dess, utan i dom enklare modellerna så är det ext4 som används och de mer företagsinriktade är det ofta ZFS.

Med tanke på hur mycket SSD/NVMe-cache det verkar vara så är det troligen det sistnämnda och är grundorsaken SSD/NVMe som gett upp så kan det bli riktigt jobbigt.

Och en sönderkörd ZFS för att för många SSD eller för många diskar kraschat är väldigt mycket svårare att rädda data ur än mer traditionella filsystem och bygger på att man har ofta uppdaterade backupper istället.

Jag skulle råda dig att konsulta någon som är väl bevandrad i ZFS innan du börja starta om vidare om lagringen har ZFS som filsystem och det fins risk att du redan ställt till med en massa saker när du började rycka i SSD och sedan startade om dessa med och utan...

Är det ext4 som filsystem så skulle jag köpa knippe med USB-dockor och sätta diskarna i dessa (efter man tagit diskimage på dessa), på en på USB-sticka LINUX - gärna av dataräddningstyp (för att inget startar automatiskt, vilket det gör med tex ubuntu då udev skannar enheter och försöker montera dessa automatiskt och därmed också skriver på diskarna och det är inget man vill om man skall ägna åt dataräddning utan allt skall vara i read-only) läsa lite på hur mdadm-RAID, LVM och LVM2 - vilket som nu används för RAID-konfigurationerna och sedan hoppas på det bästa.

Slutligen en RAID10 har bara 1-2 diskars bortfalls-skydd - dvs. det fins kombinationer där man klarar 2 diskar bortfall och andra bara klarar en disk bortfall och är man krass så är RAID10 bara 1-disk paritets-skydd.

Vad vad det för filsystem på dessa ??? ext4 på dessa storlekar låter lite mastigt.

och har du något matnyttigt du vill delge när det gäller hur man kliar huvudet på sådan katt

hur verkar skicket på SSD - enterprise-SSD eller vanliga prosumer-modeller.

vet du var det är för typ av SSD-cache som används - bcache ?? eller är det ZFS egna rutiner

Om SSD:a går jättretröga att läsa och framförallt skriva till när du senare testar dem i diskdocka så känner jag igen problemet då du har troligen fått en FTL-databasförgiftning (flash-translation layer) - det har till och ifrån varit mer eller mindre allvarliga buggar på dessa i olika serier och modeller av SSD/NVMe över åren och även inom enterprise-klass som kan göra att det går långsammare och långsammare och långsammare att skriva till dessa och till sist blir utkickade för att de inte svarar alls.

Problemet är att det går inte att hitta info om det då tillverkarna av flash-lagringen verkligen inte vill skylta om sådana svagheter i sina produkter utan i princip måste man prova fram med att skriva våldsamma mängder 4K sektorer i olika mönster och det behöver inte att vara random-mönster som utöser problemet.

Det som jag vet knäcker fort SSD som är känsliga för den typen av nedgång är att man kör BTRFS-disk via bcache (med sagda SSD) som är fylld med olika disk-images och som man sedan med programmet 'bees' lågnivå-deduplicera BTRFS-filsystemet - funkar det efter 2-3 dygn så är det förmodligen ingen fara med just den serien SSD/NVMe, kraschar det och blir utkastade inom ett dygn så har det bevisat att den inte pallar för jobbet. - ofta behöver man göra full secure erase på dessa SSD efter en sådan test innan de början bete sig som förväntat i respons och prestanda.

---

Grattis i alla fall att du fick igång det i alla fall och förstås att säkra backupper av det i framtiden även om 120 TB storlek är nästan på nivå att överväga en bandrobot för backupper någonstans.