Perdeu a partição ext4: o testdisk lista arquivos, mas não conserta a tabela de partições

Question

Resumo:

O Testdisk encontra a partição ext4 perdida e é capaz de listar arquivos contendo, mas tentar gravar a estrutura da partição no disco não faz nada.

Atualizar : depois de executar e2fsck -f /dev/sdc1 , o disco foi montado e parece estar funcionando normalmente. No entanto, também relatou alguns erros (ver 15. abaixo).

O que aconteceu:

Vou tentar listar tudo o que fiz relacionado ao problema:

1. Eu tenho um novo disco rígido externo de 5TB que foi pré-formatado como FAT32 (chamado Intenso).
2. Eu apaguei essa partição e criei uma nova partição ext4 usando o gparted (chamado Intenso5TB).
3. Como a partição pertencia ao root, alterei o proprietário e o grupo para o meu usuário.
4. Mudei algumas centenas de GB de dados para essa partição e removi-a com segurança.
5. A próxima vez que eu conectei o disco rígido, ele foi montado como somente leitura. Meu usuário ainda era o proprietário.
6. Eu adicionei "rw" às opções de montagem no utilitário "Discos" do Ubuntu e desmontei a unidade.
7. O utilitário Disks exibiu a partição / dev / sdc1 como "tipo desconhecido" e não pôde ser montado.
8. escolhi "Edit Partition" e selecionei "Type linux (0x83)" (nenhum tipo foi pré-selecionado). Não houve alteração (Still Type desconhecido).

9. Eu corri sudo testdisk /dev/sdc e fiz uma análise rápida, que encontrou:

   * Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]
   

   pressionando p mostra os arquivos que eu movi para a partição , então eu disse ao Testdisk para escrever a estrutura da partição no disco.

10. Após outra reinicialização para atualizar a tabela de partição, o comportamento foi novamente conforme descrito em 7.

11. Eu refiz 9; desta vez eu tentei usar

    partprobe /dev/sdc
    

    para evitar a reinicialização novamente, mas recebi a mensagem:

    Error: Partition(s) 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64 on /dev/sdc have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.
    

12. sudo fdisk -lu retorna

    Disk /dev/sdc: 4,6 TiB, 5000981078016 bytes, 1220942646 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 33550336 bytes
    Disklabel type: dos
    Disk identifier: 0x4400838c
    
    Device     Boot Start        End    Sectors  Size Id Type
    /dev/sdc1  *      256 1220942591 1220942336  4,6T 83 Linux
    

13. Corri sudo parted /dev/sdc then rescue 256 1220942591 que não fez nada (sem atraso, sem saída, apenas um novo prompt de comando dentro do parted), mesmo com rescue 0 1220942591 , rescue 1 1220942591 ou rescue 1 -1 .

14. Eu fiz uma pesquisa profunda com o Testdisk, que relatou várias linhas idênticas de:

    Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]
    

    e também:

    check_FAT: can't read FAT boot sector
    Invalid FAT boot sector
     0 D FAT16 LBA            252822 192 45 254047 161 57   19677685
      FAT16 LBA            252822 192 45 254047 161 57   19677685
    

    enquanto corre e fecha com:

    TestDisk 7.0, Data Recovery Utility, April 2015
    Christophe GRENIER <[email protected]>
    http://www.cgsecurity.org
    
    Disk /dev/sdc - 5000 GB / 4657 GiB - CHS 76000 255 63
    
    The harddisk (5000 GB / 4657 GiB) seems too small! (< 16 TB / 15 TiB)
    Check the harddisk size: HD jumpers settings, BIOS detection...
    
    The following partition can't be recovered:
         Partition               Start        End    Size in sectors
    >  FAT16 LBA            252822 192 45 254047 161 57   19677685
    
    
    
    
    
    
    
    
    
    
    [ Continue ]
    80 GB / 75 GiB
    

15. Depois de executar e2fsck -f /dev/sdc1 , o disco apareceu no inicializador. Cancelei e2fsck com Ctrl+C para evitar mais alterações até saber mais. A unidade foi então montada com sucesso no clique. Eu pareço ser capaz de ler e escrever. Saída de e2fsck :

    e2fsck -f /dev/sdc1
    e2fsck 1.42.13 (17-May-2015)
    ext2fs_open2: Bad magic number in super-block
    e2fsck: Superblock invalid, trying backup blocks...
    Superblock needs_recovery flag is clear, but journal has data.
    Recovery flag not set in backup superblock, so running journal anyway.
    Intenso5TB: recovering journal
    Pass 1: Checking inodes, blocks, and sizes
    Inode 59883521 is in use, but has dtime set.  Fix<y>? yes
    Inode 59883521 has imagic flag set.  Clear<y>? yes
    Inode 59883521 has compression flag set on filesystem compression support.  Clear<y>? yes
    Inode 59883521 has INDEX_FL flag set but is not a directory.
    Clear HTree index<y>? yes
    Inode 59883521, i_blocks is 16777216, should be 0.  Fix<y>? yes
    Deleted inode 59885573 has zero dtime.  Fix<y>? yes
    Deleted inode 59885574 has zero dtime.  Fix<y>? yes
    ^CIntenso5TB: e2fsck cancelled.
    
    Intenso5TB: ***** FILE SYSTEM WAS MODIFIED *****
    

Minhas perguntas:

1. Existe algum erro óbvio que eu tenha cometido que poderia ter causado este problema em primeiro lugar?

2. Existe alguma esperança de recuperar a partição perdida? Nova pergunta : os erros relatados por e2fsck são motivo para preocupação? Eles poderiam sugerir uma unidade fisicamente danificada?

3. O que causa a mensagem de erro de partprobe em 11?

(Os dados foram movidos de outro disco que não toquei desde então, embora não seja visível no momento, ele deve ser aproveitável a partir de lá.)

    

Answer 1

A execução de e2fsck -f /dev/sdc1 corrigiu um superbloco ruim e o dispositivo foi reconhecido sem problemas. Então, eu deixo e2fsck corrigir todos os problemas que ele descobriu. Em uma execução subsequente, e2fsck não relatou mais erros.

Um teste offline estendido com smartctl concluído após 9 horas relatando nenhum erro (para impedir que o spindown automático abortasse o teste, apliquei esta solução alternativa ).