13Sep
Hvorfor er det, at du kan bruge en Linux-baseret computer eller Linux Live CD til at gendanne data Windows kunne ikke?
Dagens Spørgsmål &Svar session kommer til os høflighed af SuperUser-en underafdeling af Stack Exchange, en community-drevet gruppe af Q & A-websteder.
Spørgsmål
SuperUser læser Philip Allgaier ønsker at vide, hvorfor han var i stand til at gendanne data med en Linux Live CD, der blev rapporteret som uoprettelig i Windows:
Baggrund: Tidligere i år havde jeg et problem med et SSD-drev, som Windows ville genkendelængere. Men i sidste ende en bootable Parted Magic 2012-10-10 gjorde tricket. Se denne løst tråd. Et spørgsmål der sidder fast med mig fra det øjeblik. ..
Spørgsmål: Jeg er klar over, at Linux generelt er lidt mere teknisk og rå, men kan nogen omhyggeligt skitsere, hvorfor et Linux-system( eller faktisk kun den særlige, siden Ubuntu ikke gjordetricket) er i stand til stadig at få adgang til / kommunikere med en halvkorruptet enhed, når Windows ikke er?
-
Har de bare ignoreret eventuelle indikatorer for at noget kan være forkert?
-
Er der nogen konkrete grunde overhovedet?
-
Var det bare held og lykke, at dette særlige miljø var i stand til at få SSD'en til at reagere, hvis det kun var i et begrænset tidsrum?
Selvom det helt sikkert kunne have været held, er der sandsynligvis mere end et par faktorer til spil. Lad os undersøge.
Svaret
SuperUser-bidragsyderen Eike giver nogle mulige forklaringer ud over bare held og lykke for hans evne til at gemme dataene:
Normalt kommer det til, hvad der nøjagtigt er tilgængeligt, og hvordan netop enheden fejler. Hvis f.eks. SSD'en ikke er i stand til at hente, siger sektor 5 og begynder at stoppe, så snart der er noget, der læser sektor 5, kan forskellen simpelthen skyldes, hvilke forskellige systemer der automatisk kommer adgang til, når de genkender en ny disk.
Når Windows registrerer en ny disk, vil den læse partitionstabellen og automatisk forsøge at åbne filsystemer, som den ved, hvordan man læser. Hvis nogen af de strukturer / blokke, der læses under denne "montage" -proces, udløser din fejlbehæftede SSD for at sige farvel, er forskellen med den specifikke Linux-distribution simpelthen, at den ikke automatisk kan montere alle de pågældende partitioner eller måske,når du monterer, skal du blot læse en anden delmængde af sektorer( implementeringen af NTFS i Linux er meget forskellig fra den i Windows - mens diskformatet er det samme, er det op til OS'et, hvilke strukturer det anser for nødvendigt at læse. Windows kan læse sekundære kopier af MFT, eller det kan begynde at forklare nogle data, og det kunne være forskellen. Ubuntu er i en lignende båd - den er ikke gearet til genopretning ud af kassen, det vil forsøge at montere et hvilket som helst filsystem, det finderpå nyopdagede medier automatisk. Det er derfor, at specialiserede distributioner gearet til opsving er et bedre spil, da de kun gør hvad du udtrykkeligt beder dem om i modsætning til at gøre ting automatisk.
Selvfølgeligkan simpelthen også have haft heldige. Jeg ved ikke nok om SSD's svigtmodus at sige.
Linux ignorerer generelt ikke indikatorer om at noget er forkert. Det vil modtage de samme SCSI fejl fra SATA chipset som Windows vil - hvis du kigger på kernel loggen, på en defekt disk vil du se mange fejlmeddelelser. Det afhænger af, hvilke programmer der aktuelt kommer til disken, hvad der vil ske næste gang. Hvis det er software, der er rettet mod opsving, kan det forsøge at genlæse samme sektor et begrænset antal gange, det kan springe over det osv. Normalt er det bedste alternativ at få et billede af drevet med så mange sektorer som muligt læst, ogprøv derefter at gendanne dine data fra det billede( gør en analyse direkte på drevet er en dårlig ide, da det normalt kan forværres, og bare fordi du kunne læse noget en gang, betyder det ikke, at du vil kunne læse det igen.)
Medleverandør AthonSfere, tilbyder en anden udfordring:
Meget af det er, hvordan miljøet håndterer filsystemet og ACL'erne eller harddisken.
Windows skal gøre alt, hvad det selv kan, for at adlyde sine ACL'er og sektorer markeret som dårlige eller tomme. Så NTFS eller Fat partitioner oprettet og vedligeholdt i Windows samt Windows MBR'er vil blive håndteret af Windows, da Windows markerede det.
Hvis drevet svigter, desto mere bruger du det, desto mere sandsynligt er det at støde på et stort problem, og miljøet vil gå ned. Så hvordan operativsystemet håndterer, der kommer i spil, Windows vil BSOD eller genstarte, Windows-opstartsprocessen vil kaste MBR-meddelelser, manglende filbeskeder( NTDLR.dll mangler eller korrupt) og stopper, fordi disse dårlige filer er påkrævet.
Når du bruger en levende disk, er du ikke afhængig af nogen af dette. En dårlig MBR er omgået, fordi du starter fra disken. En dårlig sektor, der ødelagde NTDLR.dll, er ikke nødvendig. Alt er på disken. Du kan så prøve en læsning. Hvis det møder en "tom" sektor eller dårlig bit, håndterer det miljø det, men det var programmeret til at gøre. Ubuntu sandsynligvis vil hellere opretholde normale OS-adfærd og fortsætte med, hvad der mest sandsynligt vil ske. Sektoren er tom, gør noget andet. Den sektor er dårlig, holde sig væk, ikke læse igen, skriv ikke, eller det vil medføre problemer.
En recovery platform vil imidlertid gerne læse alle data. Filmarkørerne siger, at filen skal være på 0,5, 13. ...Hvis filsystemrapporterne 13 mangler, ignorerer du det tomme overskrift og læser filen alligevel, eller læs den dårlige sektor så godt som muligt, og prøv at genoprette.
Windows kan også gøre meget af dette med tredjepartsprogrammer, Recuva kan finde mange af disse "manglende" filer, for en. Men du vil ikke være i et miljø, der kan skrive tilbage til disken og forårsage sandt permanent tab.
Jeg forenklede dette, og tilføjer en vis fortolkning, men det skal udfylde nogle emner for det du spørger.
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.
http: //superuser.com/questions/586666/ why-can-linux-systems-sometime-recover-data-windows-cant-any-concrete-grunde