Varför kan du använda en Linux-baserad dator eller Linux Live CD för att återställa data som Windows inte kunde?
Dagens Fråga & Svar-session kommer till oss med tillstånd av SuperUser - en underavdelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.
Frågan
SuperUser-läsaren Philip Allgaier vill veta varför han lyckades återställa data med en Linux Live CD som rapporterades som oåterhämtningsbar i Windows:
Bakgrund: Tidigare i år hade jag problem med en SSD-enhet som Windows skulle känna igen längre. Men så småningom gjorde en startbar Parted Magic 2012-10-10 tricket. Se detta löst tråd . En fråga höll fast vid mig från det ögonblicket ...
Fråga: Jag är medveten om att Linux i allmänhet är lite mer teknisk och rå, men kan någon grovt beskriva varför ett Linux-system (eller i själva verket bara det specifika, eftersom Ubuntu inte gjorde tricket) kan fortfarande komma åt / kommunicera med en halv -skadad enhet när Windows inte är det?
-
Bortser de bara från några potentiella indikatorer på att något kan vara fel?
-
Finns det några konkreta skäl alls?
-
Var det bara tur att just den här miljön kunde få SSD-enheten att svara, bara för en begränsad tid?
Även om det verkligen kunde ha varit tur, är det troligtvis fler än några faktorer som spelar. Låt oss undersöka.
Svaret
SuperUser-bidragsgivare Eike erbjuder några potentiella förklaringar, utöver bara tur, för sin förmåga att spara data:
Vanligtvis kommer detta ner på vad, exakt, som nås och hur, exakt, enheten misslyckas. Till exempel, om SSD i fråga inte kan hämta, säg sektor 5 och kommer att börja stanna så snart något läser sektor 5, kan skillnaden helt enkelt bero på vad olika system automatiskt får åtkomst när de känner igen en ny disk.
När Windows upptäcker en ny disk kommer den att läsa partitionstabellen och automatiskt försöka öppna alla filsystem som de kan läsa. Om någon av strukturerna / blocken som läses under denna "monterings" -process utlöser din felaktiga SSD att gå hejdå, är skillnaden med den specifika Linux-distributionen helt enkelt att den kanske inte automatiskt monterar alla partitioner i fråga, eller kan, när du monterar, läs helt enkelt en annan delmängd av sektorer (implementeringen av NTFS i Linux skiljer sig väldigt mycket från den i Windows - medan diskformatet är detsamma är det upp till operativsystemet vilka strukturer det anser nödvändigt att läsa. Windows kan läsa sekundära kopior av MFT, eller det kan börja föregöra vissa data och det kan vara skillnaden.Ubuntu är i en liknande båt - den är inte inriktad på återställning ur lådan, den kommer att försöka montera vilket filsystem som helst på nyupptäckta medier automatiskt. Det är av den anledningen att specialdistributioner som är inriktade på återhämtning är en bättre insats, eftersom de bara gör vad du uttryckligen ber dem om i motsats till att göra saker automatiskt.
Naturligtvis kan du helt enkelt ha fått tur också. Jag vet inte tillräckligt om SSD-fel för att säga.
Linux ignorerar vanligtvis inte indikatorer om att något är fel. Det kommer att få samma SCSI-fel från SATA-chipset som Windows kommer - om du tittar på kärnloggen, på en felaktig disk kommer du att se massor av felmeddelanden. Det beror på vilka program som faktiskt kommer åt hårddisken vad som händer härnäst. Om det är programvara som är inriktad på återhämtning kan den försöka läsa om samma sektor ett begränsat antal gånger, den kan hoppa över den, etc. Vanligtvis är det bästa alternativet att få en bild av enheten med så många sektorer som är lästa rent som möjligt och försök sedan återställa dina data från den bilden (att göra någon analys direkt på enheten är en dålig idé, vanligtvis eftersom dess tillstånd kan försämras och bara för att du kunde läsa något en gång, betyder det inte att du kommer att kunna läsa det igen .)
Medarbetare AthonSfere, erbjuder en annan uppfattning om saker:
Mycket av det är hur miljön hanterar filsystemet och ACL: erna eller hårddisken.
Windows kommer att göra allt det kan på egen hand för att följa sina ACL: er och sektorer markerade som dåliga eller tomma. Så NTFS- eller Fat-partitioner som skapats och underhålls i Windows såväl som Windows MBR kommer att hanteras av Windows som Windows markerade det.
Dessutom, om enheten misslyckas ju mer du använder den desto mer sannolikt är det att det stöter på ett stort problem och miljön kommer att krascha. Hur OS hanterar det som spelas in, Windows kommer att BSOD eller starta om, Windows startprocess kommer att kasta MBR-meddelanden, saknade filmeddelanden (NTDLR.dll saknas eller är korrupt) och sluta, eftersom dessa dåliga filer krävs.
När du använder en live-disk, förlitar du dig inte på något av detta. En dålig MBR kringgår eftersom du startar från disken. En dålig sektor som skadade NTDLR.dll behövs inte. Allt finns på skivan. Du kan sedan försöka läsa. Om den stöter på en "tom" sektor eller en dålig bit, hanterar den miljön den emellertid den var programmerad att göra. Ubuntu skulle sannolikt hellre upprätthålla normalt OS-beteende och fortsätta med det som sannolikt kommer att hända. Sektorn är tom, gör något annat. Den sektorn är dålig, håll dig borta, läs inte igen, skriv inte eller det kommer att orsaka problem.
En återställningsplattform kommer dock att vilja läsa all data. Filmarkörerna säger att filen ska vara 0,5, 13…. om filsystemrapporterna 13 saknas ignorerar du den tomma rubriken och läser filen ändå eller läser den dåliga sektorn så bra som möjligt och försöker återställa.
Windows KAN också göra mycket av detta med applikationer från tredje part, Recuva kan hitta många av dessa "saknade" filer, för en. Men du vill inte vara i en miljö som kan skriva tillbaka till disken och orsaka verklig permanent förlust.
Jag har förenklat detta och lagt till lite tolkning, men det borde fylla i några tomma för vad du frågar.
Har du något att lägga till förklaringen? Ljud av i kommentarerna. Vill du läsa fler svar från andra tekniskt kunniga Stack Exchange-användare? Kolla in hela diskussionstråden här .
http://superuser.com/questions/586666/why-can-linux-systems-sometime-recover-data-windows-cant-any-concrete-reasons
