Tittar du runt i NAS:ens webgränssnittet så finns SMART under 'Performance' och du får hovra över färgpunkten med musen för respektive disk så kommer listan fram.
Du anger 3 diskar - är dessa i RAID5, fungerar alla diskar eller är någon eller fler borta ?? - är det jbod och en disk borta så är filsystemet ej räddningsbar om en disk saknas.
Har du hållit firmware konstant uppdaterad ??
Tidigt så fanns det problem med 32-bitars OS och filsystem som är större än 8 eller 16 TB storlek vilket har varit ett klassiskt problem med 32-bitars OS av oavsett sort och tillverkare
---
Kutymen när man hanterar havererade filsystem är att man först gör diskimage-kopior av samtliga inblandade diskar innan man gör något annat alls - och då i RAW-format - detta gör man helst i linux och med ddrescue ifall det är läsproblem på diskarna - och eftersom du har 3 st 4TB diskar så behövs minst 12TB + lite marginal på annan lagring för att husera dessa diskimages - dessa är din försäkring och kunna återställa innehållet på diskarna till status som de var innan ifall du gör 'screw up' på dina 3 diskar senare - och du kommer troligen att göra 'screw up' om du inte är van med sådana saker.
Det finns 'btrfs restore' om du skall försöka mjölka ut data ur disk-setet till en annan lagringsplats, det reparerar inte filsystemet - bara hämtar ut filerna. Glöm inte flaggor om du skall behålla filernas datumstämplar mm.
Men detta gör du helst inte i själva nasen utan på en dator med diskarna anslutna via SATA eller USB-dockor av erkänt fungerade modell[1]
Det beror på att modern linux med BTRFS stöd (vilket är default idag) har betydligt modernare hjälpprogram att tillgå än de som finns i NAS:en.
ReadyNAS använder som alla andra nastillverkare (som synology/Qsnap) en mdadm-RAID i botten och på denna finns BTRFS-filsystemet.
Först måste man få mdadm-raiden sätta ihop diskarna och det gör tex en ubuntu-live på en USB-sticka automagiskt om det inte är någon disk som är fel eller saknas. och finns det efter detta en läsbar BTRFS så kommer den också att monteras automatiskt under /media/användare/volymnamn. eftersom det är en automatisk process så innebär det också att diskarna modifieras om allt går bra (kom ihåg varför man först gjorde diskimage-backup innan!!) - och har du tur kan du nu tanka ut dina filer och hela 'filräddningsprocessen' avklarad.
Ibland vill man inte att allt skall gå automatisk utan styra alla momenten själv och då är det bättre att jobba via tex. https://www.system-rescue.org/Download/ som bränns på USB-sticka och startas ifrån - men i gengäld får man själv läsa på hur alla kommandon som behövs fungerar som i det här fallet för mdadm-RAID för att sätta ihop diskarna och sedan läsa på om BTRFS hur den fungerar på detaljnivå och sedan montera BTRFS-filsystemet (om den inte är för skadad) alternativt extrahera data ur filsystemet med 'btrfs restore' - gör absolut inga försök att reparera filsystemet med 'btrfs check' innan du har gjort diskimage-kopia av samtliga diskar innan - Detta med att skapa diskimage-kopior gäller alla filsystem man försöker rädda data ur eller provar att reparera på - då reparationer med skador över en viss nivå oftast istället förvärrar det ordentligt och efter 2-3 gånger bli helt oräddningsbart - som Microsofts chkdisk är mycket välkänd för att göra när skadorna når över en viss nivå eller av mer ovanliga slaget.
[1] tex. deltacos dubbel-diskdockor är tyvärr jmicron och de är kroniska på att hänga sig och kräver bus-reset över USB innan de startar igen - vilket Linux gör automagisk men tar upp till 30 sekunder innan den gör det och får man hängning typiskt 1 ggr i minuten vid stora filöverföringar så blir det väldigt irriterande... de med 'asmedia' upplever jag fungerar bättre men det det är inte lätt innan köp att finna ut vilken chipset de har i sig när man tittar ut diskdockor och den vägen kan undvika alla de med jmicron i sig då det ofta inte står något alls om det.
