Backups de servidor: a regra 3-2-1 e como restaurar

A regra 3-2-1 diz: mantenha três cópias dos seus dados importantes (o original e dois backups), em dois tipos diferentes de armazenamento, com pelo menos uma cópia guardada em outro lugar. Em um VPS, isso significa ter pelo menos uma cópia fora do servidor, além dos dados no próprio servidor.

A mesma regra é recomendada no documento Data Backup Options, preparado para o US-CERT e publicado no site da CISA. A ideia é que uma única falha, erro ou ataque não consiga destruir todas as cópias de uma vez.

Backup, snapshot e redundância de disco não são a mesma coisa

• Backup: uma cópia separada dos seus dados, geralmente com versões anteriores. Ele traz de volta um arquivo apagado ou danificado por engano.
• Snapshot: registra o estado do servidor naquele momento. É bom para ter um caminho rápido de volta antes de uma grande atualização. Mas ele depende do disco original, então não substitui um backup.
• Redundância de disco: os mesmos dados gravados em dois discos ao mesmo tempo. Protege você quando um disco falha. Um arquivo que você apaga é apagado dos dois discos, e dados criptografados por ransomware ficam criptografados nos dois. Por isso, não é um backup.

Como aplicar o 3-2-1 em um VPS

Você pode contar o backup diário do painel como uma das suas cópias. Mas a cópia que cumpre a condição de "outro lugar" é aquela que você configura e controla por conta própria. Os termos de serviço da Seturack também pedem que você guarde uma cópia dos seus dados importantes separadamente.

O que incluir no backup

Copiar os arquivos de um banco de dados em funcionamento pode gerar um backup inconsistente. Faça um dump primeiro. Estes comandos rodam como root, como rodariam em um script do cron:

mysqldump --single-transaction --all-databases | gzip > /var/backups/mysql-$(date +%F).sql.gz

sudo -u postgres pg_dumpall | gzip > /var/backups/pg-$(date +%F).sql.gz

Para arquivos, basta isto: /etc, os arquivos do seu site, a pasta de dados da sua aplicação, os volumes do Docker se você usa Docker e os arquivos .env. Não faça backup do que dá para baixar de novo, como pacotes e imagens do Docker. Se a sua aplicação tem uma chave de criptografia, guarde-a separadamente também. Em algumas aplicações, um backup sem a chave é inútil.

A frequência do backup depende de quantos dados você pode se dar ao luxo de perder. Um backup por dia significa perder até um dia de dados no pior caso. Para uma aplicação que registra pedidos ou pagamentos, é mais seguro fazer o dump do banco a cada hora e enviá-lo para fora do servidor.

Um backup fora do servidor com restic

O restic é uma ferramenta de backup de código aberto que criptografa seus backups e armazena dados repetidos uma única vez. O exemplo abaixo grava o backup em outro servidor, acessado por SFTP. O destino precisa de login SSH sem senha (com chave), porque um backup automático não consegue responder a um pedido de senha. Crie o arquivo de senha (/root/.restic-password) em um editor de texto e execute chmod 600 nele.

sudo apt install -y restic

export RESTIC_REPOSITORY=sftp:[email protected]:/backups/vps

export RESTIC_PASSWORD_FILE=/root/.restic-password

restic init

restic backup /etc /var/www /var/backups

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

A documentação do restic avisa que, se você perder a senha, seus dados estão perdidos para sempre. Guarde a senha também em um gerenciador de senhas. Coloque as duas linhas export, os dumps do banco, o restic backup e o restic forget em um script como /usr/local/bin/backup.sh, nessa ordem, e torne-o executável com chmod +x. Não se esqueça de acrescentar no fim uma linha que apague os dumps antigos, find /var/backups -name '*.sql.gz' -mtime +2 -delete, ou os arquivos de dump vão encher o disco. Depois execute o script toda noite, por exemplo a partir de /etc/cron.d/backup com esta linha:

30 3 * * * root /usr/local/bin/backup.sh

O borg é uma ferramenta parecida. Para cópias simples de arquivos você pode usar o rsync, e para enviar dados a um armazenamento de objetos, o rclone.

O teste de verdade: restaurar

Um backup que você não consegue restaurar não vale nada. Teste logo depois de configurar e depois em intervalos regulares:

• Com o restic, extraia o backup mais recente para uma pasta vazia e confira os arquivos: restic restore latest --target /tmp/restore-test
• Carregue um dump do banco em um banco temporário e olhe as tabelas.
• No painel, clique no ícone Recuperar arquivos dele ao lado de um backup, navegue lá dentro e baixe um arquivo. Uma restauração completa substitui todo o disco atual, então recuperar um único arquivo é a forma mais segura de testar.

Escolha por quanto tempo manter os backups de acordo com o atraso com que você pode notar um problema. O backup do painel guarda os últimos 7 dias, e não dá para voltar além disso. Se você pode precisar de versões mais antigas, mantenha versões semanais e mensais na sua própria cópia. Para os detalhes do backup do painel, veja o artigo sobre backups diários.

Erros comuns

• Gravar o backup no disco do mesmo servidor. Se o disco encher ou o servidor se perder, o backup vai junto.
• Guardar a senha ou a chave do backup no mesmo lugar que o backup.
• Não perceber que o script está falhando. Acrescente uma notificação ao script ou confira de vez em quando a data do backup mais recente com restic snapshots.
• Não acompanhar o destino do backup enchendo. Um destino cheio significa backups que falham em silêncio.