Hjemmeside » hvordan » Kan data på harddiske nedbrydes uden advarsel om skaden?

    Kan data på harddiske nedbrydes uden advarsel om skaden?

    Vi er alle bekymrede over, at vores data og filer er sikre og intakte, men er det muligt for data at blive beskadiget og få adgang til en bruger uden anmeldelse eller advarsel af nogen art om problemet? Dagens SuperUser Q & A-indlæg har svaret på en bekymret læsers spørgsmål.

    Dagens Spørgsmål & Svar session kommer til os med venlig hilsen af ​​SuperUser-en underafdeling af Stack Exchange, en community-driven gruppe af Q & A-websteder.

    Foto høflighed af generalisering (Flickr).

    Spørgsmålet

    SuperUser læser topo morto vil vide, om data på harddiske kan nedbrydes og fås uden advarsel om skaden:

    Er det muligt, at fysisk nedbrydning af en harddisk kunne få bits til at "flip" i en fils indhold, uden at operativsystemet bemærker ændringen og underretter brugeren om det, når man læser filen? Kan en "p" (binær 01110000) i en ASCII-tekstfil ændres til en "q" (binær 01110001), så når en bruger åbner filen, ser de "q" uden at være opmærksom på, at der er opstået en fejl?

    Jeg er interesseret i svar vedrørende FAT, NTFS eller ReFS (hvis det gør en forskel). Jeg vil gerne vide, om operativsystemer beskytter brugerne herfra, eller hvis vi skal kontrollere vores data for afvigelser mellem kopier over tid.

    Kan data på harddiske nedbrydes og fås uden advarsel om skaden?

    Svaret

    SuperUser bidragyder Guntram Blohm har svaret for os:

    Ja, der er en ting kaldet bit rådne. Men nej, det vil ikke påvirke en bruger ubemærket.

    Når en harddisk skriver en sektor til pladerne, skriver den ikke bare bitsne på samme måde som de gemmes i RAM, den bruger en kodning for at sikre, at der ikke er nogen sekvenser af samme bit, der er for lange. Det tilføjer også ECC-koder, der gør det muligt at reparere fejl, der påvirker nogle få bits og opdage fejl, der påvirker mere end et par stykker.

    Når harddisken læser sektoren, kontrollerer den disse ECC-koder og reparerer dataene om nødvendigt (og om muligt). Hvad der sker næste afhænger af omstændighederne og firmwaren på harddisken, som er påvirket af betegnelsen af ​​drevet.

    • Hvis en sektor kan læses og ikke har ECC-kodeproblemer, sendes den videre til operativsystemet.
    • Hvis en sektor let kan repareres, kan den reparerede version skrives til disk, læses tilbage og derefter verificeres for at bestemme, om fejlen var tilfældig (dvs. kosmiske stråler mv.) Eller hvis der er en systematisk fejl med medierne.
    • Hvis harddisken bestemmer, at der er en fejl i mediet, omfordeler den sektoren.
    • Hvis en sektor hverken kan læses eller korrigeres efter et par læseforsøg (på en harddisk, der er udpeget som en RAID-harddisk), vil harddisken give op, omfordele sektoren og fortælle controlleren, at der var et problem . Den er afhængig af RAID-controlleren for at rekonstruere sektoren fra de andre RAID-medlemmer og skrive den tilbage til den mislykkede harddisk, som derefter opbevarer den i den omfordelte sektor (der forhåbentlig ikke har noget problem).
    • Hvis en sektor ikke kan læses eller korrigeres på en computers harddisk, vil harddisken deltage i flere forsøg på at læse det. Afhængigt af harddiskens kvalitet kan dette indebære omplacering af hovedet og kontrol for at se, om der er nogle bits, der blinker, når de læses gentagne gange, kontrollere hvilke bits der er de svageste og et par andre ting. Hvis nogen af ​​disse forsøg lykkes, vil harddisken omfordele sektoren og skrive de reparerede data tilbage.

    Dette er en af ​​de vigtigste forskelle mellem harddiske, der sælges som harddisker "desktop", "NAS / RAID" eller "videoovervågning". En RAID-harddisk kan bare give op hurtigt og lade kontrolleren reparere sektoren for at undgå latens på brugerens side. En stationær harddisk vil fortsætte med at prøve igen og igen, fordi brugeren venter et par sekunder er nok bedre end at fortælle dem, at dataene går tabt. Og en video harddisk værdier konstante datahastigheder mere end fejlgendannelse som en beskadiget ramme bliver typisk ikke engang bemærket.

    Under alle omstændigheder vil harddisken vide, om der har været bitrot, vil typisk komme sig fra det, og hvis det ikke kan det, vil det fortælle controlleren, som igen vil fortælle føreren, som derefter vil fortælle operativsystemet. Så er det op til operativsystemet at præsentere fejlen for brugeren og handle på den. Derfor siger cybernard:

    • Jeg har aldrig været vidne til en enkelt bitfejl selv, men jeg har set masser af harddiske, hvor hele sektorer har mislykkedes.

    Harddisken vil vide, om der er noget galt med en sektor, men det ved ikke, hvilke bits der har fejlet. En enkelt bit, der har slået fejl, vil altid blive fanget af ECC.

    Vær opmærksom på, at chkdsk og filsystemer, der automatisk reparerer sig selv, ikke adresserer reparation af data inden for filer. Disse er rettet mod korruption inden for selve filsystemets struktur, som en forskel i en fils størrelse mellem mappeindtastningen og antallet af tildelte blokke. Den selvhelbredende egenskab ved NTFS vil registrere strukturelle skader og forhindre det i at påvirke dine data yderligere, men det vil ikke reparere data, der allerede er beskadiget.

    Der er naturligvis andre grunde til, at data kan blive beskadiget. For eksempel kan dårlig RAM på en controller ændre data, før det endda sendes til harddisken. I så fald vil ingen mekanisme på harddisken registrere eller reparere dataene, og det kan være en grund til, at strukturen i et filsystem er beskadiget. Andre grunde omfatter software bugs, blackouts, mens du skriver til harddisken (selvom det er rettet mod filsystem journaling) eller dårlige filsystemdrivere (NTFS-driveren på Linux er standard til at skrivebeskyttet i lang tid siden NTFS blev omvendt konstrueret, ikke dokumenteret, og udviklerne stolede ikke på deres egen kode).

    • Jeg havde dette scenario en gang, hvor en ansøgning ville gemme alle dens filer til to forskellige servere i to forskellige datacentre for at holde en arbejds kopi af de tilgængelige data under alle omstændigheder. Efter et par måneder opdagede vi, at ca. 0,1 procent af alle de kopierede filer ikke matchede MD5-checksummen, at applikationen lagret i sin database. Det viste sig at være et defekt fiberkabel mellem serveren og SAN.

    Disse andre grunde er, hvorfor nogle filsystemer, som ZFS, holder yderligere check sum-oplysninger for at opdage fejl. De er designet til at beskytte dig mod mange flere ting, der kan gå galt, end bare lidt råd.


    Har du noget at tilføje til forklaringen? Lyde af i kommentarerne. Vil du læse flere svar fra andre tech-savvy Stack Exchange brugere? Tjek den fulde diskussionstråd her.