Kan data på hårddisken bryta ut utan varning om skadan?

Vi oroar oss alla för att hålla våra data och filer säkra och intakta, men är det möjligt att data skadas och nås av en användare utan en anmälan eller varning av något slag om problemet? Dagens SuperUser Q & A-inlägg har svaret på en orolig läsares fråga.

Dagens fråga &Svarssession kommer till oss med tillstånd av SuperUser-en indelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.

Foto med tillstånd av generalisering( Flickr).

Frågan

SuperUser-läsaren topo morto vill veta om data på hårddiskar kan brytas ner och nås utan varning om skadan:

Är det möjligt att fysisk nedbrytning av en hårddisk kan orsaka bitar att "flip" i en fils innehållutan att operativsystemet märker ändringen och meddelar användaren om det när man läser filen? Till exempel kan en "p"( binär 01110000) i en ASCII-textfil ändras till en "q"( binär 01110001), då när en användare öppnar filen ser de "q" utan att vara medveten om att ett fel har uppstått?

Jag är intresserad av svar relaterade till FAT, NTFS eller ReFS( om det gör skillnad).Jag vill veta om operativsystem skyddar användare från detta, eller om vi bör kontrollera våra data för variationer mellan kopior över tiden.

Kan data på hårddiskar försämras och nås utan varning om skadan?

Svaret

SuperUser-bidragare Guntram Blohm har svaret för oss:

Ja, det finns en sak som heter bit rot. Men nej det kommer inte att påverka en användare obemärkt.

När en hårddisk skriver en sektor till disken skriver den inte bara bitarna på samma sätt som de lagras i RAM, det använder en kodning för att se till att det inte finns några sekvenser av samma bit som är för långa. Det lägger också till ECC-koder som gör det möjligt att reparera fel som påverkar några bitar och upptäcka fel som påverkar mer än några bitar.

När hårddisken läser sektorn kontrollerar den dessa ECC-koder och reparerar data om det behövs( och om möjligt).Vad som händer beror på omständigheterna och hårddiskens fasta programvara, vilket påverkas av drivrutinsbeteckningen.

• Om en sektor kan läsas och inte har några ECC-kodproblem, skickas den vidare till operativsystemet.
• Om en sektor kan repareras enkelt kan den reparerade versionen skrivas till disken, läsas tillbaka och sedan verifieras för att avgöra om felet var slumpmässigt( dvs kosmiska strålar etc.) eller om det finns ett systematiskt fel med mediet.
• Om hårddisken bestämmer att det finns ett fel med media, omfördelar det sektorn.
• Om en sektor varken kan läsas eller korrigeras efter några läsförsök( på en hårddisk som är utsedd som en RAID-hårddisk), kommer hårddisken att ge upp, omfördela sektorn och berätta för regulatorn att det fanns enproblem. Det är beroende av RAID-kontrollen att rekonstruera sektorn från de andra RAID-medlemmarna och skriva den tillbaka till den felaktiga hårddisken, som sedan lagrar den i den omfördelade sektorn( som förhoppningsvis inte har något problem).
• Om en sektor inte kan läsas eller korrigeras på en stationär hårddisk, kommer hårddisken att delta i fler försök att läsa den. Beroende på hårddiskens kvalitet kan det här innebära att du flyttar om huvudet och kontrollerar om det finns några bitar som blinkar när de läses upprepade gånger, kontrollerar vilka bitar som är de svagaste och några andra saker. Om någon av dessa försök lyckas, kommer hårddisken att omfördela sektorn och skriva tillbaka de reparerade data.

Detta är en av de viktigaste skillnaderna mellan hårddiskar som säljs som hårddiskar "skrivbord", "NAS / RAID" eller "videoövervakning".En RAID-hårddisk kan bara ge upp snabbt och få regulatorn att reparera sektorn för att undvika latens på användarens sida. En stationär hårddisk fortsätter att försöka igen och igen eftersom det är förmodligen bättre att få användaren att vänta några sekunder än att säga att data går förlorad. Och en video hårddisk värderar konstanta datahastigheter mer än felåterställning som en skadad ram kommer normalt inte ens att märkas.

Hur som helst kommer hårddisken att veta om det har funnits bitrot, kommer vanligtvis att återhämta sig från det, och om det inte kan, kommer det att berätta för regulatorn som i sin tur berättar föraren som då kommer att berätta för operativsystemet. Då är det upp till operativsystemet att presentera felet för användaren och agera på det. Det är därför cybernard säger:

• Jag har aldrig sett en enda bitfel själv, men jag har sett massor av hårddiskar där hela sektorer har misslyckats.

Hårddisken vet om det är något fel på en sektor, men det vet inte vilka bitar som har misslyckats. En enda bit som har misslyckats kommer alltid att fångas av ECC.

Observera att chkdsk och filsystem som automatiskt reparerar sig inte adresserar att reparera data i filer. Dessa är riktade mot korruption inom själva filsystemets struktur, som en skillnad i en fils storlek mellan kataloginmatningen och antalet tilldelade block. Den självhärdande egenskapen hos NTFS kommer att upptäcka strukturella skador och förhindra att den påverkar dina data ytterligare, men det kommer inte att reparera data som redan är skadad.

Det finns naturligtvis andra orsaker till att data kan bli skadade. Till exempel kan dåligt RAM på en kontroller ändra data innan det ens skickas till hårddisken. I så fall kommer ingen mekanism på hårddisken att upptäcka eller reparera data, och det kan vara en orsak till att strukturen på ett filsystem är skadat. Andra orsaker är mjukvaruproblem, strömavbrott medan du skriver till hårddisken( även om detta åtgärdas av filsystemet journaling) eller dåliga filsystemdrivrutiner( NTFS-drivrutinen på Linux som standard för att skrivskyddad länge sedan NTFS var omvänd konstruerad,inte dokumenterad, och utvecklarna litade inte på sin egen kod).

• Jag hade detta scenario en gång där en applikation skulle spara alla sina filer till två olika servrar i två olika datacenter för att hålla en arbetskopia av de data som är tillgängliga under alla omständigheter. Efter några månader märkte vi att cirka 0,1 procent av alla kopierade filer inte stämde överens med MD5-checkbeloppet som ansökan lagrade i sin databas. Det visade sig vara en felaktig fiberkabel mellan servern och SAN.

Dessa andra anledningar är varför vissa filsystem, som ZFS, behåller ytterligare check sum-information för att upptäcka fel. De är utformade för att skydda dig från mycket fler saker som kan gå fel än bara lite rutt.

Har något att lägga till förklaringen? Ljud av i kommentarerna. Vill du läsa mer svar från andra tech-savvy Stack Exchange-användare? Kolla in hela diskussionsgängan här.