Deixei meu SSD cair; não é mais possível montá-lo, mas é parcialmente legível até certo ponto. O que aconteceu?

Em relação à primeira questão:

O que aconteceu com o disco?

Eu realmente não sei, mas veja os comentários do Dr. Moishe Pippik e Ramhound para uma explicação parcial.

Para a segunda pergunta:

É possível fazer alguma coisa para recuperá-lo?

a resposta é um claro sim. Seja qual for o problema, o disco não foi danificado muito gravemente; ddrescueconsegui recuperar quase todas as informações do disco, e consegui extrair todos os arquivos que precisava.

Vou explicar todo o processo de recuperação, caso ajude alguém.

Como mencionei anteriormente, tive que conectar o drive internamente em vez de via USB para conseguir lê-lo, então foi isso que fiz aqui: inicializei o Linux ativo via pendrive, li o drive danificado dentro do computador e copiei para um drive de backup conectado via USB.

O primeiro passo é executar ddrescue, que faz basicamente exatamente o que é anunciado. Eu usei o guia aqui , mas há uma ressalva importante: se você estiver usando Linux live, não seja estúpido como eu e salve o log de resgate no diretório home, que desaparecerá assim que você reiniciar.

Então o comando inicial a ser executado é

sudo ddrescue --idirect /dev/sdc /media/ubuntu/whatever/rescue.img /media/ubuntu/whatever/rescue.log

e o resultado final que vi foi

     ipos:  497530 MB, non-trimmed:        0 B,  current rate:       0 B/s
     opos:  497530 MB, non-scraped:        0 B,  average rate:  13107 kB/s
non-tried:        0 B,  bad-sector:   55758 kB,    error rate:       0 B/s
  rescued:  500052 MB,   bad areas:    10222,        run time:  9h  2m 55s
pct rescued:   99.98%, read errors:   113242,  remaining time:          0s
                              time since last successful read:          0s
Scraping failed blocks... (forwards)
Finished                           

99,98% resgatados na primeira tentativa, nada mal.

(Uma observação: ocasionalmente, ddrescuefalhará com a mensagem ddrescue: /dev/sdc: Unaligned read error. Is sector size correct?. Quando isso acontecer, retire o disco, coloque-o novamente e execute novamente o mesmo comando (mas certifique-se de que o nome do dispositivo não mudou, por exemplo, de /dev/sdcpara /dev/sdd), que continuará de onde parou.)

Após a execução inicial, você pode tentar novamente, o que usa exatamente o mesmo comando, exceto com o --retry-passes=Nargumento adicionado. Minha experiência foi que cada nova tentativa adicional resgatou algumas centenas de kB adicionais de dados, mas era tão lento para uma quantidade tão pequena de dados que, em um certo ponto, desisti.

Agora você tem sua imagem de disco com alguns (10.000 ou mais) buracos nela. Se quiser, você pode fazer uma cópia da imagem, só para o caso de você estragar a primeira.

Neste ponto consegui montar o sistema de arquivos de interesse:

# At this point, do everything read-only (-r) to prevent modifying the image:
sudo kpartx -a -r /media/ubuntu/whatever/rescue.img
# The above command should have created devices corresponding to the partitions of the image.
# For me the partition of interest was /dev/mapper/loop14p6
sudo cryptsetup open /dev/mapper/loop14p6 try1
sudo vgchange -ay
# The above command should have created a mountable device, in my case /dev/vgubuntu/root
# both ro and noload are necessary for read-only case:
sudo mount -o ro,noload /dev/vgubuntu/root /path/to/mount/point

Neste ponto, eu consegui ver a estrutura completa do diretório e todos os meus arquivos. Abri alguns arquivos e tudo parecia normal.

Antes de fazer qualquer outra coisa, eu queria determinar quais arquivos seriam corrompidos (ou seja, quais arquivos tinham dados armazenados nos setores defeituosos que não foram recuperados pelo ddrescue). Há uma ferramenta ddrutilityque supostamente faz exatamente isso, mas não pareceu funcionar e suspeito que não funcione com discos criptografados. Então, escrevi alguns scripts python extremamente rápidos e sujos para fazer o trabalho. (Créditos a esta resposta por me dizer os debugfscomandos a serem executados)

Note que no script abaixo, é essencial que o partition_start_sectorsvalor esteja correto! Se você tem um esquema de particionamento simples, você pode simplesmente usar fdisk -lpara encontrá-lo. No entanto, para configurações com LUKS e coisas LVM, isso não é suficiente. Eventualmente, eu encontrei o comando dmsetup table, que mostra as informações necessárias:

$ sudo dmsetup table
loop14p1: 0 1048576 linear 7:14 2048
loop14p2: 0 2 linear 7:14 1052670
loop14p5: 0 1497088 linear 7:14 1052672
loop14p6: 0 974219264 linear 7:14 2551808
try1: 0 974186496 crypt aes-xts-plain64 :64:logon:cryptsetup:b422c3bc-f3f7-4fea-ab8b-900437ccc302-d0 0 252:3 32768
vgubuntu-root: 0 972177408 linear 252:4 2048
vgubuntu-swap_1: 0 2007040 linear 252:4 972179456

Portanto, o deslocamento relevante é 2551808 + 32768 + 2048.

O script 1 encontra números de blocos do sistema de arquivos e inodes associados a setores defeituosos no log de recuperação:

# step1.py
import subprocess

partition_start_sectors = 2551808 + 32768 + 2048
partition_start_bytes = partition_start_sectors*512

ext4_block_size = 4096

with open('rescue.log') as f, open('inodes.log', 'w') as inodes_out, open('missing_inodes.log', 'w') as missing_out:
    for i, line in enumerate(f.readlines()):
        print(i)
        row = line.strip().split()
        if len(row)==3 and row[2] == '-':
            bad_sector_pos = int(row[0],16)
            print(f'sector_pos: {bad_sector_pos}')
            bad_sector_size = int(row[1],16)
            first_bad_block = (bad_sector_pos-partition_start_bytes)//ext4_block_size
            last_bad_block = (bad_sector_pos+bad_sector_size-1-partition_start_bytes)//ext4_block_size
            for bad_block in range(first_bad_block, last_bad_block+1):
                print(f'block: {bad_block}')
                output1 = subprocess.check_output(f'sudo debugfs -R "testb {bad_block}" /dev/vgubuntu/root', shell=True)
                if b'marked in use' in output1:
                    print('in use')
                    output2 = subprocess.check_output(f'sudo debugfs -R "icheck {bad_block}" /dev/vgubuntu/root', shell=True)
                    if b'block not found' in output2:
                        print('no inode found for this block')
                        print(f'{bad_sector_pos} {bad_block}', file=missing_out, flush=True)
                    else:
                        inode = int(output2.split(b'\n')[1].split(b'\t')[1])
                        print(f'inode: {inode}')
                        print(f'{bad_sector_pos} {bad_block} {inode}', file=inodes_out, flush=True)
                else:
                    print('not in use')

Script 2 encontra nomes de arquivos associados a inodes:

# step2.py

import subprocess

inodes = set()
with open('inodes.log') as f:
    for line in f.readlines():
        row = line.strip().split()
        try:
            inode = int(row[2])
            inodes.add(str(inode))
        except ValueError:
            pass
inodes = list(inodes)
print(len(inodes))

for i in range(0, len(inodes), 30):
    inodes_subset = inodes[i:i+30]
    inodes_found = set()
    output = subprocess.check_output('sudo debugfs -R "ncheck ' + ' '.join(inodes_subset) + '" /dev/vgubuntu/root', shell=True)
    for line in output.split(b'\n'):
        row = line.split(b'\t')
        if len(row) == 2 and row[0] != b'Inode':
            inode = int(row[0])
            path = row[1].decode('ascii')
            inodes_found.add(str(inode))
            print(f'{inode} {path}')
    if inodes_found != set(inodes_subset):
        print('not all inodes found:')
        print(f'missing inodes: {set(inodes_subset)-inodes_found}')

Isso identificou cerca de 250 arquivos que estavam corrompidos. Com certeza, quando eu tentava abrir os supostos arquivos corrompidos, eles estavam bagunçados (por exemplo, parcialmente renderizados para jpegs, ruídos de clique e pulando para mp3s). Felizmente, dos 250 arquivos, todos eram arquivos com os quais eu não me importava, ou então arquivos dos quais eu já tinha backups anteriores suficientes.

Ele também identificou cerca de 200 blocos de sistema de arquivos não recuperados que não estavam associados a nenhum arquivo. Eu não tinha certeza do que fazer sobre eles. Olhando para a saída de dumpe2fs, não parecia que esses eram blocos que continham metadados do sistema de arquivos. Mas eles também não foram marcados como livres. Então não tenho certeza exatamente do que eles são.

Depois disso, você pode executar fsck. Embora por algum motivo eu não entenda que fscko comando em si não fez nada, e eu preciso executar e2fsck:

# Because we previously ran kpartx with -r option, the filesystem can't be modified, need to undo everything and redo it without -r
sudo umount /path/to/mount/point
# need to run these two commands in immediate succession, that's why they are combined on one line:
sudo vgchange -an && sudo cryptsetup close try1
sudo kpartx -d /media/ubuntu/whatever/rescue.img
# redo:
sudo kpartx -a /media/ubuntu/whatever/rescue.img
sudo cryptsetup open /dev/mapper/loop14p6 try1
sudo vgchange -ay
# fsck doesn't do anything (?), using e2fsck directly
sudo e2fsck -y -f /dev/vgubuntu/root

fsckencontrará muitos erros, mas felizmente nada catastrófico no meu caso.

Neste ponto, você pode montar sua unidade e copiar todos os arquivos que quiser dela.