O tamanho do Time Machine explode quando copiado para a nova unidade

Question

Estou tentando substituir uma unidade USB2 de 640 GB que uso como dispositivo de backup do Time Machine com uma unidade FireWire 400 de 1 TB sem perder o histórico de backup atual. Como a unidade de 640 GB está quase cheia e o limite de transferência de 400 Mbps dessa combinação, percebi que esse processo poderia levar algum tempo e ser interrompido no meio. Como resultado, decidi tentar fazer isso com rsync em vez do Finder (como a Apple sugere ). Depois de alguns falsos começos e algumas pesquisas online, decidi o seguinte comando rsync :

rsync -aHXSvPh --hfs-compression --protect-decmpfs /Volumes/Macintosh\ BK/Backups.backupdb /Volumes/Untitled

No entanto, esse comando ainda está causando um inchaço significativo na unidade de destino (a ponto de eu não esperar que o conteúdo da unidade antiga se encaixe na nova, apesar de a nova unidade ser cerca de 1,5 vezes maior). Existe alguma rsync opções que eu estou ausente, o que eliminaria este inchaço (estou usando a versão 31 do protocolo v3.1.2)?

Também me ocorreu que talvez eu esteja usando a ferramenta errada para o trabalho. Uma ferramenta de cópia de bloco como dd seria mais apropriada? Em caso afirmativo, como configuraria isso para tornar o processo recuperável no caso de uma interrupção (como uma causada por uma falha total do sistema, algo que aconteceu comigo duas vezes durante a execução do comando rsync )? Eu nunca usei dd antes e, portanto, não estou familiarizado com suas habilidades (mas tenho acesso a ambas as versões que vem com o Mac OSX e o GNU versão 8.25).

    

Answer 1

dd não ajusta as várias estruturas de dados de volume com base no tamanho do volume de destino, portanto, é apropriado apenas se os volumes de origem e de destino forem exatamente do mesmo tamanho. Geralmente, eu recomendo asr , mas não é uma boa maneira de continuar após uma falha.

Assim, uma possibilidade seria reduzir o volume de destino para corresponder à origem, usar dd para copiar o volume bruto e, em seguida, expandir o destino de volta para o total de 1TB. Eu não testei isso, mas acho que esse é o processo que você precisa:

1. diskutil list listará os identificadores de dispositivo do volume (por exemplo, disk2s3 é a terceira fatia (partição) do disco físico nº2)
2. diskutil info <sourcevolumeid> listará o tamanho do volume de origem em bytes (junto com muitas outras informações)
3. diskutil resizeVolume <targetvolumeid> <sourcevolumesize>B (o "B" significa "bytes" - consulte a seção "SIZES" da página diskutil man).
4. diskutil unmount <sourcevolumeid> e diskutil unmount <targetvolumeid> - não use dd em volumes montados!
5. sudo dd if=/dev/r<sourcevolumeid> of=/dev/r<targetvolumeid> para fazer a cópia. Observe o prefixo "r" nos nomes dos dispositivos - isso ignora os buffers de disco do SO e, na minha experiência, o dd é executado muito mais rápido. Tenha muito cuidado para obter os IDs de volume corretamente ou copie um volume em branco sobre o backup!
6. Finalmente, use diskutil resizeVolume ou o Utilitário de Disco para expandir o volume de destino para o tamanho total do disco.

Ah, e um aviso: esse processo não pressupõe que a origem ou o destino estejam sendo gerenciados pelo Core Storage. Se eles estiverem (por exemplo, se estiverem criptografados), as coisas ficarão um pouco mais complicadas.

    

Answer 2

A resposta curta é que o Time Machine faz uso pesado de hardlinks, que é onde um arquivo subjacente - um fluxo de bytes - aparece como vários nomes de arquivos em vários diretórios no sistema de arquivos. Se você fizer uma cópia que não seja especializada em hardlinks, esse arquivo subjacente será copiado várias vezes (uma vez para cada link com hardlink).

Então, digamos que você tenha um arquivo de imagem de disco de 1GB, que está lá desde o começo, então ele aparece como um link físico em todos os backups periódicos do Time Machine, e você tem 100 backups do Time Machine. Se você copiar isso sem ser inteligente sobre hardlinks, você vai acabar com 100 cópias desse arquivo de 1GB, para um total de 100GB, em vez de apenas 1GB com 100 hardlinks apontando para ele.

Tenho certeza de que a Apple sabe que o conselho de cópia do Finder preserva os hardlinks adequadamente. Eu esperaria que a funcionalidade "Restore" do Disk Utility também funcionasse. Não deixe o nome "Restore" enganar você, não é apenas para restaurar a partir de backups; é a maneira do Disk Utility fazer uma cópia em bloco de um volume (ou imagem de disco) para outro.

Atualizado para adicionar:
Hmm, rsync -H deveria ter preservado hardlinks. Tem certeza de que seu volume de destino é HFS + ou outro sistema de arquivos em que o OS X confia com hardlinks?