Você pode usar a configuração de cmd_postexec para executar um script personalizado após a conclusão do rsnapshot. Este script pode fazer o que você quiser.
No entanto, tarring os arquivos após o fato irá, aumentar o uso do disco. Provavelmente por muito. Por padrão, o rsnapshot passa opções para o rsync, de modo que o rsync hardlinks quaisquer arquivos inalterados para a revisão anterior do mesmo arquivo.
-
O
- tar adiciona alguns metadados, que normalmente existem separadamente (por exemplo, caminho / nome do arquivo, permissões, etc.), levando a um aumento marginal no uso do espaço em disco comparado a apenas manter os arquivos brutos. O
- tar por si só não faz nenhuma compactação (embora você possa executar o arquivo .tar resultante através de um compressor como gzip, bzip2, xz, etc.).
- Ao tarring a árvore após o término do rsync, você perde a capacidade de estabelecer hardlink entre as revisões, portanto cada arquivo tar da árvore de backup deve conter o conteúdo completo, em vez de apenas a diferença em comparação com a revisão anterior.
A única maneira em torno do terceiro ponto acima que eu posso ver seria tar toda a estrutura do diretório de destino (aquela nomeada por snapshot_root na configuração do rsnapshot), mas você precisaria descompactar antes que o rsnapshot comece a executar o rsync ( isso pode ser feito através de um script executado por meio de cmd_preexec , se você realmente quiser fazer isso, e depois refazê-lo posteriormente. Isso irá aproximadamente dobrar o pico de uso do espaço em disco, bem como aumentar significativamente o tempo necessário para executar uma execução do rsnapshot, por nenhum benefício real.
Use o rsnapshot da maneira pretendida. É mais fácil, e não vejo nenhuma desvantagem que seria resolvida religiosamente executando tar nos backups.
Se você tiver um problema específico com como o rsnapshot mantém as cópias, concentre-se nele, e não no tar (que pode ou não ser uma solução para qualquer problema que você esteja tendo). / p>