DD överföring av hårddisk - Recovery?

Permalänk
Medlem

DD överföring av hårddisk - Recovery?

Jag har ett .dd arkiv som inte avslutade sin överföring för USB minnet fick slut på minne.

Jag undrar således om det på något vis går att 'appenda' closing brackets av en hårddisk så att .dd filen är så hel den kan bli?

Permalänk
Medlem

Enklast att gör om på en större lagringsmedia - sådant tar man aldrig på USB-stickor (just för att de är opålitliga och/eller att du just fick fatt på en counterfeit-version av stickan med mycket mindre utrymme än vad det lovar eller skriver om början igen efter halva storleken utan att det märks för just din backup du absolut inte får förlora... - eller kraschar när du läst 2/3-del av stickan - USB-stickor tillsammans med SD-minnen har det sämsta av det sämsta av flash-minnen - även från Sandisk/kingston/Samsung och det finns också mycket counterfeit av dessa i omlopp och kan vara uppblandade med genuina exemplar (typ 1 pirat per 50 etc) även hos seriösa handlare då uppblandningen görs tidigt i distributionen av mindre nogräknade underleverantörer till de stora märkena ('Ghost Shift' är ett begrepp här när man nattetid gör USB-stickor från billigare och underkända skivor med flashminne med samma maskiner och processer som man gör märkesminnena dagtid)

- utan sådan man lägger man som fil till mapp monterade USB-snurrdiskar av 2.5" eller 3.5" modell - de har också mycket mer plats tillgänglig och faktiskt går snabbare än de flesta USB-stickor då de lätt kan skyffla över 140 MB/s kontinuerligt på en ny och tom 2.5" disk.

Men om du verkligen vill trixa så finns så finns "skip=" och 'seek=' och 'count=' som räknar i block i dd och här gäller det att hålla tungan rätt med positioner, antal som skall hoppas över och med använda blockstorlek - du vill inte ha ett filsystem där den senare halvan är förskjuten 1 sektor för att du inte höll reda på om det räknades från sektor 0 eller från sektor 1 när du la in värdena

tänk på att 'seek=' gäller på den skrivande sidan och 'skip=' gäller på den läsande sidan, 'ibs=' blockstorleken i byte på den läsande sidan (och blockstorleken också kopplad till antalet block som anges i 'skip') och 'obs=' för blockstorleken på det skrivs på skrivande sidan (och kopplad till blockstorleken för antalet block i 'seek') - "count=" räknar block på den läsande sidan.

- läs manualen för 'dd' _noga_ och förstå vad som står där, träna på ofarliga filer och diskar innan du ger dig på image som är viktiga.

'dd' är räddaren i många sammanhang men man kan bli fasen så blodig om man gör fel eller inte förstår vad flaggorna gör - egentligen, och namnet 'dd' gör skäl för nicknamnet 'disk destroyer'

Permalänk
Medlem
Skrivet av xxargs:

Enklast att gör om på en större lagringsmedia - sådant tar man aldrig på USB-stickor (just för att de är opålitliga och/eller att du just fick fatt på en counterfeit-version av stickan med mycket mindre utrymme än vad det lovar eller skriver om början igen efter halva storleken utan att det märks för just din backup du absolut inte får förlora... - eller kraschar när du läst 2/3-del av stickan - USB-stickor har det sämsta av det sämsta av flash-minnen - även från Sandisk/kingston/Samsung och det finns också mycket counterfeit av dessa i omlopp och kan vara uppblandade med genuina exemplar (typ 1 pirat per 50 etc) även hos seriösa handlare då uppblandningen görs tidigt i distributionen av mindre nogräknade underleveratörer till de stora märkena )

- utan sådan man lägger man som fil till mapp monterade USB-snurrdiskar av 2.5" eller 3.5" modell - de har också mycket mer plats tillgänglig och faktiskt går snabbare än de flesta USB-stickor då de lätt kan skyffla över 140 MB/s kontinuerligt på en ny och tom 2.5" disk.

Men om du verkligen vill trixa så finns så finns "skip=" och 'seek=' och 'count=' som räknar i block i dd och här gäller det att hålla tungan rätt med positioner, antal som skall hoppas över och med använda blockstorlek - du vill inte ha ett filsystem där den senare halvan är förskjuten 1 sektor för att du inte höll reda på om det räknades från sektor 0 eller från sektor 1 när du la in värdena

tänk på att 'seek=' gäller på den skrivande sidan och 'skip=' gäller på den läsande sidan, 'ibs=' blockstorleken i byte på den läsande sidan (och blockstorleken också kopplad till antalet block som anges i 'skip') och 'obs=' för blockstorleken på det skrivs på skrivande sidan (och kopplad till blockstorleken för antalet block i 'seek') - "count=" räknar block på den läsande sidan.

- läs manualen för 'dd' _noga_ och förstå vad som står där, träna på ofarliga filer och diskar innan du ger dig på image som är viktiga.

Ett utförligt och genomtänkt svar men tyvärr rörde svaret inte frågan jag hade.

Det här gäller en överföring som skedde för några år sedan som jag har valt att spara .dd arkivet för det finns data som jag skulle vilja använda igen. I min studentbostad hade jag bara ett USB minne för att rädda datan på min kraschade laptop och det ledde till det här problemet.
Eftersom en DD överföring är bit för bit tänkte jag att det kanske skulle kunna nå viss del av datan som blev överförd, även om oturen skulle visa sig att de viktiga filerna överfördes sist.

Frågan är alltså om jag kan skriva extra data/kod i slutet på det här .dd arkivet för att göra det monterbart för navigation?

Permalänk
Medlem

'skip' kan du navigera startpunkten på din image - men du behöver början också för att få ett begripligt filsystem som OS förstår - OS kan inte arbeta på delar av disken i små bitar.

skall du positionera på 1 byte när så blir det typ "dd ibs=1 skip=antalet_byte_du_vill_hoppa_över obs=1024 if=infil of=utfil"

Vet du med dig att det ligger i arkiv och att det inte skrivits fragmenterat så finns det en chans med magic-word hitta starten på arkivet (tex för zipfiler, tar-arkiv etc.) och man får titta i headrar för zip.h tar.h mm. för att se hur många byte man skall klippa före magic word för att tex. tar skall kunna känna igen och packa upp filen direkt

Har du lagt det som tar-fil utan kompression så har du ännu större chans att plocka ut data då varje filentry för varje fil inom tar-arkiven alltid börjar med 'ustar' men är det fragmenterat på disken (för att du använder NTFS) så blir det alltid snabbt mycket mer besvärligt.

---

Om det är en partitions-image (inte en diskimage) är att göra en partition som är minst lika stor som disken du tog kopia på - gör inget om den görs mycket större, på denna kopierar du sedan över dd-filen

Om det är en diskimagen (med partitionstabell) så lägger du kopia på med start på sektor noll i början av disken ( du skall inte ha någon data på disken då momentet skriver över allt gammalt där)

En annan program att prova med är 'losetup' på diskimagen direkt med typ 'losetup -f -P diskimage' på en kopia av diskimagen - om det lyckas så kommer partitionerna att synas som 'loopxx' under /dev/ och kanske blir mer tydligare om du kör lsblk för vilka som är vad.

Sedan monterar du sagda partition till lämplig mapp med 'mount -r /dev/loopxx /mnt' och du hittar sedan dina filer under /mnt/ (-r så är det skrivskyddat)

om du vill återskapa din dd-fil till dess fulla storlek (och större) - dvs större än dess trunkerade storlek och sista biten har ingen data (dvs. läses som fylld med '0' i innehåll vid läsförsök)

så är en väg att göra en 'tomfil' med önskade storleken med 'fallocate'

därefter "dd if=image.dd of=tomfil seek=0 skip=0 bs=1024k status=progress"

Då kommer 'tomfil' att skrivas över med data från image.dd så långt image.dd har någon data att skriva och resten av filen blir då fylld med '0' till sin fulla storlek.

när du läser i filen senare - speciellt om det är typ NTFS så kommer den inte att upptäcka att filsystemet är trunkerat förrän den försöker läsa sektorer som inte finns (ger IO eller CRC-error) alternativ ger resultatet med '0' i sektorerna).

Om NTFS (som jag gissar du använde) har lagt en del av sin $MFT på filutrymmet som är trunkerat (och man vet aldrig innan var det hamnar då $MFT utökar sig på samma sätt som en vanlig fil) - ja då har du problem och det är bara datascrape-kvar att hoppas på med diskräddningsprogram...

Permalänk
Medlem
Skrivet av xxargs:

'skip' kan du navigera startpunkten på din image - men du behöver början också för att få ett begripligt filsystem som OS förstår - OS kan inte arbeta på delar av disken i små bitar.

skall du positionera på 1 byte när så blir det typ "dd ibs=1 skip=antalet_byte_du_vill_hoppa_över obs=1024 if=infil of=utfil"

Vet du med dig att det ligger i arkiv och att det inte skrivits fragmenterat så finns det en chans med magic-word hitta starten på arkivet (tex för zipfiler, tar-arkiv etc.) och man får titta i headrar för zip.h tar.h mm. för att se hur många byte man skall klippa före magic word för att tex. tar skall kunna känna igen och packa upp filen direkt

Har du lagt det som tar-fil utan kompression så har du ännu större chans att plocka ut data då varje filentry för varje fil inom tar-arkiven alltid börjar med 'ustar' men är det fragmenterat på disken (för att du använder NTFS) så blir det alltid snabbt mycket mer besvärligt.

---

Om det är en partitions-image (inte en diskimage) är att göra en partition som är minst lika stor som disken du tog kopia på - gör inget om den görs mycket större, på denna kopierar du sedan över dd-filen

Om det är en diskimagen (med partitionstabell) så lägger du kopia på med start på sektor noll i början av disken ( du skall inte ha någon data på disken då momentet skriver över allt gammalt där)

En annan program att prova med är 'losetup' på diskimagen direkt med typ 'losetup -f -P diskimage' på en kopia av diskimagen - om det lyckas så kommer partitionerna att synas som 'loopxx' under /dev/ och kanske blir mer tydligare om du kör lsblk för vilka som är vad.

Sedan monterar du sagda partition till lämplig mapp med 'mount -r /dev/loopxx /mnt' och du hittar sedan dina filer under /mnt/ (-r så är det skrivskyddat)

om du vill återskapa din dd-fil till dess fulla storlek (och större) - dvs större än dess trunkerade storlek och sista biten har ingen data (dvs. läses som fylld med '0' i innehåll vid läsförsök)

så är en väg att göra en 'tomfil' med önskade storleken med 'fallocate'

därefter "dd if=image.dd of=tomfil seek=0 skip=0 bs=1024k status=progress"

Då kommer 'tomfil' att skrivas över med data från image.dd så långt image.dd har någon data att skriva och resten av filen blir då fylld med '0' till sin fulla storlek.

när du läser i filen senare - speciellt om det är typ NTFS så kommer den inte att upptäcka att filsystemet är trunkerat förrän den försöker läsa sektorer som inte finns (ger IO eller CRC-error) alternativ ger resultatet med '0' i sektorerna).

Om NTFS (som jag gissar du använde) har lagt en del av sin $MFT på filutrymmet som är trunkerat (och man vet aldrig innan var det hamnar då $MFT utökar sig på samma sätt som en vanlig fil) - ja då har du problem och det är bara datascrape-kvar att hoppas på med diskräddningsprogram...

Återigen, utförligt svar men i fel ämne.

Jag har redan ett .dd arkiv som inte blev fullständigt överfört. Det handlar alltså inte om att köra DD med alternativa inställningar.

Permalänk

Har du testat att mounta imagen? Om det inte fungera vad får du för fel?
Testat att köra ddrescue på imagen?

Beskriv gärna vad du gjort och vad du fått för resultat om du vill ha hjälp.

Permalänk
Medlem
Skrivet av Populus:

Ett utförligt och genomtänkt svar men tyvärr rörde svaret inte frågan jag hade.

Det här gäller en överföring som skedde för några år sedan som jag har valt att spara .dd arkivet för det finns data som jag skulle vilja använda igen. I min studentbostad hade jag bara ett USB minne för att rädda datan på min kraschade laptop och det ledde till det här problemet.
Eftersom en DD överföring är bit för bit tänkte jag att det kanske skulle kunna nå viss del av datan som blev överförd, även om oturen skulle visa sig att de viktiga filerna överfördes sist.

Frågan är alltså om jag kan skriva extra data/kod i slutet på det här .dd arkivet för att göra det monterbart för navigation?

Eventuellt kan du fylla på med nollor på slutet för att få rätt storlek, om det nu råkar vara ett problem.
I övrigt så finns det ingen standardiserad information du kan lägga till på slutet, utan fattas det data går det inte att säga generellt vilken data som fattas.

Permalänk
Medlem
Skrivet av raWpackeT:

Har du testat att mounta imagen? Om det inte fungera vad får du för fel?
Testat att köra ddrescue på imagen?

Beskriv gärna vad du gjort och vad du fått för resultat om du vill ha hjälp.

Jag har prövat använda "testdisk" och "OSFmount" utan några resultat. Arkivet är korrumperat / ej fullständigt.

Skrivet av Erik_T:

Eventuellt kan du fylla på med nollor på slutet för att få rätt storlek, om det nu råkar vara ett problem.
I övrigt så finns det ingen standardiserad information du kan lägga till på slutet, utan fattas det data går det inte att säga generellt vilken data som fattas.

Attans, det var just vad jag hade hoppats på. Att det skulle finnas en standardisering av hur DD överför data, att det kanske finns en början-klausul för DD operationen och således en avslutnings-klausul som i mitt hypotetiska fall skulle kunna gå att lägga till.
Det spelar ingen roll att inte hela hårddisken överfördes, jag fick med säkert 80% av hårddisken och tror chanserna är goda att den datan jag ville åt (några textfiler) finns med.

Permalänk
Medlem
Skrivet av Populus:

Jag har prövat använda "testdisk" och "OSFmount" utan några resultat. Arkivet är korrumperat / ej fullständigt.

Attans, det var just vad jag hade hoppats på. Att det skulle finnas en standardisering av hur DD överför data, att det kanske finns en början-klausul för DD operationen och således en avslutnings-klausul som i mitt hypotetiska fall skulle kunna gå att lägga till.
Det spelar ingen roll att inte hela hårddisken överfördes, jag fick med säkert 80% av hårddisken och tror chanserna är goda att den datan jag ville åt (några textfiler) finns med.

Hur dd överför data är inget konstigt - från början av källan till slutet. Hur data ligger organiserat är en annan sak. dd vet ingenting om filsystem och liknande, så använder man dd på en hel disk så överför den bara rådata från början till slut, inklusive alla tomma block.
Så den data du eventuellt vill lägga till har ingenting med dd att göra, och allt att göra med disken/partitionen du kopierade från.