Repair partition after dd

[Andrea Neroni]

Hi all,

While preparing a bootable USB a wild dd command was executed on the wrong partition, namely on /dev/sda5 instead of the intended /dev/sdb.

The consequences are easy to imagine. However, as the start of the disk has not been touched (the command run on sda5) I still have some hope to be able to recover part of the data before wiping out the disk and reinstalling (the overwritten portion of the disk is very small).

Running fdisk on /dev/sda yields the following:

> fdisk -l /dev/sda

Disk /dev/sda: 596.17 GiB, 640135028736 bytes, 1250263728 sectors

Disk model: SAMSUNG HM641JI 

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x3d27ec68

Device     Boot   Start        End    Sectors   Size Id Type

/dev/sda1  *       2048    1050623    1048576   512M  b W95 FAT32

/dev/sda2       1052670 1250263039 1249210370 595.7G  5 Extended

/dev/sda5       1052672 1250263039 1249210368 595.7G 83 Linux

The partition table should be intact, sda5 is a partition inside the extended sda2. The partition should be Ext4.

Question: having those information, is it possible to repair the partition to a state where I can copy away as much data I can and how can I do it?

Thanks to everybody!

Andrea

PS: yes, I know, data should have been backed up. Lesson learned.

[songbird]

Andrea Neroni wrote:
...
> Question: having those information, is it possible to repair the partition =

> to a state where I can copy away as much data I can and how can I do it?
> Thanks to everybody!

testdisk


songbird

[Alexander V. Makartsev]

In your case, I recommend to try R-Studio Linux. [1]
It is a complex professional data recovery utility, which could take some time to learn how to use it, but it is powerful enough to get the job done.
This version is free and supports only Ext2\3\4 filesystems.

Recovery procedure basically should go like this:
0. Don't write anything to a damaged partition to ensure better yield of recovered data.
1. Make with the utility an image of damaged partition to another physical disk.
2. Use the utility to scan image for filesystems. It could find more signatures, but the right one is usually that makes sense in size the most.
3. Perform low-level scan of chosen filesystem for available files.
4. Open list of found files and select ones you need to recover.


[1] https://www.r-studio.com/free-linux-recovery/

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀ 

[to...@tuxteam.de]

(Formerly called PhotoRec). Yes, I had good results with that, too. Same-named
Debian package.

Cheers
- t

[Alexander V. Makartsev]

It looks like these two are different programs with different purposes.
https://www.cgsecurity.org/wiki/Main_Page

[to...@tuxteam.de]

On Wed, Jul 14, 2021 at 12:26:29PM +0500, Alexander V. Makartsev wrote:

[...]

> >> testdisk
> >(Formerly called PhotoRec) [...]

> It looks like these two are different programs with different purposes.
> https://www.cgsecurity.org/wiki/Main_Page

(I guess the above snippet is what you're referring to). Yes. To be more
precise: Debian package `testdisk' encompasses testdisk and PhotoRec.

Testdisk is more about the file system structure, whereas PhotoRec tries
to rescue (portions of) files based on content.

Cheers
- t

[Thomas Schmitt]

Hi,

to...@tuxteam.de wrote:
> Testdisk is more about the file system structure, whereas PhotoRec tries
> to rescue (portions of) files based on content.

Since the partition now begins by a valid and complete ISO 9660 filesystem
it might be necessary to deface the filesystem before any search for
remnants of the original file system structure can get onto the right track.

So if the rescue effort does not show sufficient results, then the whole
ISO filesystem could be erased in order to point the rescue team to the
interesting rest of the partition.

Erasing the whole ISO would be quite similar to the original mistake:

- Determine the byte size of the ISO image that was copied to /dev/sda5.

- To get some reasonable throughput, divide the byte size by 2048 which
will yield the block count. Let's assume the result is 714752.

- Now zeroize the ISO's range in /dev/sda5:
dd if=/dev/zero bs=2048 count=714752 of=/dev/sda5

(If enough empty storage is available, then i'd advise to make a plain
copy of /dev/sda5 before beginning to fiddle with it.)


Have a nice day :)

Thomas

[to...@tuxteam.de]

On Wed, Jul 14, 2021 at 10:09:17AM +0200, Thomas Schmitt wrote:
> Hi,

[good advise, as always from Thomas]

> (If enough empty storage is available, then i'd advise to make a plain
> copy of /dev/sda5 before beginning to fiddle with it.)

Oh, yes. Forgot that. Make *always* a copy and play on that. Always.

If your data is worth anything (and you're going to pour tens of hours
into it), then some external HD (or a stick) is totally worth it.

Don't rush it :)

Cheers
- t

[Brian]

On Tue 13 Jul 2021 at 22:12:28 +0000, Andrea Neroni wrote:

> While preparing a bootable USB a wild dd command was executed on the
> wrong partition, namely on /dev/sda5 instead of the intended /dev/sdb.
> The consequences are easy to imagine.

It would be nice to avoid having to have root privileges in order
to do 'cp <ISO> /dev/sdX' with a USB stick. A udev rule under
/etc/udev/rules.d/ could be a solution:

SUBSYSTEM=="block", ATTRS{removable}=="1", GROUP="floppy"

OTOH, perhaps it would be wise to read

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788662
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751892

--
Brian.

[Thomas Schmitt]

Hi,

Brian wrote:
> It would be nice to avoid having to have root privileges in order
> to do 'cp <ISO> /dev/sdX' with a USB stick. A udev rule under
> /etc/udev/rules.d/ could be a solution:
>
> SUBSYSTEM=="block", ATTRS{removable}=="1", GROUP="floppy"

This could have prevented the mishap, indeed, provided that /dev/sda is
an internal SATA disk.

But i think that the criterion of being "removable" does not sufficiently
characterize a valid target for dd-ing an installation ISO, although
being an internal disk is a strong indication for being not the right one.

It is rather about the current content of the USB stick or memory card
which should be considered.
Best is to make an unambiguous relation between the physical stick in the
user's hand and the target device file.

My proposal for a mitigation of the currently dangerous situation is to
see on
https://wiki.debian.org/XorrisoDdTarget

[neroni...@yahoo.it]

Hi,

> Since the partition now begins by a valid and complete ISO 9660 filesystem

> it might be necessary to deface the filesystem before any search for
> remnants of the original file system structure can get onto the right track.
>
> So if the rescue effort does not show sufficient results, then the whole
> ISO filesystem could be erased in order to point the rescue team to the
> interesting rest of the partition.

Yes, I aws afraid that having a valid filesystem on top of the previous one could lead to some misunderstanding in TestDisk. I'll definitely try what you are suggesting.

> - Determine the byte size of the ISO image that was copied to /dev/sda5.

>
> - To get some reasonable throughput, divide the byte size by 2048 which
>  will yield the block count. Let's assume the result is 714752.
>
> - Now zeroize the ISO's range in /dev/sda5:
>    dd if=/dev/zero bs=2048 count=714752 of=/dev/sda5

Thanks. Hopefully something good will come out. In any case I already did a PhotoRec run to extract as many files I could from the partition. Something has been retrieved, I'll need a lot of time to go over everything though.

Thanks again!

Andrea

[to...@tuxteam.de]

On Wed, Jul 14, 2021 at 10:36:23AM +0000, neroni...@yahoo.it wrote:

> [...] Something has been retrieved, I'll need a lot of time to go over everything though.

My experience, too. I've done that for other people now and then
(because this never happens to me [1]) and when they say "gee...
this is taking long", my reply is "wait until we've to go over all
that "recovered" stuff".

Cheers, good luck
[1] *BLAM*! "uh-oh..." ;-)

- t

[songbird]

<to...@tuxteam.de> wrote:
...

> My experience, too. I've done that for other people now and then
> (because this never happens to me [1]) and when they say "gee...
> this is taking long", my reply is "wait until we've to go over all
> that "recovered" stuff".

many years ago i had a windows check disk of about 300,000 files
to wade through. i wrote a program which went through that looked
at the magic numbers and then from there it was mostly string
indexing to find only the files i was interested in. one of
the best things i ever did for myself was delete all of that once
i had the few files i needed right away. there was a lot of old
history in there that i could read again and then i figured out
that i just didn't need to dwell on that stuff any more.

in the middle of last winter i was trying to find if i'd backed
up all those parts of files someplace but gladly i didn't find a
bit of it anywheres.


songbird

[David Christensen]

I think we've all made painful mistakes with /dev/sd* device nodes.
Beyond identifying disks, partitions, filesystems, etc., with dmesg(1),
lsusb(1), parted(8), e2label(8), I have developed the habit of using
/dev/disk/by-id/* device nodes whenever possible.


David