Instalação do rsnapshot

Instalar o rsnapshot no Debian e no Ubuntu é moleza, pois o pacote está no repositório principal (e isso já ocorre há várias versões):

Se você vai manter os backups no mesmo computador (de um disco para o outro, por exemplo), só vai precisar disso. Para instalação em uma LAN, no entanto, você provavelmente vai precisar de um “servidor de backup”, no qual o disco de backup esteja
montado, e de vários “clientes de backup”, de cujos dados você vá fazer o backup para o servidor.

Para isso você vai ter que configurar o acesso via login remoto para o usuário do backup. Neste artigo, vamos configurar o root como usuário de backup. Embora isso possa ser um risco de segurança em uma rede comercial vulnerável, está de bom tamanho
para uma LAN doméstica ou uma rede de pequena empresa, em que você possa confiar nas pessoas com acesso físico ao computador. Outra vantagem é poder manter as identidades e permissões de usuário corretas nos arquivos do backup.

Acesso SSH sem senha

A pior parte da instalação provavelmente será a configuração dos logins via SSH sem senha aos seus sistemas. Essa é uma falha de segurança em potencial em redes locais abertas, embora para a maioria das redes domésticas isso não seja um problema. Seja
como for, é preciso fazer as coisas direito para que o rsnapshot funcione.

Vamos configurar o acesso SSH sem senha para ida e volta para os usuários root das máquinas cliente e servidor. Em algumas configurações isso não é estritamente necessário, mas é muito útil em máquinas que volta e meia são desconectadas, como vamos ver
em breve.

Configuração do cliente para acesso SSH

Em primeiro lugar, use os nomes reais de seus hosts. Nos meus exemplos, vou usar myclient como nome do computador cliente e myserver no servidor de backup. Em cada computador cliente e no servidor, você vai precisar gerar um par de chaves
públicas/privadas, usando o OpenSSH:

Não digite passphrase nenhuma! Para acesso sem senhas, você precisa de um passphrase vazia.

A elipse (…) omite uma representação da chave fornecida como confirmação.

Se você olhar em seu diretório .ssh, vai ver duas chaves novas:

Use o scp (a cópia segura do OpenSSH) para transferir o arquivo myclient.pub para o servidor de backup (e copie também o arquivo myserver.pub do servidor para a máquina cliente). De posse de todas as chaves necessárias, crie (ou edite) um arquivo
chamado /root/.ssh/authorized_keys2 para que as máquinas possam ser acessadas:

Obviamente, você vai ter que fazer a mesma coisa em todos os clientes para configurar o acesso de ida e volta:

Configuração do rsnapshot no servidor

Como você já deve estar imaginando, o arquivo de configuração do rsnapshot é o /etc/rsnapshot.conf. Vamos configurar esse arquivo para cuidar de backups locais de sistemas de arquivos montados no servidor, e também em um cliente que tenhamos certeza de
estar sempre conectado (você pode, por exemplo, usar um servidor de arquivos separado, que eu chamei de myfileserver aqui). Essa configuração também é apropriada para uso em um único computador.

Há muitos comentários no /etc/rsnapshot.conf que acompanha a instalação padrão do Debian, mas vou omiti-los por aqui.

Primeiro, vamos ver o resultado final da minha configuração de exemplo:

Agora vamos explicar isso tudo. A primeira linha (config_version) é uma formalidade, só para dizer ao rsnapshot qual formato ele deve esperar deste arquivo (deixe-a exatamente como eu deixei). Na linha seguinte, snapshot_root diz onde o volume de
backup está montado no servidor. Eu tenho um disco rígido grande montado como /backup, mas uso partes dele para outros tipos de backup, por isso deixo o rsnapshot usar o diretório /backup/auto dele.

As linhas seguintes (cmd_*) também são basicamente uma formalidade. Elas dizem ao rsnapshot que tipos de utilitários ele tem à disposição para fazer seu trabalho (sem eles, o rsnapshot pode usar métodos internos, mas qualquer sistema GNU/Linux inclui
todos esses utilitários).

As linhas que vêm depois (interval) são bem mais interessantes:

É aqui que eu decido o tipo de agendamento do backup. Há muitas configurações possíveis, mas no meu caso eu optei por manter backups diários por um mês, backups semanais por um ano e backups mensais “indefinidamente” – eu usei dez anos, tempo de sobra
para fazer cópias permanentes de qualquer coisa que eu vá precisar por mais tempo do que isso!

Aliás, os nomes “daily” (diário), “weekly” (semanal) e “monthly” (mensal) usados aqui não têm significado algum para o rsnapshot, você pode usar qualquer nome para os intervalos. Você mesmo vai dar o significado aos nomes ao configurar os trabalhos do
cron (ou do anacron) que vão chamar o rsnapshot. Você pode perfeitamente usar nomes como “a_cada_duas_semanas” ou “de_dez_em_dez_dias”.

Por outro lado, é essencial que os intervalos sejam listados em ordem, dos mais frequentes para os menos frequentes. O rsnapshot realiza os backups de intervalo maior simplesmente rotacionando um backup de intervalo menor que seja apropriado (por
exemplo, o último backup diário vai se tornar o primeiro backup semanal quando chegar a hora, e o último backup semanal vai se tornar o primeiro mensal). Isso pode parecer meio confuso a princípio, mas funciona direitinho.

Ainda vamos ter que cuidar de mais alguns pequenos detalhes: o que deve entrar nos arquivos de log (verbose, loglevel), onde esses logs devem ficar (logfile) e onde manter um arquivo de bloqueio para evitar colisões caso eu (acidentalmente) tente rodar
duas instâncias do programa ao mesmo tempo (lockfile).

A próxima linha (one_fs) impede que os backups sigam links simbólicos para outras unidades. Isso pode ser um problema se você usar muitos links simbólicos para facilitar a navegação pela linha de comando no sistema, do contrário não deve causar maiores
inconvenientes.

Já a linha sync_first orienta o rsnapshot a operar um pouco diferente de seu comportamento normal. Em vez de fazer todos os backup e rotacioná-los em uma mesma operação, ele realiza duas operações: a primeira sincroniza a cópia de backup, e a segunda
rotaciona o backup diário. Isso é extremamente útil para fazer backup de computadores que nem sempre estejam conectados à rede, como veremos mais para a frente.

Por fim, as linhas backup indicam de quais dados fazer backup:

Nesse caso, estou fazendo backups do meu diretório /home (dados de usuário) e do diretório /etc (dados de configuração) no meu servidor de backup (que neste exemplo também é uma estação de trabalho). Esses são backups locais, e por isso nenhuma
informação de login é exigida na coluna de origem (o primeiro argumento).

Em myfileserver, eu configurei o login SSH sem senha (como vimos na seção anterior), e a coluna de origem inclui a identificação de login e o nome de host, além do diretório.

Em todas as linhas, eu incluí uma coluna de destino, que é um caminho relativo. Ela será interpretada em relação ao que definimos anteriormente como snapshot_root. Logo, um usuário chamado joe em myserver, por exemplo, encontrará os dados de backup de
ontem em /backup/auto/daily.0/myserver/home/joe.

Em myfileserver, é preciso conferir se o rsync está instalado e se o login SSH sem senha foi configurado corretamente para o usuário root em myserver. Não é preciso mais nada no cliente de backup (myfileserver).

O trabalho do cron

A etapa final é configurar um trabalho no “crontab” do servidor de backup (myserver) para executar o programa rsnapshot em intervalos apropriados para realizar os backups:

Cada distribuição GNU/Linux tem um jeito diferente de lidar com as tabelas do cron, então a abordagem pode ser um pouco diferente no seu sistema. Em distribuições derivadas do Debian, o diretório /etc/cron.d contém essas informações. Com isso, fica
mais fácil manter tabelas separadas para diferentes propósitos. O pacote rsnapshot do Debian cria um arquivo nesse diretório para o rsnapshot, o `/etc/crond.d/rsnapshot’.

É nesse arquivo que você vai definir o significado dos intervalos de backup do rsnapshot. Tirando os comentários, esta é a minha configuração de exemplo:

A sintaxe no início de cada linha é exclusiva do cron. Para uma maior compreensão da sintaxe, consulte a man page (página de manual) correspondente (digite man 5 crontab para encontrar “crontab(5)”, que documenta o formato). No caso, as linhas dizem
que o programa deve ser executado com o argumento daily diariamente às 4 h 30 min, com o argumento weekly toda segunda-feira às 4 h e com o argumento monthly às 3 h 30 min do primeiro dia de cada mês.

Os horários são espaçados assim para evitar colisões entre diferentes invocações (por exemplo, quando a segunda-feira cair no primeiro dia do mês, caso no qual o rsnapshot seria chamado três vezes seguidas, enquanto a ideia é ter tempo de concluir a
primeira execução para só então dar início à próxima).