Parece que o ddrescue tenta recuperar todos os blocos de um disco ou partição, mesmo aqueles que não contêm arquivos. Não seria possível descobrir quais blocos realmente contêm arquivos observando o sistema de arquivos, por exemplo, tabela mestre de arquivos em NTFS?
Editar: Parece que pode ser possível em combinação com partclone:
http://partclone.org/features/
Para situações de resgate, o modo de resgate do Partclone tentaria pular blocos defeituosos e fazer backup de todos os blocos bons para as partições. O programa ddrescue é outra solução melhor para salvar discos defeituosos, enquanto com a ajuda do partclone, listando todos os blocos usados como arquivo de domínio, pode tornar o ddrescue mais inteligente e rápido ao despejar uma partição.
Veja também: http://sourceforge.net/p/partclone/mailman/partclone-user/thread/[e-mail protegido]/
Responder1
Resposta curta: porque não é esse o seu propósito. Ddrescue faz uma coisa (copiar 1:1 um HDD com falha) e faz bem.
Responder2
Não acredito que isso seja possível, pois o ddrescue, assim como o próprio dd, foi projetado para operar em qualquer dispositivo de bloco, mesmo aqueles sem sistema de arquivos ou danificados. Observar o sistema de arquivos, se ele existir, apenas o complicaria.
Responder3
Tópico antigo, mas pode ser útil para outras pessoas...
Se a entrada for um volume formatado em NTFS, você pode usar ddru_ntfsbitmap do ddrutility, para gerar um mapfile para ddrescue usando o arquivo de sistema $Bitmap, que é precisamente um mapa dos clusters usados/não utilizados em uma partição NTFS. É claro que é necessário que o arquivo $Bitmap esteja intacto, localizado em uma área totalmente legível, para funcionar corretamente (geralmente está localizado no início da partição). Se for esse o caso, ele prossegue rapidamente (na minha primeira e até agora única experiência, demorou cerca de 2 minutos para gerar o mapfile a partir de uma partição de 1 TB). Então você executa o ddrescue com este comando básico:
ddrescue [options] [input path] [output path] [logfile] -m [mapfile]
Nas versões recentes do ddrescue, o termo “logfile”, como o arquivo onde as áreas resgatadas/não testadas/ruins do volume de entrada são salvas durante a recuperação, foi substituído por “mapfile”, o que torna isso bastante confuso . Então, se por exemplo você deseja recuperar um HDD chamado /dev/sdc para uma imagem em /media/sdd1 chamada Recovery, usando um mapfile gerado por ddru_ntfsbitmap chamado Recovery_bitmap.log, o comando deve ser:
ddrescue [options] /dev/sdc /dev/sdd1/Recovery /dev/sdd1/Recovery.log -m /dev/sdd1/Recovery_bitmap.log
Responder4
A principal razão é provavelmente que isso tornaria ddrescueo código do 's significativamente mais complexo, pois precisaria incorporar informações sobre vários sistemas de arquivos e analisar suas estruturas internas.
No entanto, mesmo ignorando o esforço adicional de desenvolvimento, tentar descobrir quais blocos possuem dados é geralmente difícil. ddrescueé normalmente usado em situações em que os dados já estão danificados e possivelmente inconsistentes. Tentar encontrar blocos usados é arriscado nessa situação - e se a própria lista de blocos livres estiver corrompida (mas ainda legível)? Ou talvez a versão atual de um arquivo não seja mais recuperável, mas uma versão antiga do arquivo ainda esteja presente em blocos livres (porque o sistema de arquivos não foi substituído no local).
Nesse caso, a única opção segura é pegar tudo e resolver os detalhes depois.