Após uma queda de energia, meu laptop não inicializa. Investiguei o assunto com vários utilitários de disco e Live CDs. Os dados estão intactos e fiz uma cópia de backup deles. No entanto, gostaria de restaurar o funcionamento do disco, incluindo a inicialização, é claro, com o mínimo de esforço possível. Sei que muitos especialistas sugerem recriar partições novamente, restaurar o sistema operacional e reinstalar o software novamente. Isso dificilmente é possível no meu caso (nem tenho todos os kits de distribuição). É por isso que gostaria de editar a tabela de partições corrompida no local e preciso de um conselho sobre qual parte exatamente é problemática.
O disco contém 2 volumes: um é a partição primária e o outro é uma unidade lógica na partição estendida.
Quando inicializo o laptop a partir de um live CD, o Windows vê as duas unidades, mas a unidade lógica na partição estendida fica inacessível.
diskpartO comando do list volumemostra que o sinalizador do volume fs é RAW em vez de NTFS. O estranho é que os utilitários de disco que usei para restaurar dados (incluindoDMDE) veja este volume como NTFS e leia os dados dele sem problemas.
Aqui está a saída do diskpart:
E aqui está o que o DMDE mostra:
A questão é quais bytes brutos e como devo editar na tabela (posso usar DMDE para edição direta de disco, por exemplo) para tornar o volume NTFS adequado acessível no Windows?
Não tenho certeza de quais outros detalhes podem ser importantes e estou pronto para fornecê-los mediante solicitação.
Atualizar
A única resposta real entre as vinculadas sugere o uso do TestDisk. Primeiro, devo dizer que este utilitário é muito exigente quanto ao sistema operacional - ele não roda em nenhum live CD baseado em WinPE que eu tentei. Finalmente consegui executá-lo em um live CD Win7 [quase] completo. Aqui está o que mostra (observe o NTFS no volume lógico da partição estendida):
e (observe FAT32 desta vez):
Preciso recuperar o maior volume daqui. É exibido como FAT32 em TestDisk (DMDE mostrado como NTFS). Pcomando não produz uma lista legível de arquivos para este volume. Tentei o Tcomando para alterar o tipo para NTFS, mas isso não resolveu o problema: Painda lista um lixo ("sistema de arquivos pode estar danificado"). Mesmo assim, vejo o sistema de arquivos completo no DMDE e o salvei usando o utilitário r.saver.
Fiz uma pesquisa mais profunda:
e encontrei:
O volume NTFS excluído é a unidade real com meus dados. Então mudei de 'D' para 'L' e gravei as alterações no disco e reiniciei.
A unidade ainda está inacessível, mas agora, se eu executar o DMDE, ele reclamará que os registros MBR exigem um disco de pelo menos 625153410 LBA (320 GB), mas o disco é 625142448 LBA (320 GB).
Pela minha experiência, o TestDisk é incapaz de fazer o trabalho no meu caso ou preciso de instruções mais detalhadas sobre o que exatamente corrigir usando o TestDisk.
Desde já, obrigado.
Como uma pequena observação, devo dizer que o TestDisk tem bugs: fiz um backup da tabela de partição pelo comando correspondente do TestDisk, depois alterei a tabela e gravei-a no disco; então descobri que as alterações não ajudaram e decidi reverter as alterações do backup - como resultado, obtive uma tabela de partições completamente diferente e incorreta. A única coisa que me salvou do fiasco foi fazer outro backup usando dmde, que restaurou a estrutura conforme o esperado.
Responder1
O problema está resolvido (com o apoio de alguns gurus técnicos compartilhando seus conhecimentos nas redes sociais), e estou postando os detalhes mais importantes como resposta.
Desde o início, foi meu mal-entendido que a bandeira RAW é igual afisicamenteescrito 0 na partição correspondente. O fato é que 0 significa registro de partição vazio, ou seja, nenhuma partição, enquanto RAW é um registro especial.lógicosinalizador denotando alguns problemas na partição. Assim, diskparta “mensagem” neste caso foi que, embora a partição “inacessível” seja logicamente “saudável”, seu disco rígido subjacente pode conter alguns defeitos.
Na era dos discos rígidos SMART, os defeitos são registrados internamente em cada disco e podem ser corrigidos (se não forem fatais).
Então, primeiro eu useiHDDScanpara ler informações SMART. Aqui está o que consegui:
Observe que a contagem de erros pendentes é 3. Esses erros devem ser corrigidos.
Para isso, deve-se descobrir quais setores produzem exatamente esses erros, especificamente verificar a superfície do disco em busca de erros de leitura. No meu caso, Vitóriautilitário foi usado (a interface do utilitário está em inglês, mas infelizmente o site está em russo).
Como resultado, obtive 3 endereços de bloco com setores danificados.
A seguir, um dos métodos para reparar os blocos deve ser aplicado (o método específico pode variar dependendo do fabricante do disco rígido). No meu caso foi suficiente tentar escrever alguns dados nos blocos danificados. O disco SMART é inteligente o suficiente para remapear blocos danificados para algum outro espaço reservado se a operação de gravação falhar. A maneira mais fácil de executar o comando de gravação é copiar uma região de blocos para si mesma. Você pode usar sua ferramenta preferida para isso, eu useidmde( Tools -> Copy sectors). Na medida em que os blocos defeituosos estavam localizados próximos uns dos outros no meu caso, executei o comando copy apenas uma vez: o bloco inicial de Sourcee Destinationfoi definido como o mesmo (um pouco antes do primeiro setor defeituoso) e o número de setores a serem copiados foi definido grande o suficiente para cobrir a região com todos os 3 blocos ruins. Como esta é uma cópia de si mesma, ela não altera os blocos válidos. Os blocos ruins são preenchidos com zeros. Seus dados originais serão perdidos de qualquer maneira. Se os blocos defeituosos não contiverem dados críticos, o disco restaurado provavelmente poderá executar bem todos os programas.
Após a execução do comando de cópia, verifiquei as informações SMART mais uma vez e certifiquei-me de que a contagem de erros fosse 0. Caso contrário, algo deu errado e deveria ser investigado em profundidade.
A última coisa a fazer é executar chkdsk d: /F(onde destá a letra da sua unidade) para corrigir erros lógicos na partição restaurada fisicamente.
Depois de tudo isso feito, consegui recuperar a partição NTFS problemática (o sinalizador RAW desapareceu e está listado como NTFS novamente), no local e quase sem perda de dados - pelo menos o Windows está inicializando como antes.