Resposta curta: porque não é seu propósito. O Ddrescue faz uma coisa (copiar 1: 1 um disco rígido com defeito) e faz isso bem.
Parece que o ddrescue tenta recuperar todos os blocos em um disco ou partição, mesmo aqueles que não contêm arquivos. Não seria possível descobrir quais blocos realmente armazenam arquivos observando o sistema de arquivos, por exemplo, tabela de arquivos mestre em NTFS?
Editar : parece que pode ser possível em combinação com partclone:
For rescue situation, the rescue mode of Partclone would try to skip bad blocks and backup all good blocks for the partitions. The ddrescue program is another better solution to save bad disk while with partclone's help by listing all used blocks as domain file, it could make ddrescue smarter and faster when dumping a partition.
Veja também: link
Eu não acredito que isso seja possível, já que o ddrescue, como o próprio dd, serve para operar em qualquer dispositivo de bloco, mesmo aqueles sem sistema de arquivos ou danificado. Observar o sistema de arquivos, se existir, apenas o complicaria.
Tópico antigo, mas pode ser útil para os outros ...
Se a entrada for um volume formatado em NTFS, você pode usar o ddru_ntfsbitmap da ddrutility, para gerar um arquivo de mapeamento para ddrescue usando o arquivo de sistema $ Bitmap, que é precisamente um mapa dos clusters usados / não usados em uma partição NTFS. É claro que requer 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 esse for o caso, ele prossegue rapidamente (na minha primeira e até agora única experiência, demorou cerca de 2 minutos para gerar o arquivo de mapeamento 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]
Em versões recentes do ddrescue, o termo “logfile”, como no arquivo onde as áreas recuperadas / não experimentadas / 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ê quiser 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
A razão principal é provavelmente que tornaria o código de ddrescue significativamente mais complexo, pois precisaria incorporar informações em vários sistemas de arquivos e analisar suas estruturas internas.
No entanto, mesmo ignorando o esforço de desenvolvimento adicional, tentar descobrir quais blocos têm dados em geral são difíceis. 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 está presente em blocos livres (porque o sistema de arquivos não foi substituído).
Nesse caso, a única opção segura é pegar tudo e resolver os detalhes mais tarde.
Hoje em dia é possível, como o segmento mencionado na pergunta foi implementado. Você pode usar o utilitário Parclone para criar um arquivo que informa quais partes devem ser verificadas.
Aqui está um exemplo de como usá-lo a partir do tópico mencionado:
# produce a domain file for NTFS partition on /dev/sda1
partclone.ntfs -s /dev/sda1 -D -o sda1.domain
# copy /dev/sda1 to /dev/sdb1 using ddrescue with domain log file
ddrescue --domain-log sda1.domain /dev/sda1 /dev/sdb1 rescue.log
Tags ntfs data-recovery linux ddrescue