Partição ext4 perdida: testdisk lista arquivos, mas não consegue corrigir a tabela de partição

Partição ext4 perdida: testdisk lista arquivos, mas não consegue corrigir a tabela de partição

Resumo:

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

Atualizar: Após a execução 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 que fiz relacionado ao problema:

  1. Comprei um novo disco rígido externo de 5 TB pré-formatado como FAT32 (chamado Intenso).
  2. Excluí essa partição e criei uma nova partição ext4 usando gparted (chamada Intenso5TB).
  3. Como a partição pertencia ao root, mudei de proprietário e grupo para meu usuário.
  4. Movi algumas centenas de GB de dados para essa partição e removi-os com segurança.
  5. Na próxima vez que conectei o disco rígido, ele foi montado como somente leitura. Meu usuário ainda era o proprietário.
  6. Adicionei “rw” às opções de montagem no utilitário “Disks” 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 montada.
  8. Eu escolhi "Editar Partição" e selecionei "Tipo linux (0x83)" (nenhum tipo foi pré-selecionado). Não houve alteração (tipo ainda desconhecido).
  9. Corri sudo testdisk /dev/sdce fiz uma análise rápida, que descobriu:

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

    pressionar pmostra os arquivos que movi para a partição, então eu disse ao Testdisk para gravar a estrutura da partição no disco.

  10. Após outra reinicialização para atualizar a tabela de partições, o comportamento foi novamente descrito em 7.
  11. Refiz 9.; dessa vez tentei usar

    partprobe /dev/sdc
    

    para evitar reiniciar 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 -luretorna

    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. Executei sudo parted /dev/sdcentão rescue 256 1220942591o que não fez nada (sem atraso, sem saída, apenas um novo prompt de comando dentro do parted), o mesmo com rescue 0 1220942591, rescue 1 1220942591ou rescue 1 -1.

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

    Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]
    

    assim como:

    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
    

    durante a execução e fechado 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. Após a execução e2fsck -f /dev/sdc1, o disco apareceu no inicializador. Cancelei e2fsckcom Ctrl+Cpara evitar novas alterações até saber mais. A unidade foi então montada com sucesso com um clique. Parece que consigo 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. Cometi algum erro óbvio que poderia ter causado esse problema em primeiro lugar?

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

  3. O que causa a mensagem de erro partprobedo 11?

(Os dados foram movidos de outro disco que não toquei desde então, portanto, embora não estejam visíveis no momento, devem ser recuperáveis ​​a partir daí.)

Responder1

A execução e2fsck -f /dev/sdc1corrigiu um superbloco ruim e o dispositivo foi reconhecido sem problemas. Em seguida, deixei e2fsckcorrigir todos os problemas descobertos. Em uma execução subsequente, e2fscknão relatou mais erros.

Um teste off-line estendido smartctlconcluído após 9 horas sem relatar erros (para evitar que a rotação automática aborte o teste, apliqueiesta solução alternativa).

informação relacionada