Eu tenho dois diretórios de backup que residem no mesmo sistema de arquivos no meu servidor de backup. O primeiro é chamado de "clone" - contém um clone do meu laptop que é atualizado remotamente todas as noites via rsync. O segundo é chamado de "backup", que é um instantâneo semanal do rsync apenas das partes importantes do clone. Para economizar espaço, "backup" é criado como links físicos para clonar em vez de cópias, usando --link-dest:
rsync -avum --link-dest=/clone /clone/ /backup
Agora quero também usar a opção --backup para copiar as versões antigas dos arquivos alterados do backup para uma área de retenção, caso eu precise deles ou exclua acidentalmente algo importante. Isso funciona bem sem --link-dest:
rsync -avumb --backup-dir=/holding/2016_10_22 /clone/ /backup
No entanto, isso cria cópias dos arquivos alterados no backup, desperdiçando espaço - quero links físicos. Mas se eu adicionar o parm --link-dest novamente:
rsync -avumb --backup-dir=/holding/2016_10_22 --link-dest=/clone /clone/ /backup
...então somenteexcluídoos arquivos são copiados. Os arquivos alterados são vinculados silenciosamente. A razão (acredito) é que --link-dest compartilha a lógica de --copy-dest. Ou seja, se o arquivo de origem não for alterado em relação ao arquivo copy-dest (ou link-dest), então ele não será transferido, mas sim copiado/vinculado do diretório copy/link-dest para o diretório de destino. Como estou usando o diretório de origem como diretório de destino do link, todos os arquivos não excluídos são "inalterados" e tratados silenciosamente.
Eu poderia fazer isso em duas etapas: primeiro --backup sem --link-dest, depois novamente --link-dest sem --backup. (As versões mais recentes do rsync substituirão arquivos idênticos por links físicos.) Mas eu realmente prefiro fazer tudo de uma vez.
Existe uma maneira de fazer --backup criando apenas links físicos? (Realmente o que eu quero é rsync "normal" com hard linking em vez de transferência de arquivos. Meu uso de --link-dest parece um hack, dada a lógica pretendida dessa opção.)
Pergunta bônus: a página de manual parece indicar que é preferível usar --link-dest apenas em destinos vazios:
Esta opção funciona melhor ao copiar para uma hierarquia de destino vazia, pois os arquivos existentes podem ter seus atributos ajustados e isso pode afetar arquivos de destino alternativos por meio de links físicos. Além disso, a especificação das alterações pode ficar um pouco confusa.
A parte sobre a listagem de itens ficar "confusa" é um pouco vaga. Usar --link-dest em um destino não vazio é realmente "perigoso", supondo que não me importo muito com os atributos do arquivo? Alguém pode dar um exemplo?
Responder1
Conforme mencionado acima, acabei executando o processo em duas etapas.
src = the "live" clone directory, a mirror of my laptop = primary backup
dst = the weekly snapshot of important parts clone
trashdir = the items from src that don't exist in dst, because they have since been deleted, sorted into date-stamped directories
cmd = ("rsync -avumb --stats --delete --delete-excluded --filter='merge %s' --backup-dir=%s %s %s" %
(filterfile, trashdir, src, dst))
cmd = ("rsync -avum --stats --delete --delete-excluded --filter='merge %s' --link-dest=%s %s %s" %
(filterfile, src, src, dst))
A primeira etapa faz um backup das partes importantes do clone e salva os arquivos que foram excluídos desde o último backup no lixo. (Existem motivos pelos quais desejo esse backup intermediário apenas dos arquivos selecionados e quero atualizá-lo apenas semanalmente.)
A segunda etapa converte os arquivos de backup em links físicos apontando para o clone. O resultado é que o backup ocupa zero espaço real. trashdir, por definição, não é um arquivo com link físico, porque consiste apenas em arquivos que foram excluídos do clone e do backup.
Não tenho certeza se os sinalizadores --delete-excluded são necessários (principalmente no segundo comando). Deixei-os lá, caso eu altere o filterfile, que define quais partes do clone devem ser ignoradas na criação do backup.
Descobri que em cinco anos, o trashdir cresceu aproximadamente para o tamanho de um clone, então tamanho total = clone x2, o que é aceitável para mim, visto que tenho seis anos de histórico de arquivos excluídos e posso facilmente removê-los por data.
Além do acima, eu tenho um script que é executado cp -alpara copiar o clone em cerca de um mês de instantâneos rotativos com carimbo de data e com link rígido. Isso me cobre arquivos que foram alterados, em vez de excluídos. O tamanho total de um mês parece ser cerca de metade do tamanho do clone.
Portanto, o espaço total em disco é de aproximadamente 2,5 do clone e eu tenho:
- o próprio clone, atualizado todas as noites
- um backup de arquivos selecionados que é estável por uma semana
- um mês de snapshots clones versionados
- seis anos de arquivos excluídos
O que considero uma proteção muito boa contra perda do disco original, substituição de um arquivo e necessidade de uma versão mais antiga e exclusão de um arquivo e necessidade dele mais tarde.
É um pouco complicado e provavelmente poderia ter sido alcançado com software de terceiros, mas funciona para mim e é baseado em ferramentas de baixo nível que provavelmente não desaparecerão ou alterarão significativamente a funcionalidade.
(@gsl - Na verdade, obrigado por solicitar a atualização. Descobri que um dos meus scripts quebrou quando atualizei para python3 e não estava funcionando há alguns meses. Preciso prestar mais atenção aos meus logs de erros!)
Definitivamente, ainda estou interessado em maneiras de agilizar isso - então sinta-se à vontade para comentar se as coisas que estou fazendo podem ser realizadas de alguma maneira mais fácil.