Raid 0 disk har kraschat i Synology, hur kommer jag åt filerna?

Som redan skrivet - det blir inte bad sectors för att man skriver - bara det som läses. i ditt fall troligen metadata för filsystemet som den förväntades hitta och har troligen blivit stopp redan i lägsta lagret pga. IO-error från disken i mdadm-RAID som den troligen använder sig av. Filsystemet som används ovanpå mdadm-RAID volymen (brukar kallas liknande /dev/md127) är med största sannolikhet ext4.

Hade filsystemet varit BTRFS och med dubbel metadata (default vid formatering) så hade det förmodligen klarat sig, ja om inte mdadm-RAID i lagret under hade stoppat det innan och då kan inte BTRFS göra något åt situationen då den aldrig får chansen - däremot är chansen för dataräddning mycket hög senare när det läser från diskimages utan IO-error vid läsning.

När det skriver på disk så skrivs det om flertal försök på samma sektor om första skrivningen misslyckades, och sedan används reservsektorer tills skrivningen lyckas och det görs helt automatiskt av SATA-disken själv utan OS-hjälp (detta brukar ingen se mer än att det kanske ev. noteras i dmesg och vid senare titt i SMART ser att räknaren för reallokeringar ökat.)

moderna SATA-diskar har läshuvud några hundra nanometer bakom skrivhuvudet så verifieringen görs omedelbart samtidigt som det skrivs. Tyvärr lagar inte SATA-diskar några veka sektorer som hittas senare vid läsning - sådant gör bara SAS-diskar... ...därför om man i sin lagringssystem kan använda SAS-diskar så bör man göra det, speciellt nu med dagens stordiskar där det bara är hundralappar mellan en SAS och SATA-variant av samma disk, ibland kan tom. SAS vara billigare än SATA i olika kampanjer.

---

Som redan sagt gör Diskimage av diskarna och här säger jag 'ddrescue' i linux framför 'dd' för kopieringen av diskarna då den kan hantera läsfel på diskarna och har smarta strategier för det så att det inte läser sektorer med läsfel på rad (en fysisk 4K-sektor ger 8 logiska 512-bytes sektorer i rad - är den skadad så blir det 8 läsförsök med kanske 8-50 sekunders tid på varje 512-bytes sektor innan den försöker med nästa sektor i rad...) utan hoppar över ett stycke och går tillbaka till problemområdet först när allt annan är läst och där saxar in sig allt närmare den sista noterade läsfelet för att ta så mycket det går runt om innan den igen ger sig på de oläsbara sektorerna med många läsförsök, det kan ju gå att läsa en gång av många försök - och en gång räcker... och dessutom har ddrescue en viss 'nybörjarsäkerhet' att inte av misstag skriva direkt mot råa diskdevice - bara läsa.

Kom ihåg att ddrescue skall ha 3 filargument ( platsen för raw-devicet (/dev/sda), platsen där diskimage skrivs (/mnt/diskimage1.img), platsen för loggfil för diskimagen (/mnt/diskimage1.log)) - inte två, med loggfilen så startar ddrescue där det slutade sist om överföringen har brutits av någon orsak och försöker inte läsa redan utlästa sektorer från RAW-disken till diskimagen - diskar kan hänga sig, de kan behövas kylas, datorer kan hänga sig (HD/SSD som blockerar SATA-bus...) etc.

ddrescue med loggfil kan startas och stoppas som man vill - med flaggor kan den försöka läsa oläsbara sektorer med upprepande försök så länge man önskar och det finns folk som efter halvår fått ut 99.9% av disk som vid första körningen var typ 50 % läsbart.

Om läshuvuden har hoppat av bryggan av hårt vridande stöt pga. dålig transportpackning så finns inte en chans att diskarna fungerar ens vid första försöket - skivan kommer inte ens att snurra igång och disken är DOA.

så, vad är det för annat som kan göra att diskarna har problemområden, visst rejäl mekanisk misshandel i transport kan kröka axel på spindeln och diskstacken börja vobbla - men det lär märkas på fatalt sätt också i första starten...

vad är kvar - slag och stötar kan få partiklar att fara runt och sätta sig på skivorna - men å andra sidan är utrymmet inne i hårddisken bland det mest dammfria vi kan hitta och filtreras kontinuerligt under drift hela tiden.

Det som tydligen är bekymmer i HD-världen är olja - olja från spindellager främst. och det handlar om förgasad olja eller i fin aerosol som senare blir droppar på skivan - det är inga stora droppar, mindre än vad en ljusmikroskop skulle se, de ställer till med bekymmer för slädarna och läshuvudet. Det finns några 'papers' om det både från Seagate och någon mer tillverkare (HGST?) där man går rätt djupt ned i problemet och helt plötsligt är tätningarna kring axlar till spindeln en ingenjörsmässig utmaning.

När spindeln snurrar så är det väldigt liten risk att olja tar sig ut då det är massor av skruvar och andra ribbor tvingar oljan mot mitten i lagret hela tiden, problemet är när det står still och och kanske av hårda slag stöter ut aerosoler av olja varav lite av det sätter sig på någon skiva och det blir ett latent bekymmer som sedan inte upptäcks förrän när man tex. skriver/läser nära diskcentrum. Man har också bekymret att olja som stött ut i HD-utrummet också flyttar på sig - dvs. gasar och kondenseras och något av det kan hamna på skiva, kanske flera år senare.

ovanstående är förstås långt ifrån alla mekanismer som gör att en disk får oläsbara sektorer men var ändå rätt intressant att läsa dessa 'papers' med svepelektronmikroskop på diskytor med 'droppar' och att det är ett problem.