Mjukvara för att rädda data från en Mac formaterad HDD

En så hel diskimage som möjligt av disken är det du skall satsa på allra först, speciellt om disken i fråga börja ha problem att läsa ut data och snabbt förvärras på minutnivå typ. - att analysera innehållet är en senare sak, det gör man på kopian av den diskimage man har skapat av disken.

ddrescue i linux (med 3 filargument) är lämplig tool för att försöka rädda data och skapa diskimage ur krassliga snurrdiskar - antal optioner är armlång med olika trix du kan försöka med om det inte ger så mycket vid första försöket med standard-strategi.

Det finns de som kört ddrescue ett halvår med 99.99% räddat från snurrdisken när första skörningen gav mindre än 50% räddad mängd.

ddrescue provläser bara de sektorer som inte redan är lästa - det är också varför man skall ha 3 filargument då den 3' filen håller reda på vad som är läst och inte är läst, så att man inte startar från början igen när man startar om programmet av olika orsaker - vilket gör att det fortsätter där det var sist (men inte på samma ställe sektormässigt) även om du tvingats starta om lagringen för att det hängde sig (händer ganska ofta på krassliga SSD-minnen att det tvärlåser sig när man skall läsa en viss sektor och kräver power off/on-reset innan den är kontaktbar igen - ibland...)

När det gäller analys och räddning av filer för specifikt filsystem får man titta efter andra verktyg - men krasst sett, filsystem som krånglar ofta finns det mycket diskräddningsverktyg (som för NTFS, (V)FAT, ExFAT mfl. ms-filsystem) med varierande lycka i räddningen medans filsystem som är säkrare och mer sällan havererar så finns det mindre och kanske rentav bara fåtal opensource verktyg att förlita sig till för att filsystemen i fråga helt enkelt krånglar för lite för att man skall kunna slå mynt av det.

- de flesta lägen vid haverier så vill folk få ur sina filer i första hand - att reparera filsystemet är bonus, men man kan lika gärna fylla på en ny filsystem med de filer som är räddade.

NTFS är ren massaker om $MFT är skadad/överskriven (vilket händer ganska ofta när folk formaterar fel partion/disk) - även om diskräddningsprogram får ut filer så kan de vara i bedrövlig skick utan filnamn, där filkroppen kan innehålla sektorer från andra filer, fel storlek etc. - där fins det många diskräddningsföretag som vill tälja guld, men efter att prova flertal av dessa så ser man snart att de är ungefär lika bra/dåliga i räddningsförmåga för en havererad NTFS på ett visst sätt.

Det brukar vara enkelt, men anslut en disk i taget

dvs. anslut först den disken du botar linux på, när den uppe och snurrar, så ansluter du disken där diskimagen skall sparas på - och när den är ansluten, hittad och monterad - då först ansluter du disken som du vill rädda data ifrån.

med andra ord

'lsblk'

för att se vilka lagringar du har inkopplat

identifiera dessa på storlek tex. och eventuellt om de har monterats

tex disken du botade på är förmodligen är oftast "/dev/sda1" och monterad som "/" (skriven som enbart 'sda1' i lsblk då '/dev/' är underförstådd)

sätt in lagringen som du skall ha diskimagen på

'lsblk' igen - nästa disk förutsätts här namnad som "/dev/sdb" här

så är den antingen automonterat som /dev/sdb1 på "/media/användare/disknamn" - typisk Ubuntu-distrubition

Eller så får du montera denna själv med "mount /dev/sdb1 /mnt" - under förutsättning att andra inkopplade disken döptes till /dev/sdb och partition 1 (alltså /dev/sdb1) - vilket också visas och kan kontrolleras med 'lsblk'

när ovanstående är gjort - nu kan du kan du ansluta diskdockan med den trubbliga disken

kolla med 'lsblk' igen om den dykt upp och då förmodligen som disk 'sdc'

sedan - under förutsättning att disken som diskimagen skall lagra på är monterad under /mnt:

"ddrescue /dev/sdc /mnt/namnet_på_diskimage /mnt/namnet_på_diskimage.log"

Det är viktigt att ha med log-filen som den 3' filnamet i kommandot då den bokför vad som är läst och vad som är kvar att läsa, detta är en förutsättning för att fortsätta där den var sist om du av någon anledning måste starta om datorn eller disken tex. om det hängt sig. utan denna logfil så börja den från början igen och har man en disk som håller på att rasa så har man ofta inte chansen att kunna läsa om det som man lyckades med förra gången.

flaggor mm. argument till ddrescue kan man experimentera senare när första körningen inte går bra och stoppar i förtid - annars brukar det inte vara så mycket mer för en disk som inte har lästrubbel.

---

slutligen - om du startar om linux igen av någon orsak så måste du koppla diskarna i rätt ordning igen och dubbelkolla med 'lsblk' att diskarna ligger i samma ordning som tidigare

det är inte Linux som bestämmer hur diskarna och vilken ordning diskarna namnas - utan det är BIOS och PCIe som bestämmer det och första disken som blir klar heter /dev/sda, nästa disk som blir klar heter /dev/sdb etc och har man snabba SSD inkopplade samtidigt så kan dessa byta plats beroende på vem inom nanosekunder när blir klar först...

och till sist - disken som du lägger diskimagen på måste ha filsystem som är POSIX-kompatibel och den enda som fungerar även för windows är NTFS. - om man inte måste ha det kompatibelt mot windows så använder man mycket hellre BTRFS, ext4, XFS mfl. då dessa är mycket snabbare och säkrare filsystemformat - NTFS i Linux är en pina i hastighet inte mycket högre än dryga 100 MB/s medan de andra linux-filsystemen är (mycket) mer än 4 ggr snabbare vid kopiering.

BTRFS har också jättebra funktioner som man har svårt att vara utan när man väl vant sig vid dessa som kompression på filsystemnivå, snapshot - lättviktskopierig med --reflink inom samma filsystem (bara metadata kopieras - inte innehållet på filen som då blir gemensam både för orginalet och kopian - att göra en säkerhetskopia av en 2 TB stor diskimagefil innan du tänker montera den med losetup tar typ 1/4-dels sekund. att kunna äta och ha kakan kvar samtidigt bokstavligen

glöm FAT/ExFAT-formaterad lagring - dessa måste formateras till NTFS innan du försöker med ddrescue.