Copiar arquivos de um HD defeituoso, saltando rapidamente os arquivos corrompidos, tem como?

Olá galera!

Estou com meus backups pessoais em 3 HD’s externos, GPT/NTFS, sendo duas de 1 TB e uma de 596 GB, todas demorando para acessar, e sob alerta do SMART de que vão pifar a qualquer momento.

Vou passar todas para outra unidade externa, desta vez um M.2 nvme Netac nv3000 Gen3x4 de 2 TB, montado em case externa, também GPT/NTFS (que posso formatar para EXT4 ou algo que vcs considerem melhor - aceito dicas!). Vai caber tudo, já que tem várias coisas repetidas nos dois HD’s de 1 TB, então o resultado não deve extrapolar a capacidade do Netac.

Claro que vou correr para adquirir também um HDD de 2 TB para espelhar o SSD (e aceito dicas de HD’s seguros… um técnico de hardware me recomendou HD’s de servidor, bem como alugar armazenamento em nuvem, mas minha internet é somente móvel 4G e muita lenta a conexão onde moro).

Pesquisei neste portal, sobre como copiar de unidades com bad blocks para outra unidade 100% íntegra, só que a maioria das dicas foca na recuperação de dados, incluindo, por ex., a clonagem da unidade defeituosa para outra saudável.

O motivo de eu ter criado este tópico é que desejo, numa primeira etapa, efetuar uma cópia apenas dos arquivos íntegros, usando parâmetros específicos (que desconheço, por isso peço ajuda) para ignorar/saltar rapidamente os arquivos corrompidos / inacessíveis.

Isso mesmo, saltar rapidamente para evitar perda de tempo, inclusive o risco do HD pifar de vez, caso fique tentando diversas vezes ler cada arquivo, que se encontra em setores corrompidos. Nos meus tempos de MS-DOS, o comando copy ficava insistindo alguns segundos em cada arquivo corrompido, para só depois perguntar: retry, ignore or cancel… Um outro comando MS-DOS (que não me recordo) já incorporava a alternativa “ignore all”, mas também tentava várias vezes ler cada arquivo corrompido, antes de seguir adiante.

Mas agora que uso somente Linux, segue a pergunta chave deste tópico:

  • Tem como usar o comando “cp”, dando algum parâmetro para logo de cara ignorar/saltar os arquivos corrompidos, sem ficar “numerosos segundos” tentando lê-los? Ou tem alguma ferramenta mais adequada? (para saltar logo, e não para tentar recuperar)

Em seguida, numa segunda etapa, vou tentar copiar apenas os arquivos corrompidos. Aí quem sabe, usar o rsync para identificar na nova unidade, os arquivos íntegros que já foram copiados na primeira etapa, para agora se concentrar em copiar só os que sobraram (os corrompidos).

Não tenho nenhuma experiência com rsync. Apenas o citei porque sei que serve para backups. Por isso aceito sugestões de qualquer ferramenta que atenda meu desejo, tanto via terminal quanto gráficas ou com front end.

Penso que uma boa solução postada aqui, vai fazer diferença até nas pesquisas do Google, onde também não encontrei nada tão específico para o que desejo fazer.

Gratidão a todos!

Se você esta dizendo que o MSDOS tinha o copy que fazia isto, o wine tem o cmd.exe que tem o copy.

adm1@adm1-H310:~/.wine/drive_c/windows/system32$ wine ./cmd.exe 
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:xinput:pdo_pnp IRP_MN_QUERY_ID type 5, not implemented!
007c:fixme:xinput:pdo_pnp IRP_MN_QUERY_ID type 5, not implemented!
007c:fixme:xinput:pdo_pnp IRP_MN_QUERY_ID type 5, not implemented!
007c:fixme:xinput:pdo_pnp IRP_MN_QUERY_ID type 5, not implemented!
Microsoft Windows 2.0.0

C:\windows\system32>copy
Faltando argumento

C:\windows\system32>

Bem lembrado! Mas será que esse copy possui parâmetros para ignorar e saltar rapidamente, de forma automatizada, os arquivos que estão em setores ruins?
E eu teria que instalar o wine…

Uai, é o copy do wine né, deve ter as mesmas funções do copy da MS.

Citei o copy do MS-DOS como um recurso que eu usava antigamente, e como eu mencionei, a cada arquivo corrompido ele interrompia a cópia pra eu responder com (r), (i) ou (c).

Portanto, esse copy foge ao objetivo deste tópico…

Reeditando: foge ao meu objetivo com este tópico…

A demora no acesso é a nível de hardware e firmware do disco. Assim que a informação chega no sistema operacional, há o código de erro e a operação falha no caso comum.

O ddrescue tem uma opção que vc pode configurar de tentativas de releitura de um bloco defeituoso. Se vc setar para zero ele simplesmente vai pro próximo.

O detalhe é que o ddrescue vai criar uma imagem da partição antiga, então vc ainda vai precisar tentar corrigir ou então montar em loop para copiar os arquivos. Nessa segunda fase pelo menos não haverá erro de leitura, mas sim o conteúdo dos arquivos estará corrompido. Agora se o bloco corrompido for do sistema de arquivos, possivelmente pastas inteiras fiquem desaparecidas, ou tenha problemas para conseguir acessar os arquivos.

Bem, já imagino facilmente que vai faltar espaço pros seus arquivos, pois tendo sucesso nessa primeira fase da recuperação vc teria que indexar os arquivos para saber quais são iguais, e quais diferentes, sendo que arquivos que deveriam ser iguais podem estar diferentes por ter dados corrompidos.

O que cai na sua primeira opção, que seria tentar a leitura direto do hd defeituoso pulando os arquivos com problemas, o que ‘garantiria’ que os arquivos copiados não estão corrompidos.

Depois dessa volta, acho que a melhor opção seria a resposta dessa pergunta: macos - How to avoid copying corrupted files with rsync - Super User :
rsync -aP --partial-dir=/cygdrive/j/broken /cygdrive/g /cygdrive/j/gee

Isso vai separar os arquivos íntegros daqueles que foram copiados parcialmente (com erro de leitura).

Bem, não testei nenhum comando e só fiz a pesquisa na internet para chegar nessas respostas, espero que ajude.

–edit

Ah, outra dica é montar o hd defeituoso como somente-leitura, evitando assim qualquer nova operação de escrita no disco.

Certo, então quanto à falta de espaço, eu poderia deixar o terceiro HD de 596GB pra outra hora.

O ddrescue poderia copiar os dois HDs de 1 TB no novo SSD de 2 TB, cada um como um dir distinto no SSD? Por ex:

/dados_do_HD1
/dados_do_HD2

Ou o que o ddrescue faz é um clone de cada HD defeituoso? Nesse caso, faltaria espaço mesmo, a menos que eu tivesse duas unidades íntegras de 1 TB cada.

rsync -aP --partial-dir=/cygdrive/j/broken /cygdrive/g /cygdrive/j/gee

Confere se eu entendi:

O diretório “partial” será criado automaticamente pelo rsync no meu SSD de destino, e nele serão copiados apenas os arquivos corrompidos?

/cygdrive/j é meu SSD de destino?

/cygdrive/g é meu HD defeituoso?

No meu caso:

HD defeituoso: /media/mx/Samsung_1TB/ (/dev/sdc1)
SSD íntegro: /media/mx/Netac_2TB/ (/dev/sdd1)

Então a sintaxe seria essa abaixo?

rsync -aP --partial-dir=/media/mx/Netac_2TB/j/broken /media/mx/Samsung_1TB/g /media/mx/Netac_2TB/j/gee

Ou devo preencher com os pontos de montagem?

rsync -aP --partial-dir=/dev/sdd1/j/broken /dev/sdc1/g /dev/sdd1/j/gee

E o que “/gee” indica, no final do comando?

Tenho uma questão pertinente a backups. Às vezes uso o dd para criar imagem de alguma partição. Só que ele cria imagem da partição inteira.

Eu queria criar um “rescue” apenas do sistema de arquivos, incluindo os índices de todos os arquivos com seus respectivos inodes, para restaurar no caso de deletar acidentalmente alguma partição.

Tempos atrás, perdi praticamente todo o meu principal backup, o mais atualizado que eu tinha, ao comparar ele com outro backup mais antigo, usando o Free File Sync, e dando comando para deletar os arquivos iguais em apenas um dos lados, no caso o lado em que estava o backup mais atual. Por isso, tão cedo não quero mais ver essa ferramenta nem pintada de ouro…

Os diretórios é vc quem escolhe, tanto da origem quanto do destino. O cara colocou ‘j/gee’ talvez porque o nome dele era gee e o windows detectava o drive como ‘j’ (e ele estava rodando o rsync via cygwin).

Na verdade no partial vai ficar apenas arquivos que estavam sendo copiados quando apresentaram erro de leitura (cópia parcial). Pode ser que tenha arquivo que sequer consiga ser lido e nesse caso não vai ficar nem no destino e nem no parcial.

Explicando o comando rsync (alô chat gpt): Claro! Esse comando rsync é uma ferramenta poderosa para sincronização e cópia de arquivos em sistemas Unix-like. Vamos analisar os argumentos:

  • -a: Este é o argumento para o modo “arquivo”, que é usado para fazer uma sincronização recursiva, preservando todas as permissões, timestamps e outros atributos dos arquivos.
  • -P: Este argumento é uma combinação de --partial e --progress. --partial permite que o rsync continue a transferência de arquivos parcialmente baixados caso a conexão seja interrompida, enquanto --progress mostra o progresso da transferência.
  • --partial-dir=/cygdrive/j/broken: Este argumento especifica um diretório onde os arquivos incompletos são armazenados temporariamente durante a transferência. Isso pode ser útil para identificar e lidar com arquivos parcialmente transferidos em caso de interrupção da conexão ou outros problemas durante a transferência.
  • /cygdrive/g: Este é o diretório de origem de onde os arquivos serão copiados.
  • /cygdrive/j/gee: Este é o diretório de destino para onde os arquivos serão copiados.

Resumindo, o comando rsync está copiando recursivamente todos os arquivos e diretórios do diretório /cygdrive/g para o diretório /cygdrive/j/gee, exibindo o progresso da transferência e mantendo os arquivos parcialmente transferidos em /cygdrive/j/broken em caso de interrupção da conexão.

Uai, é o backup tradicional que pode ser feito com o clonezilla, linha de comando com o tar ou milhares de programas de backup. Eles copiam apenas os dados dos arquivos. O dd seria um desperdício pois ele lê todos os blocos do sistema de arquivo, sejam eles ocupados ou não. Outra coisa que não dá pra fazer backup incremental. Vale lembrar que milhares dos programas de backup usam o rsync por baixo dos panos (ou da interface bonitinha).

Eu queria um backup apenas dos índices de alocação dos arquivos, das listas de diretórios com os inodes de todos os arquivos.
Seria como copiar apenas a trilha zero (MBR), a FAT ou MFT caso fosse uma formatação típica do Windows.
Mas quero fazer isso com unidades GPT/NTFS, MS-DOS/NTFS e também com partições EXT4 e BTRFS em unidades GPT.

Você vai precisar recorrer a ferramentas específicas para cada sistema de arquivos, e nem todas estas ferramentas vão conseguir reusar o resultado para algo produtivo se algo der errado na partição original.

Apenas dando minha opinião, tem certeza que não seria melhor começar a pensar em um esquema de backup normal com alguma camada em RAID1? Você vê algum problema no backup tradicional?

Já fiz RAID usando o software mdadm mas o BTRFS já tem suporte a RAID, se usar o mdadm será mais um software onerando recurso sendo que seria só usar um filesystem que já tem esse recurso.

Lembrando que RAID via software é menos seguro que um RAID via hardware, e RAID por filesystem é RAID via software assim como o mdadm. Sim, filesystem é software é uma coisa lógica, filesystem não existe de verdade.

A sim, se você decidir usar um ext2 o jeito é usar o mdadm, mas se você for usar um filesystem que tem suporte a RAID usar o mdadm é desperdício de recurso.

Se bem que as únicas pessoas que se preocupam em otimizar o sistema são pessoas técnicas que já devem saber disso. De menos os que estão estudando para serem ou não técnicas.

Sim, sim, não estou dizendo para ele procurar a solução RAID mais complicada que ele encontrar. Imaginei que estava subentendido, já que a minha indagação era mesmo qual poderia ser o problema em fazer algo mais simples que funciona bem tem mais suporte, e trabalho de muitas pessoas já ao redor, para tornar simples e confiável.

É simples fazer um RAID por software, tem um monte de tutorial na internet. Se a pessoa souber mexer com software de particionamento ela já consegue fazer um RAID por software, e se for por filesystem é mais simples ainda.

Oops… lapso de minha parte!
Faltou eu deixar claro que minha intenção é ter uma cópia da MFT e das árvores de diretórios e filenames, das minhas unidades de backup GPT/NTFS (ou EXT4 se for mais seguro), e não das fontes a serem becapeadas.
Ou seja, ter uma salvaguarda extra pros meus backups, em caso de corrompimento nas MFT’s (ou de seus similares se eu montar backups em EXT4, BTRFS ou outro formato que vcs considerem mais seguro).

Bem, amigos, o RAID que eu conheço consiste na “fusão” de no mínimo dois HDD’s físicos, ou pra dobrar a velocidade, ou pra espelhar dados… como seria o RAID via software, quando se trata de copiar dados de um backup dando alertas no SMART, para uma nova unidade íntegra?

Se bem que eu acharia interessante o sistema tratar minhas duas novas unidades SSD externas, como se fossem um RAID1. Assim eu poderia realizar backups dos meus arquivos em ambas ao mesmo tempo, já que minha intenção é que, de fato, uma unidade seja espelho da outra.

Eu optei pelo NTFS para poder acessar meus backups também em PC’s de terceiros, cuja maioria ainda é acomodada ao sistema da Redmond.

Entendo, um RAID 1 (espelhamento) seria mais efetivo e simples, especialmente com sistemas de arquivo como BTRFS, você consegue benefícios relevantes, sem fazer muito esforço.

A forma mais simples é comprar um Synology e ligar e usar, mas montar um RAID 1 entre 2 ou 3 HDDs no BTRFS não é muito complicado.

Fazer backup de partes específicas dos metadados é uma coisa meio que muito específica e acho que pouco efetiva em proteger o que importa, os dados.

Quem estava falando do RAID foi o @romulopb eu só acrescentei informação que nem sei se é útil. Eu imagino que ele estava sugerindo fazer RAID 1, espelhamento mesmo.
Eu pesquisei na wiki MFT e entende que MFT é para transferência de dados assim como FTP.
Eu não sei o que seria backup disso, será que é backup realizado via MFT? é isso?
O NTFS e o EXT4 não tem muita diferença em recurso de segurança de dados, mas o BTRFS esse sim espanca o EXT4.
Mas o suporte ao NTFS no Linux é meio capenga. Tem suporte parcial ao Journaling.

O DD consegue copiar os primeiros bytes do armazenamento se for copiar a GPT e os primeiros bytes do filesystem você pode copiar tudo emendado, mas teria que passar o local de inicio(não é difícil, é só começar do primeiro byte) e o local de fim da partição e seu filesystem, não sei como fazer isso. Não sei se na restauração vai corromper também, mas que copia isso é verdade.

Eu perdi um backup inteiro ao usar o Free File Sync pra comparar esse backup com o de outra que eu tinha, para em seguida deletar todos os arquivos idênticos, para sobrar espaço. E aí deu pau, não sei se por culpa do Free File ou do próprio HD externo.
O fato é que zerei meu HD! Perdi praticamente o backup inteiro.

Eu tinha uma cópia da trilha zero / MBR feita pelo gparted, que de nada me serviu nesse caso.

Por isso que eu pergunto, se tivesse uma cópia de todos os inodes, dirs e filenames, quem sabe traria tudo de volta.

Quando fiz um deep scan nessa unidade pelo testdisk, não encontrou nada.

Quando usei uma ferramenta de recuperação de dados (não me lembro qual), após uma longa varredura em raw (1 TB), ele encontrou milhares de arquivos e gerou uma lista infindável de nomes genéricos do tipo “file0001.chk” (não lembro ao certo como foram enumeradas), assim como “dir0001”, “dir0002” e assim por diante.
E pra recuperar, tinha que comprar o software que era pra Windows.

O MFT ao qual me refiro, é a Master File Table de partições NTFS, que cumpre o mesmo papel da FAT em unidades formatadas em FAT ou FAT32. São os índices de tudo o que as unidades contém, como o CEP dos Correios que localiza qualquer localidade.

Em HD’s formatados em EXT4 ou BTRFS também deve ter algo similar na trilha zero , mas não sei o nome.