Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #237337 > unrolled thread

Repair partition after dd

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Repair partition after dd Andrea Neroni <bignero_86@yahoo.it> - 2021-07-14 00:40 +0200
    Re: Repair partition after dd songbird <songbird@anthive.com> - 2021-07-14 04:50 +0200
      Re: Repair partition after dd <tomas@tuxteam.de> - 2021-07-14 09:00 +0200
        Re: Repair partition after dd "Alexander V. Makartsev" <avbetev@gmail.com> - 2021-07-14 09:30 +0200
          Re: Repair partition after dd <tomas@tuxteam.de> - 2021-07-14 09:40 +0200
            Re: Repair partition after dd "Thomas Schmitt" <scdbackup@gmx.net> - 2021-07-14 10:10 +0200
              Re: Repair partition after dd <tomas@tuxteam.de> - 2021-07-14 11:10 +0200
              Re: Repair partition after dd "neroni_andrea@yahoo.it" <neroni_andrea@yahoo.it> - 2021-07-14 13:00 +0200
                Re: Repair partition after dd <tomas@tuxteam.de> - 2021-07-14 13:40 +0200
                  Re: Repair partition after dd songbird <songbird@anthive.com> - 2021-07-14 14:50 +0200
    Re: Repair partition after dd "Alexander V. Makartsev" <avbetev@gmail.com> - 2021-07-14 05:50 +0200
    Re: Repair partition after dd Brian <ad44@cityscape.co.uk> - 2021-07-14 12:10 +0200
      Safer ways to write an ISO onto USB stick [was Re: Repair partition after dd] "Thomas Schmitt" <scdbackup@gmx.net> - 2021-07-14 12:50 +0200
        Re: Safer ways to write an ISO onto USB stick [was Re: Repair  partition after dd] David Christensen <dpchrist@holgerdanske.com> - 2021-07-15 02:30 +0200

#237337 — Repair partition after dd

[Multipart message — attachments visible in raw view] — view raw

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/sdaDisk /dev/sda: 596.17 GiB, 640135028736 bytes, 1250263728 sectorsDisk model: SAMSUNG HM641JI Units: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk 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.

[toc] | [next] | [standalone]

#237347

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

[toc] | [prev] | [next] | [standalone]

#237353

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 13, 2021 at 10:40:20PM -0400, songbird wrote:
> 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

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

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#237356

[Multipart message — attachments visible in raw view] — view raw

On 14.07.2021 11:55, tomas@tuxteam.de wrote:
> On Tue, Jul 13, 2021 at 10:40:20PM -0400, songbird wrote:
>> 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
> (Formerly called PhotoRec). Yes, I had good results with that, too. Same-named
> Debian package.
>
> Cheers
>   - t
It looks like these two are different programs with different purposes.
https://www.cgsecurity.org/wiki/Main_Page

-- 
With kindest regards, Alexander.

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

[toc] | [prev] | [next] | [standalone]

#237357

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#237360

Hi,

tomas@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

[toc] | [prev] | [next] | [standalone]

#237361

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#237370

[Multipart message — attachments visible in raw view] — view raw

 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
  

[toc] | [prev] | [next] | [standalone]

#237371

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jul 14, 2021 at 10:36:23AM +0000, neroni_andrea@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

[toc] | [prev] | [next] | [standalone]

#237375

<tomas@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

[toc] | [prev] | [next] | [standalone]

#237348

[Multipart message — attachments visible in raw view] — view raw

On 14.07.2021 03:12, Andrea Neroni wrote:
> 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.
>
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
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#237363

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.

[toc] | [prev] | [next] | [standalone]

#237368 — Safer ways to write an ISO onto USB stick [was Re: Repair partition after dd]

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


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#237408 — Re: Safer ways to write an ISO onto USB stick [was Re: Repair partition after dd]

On 7/14/21 3:47 AM, Thomas Schmitt wrote:
> 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
> 
> 
> Have a nice day :)
> 
> Thomas


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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web