@Garmzon Menar du silent korruption (dvs omärkligt korrupta filer som kopieras) eller att filerna inte går att läsa alls i ditt fall, eller rent av att filsystemet som sådan inte går att läsa ?
Hårddiskar gör sällan korrupta sektorer av sig själv utan istället genererar IO-error när datat inte är läsbart av någon orsak - inte heller att de ger en 'massa korrupta data', bara en mer eller mindre mängd IO-error pga. oläsbar data - om det är läsbar men korrupt data så är det ditskrivet tidigare av programmet/filsystemet som skrivit datat till disken.
felrättningen är mycket stark i SSD och snurrdiskar och en miss-korrigerad sektor eller felaktig sektor som går igenom oupptäckt är extremt sällsynt - typ minst 100000 mer sällsynt är att du får en oläsbar sektor. Dataskyddet som går igenom SATA-kabeln är betydligt klenare än hårddiskens egna skydd då det bara skyddas av en 32-bit CRC-summa per 512-byte och enligt T10 räknar man med ca 4.5 oupptäckta fel per år när man läser kontinuerligt 500 MB/s per Sata-länk dygnet runt.
Dock - har du lagrat data på SD-minnen eller USB-stickor, så gäller dessvärre inte ovanstående resonemang utan det kan ge silent error i massor...
----
@ZaInT
Vilken topologi hade du på diskarna - i avseende de olika diskstorlekarna, du skrev RAID5, men...
Med 2 8:or och 2 6:or så kanske man partitionerat 8:orna som 6TB-partitioner tillsamman med 6TB-diskarna blir en RAID5 och de kvarvarande 2TB på 8:orna används inte - eller ?
Det finns dock ett problem med arrangemanget med 4st 6TB partitioner i RAID5 och det blir 18 TB synligt plats tillsammans - du vill inte ha filsystem över 16 TB på en 32-bitars system som sagda Netgear RN204.
Detta gäller i stort sett alla NAS med 32-bitars OS (läs i stort sett alla med ARM-processorer) att de inte kan hantera filsystem med storlek över 16TB även om filsystemen som sådan klarar mycket mer. och detta gäller både ext4 och BTRFS och kör man större filsystem än 16TB bara för att det gick att formatera för det så kommer det jättesurt när man fyller disken och passerar 16TB-gränsen - går filsystemet till read-only (dvs du kan inte längre skriva filer på NAS:en - gör backup på rubb och stubb igen - varenda fil på Nasen _utan_ att stänga av NAS:en - för starta du om Nasen nästa gång så är filsystemet förlorad för alltid !!! Varning alltså!!!
Problemet är att många av dom här systemen har inga spärrar för detta när man skapar filsystemen eller varnar för det då det inte för så länge sedan var drömnivå att kunna skapa filsystem över 16 TB när största diskarna låg på 4 TB...
---
Gissar att det är MDADM som krachat vilket tyvärr kan hända och filsystemet ovanpå är då helt utlämnad åt MDADM.
MDADM kan teoretisk göras mer resilient mot plötsliga avbrott då det finns en betaversion för journalskrivning (lite som "slog" i zfs) - men plats måste reserveras i samband med skapandet av RAID och det är dyrt prestandamässigt så därför är det inte påslaget av de flesta distributionerna default eller ens ger möjligheter till detta - men om någon frågar mig så är Gigabitethernet flaskhalsen i en NAS och bandbredden till diskarna för en journal bör inte vara ett problem, så varför är det inte påslaget kan man fråga sig?
Kan du få ihop mdadm-raiden (i Read Only!) så att imagen av BTRFS är läsbar i någon kombination av diskarna i degraded mode i mdadm ? - man bör få till den virtuella enheten att man kommer åt den liggande BTRFS-imagen i ett stycke sas. - i värsta fallet läsa ut till annan media...
Sedan skulle jag prova att montera btrfs-imagen i readonly eller RW på en _kopia_ av imagen (inte i NAS:en utan på en riktig dator/laptop med en modern distribution och uppdaterad BTRFS och btrfs-tools i denna), skulle inte alls bli förvånad om efter en stunds skrotande faktiskt får upp ett fullt fungerande filsystem - min erfarenhet är att BTRFS är förbaskat stryktålig och det värsta som kan hända är att du tappat senaste 30 sekundens transaktion då den rullat tillbaka till en tidigare om den sista inte kunnat slutföras.
Sedan om ovanstående inte skulle fungera finns det en off-line filräddningsverktyg i btrfs-tools kedjan som när jag provade för ett par år sedan på en avsiktlig sabbad BTRFS där jag fick ut det mesta av datat (utom det som skrevs sönder förstås) - det tar helvetes tid och man bör få med alla flaggor som man anser nödvändiga för tex tidsstämplar och behörighet redan från början när man startar räddningsverktyget då det är efter lång tid lite snopet att man fick tillbaka filerna, filhierakin, men alla med 'dagens' datum - men ut kom filerna till slut och med filhireakin i behåll - mer än vad man kan säga om de olika kommersiella NTFS-filräddningsprogrammen kan åstadkomma när $MFT är skadad/borta... Nu är det inte säkert att korruptionen av filsystemet pga. strömavbrott är samma typ som jag provade med. Men kanske värt ett prov...
En sak som man bör gå in och göra preventivt och när man skapar sina (BTRFS) volymer i sin köpenas - även i värsta fallet manuellt via SSH om/när GUI inte tillåter det - se till att BTRFS har DUP (vid '1-disk' som filsystem liggande på en MDADM-RAID) / RAID1 (vid flerdisk där BTRFS själv rår om diskarna) på sin metadata påslaget - det ökar överlevnadschansen mångfald vid plötlig avbrott då sannolikheten är mindre att hinna skriva sönder två olika metadata på två olika fysiska ställen samtidigt när strömmen försvinner...
För konvertering av en BTRFS liggande på en MDADM kan man tex. använda "btrfs fi balance start -mconvert=dup /mountpunkt" för detta när man konverterar metadata till DUP i SSH-promten och överliggande systemet kommer inte att veta om det i senare användning utan det bara sker...