Håller med övriga inläggen - gör kopia på alla viktiga filer - först - och därefter en
klon/diskimage av disken med clonezilla eller liknande. Går det inte bra och disken hänger sig och fastnar hela tiden och du måste starta om datorn...
Prova då linux rescue disk av någon slag startad på USB-sticka/DVD-skiva - inkopplad USB-snurrdisk av tillräckligt stor storlek.
Kör kommando 'lsblk' för att identifiera diskarna (gå på storleken) - om i exemplet nedan att din krånglade disk sitter på 'sda' och inkopplade USB-disken sitter på 'sdb' och skrivbara partitionen på USB-disken ligger på sdb1
Börja med 'mount /dev/sdb1 /mnt <enter>
Därefter 'cd /mnt <enter>'
med 'ls <enter> ' bör du se eventuella filer som ligger sedan innan på din externa USB-disk
därefter
'ddrescue /dev/sda /mnt/diskimage_2TB_seagate.img loggfil <enter>'
('loggfil' är jätteviktig - många glömmer den...)
och du kommer se att den börja räkna upp värden när den börja kopiera från den krånglande disken till en disk-imagefil på USB-disken.
Varför då ddrecue - jo det första är att den har en viss användarmisstag-skydd - man skriver inte över själva disken av misstag utan att man måste forcera detta i så fall dvs. det går att läsa från raw-disk till fil men inte tvärt om om man snubblar på device-namnen
Den är specialist på diskar som krånglar vid läsning och tex. hoppar över rejäl stycke om man går in i ett område som är svårläst och tar lång tid per lyckad läsning och prioriterar det som är lättläst först innan den åter igen går tillbaka till de svåra områdena och tex. plockar de friska delarna inom det dåliga områdena och går både fram och bakifrån och saxar in sig så att så mycket det går runt och i de dåliga områdena och friska sektorer kopieras ut - i slutändan så kanske det är bara några tiotals kilobyte på 2-3 fläckar den inte lyckas ta ut trots väldigt lång försökstid.
loggfilen är jätteviktig då den bokför var den är i processen och fryser disken och den måste göra ON/OFF för att det skall synas igen så vet den genom loggfilen var den var sist och fortsätter på en annan del av disken som redan inte är överförd och inte börjar från början igen eller fastnar på området som den fastnade på sist det första det den gör. - det gör också att man kan avbryta jobbet för senare försök - men kräver förstås att disken man räddar ifrån kopplas ur och inte används innan nästa försök - för så fort windows försöker starta på disken så ändras saker och ting på disken och diskimagen blir inkonsistent om man efter försöker rädda ut data senare - då måste man börja från början ingen med ny diskimagefil om det har skett.
Det finns massor av parametrar som kan styra hur ddrescue skall läsa inklusive baklänges, hur många gånger etc.
har folk i bekantskapskretsen som har kört en disk över halvår med mycket dålig prognos med typ bara 60% lyckat första varvet men när ddrescue fått jobbat med den i ett halvår - fått ut över 98% av diskens data.
---
Har man tid och plats så kan man sedan göra om processen partition för partition ( istället för /dev/sda så skriver man /dev/sda1, sda2 etc. för partition 1, partition2 etc.) för lättare montering när man skall hämta ut filer senare eller lägga tillbaka partitionerna igen, men den viktigaste är att få ut själva fulla diskimagen först om disken är på väg att dör - för partitionerna kan man nämligen plocka ut senare från den fulla diskimagen, eller att man lägger tillbaka diskimagen som den är på ersättningsdisken - I regel fungerar det utmärkt och även om ersättningsdisken skulle vara större - med 'kostnaden' att det större utrymmet inte används förrän man partitionera upp det senare.
---
Lite noteringar om din disk-användning:
Spindeln har stoppat och startat över 4800 ggr. (1 per 6 timmar) och man har slagit på och av strömmen 597 ggr disken (1 ggr per 2 dagar) har parkerat huvudena 370000 ggr. (12 ggr i timmen).
Låter nästan som att datorn slås av och på nära dagligen, aggressiv parkering och snabb nedstängning av spindeln av datorns APM så fort den inte flyttar data och många huvudparkeringar förstärker intrycket (inte för att just det är ett bekymmer då jag har diskar med uppemot 3 miljoner parkering fast den är ratad för max 300000 parkeringar)
Med andra ord inte en så snäll men väldigt vanlig drift-profil för många konsument diskar i datorer, och man kan nog säga så här - instoppad i en NAS med lätt last (som tex. mediaserver) men ändå tillräckligt mycket med aktiviteter för att huvudet inte skall parkera sig och spindeln går 24/7 året om, så hade den antingen rasat för ett år sedan eller ännu tidigare eller så hade den hållit minst 2-3 år till.
Spindelstarter och på/avstängningar och väldigt många parkeringar är det som sliter mest på en mekanisk disk (detta pga. temperaturväxlingar det medför) medans att skivan snurrar kontinuerligt och att huvudena konstant flyger på skivorna räknas inte idag som en åldrande faktor - med dagens lagersystem så är det nära på obegränsad livslängd och om det havererar så är det tillverkningsfel eller orenheter i lagret från tillverkningen som orsakar det. - på Enterprisediskar av SAS-typ så räknas antal starter i ental och huvudparkeringar i max 2-siffigt under disken livslängd (brukar vara satt på 5 år - men i verkligheten håller mycket längre än så - diskar byts inte för att de är slitna eller går sönder i Enterprise-system - utan att de helt enkelt är för små eller efter schemalagt plan/investeringskalkyl/leasing-plan... oavsett om det fungerar perfekt eller inte)
