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


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 correr 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, em seguida, 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. Eu escolhi "Edit Partition" e selecionei "Type linux (0x83)" (nenhum tipo foi pré-selecionado). Não houve alteração (Still Type desconhecido).
  9. Irã sudo testdisk /dev/sdc e fez uma análise rápida, que encontrou:

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

    pressionando p mostra os arquivos que eu mudei 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 como descrito em 7.
  11. Eu refiz 9; desta vez eu 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 -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. Irã sudo parted /dev/sdc então 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. Fiz uma pesquisa profunda com o 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
    

    enquanto correndo e fechado com:

    TestDisk 7.0, Data Recovery Utility, April 2015
    Christophe GRENIER <grenier@cgsecurity.org>
    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 correr e2fsck -f /dev/sdc1, o disco apareceu no lançador. Eu cancelei e2fsck com Ctrl+C para evitar mais mudanças até que eu saiba 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 para recuperar a partição perdida? Nova pergunta: Os erros relatados por e2fsck um motivo para se preocupar? Eles poderiam sugerir uma unidade fisicamente danificada?

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

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


0


origem


Erro óbvio? Pessoalmente, eu teria reformatado completamente o novo disco e o remarcado com um GPT. - fpmurphy1
Parece um bom plano para o futuro. No entanto, estou um pouco confuso, porque eu continuo lendo que o GPT é necessário para unidades acima de 2,2 TB. Como poderia um disco de 5TB funcionar mesmo com uma tabela de dados? - hife
Se você tiver um disco AF (formato avançado), em que o tamanho do setor é 2049, ele pode funcionar - praticamente. - fpmurphy1
Obrigado, eu vejo. Existe alguma chance de substituir o MBR com GPT ajudaria na recuperação da partição perdida? Ou isso apenas tornará mais difícil / impossível? O Testdisk oferece a opção de excluir a tabela de partições, que eu não ousei tentar. (Parece haver um software que afirma que pode converter MBR para GPT sem perder partições.) - hife


Respostas:


Corrida e2fsck -f /dev/sdc1 consertado um superbloco ruim e o dispositivo foi reconhecido sem problemas. Então eu deixo e2fsck corrija todos os problemas descobertos. Em uma corrida subseqüente e2fsck não apresentou mais erros.

Um teste offline estendido com smartctl concluído após 9 horas sem relatar erros (para evitar que o spindown automático aborte o teste, apliquei esta solução alternativa).


0