Söndrig hårddisk

Du menar återställa FAT/MFT? Det brukar man inte göra eftersom FAT/MFT inte brukar gå sönder av sig själv utan det rör sig ofta om en opålitlig disk (dessutom skulle det vara en rätt omständig process). Därför försöker man få ut informationen så fort som möjligt från disken.

Du har sett till att disken är okej? Om inte så jobbar du på en avbild och inte själva disken?

Först, se till att disken inte håller på att gå sönder genom att plocka ut SMART. Använd SpeedFan, http://www.almico.com/speedfan.php, eller tillverkarens "diagnostikprogramvara" och posta om du inte vet hur du ska tyda.

Om disken håller på att gå sönder så ska du undvika att jobba med den. Om den är hel går det bra att köra ett rekonstruktionsprogram direkt på den (men jag skulle aldrig ta risken och göra det). Mitt tips är GetDataBack, http://www.runtime.org/. Såvida inget allvarligt har hänt så skulle jag tippa på att chansen att få tillbaka alla filer är goda.

Hur menar du att disken har minskat med 170 GB? Hur stor är den nu?

Hm, disken har gått snart 40 000 timmar (5 års dygnet runt drift) och startat 1578 gånger, så det är inte konstigt om den börjar må lite dåligt.

Disken har 6 stycken sektorer som har fallerat och mappats om men reallocated event count är 0, konstigt (borde vara över 6). Disken har 6 stycken sektorer som väntar på att mappas om och det är förmodligen därför det har blivit problem med disken. Det är alltså 6 stycken sektorer som disken inte kan läsa. Den kommer att försöka läsa dem igen men hittills har det inte gått och den kommer kanske inte kunna göra det heller.

Offline Seek Performance är 0 och det är lite konstigt. Det är alltså seek perfomance när disken gör egna självtest. Sjunkande seek performance är en indikator på att det är något allvarligt fel med disken och jag är lite osäker på hur man ska tolka sjunkade offline seek performance, men hur som helst är det inte bra att den är 0.

Diskens SMART ger motstridiga uppgifter och jag skulle inte lita på dem. Anta att disken kommer att gå sönder snart. Skapa en avbild och jobba på den istället för att belasta disken. Du kan göra en avbild i GetDataBack.

Köp en ny hårddisk och använd denna bara för data som det inte spelar någon roll om ni förlorar, då den kommer att gå sönder snart med tanke på hur gammal den är.

Ärligt talat har jag faktiskt bara upplevt en diskkrasch en gång och det var inte ens en krash. Den började tappa sektorer så jag tog ut den ur RAID-volymen och körde den tills den gick sönder och fick en ny på garantin. Jag vet inte om det är tur eller skicklighet men privat har jag bara förlorat en disk (jag har väl haft ett 50-tal privat och alla har väl gått dygnet runt). Kan ju i och för sig ha att göra med att jag behandlar mina diskar som om de vore mina barn... Men jag jobbar med rekonstruktion så man ser många krascher och en del har mer otur än andra verkar det som.

Även om det inte är så troligt så kan det hända att disken är återanvänd, så den kan vara 5 år gammal. Men det kan också vara så att det är något fel på SMART informationen eller hur SpeedFan tolkar den (en del tillverkare anger Power On Hours i timmar+minuter istället för bara timmar) varav den sistnämnda är den troligaste orsaken.

Ja, det går det men det lättaste är att göra en avbild på hela disken. I GetDataBack ska det finnas en funktion för att göra en hel avbild av disken. Jag antar att man också kan välja att göra bara en del om man vet var partitionen inte ligger. Efter att du gjort en avbild låter du GetDataBack analysera den. Det finns två versioner av programmet, en för FAT-32 och en för NTFS, välj den som passar.

Finns säkert program för Windows men det jag brukar använda är dd i linux (man kan köra dd i Windows också).

Boota upp med en linux live CD och ha bara den disken som ska nollställas i (så att det inte blir någon förväxling). Skriv dd if=/dev/zero of=/dev/hda, byt ut /dev/hda till det som passar. Då skrivs det nollor över hela disken och i princip kan man säga att det går inte att få tillbaka informationen efter det (det går men oftast är det inte ekonomiskt försvarbart). Vill man skriva över med slumpmässig information kan man använda /dev/urandom istället för /dev/zero.

GetDataBack lär ta några timmar (typ 8-12) på att söka avbilden (närväl du har skapat avbilden) och du bör nog köra det på den snabbaste datorn du har. Om den ändå inte kan få tillbaka filerna så går det att fixa tillbaka dem på andra sätt (vi kan fixa sånt) men jag känner inte till någon sådan komersiell produkt.

Hm, du klickar på "1st hard drive 200 GB(...)" under Physical drives eller vilken det nu är och sedan väljer du Tools->Create Image file...

Då kan du välja var du vill skapa kopian och det står "Range: entire drive"

Det finns några inställningar under options som du kanske behöver ändra.

Generellt är S.M.A.R.T inte en helt pålitlig metod för att avgöra om diskar är defekta eller ej.

Här kan man se ett mycket bra exempel på detta: http://lkml.org/lkml/2006/6/10/40

Google släppte en undersökning för ett halvår/år (?) sedan där de kom fram till att ca 50% av diskkrascherna inte gick att förutsäga med SMART. Men då pratar vi om serverdiskar. Ta t.ex. spin up time på en serverdisk som man aldrig stänger av. Hur ska det värdet kunna larma om lagren eller motorn i disken håller på att gå sönder? Dessutom, räknar man med tappade servrar eller dylikt i statistiken? (inte så konstigt om SMART inte kan förutse sådant) SMART är inte perfekt men jag själv tycker jag att det är ett rätt så tillförlitligt system.

Jag själv har skrivit en applikation som samlar in SMART data till en databas och jämför hur fort förändringen sker i vissa värden. Det ger en betydligt bättre förvarning än tröskelvärdena.

Länken som du gav visade ett exempel på en disk som inte hade problem att läsa men däremot att skriva till vissa sektorer. Det är inte så konstigt att felet inte upptäcks under självtestet men däremot borde disken ha mappat om sektorn när den fick skrivfel, verkar som en bugg i disken.

Vad roligt att det gick bra. Kontrollera bara så att filerna verkligen är hela innan du tar bort avbilden.

Om du känner att du är skyldig mig något så kan du komma ihåg till vilket företag folk ska vända sig när de har problem med disken eller när de ska köpa in en fjärrsäkerhetskopieringslösning, så är vi kvitt.

Skall hjälpa en kompis med att recovra från hans krashade disk, men kan jag skapa imagen på en annan disk utan att formatera den disken? Alltså utan att vara orolig för att den disken som jag skapar imagen till kommer att ta bort den data som redan finns?

Det är ingen bugg, det är helt vanliga skadade sektorer. Disken kan bara mappa om till en viss gräns.

Hur som helst, jag har haft ett antal hårddiskkrashar och ingen har involverat yttre våld eller S.M.A.R.T-varningar, däremot har alla involverat skadade sektorer.

Hur som helst, om S.M.A.R.T förutsäger 50 % av alla diskhaverier så är det inte dåligt, men det hjälper inte trådskaparen så mycket..

Och vilken är denna gräns enligt dig?

Jag misstänker att du syfter på att gränsen är antalet reservsektorer (vilka är ett par tusen i en modern disk) och om du läser vidare i den tråden som du gav en länk till så visade det sig att Reallocated Sector Count, Reallocated Event Count och Offline Uncorrectable var noll. Alltså hade inga trasiga sektorer mappats om, disken hade aldrig försökt mappa om och inte heller hade disken hittat någon sektor som skulle behöva mappas om. Vid ett läsfel skulle disken ha mappat om den trasiga sektorn om den fungerade som den skulle, varför den inte gjorde det vet jag inte och mitt förslag är att det var en dålig SMART implementering.

Om du kollar SMART:en på en trasig disk så kan du se att den visar spår i SMART:en att den inte är helt okej (om det inte är något fel på själva SMART så ska den visa hur många sektorer som har mappats om och så vidare), även om den inte nödvändigt har löst ut (gått över eller under tröskel värdet). Googles undersökning visade rätt tydligt att det fanns ett samband mellan vissa SMART-värden och krasch, även om det inte var någon direkt nyhet för mig eller någon annan. Men den undersökningen gällde för server diskar som går 24/7 och det gör att vissa typer av fel inte kan förutsägas med SMART, exempelvis att motorn/lagren håller på att ta slut. Dessutom har de ett annat slitage mönster än vanliga diskar så man får ta det med en nypa salt.

Jag förstår inte riktigt var du vill komma med "men det hjälper inte trådskaparen så mycket"?
Jag har ju påpekat att disken inte är att lita på och att de ska köpa en ny samt bara använda denna för sådant som de kan förlora.

SMART är inte bara varningen som du får när något värde gör över eller under tröskel värdet. Det är klart att vanliga SMART-applikationer kan inte göra mer än läsa om SMART har löst ut och larma men dels finns det speciella applikationer som kan mer än så (inte speciellt svårt att skriva en sådan) och dels är det ett bra verktyg för att se hur disken mår. T.ex. har jag en disk framför mig som har fått en korrupt MFT och vi har rekonstruerat alla filer och har kört en badblocks -w på disken. Enligt SMART ser disken fin ut och badblocks gav inget så vi kan skicka tillbaka disken till kunden och säga att det med all sannolikhet var det inte något fel på själva disken. Hade SMART:en haft ett par hundra Reallocated Sector Count men badblocks inte hade visat något hade vi rekommenderat kunden att inte använda disken till något viktigt då den förmodligen kommer att gå sönder snart, även om inte SMART har löst ut eller badblocks gett något. En människa eller intelligentare program (än tröskelvärdesläsning) som kan "förstå" de bakomliggande orsakerna och titta på flera faktorer kan uppskatta väldigt bra hur pålitlig en disk är. Jag misstänker att Googles undersökning var det första steget i att bygga en applikation som kan förutsäga diskarnas livslängd bättre än SMART:s tröskelvärden. De har ju otroligt många diskar och skulle nog kunna spara en hel del pengar på att byta ut diskar som håller på att gå sönder under schemalagd service istället för att göra utryckningar när väl en disk har fallerat enligt SMART:s tröskelvärden.

Avbilden skapas som en fil på diskens filsystem, i alla fall i GetDataBack, så du behöver inte oroa dig.
Se bara till att målet kör NTFS eller annat filsystem som klarar av stora filer.