Usando o ddrescue para recuperar uma unidade quebrada. Posso verificar o progresso antes da conclusão da execução?

Question

Em teoria, você pode encerrar ( ctrl+ C) ddrescuee executá-lo mais tarde com o mesmo arquivo de log para continuar em vez de recomeçar. Tenho visto alguns posts afirmando que esse método nem sempre funciona – nesses casos ddrescueignorei trabalhos anteriores e comecei do início por motivo desconhecido.

Tente montar a partição de destino somente leitura:

sudo mount -o ro /dev/sdc2 /mnt/foo

Como somente leitura, não deve atrapalhar a ddrescueoperação. Existe o risco de que os dados cruciais para o sistema de arquivos ainda não sejam recuperados, neste caso mountfalharão. Com alguma sorte, você poderá montar e ler os arquivos necessários, mas os arquivos poderão estar corrompidos mesmo se você não receber nenhum erro de mounte (por exemplo) cp. Inspecione-os ou suas cópias. Não encerre ddrescuea menos que você tenha certeza de que os arquivos são válidos e sem fragmentos não recuperados/desordenados dentro dele.

Em caso de algum problema você pode esperar para ddrescuerecuperar mais dados (se houver). Eu não esperaria que os arquivos não corrompidos aparecessem no ponto de montagem, porque o sistema pode armazenar em cache os metadados ou os próprios arquivos, etc. Espere umountpor mais dados recuperados, mountnovamente e verifique os arquivos.

Editar: respondendo a perguntas adicionais.

Existe uma maneira de dizer ao ddrescue para especificar uma pasta específica?

Não. A ferramenta funciona em nível de bloco. Não sabe nada sobre sistema de arquivos e arquivos. Sua declaração "ddrescuelog diz que 99,73% dos meus arquivos foram recuperados" deveria dizer "99,73% dos blocos".

Além disso, é possível que os dados tenham sido recuperados, já que 99,73% foram resgatados, mas estão danificados demais para serem reconhecidos como arquivos? Se for esse o caso, existe algum programa para visualizar arquivos danificados, talvez eu possa recuperar alguns deles manualmente.

Cenário possível: o conteúdo do arquivo é recuperado, mas a entrada correspondente do sistema de arquivos não (nota: em geral, o oposto também é possível, mas obviamente não é o seu caso). Você disse que a pasta inteira desapareceu. Acho que alguns dos arquivos podem aparecer lost+founddepois fsck(ou de forma semelhante, dependendo do seu sistema de arquivos - não sei o que é).

Mais informações aqui:Qual é o propósito da pasta perdida+encontrada no Linux e Unix?

Esta fsckoperação não é somente leitura e não deve ser executada quando ddrescueestiver funcionando. Encerrar ddrescue, executar fscke retomar ddrescuetambém é uma coisa ruim de se fazer. É melhor esperar ddrescueterminar. Pode levar algum tempo – leiaesseeesse.

Em geral, você deve trabalhar com fsck(ou qualquer outra ferramenta não somente leitura) em uma cópia dos dados recuperados. Bom caminho a seguir, para referência futura:

Grave em um arquivo, não em um dispositivo. Use um sistema de arquivos comcopiar na gravação (COW)recurso.
Faça umVACAcopie com cp --reflink=always. Você pode fazer isso durante ddrescuea operação. Esta cópia é como um instantâneo do seu arquivo de destino.
Use qualquer ferramenta na cópia, incluindo aquelas não somente leitura.
Em caso de falha você ainda tem o arquivo de destino original (talvez com mais dados recuperados, se ddrescueainda estiver em execução) para recomeçar com outroVACAcopiar (e talvez com ferramentas diferentes).

Você também pode tentar procurar arquivos excluídos e recuperá-los. A escolha de uma ferramenta depende do sistema de arquivos.

Outra dica: talvez o seu software estivesse usando arquivos temporários em algum outro lugar na hierarquia do sistema de arquivos. Verificar /tmp/, /var/tmp/.

Edite, respondendo a perguntas adicionais.

Quando o ddrescuelog diz que 99,73% dos blocos foram resgatados, o que isso significa exatamente? Parece que devo esperar alguns resultados, não um disco vazio.

Nota: o exemplo abaixo não pretende cobrir todos os problemas e cenários do sistema de arquivos, nem distinguir setores de disco de unidades de alocação de sistema de arquivos; é apenas para responder à pergunta.

Imagine que sua partição é um livro – uma enciclopédia, não um romance com enredo. Arquivos são artigos dentro. O bloco de disco (ou setor) é como uma página de um livro. O sistema de arquivos é uma forma geral de colocar artigos nas páginas. Algumas páginas contêm oÍndice (ToC)que é um problema de sistema de arquivos em nossa imagem e pode ser algo assim:

artigo nº 289: páginas 2076, 2077, 2078, 402, 403.

Observe que este artigo está fragmentado como um arquivo pode ser. Em outra página, mas ainda dentroToCtemos algo como estrutura de pastas:

…
people/: verToCna página 43.
…
(página 43)
mathematicians/: consulteToCna página 80
famous Poles/.: vejaToCna página 82
Adam and Eve.: consulte o artigo nº 14.
…
(página 80)
Euclid: consulte o artigo nº 289.
Banach Stefan: veja o artigo #4380.
…
(página 82)
Banach Stefan: consulte o artigo #4380.
Kościuszko Tadeusz: veja o artigo #2208.
…

Esta estrutura é um exemplo de arquivos com link físico. Existem pelo menos dois caminhos que apontam para um único artigo: ./people/mathematicians/Banach Stefane ./people/famous Poles/Banach Stefan. Aqui coloquei o ponto no início de cada caminho porque meu exemplo esconde deliberadamente a informação: a qual seção people/a seção pertence? (também pode ser /people/ou /full articles/people/ou /stubs/people/ou /foo/bar/people/).

OToCtambém pode ter uma seção que diz:

páginas "vazias": 567, 568, 569, 2070, 2071…

Uma determinada página contém texto (ou seja, dados), mesmo que não pertença a nenhum artigo existente no momento. Isso ocorre porque um processo de exclusão de artigo afeta apenasÍndice. OToCé a única maneira certa de saber se uma determinada página pertence a um artigo, qual artigo, ou pode ser tratada como vazia e substituída. Além disso: não há como identificar uma “página vazia” semToC. É estranho na enciclopédia ter uma página em branco como parte de um artigo, mas o setor cheio de 0s ou espaços ou qualquer outra coisa pode fazer parte de um arquivo. É tudo sobreToC.

Algumas de suas páginas (blocos) não foram resgatadas (ainda). Qualquer uma delas pode ser uma página com dados de artigos ouToc-metadados. Possibilidades:

O bloco ausente é o bloco de dados (digamos, página 2078). Você sabe o caminho para o artigo sobre Euclides e em quais páginas ele está, mas uma das páginas está em branco quando não deveria. O artigo é inválido.
O bloco ausente é o bloco de metadados. Alguns cenários:
- Você perdeu a noção do espaço livre.
- Você sabe que existe ./people/mathematicians/Euclidum caminho, mas não tem informações sobre quais páginas o artigo está. É impossível encontrar o artigo a menos que você já saiba algo sobre ele (por exemplo, uma entrada sobre uma pessoa provavelmente contém a palavra “nascido”; os arquivos PDF começam com “%PDF”).
- Você sabe que existe um único artigo em tais páginas, mas não existe um caminho completo para ele. Nesse caso você pode colocá-lo embaixo lost+founde é isso que fsckservirá. Na nossa foto existem possibilidades (entre outras):
  - Página 80 faltando: você sabe (da página 43) que existe mathematiciansuma seção (pasta), mas você não sabe que o artigo nº 289 deveria estar nela com o nome "Euclides".
  - Faltando a página 43: você não sabe que deveria haver o artigo nº 14 sobre Adão e Eva, nem seções com matemáticos ou poloneses famosos; mas você pode ver (na página 80) que há uma seção com artigos sobre Euclides e Banach, e há outra seção (página 82) com artigos sobre Banach e Kościuszko.Isto é o que pode estar acontecendo com o seu /home.Os artigos (arquivos) estão lá e podem ser válidos. Eles não podem ser alcançados pelo caminho porque você não temTocdo seu /home.
Qualquer combinação dos problemas acima pode ocorrer se houver vários blocos não recuperados.
O bloco ausente pode ser marcado como vazio. Neste caso você não perde nada.

Answer 1

Em teoria, você pode encerrar ( ctrl+ C) ddrescuee executá-lo mais tarde com o mesmo arquivo de log para continuar em vez de recomeçar. Tenho visto alguns posts afirmando que esse método nem sempre funciona – nesses casos ddrescueignorei trabalhos anteriores e comecei do início por motivo desconhecido.

Tente montar a partição de destino somente leitura:

sudo mount -o ro /dev/sdc2 /mnt/foo

Como somente leitura, não deve atrapalhar a ddrescueoperação. Existe o risco de que os dados cruciais para o sistema de arquivos ainda não sejam recuperados, neste caso mountfalharão. Com alguma sorte, você poderá montar e ler os arquivos necessários, mas os arquivos poderão estar corrompidos mesmo se você não receber nenhum erro de mounte (por exemplo) cp. Inspecione-os ou suas cópias. Não encerre ddrescuea menos que você tenha certeza de que os arquivos são válidos e sem fragmentos não recuperados/desordenados dentro dele.

Em caso de algum problema você pode esperar para ddrescuerecuperar mais dados (se houver). Eu não esperaria que os arquivos não corrompidos aparecessem no ponto de montagem, porque o sistema pode armazenar em cache os metadados ou os próprios arquivos, etc. Espere umountpor mais dados recuperados, mountnovamente e verifique os arquivos.

Editar: respondendo a perguntas adicionais.

Existe uma maneira de dizer ao ddrescue para especificar uma pasta específica?

Não. A ferramenta funciona em nível de bloco. Não sabe nada sobre sistema de arquivos e arquivos. Sua declaração "ddrescuelog diz que 99,73% dos meus arquivos foram recuperados" deveria dizer "99,73% dos blocos".

Além disso, é possível que os dados tenham sido recuperados, já que 99,73% foram resgatados, mas estão danificados demais para serem reconhecidos como arquivos? Se for esse o caso, existe algum programa para visualizar arquivos danificados, talvez eu possa recuperar alguns deles manualmente.

Cenário possível: o conteúdo do arquivo é recuperado, mas a entrada correspondente do sistema de arquivos não (nota: em geral, o oposto também é possível, mas obviamente não é o seu caso). Você disse que a pasta inteira desapareceu. Acho que alguns dos arquivos podem aparecer lost+founddepois fsck(ou de forma semelhante, dependendo do seu sistema de arquivos - não sei o que é).

Mais informações aqui:Qual é o propósito da pasta perdida+encontrada no Linux e Unix?

Esta fsckoperação não é somente leitura e não deve ser executada quando ddrescueestiver funcionando. Encerrar ddrescue, executar fscke retomar ddrescuetambém é uma coisa ruim de se fazer. É melhor esperar ddrescueterminar. Pode levar algum tempo – leiaesseeesse.

Em geral, você deve trabalhar com fsck(ou qualquer outra ferramenta não somente leitura) em uma cópia dos dados recuperados. Bom caminho a seguir, para referência futura:

Grave em um arquivo, não em um dispositivo. Use um sistema de arquivos comcopiar na gravação (COW)recurso.
Faça umVACAcopie com cp --reflink=always. Você pode fazer isso durante ddrescuea operação. Esta cópia é como um instantâneo do seu arquivo de destino.
Use qualquer ferramenta na cópia, incluindo aquelas não somente leitura.
Em caso de falha você ainda tem o arquivo de destino original (talvez com mais dados recuperados, se ddrescueainda estiver em execução) para recomeçar com outroVACAcopiar (e talvez com ferramentas diferentes).

Você também pode tentar procurar arquivos excluídos e recuperá-los. A escolha de uma ferramenta depende do sistema de arquivos.

Outra dica: talvez o seu software estivesse usando arquivos temporários em algum outro lugar na hierarquia do sistema de arquivos. Verificar /tmp/, /var/tmp/.

Edite, respondendo a perguntas adicionais.

Quando o ddrescuelog diz que 99,73% dos blocos foram resgatados, o que isso significa exatamente? Parece que devo esperar alguns resultados, não um disco vazio.

Nota: o exemplo abaixo não pretende cobrir todos os problemas e cenários do sistema de arquivos, nem distinguir setores de disco de unidades de alocação de sistema de arquivos; é apenas para responder à pergunta.

Imagine que sua partição é um livro – uma enciclopédia, não um romance com enredo. Arquivos são artigos dentro. O bloco de disco (ou setor) é como uma página de um livro. O sistema de arquivos é uma forma geral de colocar artigos nas páginas. Algumas páginas contêm oÍndice (ToC)que é um problema de sistema de arquivos em nossa imagem e pode ser algo assim:

artigo nº 289: páginas 2076, 2077, 2078, 402, 403.

Observe que este artigo está fragmentado como um arquivo pode ser. Em outra página, mas ainda dentroToCtemos algo como estrutura de pastas:

…
people/: verToCna página 43.
…
(página 43)
mathematicians/: consulteToCna página 80
famous Poles/.: vejaToCna página 82
Adam and Eve.: consulte o artigo nº 14.
…
(página 80)
Euclid: consulte o artigo nº 289.
Banach Stefan: veja o artigo #4380.
…
(página 82)
Banach Stefan: consulte o artigo #4380.
Kościuszko Tadeusz: veja o artigo #2208.
…

Esta estrutura é um exemplo de arquivos com link físico. Existem pelo menos dois caminhos que apontam para um único artigo: ./people/mathematicians/Banach Stefane ./people/famous Poles/Banach Stefan. Aqui coloquei o ponto no início de cada caminho porque meu exemplo esconde deliberadamente a informação: a qual seção people/a seção pertence? (também pode ser /people/ou /full articles/people/ou /stubs/people/ou /foo/bar/people/).

OToCtambém pode ter uma seção que diz:

páginas "vazias": 567, 568, 569, 2070, 2071…

Uma determinada página contém texto (ou seja, dados), mesmo que não pertença a nenhum artigo existente no momento. Isso ocorre porque um processo de exclusão de artigo afeta apenasÍndice. OToCé a única maneira certa de saber se uma determinada página pertence a um artigo, qual artigo, ou pode ser tratada como vazia e substituída. Além disso: não há como identificar uma “página vazia” semToC. É estranho na enciclopédia ter uma página em branco como parte de um artigo, mas o setor cheio de 0s ou espaços ou qualquer outra coisa pode fazer parte de um arquivo. É tudo sobreToC.

Algumas de suas páginas (blocos) não foram resgatadas (ainda). Qualquer uma delas pode ser uma página com dados de artigos ouToc-metadados. Possibilidades:

O bloco ausente é o bloco de dados (digamos, página 2078). Você sabe o caminho para o artigo sobre Euclides e em quais páginas ele está, mas uma das páginas está em branco quando não deveria. O artigo é inválido.
O bloco ausente é o bloco de metadados. Alguns cenários:
- Você perdeu a noção do espaço livre.
- Você sabe que existe ./people/mathematicians/Euclidum caminho, mas não tem informações sobre quais páginas o artigo está. É impossível encontrar o artigo a menos que você já saiba algo sobre ele (por exemplo, uma entrada sobre uma pessoa provavelmente contém a palavra “nascido”; os arquivos PDF começam com “%PDF”).
- Você sabe que existe um único artigo em tais páginas, mas não existe um caminho completo para ele. Nesse caso você pode colocá-lo embaixo lost+founde é isso que fsckservirá. Na nossa foto existem possibilidades (entre outras):
  - Página 80 faltando: você sabe (da página 43) que existe mathematiciansuma seção (pasta), mas você não sabe que o artigo nº 289 deveria estar nela com o nome "Euclides".
  - Faltando a página 43: você não sabe que deveria haver o artigo nº 14 sobre Adão e Eva, nem seções com matemáticos ou poloneses famosos; mas você pode ver (na página 80) que há uma seção com artigos sobre Euclides e Banach, e há outra seção (página 82) com artigos sobre Banach e Kościuszko.Isto é o que pode estar acontecendo com o seu /home.Os artigos (arquivos) estão lá e podem ser válidos. Eles não podem ser alcançados pelo caminho porque você não temTocdo seu /home.
Qualquer combinação dos problemas acima pode ocorrer se houver vários blocos não recuperados.
O bloco ausente pode ser marcado como vazio. Neste caso você não perde nada.

Usando o ddrescue para recuperar uma unidade quebrada. Posso verificar o progresso antes da conclusão da execução?

Responder1

Editar: respondendo a perguntas adicionais.

Edite, respondendo a perguntas adicionais.

informação relacionada