Introdução
Neste artigo, apresentaremos um método para sincronizar uma pasta de origem com uma pasta de destino no Linux, no modo espelho, onde os arquivos excluídos da origem também são excluídos da pasta de destino. A pasta de destino será automaticamente versionada após a sincronização, se possível em modo de blocos, em vez de ser versionada em intervalos fixos por meio de um cron job, para evitar versionamentos desnecessários.
Configuração do servidor de backup
O servidor de backup deve ter o daemon rsync em execução continuamente. Esse daemon utiliza os seguintes arquivos de configuração: /etc/rsyncd.conf e /etc/rsyncd.secrets. Vamos nos concentrar nos recursos do rsync, também conhecidos como módulos rsync.
Aqui está um exemplo de configuração no arquivo rsyncd.conf:
[data]
path=/data/org/
[dir-1]
path=/data/org/dir-1/
[dir-2]
path=/data/org/post-xfer
exec=/usr/local/bin/snapshot-dir-2
[dir-3]
path=/data/org/post-xfer
exec=/usr/local/bin/snapshot-dir-3Nesse exemplo, o módulo data aponta para a pasta org em um disco de backup formatado em Btrfs e montado em /data. A pasta /data/org corresponde à pasta /data/snapshot onde os dados são versionados.
Os módulos dir-1, dir-2 e dir-3 apontam para a mesma pasta org, pois desejamos mesclar o conteúdo dessas pastas no servidor de backup. No entanto, esses módulos executam scripts de snapshot diferentes, cada um responsável por versionar as pastas apropriadas.
Os módulos rsync são essenciais para associar um script pós-transferência a um diretório. É importante observar que o ponto é proibido no nome do script, caso contrário, ele não será executado.
Para fazer backup pela internet, é necessário garantir a segurança das comunicações por meio de um túnel SSH, mantendo os módulos rsync. No lado do cliente, a autenticação SSH será solicitada imediatamente antes da senha do módulo rsync.
Configuração do cliente de cópia
Aqui está um exemplo de script de backup usando o rsync. Nada de especial. Aqui, usamos a opção --delete porque o sistema de arquivos de destino é versionado por meio de snapshots, o que significa que sempre podemos voltar atrás em caso de exclusão ou modificação acidental dos dados.
RSYNC_PASSWORD="senha" /usr/bin/rsync -rtvyy --delete --partial --progress --inplace /dir-1/htpc::dir-1/
RSYNC_PASSWORD="senha" /usr/bin/rsync -rtvyy --delete --partial --progress --inplace /dir-2/* htpc::dir-2/
RSYNC_PASSWORD="senha" /usr/bin/rsync -rtvyy --delete --partial --progress --inplace /dir-3/* htpc::dir-3/Sempre que um módulo rsync é usado, o script pós-transferência é executado no servidor. Monitorando o arquivo de log, você deve encontrar algo como:
Jan 16 19:13:33 ordinateur snapshot-dir-2: start snapshot subdir1
Jan 16 19:13:33 ordinateur snapshot-dir-2: stop snapshot subdir1
Jan 16 19:13:37 ordinateur snapshot-dir-3: start snapshot subdir2
Jan 16 19:13:37 ordinateur snapshot-dir-3: stop snapshot subdir2Limitações do método proposto
O método proposto tem uma limitação: a cópia de arquivos entre o cliente e o servidor de backup não pode ser feita usando a técnica de cópia em gravação (CoW). Portanto, o versionamento padrão é feito em nível de arquivo, em vez de em nível de bloco. Isso ocorre porque, assim que o rsync detecta uma modificação em um arquivo, ele começa criando um novo arquivo temporário com um novo inode para preenchê-lo. Nesse ponto, reproduzimos o comportamento do rsnapshot sem ultrapassá-lo.
Uma otimização importante é o uso da opção --inplace do rsync, que preserva o inode do arquivo de destino, permitindo que o sistema de arquivos CoW entenda que o arquivo de destino e sua cópia versionada têm apenas alguns blocos de diferença, em vez do arquivo inteiro. Essa opção é lógica quando se conhece o funcionamento do rsync e é confirmada por outras fontes.
Para melhorar ainda mais, é necessário usar a cópia em gravação entre a origem e o destino, o que implica que o versionamento deve ser feito no mesmo sistema de arquivos dos dados originais. Nesse caso, não é necessário usar o rsync, apenas um snapshot do subvolume Btrfs ou um simples cp --reflink. Atualmente, apenas o Btrfs suporta os reflinks.
Ao fazer backup remoto com o rsync, surge a pergunta: devemos fazer o versionamento ou não? Se optarmos pelo versionamento em nível de arquivo, haverá um consumo adicional de espaço. Para pastas com arquivos pequenos, como /etc, /usr ou /var/www, o consumo adicional será tolerável. No entanto, para arquivos grandes, como imagens de disco, o versionamento em nível de arquivo consumirá espaço igual ao tamanho do arquivo.
Por que isso é útil?
O snapshot Btrfs oferece muitas possibilidades para manter versões anteriores de diretórios completos e, assim, retroceder no tempo para encontrar um arquivo como ele era antes de sua última modificação ou exclusão acidental.
Imagine um cenário em que seu computador é infectado por um ransomware que criptografa todos os seus arquivos (no disco do sistema e em todas as redes compartilhadas) e exige um resgate para descriptografá-los. Se você tiver feito snapshots dos seus dados anteriormente, o ransomware não poderá mais chantageá-lo, pois a restauração dos dados será simples. Assim, percebemos que o snapshot, que não é um backup, também pode trazer benefícios em termos de segurança, permitindo voltar no tempo.
Esse método tem suas limitações, mas é uma solução eficaz para sincronizar pastas e manter versões anteriores de arquivos importantes. O uso do Btrfs e do rsync em conjunto permite uma estratégia de backup robusta e confiável.
Esperamos que este artigo tenha sido útil para entender como versionar automaticamente uma pasta de destino no Linux usando um snapshot Btrfs após sincronizá-la com o rsync.