Hvorfor kan du bruke en Linux-basert datamaskin eller Linux Live CD til å gjenopprette data Windows ikke kunne?
Dagens spørsmål og svar-økt kommer til oss med tillatelse fra SuperUser - en underavdeling av Stack Exchange, en samfunnsdrevet gruppe av spørsmål og svar-nettsteder.
Spørsmålet
SuperUser-leser Philip Allgaier vil vite hvorfor han klarte å gjenopprette data med en Linux Live CD som ble rapportert som uopprettelig i Windows:
Bakgrunn: Tidligere i år hadde jeg et problem med en SSD-stasjon som Windows ville gjenkjenne lenger. Men til slutt gjorde en oppstartbar Parted Magic 2012-10-10 susen. Se dette løst tråd . Et spørsmål stod fast hos meg fra det øyeblikket ...
Spørsmål: Jeg er klar over at Linux generelt er litt mer teknisk og rå, men kan noen grovt skissere hvorfor et Linux-system (eller faktisk bare det bestemte, siden Ubuntu ikke gjorde kunsten) fortsatt er i stand til å få tilgang til / kommunisere med en halv -korrupt enhet når Windows ikke er det?
-
Ignorer de bare potensielle indikatorer for at noe kan være galt?
-
Er det noen konkrete grunner i det hele tatt?
-
Var det bare flaks at nettopp dette miljøet var i stand til å få SSD til å svare, bare i en begrenset periode?
Selv om det absolutt kunne ha vært flaks, spiller det sannsynligvis mer enn noen få faktorer. La oss undersøke det.
Svaret
SuperUser-bidragsyter Eike tilbyr noen potensielle forklaringer, utover bare flaks, for sin evne til å lagre dataene:
Vanligvis kommer dette ned på hva som blir tilgang til og hvordan enheten mislykkes. For eksempel, hvis den aktuelle SSD ikke klarer å hente, for eksempel sektor 5, og vil begynne å stoppe så snart noe leser sektor 5, kan forskjellen ganske enkelt skyldes at forskjellige systemer automatisk får tilgang til når de gjenkjenner en ny disk.
Når Windows oppdager en ny disk, vil den lese partisjonstabellen og automatisk prøve å åpne eventuelle filsystemer den vet hvordan de skal lese. Hvis noen av strukturene / blokkene som blir lest under denne "monteringsprosessen", utløser den defekte SSD-en til å farvel, er forskjellen med den spesifikke Linux-distribusjonen ganske enkelt at den ikke automatisk monterer alle de aktuelle partisjonene, eller når du monterer, les bare en annen delmengde av sektorer (implementeringen av NTFS i Linux er veldig forskjellig fra den i Windows - mens diskformatet er det samme, er det opp til operativsystemet hvilke strukturer det anser nødvendig å lese. Windows kan lese sekundære kopier av MFT, eller det kan begynne å forpakke noen data, og det kan være forskjellen. Ubuntu er i en lignende båt - den er ikke rettet mot utvinning ut av esken, den vil prøve å montere et hvilket som helst filsystem det finner på nyoppdagede medier automatisk. Det er av denne grunn at spesialiserte distribusjoner rettet mot utvinning er en bedre innsats, da de bare gjør det du eksplisitt ber dem om i motsetning til å gjøre ting automatisk.
Selvfølgelig kan du rett og slett ha blitt heldig også. Jeg vet ikke nok om feilmodus for SSD til å si.
Linux ignorerer generelt ikke indikatorer for at noe er galt. Den vil motta de samme SCSI-feilene fra SATA-brikkesettet som Windows vil - hvis du ser på kjerneloggen, på en feil disk vil du se mange feilmeldinger. Det avhenger av hvilke programmer som faktisk får tilgang til disken hva som vil skje videre. Hvis det er programvare rettet mot gjenoppretting, kan det prøve å lese den samme sektoren et begrenset antall ganger, den kan hoppe over den, etc. Vanligvis er det best å få et bilde av stasjonen med så mange sektorer som er rene som mulig, og så prøv å gjenopprette dataene dine fra det bildet (det er dårlig å gjøre en analyse direkte på stasjonen, siden tilstanden kan forverres og bare fordi du var i stand til å lese noe en gang, betyr ikke det at du vil kunne lese det igjen .)
Medarbeider AthonSfere, tilbyr en ny ting på ting:
Mye av det er måten miljøet håndterer filsystemet, og ACL-ene eller harddisken.
Windows kommer til å gjøre alt det kan for å adlyde ACL-ene, og sektorer som er merket som dårlige eller tomme. Så NTFS- eller Fat-partisjoner som er opprettet og vedlikeholdt i Windows så vel som Windows MBR, vil bli håndtert av Windows mens Windows markerte det.
Dessuten, hvis stasjonen svikter jo mer du bruker den, desto mer sannsynlig er det å støte på et stort problem, og miljøet vil krasje. Så hvordan operativsystemet håndterer det som spilles inn, Windows vil BSOD eller starte på nytt, vil Windows-oppstartsprosessen kaste MBR-meldinger, manglende filmeldinger (NTDLR.dll mangler eller er ødelagt) og stoppe, fordi disse dårlige filene er nødvendige.
Når du bruker en live disk, stoler du ikke på noe av dette. En dårlig MBR blir omgått fordi du starter opp fra disken. En dårlig sektor som ødela NTDLR.dll er ikke nødvendig. Alt er på disken. Du kan deretter prøve å lese. Hvis det støter på en 'tom' sektor eller dårlig bit, håndterer miljøet det, men det var programmert til å gjøre. Ubuntu vil sannsynligvis heller opprettholde normal OS-oppførsel og fortsette med det som mest sannsynlig vil skje. Sektoren er tom, gjør noe annet. Denne sektoren er dårlig, hold deg unna, ikke les igjen, ikke skriv, eller det vil føre til problemer.
En gjenopprettingsplattform vil imidlertid ønske å lese all data. Filmarkørene sier at filen skal være 0,5, 13…. hvis filsystemrapportene 13 mangler, ignorerer du den tomme overskriften og les filen uansett, eller les den dårlige sektoren så godt den kan og prøv å gjenopprette.
Windows KAN også gjøre mye av dette med tredjepartsapplikasjoner, Recuva kan finne mange av disse "manglende" filene, for en. Men du vil ikke være i et miljø som kan skrive tilbake til disken og forårsake virkelig permanent tap.
Jeg forenklet dette og la til noen tolkninger, men det burde fylle ut noen blanke for det du spør.
Har du noe å legge til forklaringen? Hør av i kommentarene. Vil du lese flere svar fra andre teknologikyndige Stack Exchange-brukere? Sjekk ut hele diskusjonstråden her .
http://superuser.com/questions/586666/why-can-linux-systems-sometime-recover-data-windows-cant-any-concrete-reasons
