3

I imaged a failing SSD as best I could using ddrescue or dd (it's been too long to recall which). With the resulting .img, I've burnt a disk which is not recognised as mountable.

Using e2fsck -fyvC 0 upon the disk, I'm able to subsequently mount it, recovering some, but certainly not all, files originally on the SSD.

Is this the best option I'd have for data retrieval, or is there a better tool which could recover more?

Running e2fsck with the above flags, I receive various warnings about orphaned or deleted inodes, which are either fixed or deleted. Unfortunately, these seem to correspond to the data I'm most seeking from the disk.

The output is 227,000 lines, but some highlights below:

ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Clear? yes

*** journal has been deleted ***

Superblock has_journal flag is clear, but a journal is present.
Clear? yes

Truncating orphaned inode 6302578 (uid=1000, gid=1000, mode=0100664, size=3600)
Pass 1: Checking inodes, blocks, and sizes

[...]

Inode 1048618 was part of the orphaned inode list.  FIXED.
Inode 1048634 was part of the orphaned inode list.  FIXED.
Deleted inode 1048662 has zero dtime.  Fix? yes

[...]

Entry '..' in <6291748>/<9965526> (9965526) has deleted/unused inode 6291748.  Clear? yes

[...]

Unattached inode 9712327
Connect to /lost+found? yes

Inode 9712327 ref count is 2, should be 1.  Fix? yes

[...]

Free blocks count wrong for group #740 (32768, counted=3012).
Fix? yes

[...]

Directories count wrong for group #4593 (0, counted=114).
Fix? yes

[...]

Padding at end of inode bitmap is not set. Fix? yes

Recreate journal? yes

Creating journal (262144 blocks):  Done.

*** journal has been regenerated ***

/dev/sdc: ***** FILE SYSTEM WAS MODIFIED *****

     2205797 inodes used (4.52%, out of 48807936)
       20864 non-contiguous files (0.9%)
        1884 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 2154021/1685/13
   128999150 blocks used (66.08%, out of 195210139)
           0 bad blocks
          18 large files

     1869601 regular files
      282774 directories
          10 character device files
           1 block device file
           5 fifos
  4294963048 links
       53513 symbolic links (50169 fast symbolic links)
          14 sockets
------------
     2164179 files

Are there more advisable methods of data recovery here? Thanks in advance for any assistance.

Stribog
  • 31
  • 4
  • which dd command exactly? dd can't handle read errors well. use ddrescue instead. – frostschutz Dec 13 '22 at 13:16
  • "_I imaged a failing SSD as best I could using dd_" - that's almost certainly the problem; it's the wrong tool for the job. If the SSD is still working in any way at all, repeat the process but this time use `ddrescue`. – roaima Dec 13 '22 at 13:20
  • Thanks. Frankly, I very well could have used `ddrescue` at the time, though it's been long enough I can't recall. I can attempt another imaging on the original drive though. – Stribog Dec 13 '22 at 13:55
  • SSDs should have trim enabled. But then you have to have good backups. SSD is not like HDD which may keep old data and just overwrites it. After a SSD trim old data is erased, so space is ready for a new write. – oldfred Dec 13 '22 at 15:28

1 Answers1

1

I've recovered files this way in the past.

Use ddrescue (a similar program called recoverdisk for FreeBSD) to make an image of the disk. Do this before trying to recover. If fsck prompts you, just say no and make the image.

Use a VM (VMWare or something with snapshots) and load this image as a HDD disk in the VM. This avoids trim issues.

  • Snapshot, then run fsck and copy all files you could save. Ask fsck to delete files it can't repair.
  • Revert the Snapshot then try before and after fsck with the e2undel tool.
  • Revert again and try ext4magic -M option.
  • Finally revert and less -f /dev/sdb to find known text strings. Note: you may find multiple revisions of these over time. This will be all manual.
James Risner
  • 1,143
  • 2
  • 4
  • 18