Hoe in een "unallocated space" bestanden terug te vinden?

[Beekhof]

Vorig jaar maakte ik een back-up van de home partitie horende bij Ubuntu12.04 (alvorens deze te vervangen door Ubuntu14.04) op een externe HD van 500GB.
Daarna maakte ik een fout bij het uitlezen waardoor die Seagate HD geen (backup) bestanden meer terug te vinden zijn.
Daarom heb ik er TestDisk op toegepast om de verdwenen bestanden weer terug te vinden. Op bijgaande bijlage “testdisk.log” is te zien dat de 4 partities (die ik er op gezet had in 2014) nog aanwezig zijn, echter zijn geen bestanden te vinden, met dit “data recover” programma.

Ubuntu14.04 (root en home) staat op ST9500320AS=/dev/sda en de verloren bestanden op ST9500325AS=/dev/sdb.
Van sdb heb ik een partitie tabel gemaakt m.b.v. GPARTED, zie bijlage “Partities-ST9500325(11-11-15)”. Daarop valt af te lezen dat de indeling veranderd is!!
Nu vraag ik mij af hoe er van het eerste deel (unallocated 97.66GiB) een image te maken valt om er daarna nog eens de “recovery” programma's TestDisk en/of PhoteRec op in te laten werken?
Ik vond namelijk een artikel om verdwenen bestanden op zgn. lege ruimte op te sporen: http://super.com/questions/710814/restore-data-on-unallocated-space.
Daarin wordt het Linux commando dd toegepast voor een “unallocated” ruimte op het einde van een HD, nadat er van de totale HD een image-file gemaakt is. Hoe staat er echter niet bij! Ik vermoed: sudo dd if=/dev/sdb of=image-file.
Mijn vraag is ook hoe dit dd commando er uit ziet om de 97.66 GiB aan het BEGIN van de beschadigde ST900325 HD aangegeven moet worden?
Toepassing van seek, skip, bs … , en de omrekening van 97,66GiB naar hoeveel bytes?
Of valt er iets te doen met foremost?

[Beekhof]

Ten tweede male toegevoegde bijlage: TestDisk.log

[jvecht]

Hoi Beekhof,

Vond Photorec niks dan?

[Beekhof]

dank, jvecht. Nog niet geprobeerd PhotoRec, zal zeker nog doen.

Wat ik vergat te melden: die DATA-1 partiële lijkt nu unallocated space, maar daarop herinner me juist veel files "geschoven" te hebben. ik bedoel cntl C en V voor copy en paste.

[jvecht]

Hoi Beekhof,

OK. Photorec is het ding voor dit soort problemen. Ik ben benieuwd. Succes, ouwe molenaar !

[jan11000]

Je hebt al een fout gemaakt door een partitie tabel te maken, van een partitie.

Sommige data is nu al weg.

Zoek eerst eens uit wat je moet doen, zoek handleidingen, zoek google af, zoek youtube.
Eerst goed op papier zetten wat de volgorde is.

Dan gaan oefenen, bijv met dd, dit kun je ook google voor gebruiken, en testen op een andere hd.

Als je weet hoe recovery gaat, dan kun je met je beschadigde hd gaan recoveren.
https://gathering.tweakers.net/forum/list_messages/1351243

[Beekhof]

Jan-1100:
Inderdaad dat was ook mijn vraag: hoe kun je met het Linux commando d.d. van een “unallocated” (toegewezen lege ruimte) een image maken?
In het genoemde artikel is er een voorbeeld:
“You could also try to make an image of the UNALLOCATED space only, and run photorec on that image. It should be faster. I assume you already have an image of the disk as image-file”
 
dd if=image-file of=unallocated-space bs=512 skip=312581807
waarbij het getal 31..807 staat voor het einde van de linux partities er voor.
M.a.w. hier is een unallocated-space gevonden die als laatste op d HD aanwezig is.

Wat ik nu zoek is een dd cmd voor idem zo'n unall.. space, maar nu als EERSTE op de HD
Ik weet wel dat die ruimte 97,66 GiB groot is, zie hierboven GPARTED partities.
Hoe dit nu in dd verwerken?

dd if=/dev/sdb of=image-file                                                Mijn vraag: is dit de juiste notatie??
Dit levert een image-file van de totale HD waarop de verloren files nog zouden moeten staan.

Nu weet ik achteraf zeker dat  ik die gezet heb aan het BEGIN van de HD, dus in de ruimte die nu unallocated blijkt te zijn!.
dd if=image-file of=unallocated-space bs=107378305568 count=1        Is dit de juiste notatie??
(97,66GiB= 97.66x1,024 GB=100,00384GB=100,00384x1024x1024x1024~107378305568 bytes)

Krijg ik dan de unallocated ruimte waarop de programma's TestDisk, PhotoRec, Foremost............. de verloren files kunnen gaan opleveren?

[Nero]

Code: [Selecteer]

dd if=/dev/sdb of=image-file bs=16K count=7M16K=16*1024=16,384 bytes
7M=7*1024*1024=7,340,032 blocks van 16K
16K*7M=120,259,084,288 bytes.

Daarbij heb je een kleine reserve. 6M is net te weinig.

[Beekhof]

Jan-11000:
ben 't met je eens GPartted voorzichtig ermee, maar enkel kijken (zonder kopen) mag toch wel?
Om inderdaad problemen te voorkomen is een  backup noodzakelijk alvorens iets m.b.v. GParted te gaan wijzigen (zoals resize) en is het verstandig GParted niet te starten vanuit het "werksysteem". Ik pas het dan ook altijd vanaf een live-usb toe, ook zelfs om te kijken naar de partitie verdeling op de HD!

Nero:
Is dezelfde voorzichtigheid gewenst voor het commando dd?
Je oplossing lijkt mij de beste en simpeler dan in het genoemd artikel, mijn dank.
Op die manier komen de 97,66 GB vrije ruimte in image-file terecht waarmee je verder kan.
Wat er met die enkele bytes te veel gebeurt (uiterst klein deel van part. sdb1) is mij nog een raadsel? 
 

[Nero]

dd kan je gerust van uit de gewone werkomgeving starten. Uiteraard wel zeker zijn dat niet naar het ongebruikte schijfgedeelte wordt geschreven, maar als je een bestandsnaam als doel geeft is dat sowieso verzekerd.

De extra bytes uit de image worden ook gescand op bestanden, maar die kan je makkelijk als duplicate verwijderen uit de resultaten. Tenzij je bij Testdisk de scan area beperkt.

[Beekhof]

Nero: Dat ziet er mooi uit, ga ik doen.

[Beekhof]

Bedankt Nero: het is prima gelukt de omzetting dd, nu nog PhotoRec er op proberen.