Cópias de segurança do servidor: a regra 3-2-1 e como restaurar

A regra 3-2-1 diz: guarde três cópias dos seus dados importantes (o original e duas cópias de segurança), em dois tipos de armazenamento diferentes, com pelo menos uma cópia guardada noutro local. Num VPS, isto significa ter pelo menos uma cópia fora do servidor, além dos dados que estão no próprio servidor.

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

Uma cópia de segurança, um instantâneo e a redundância de discos não são a mesma coisa

• Cópia de segurança: uma cópia separada dos seus dados, normalmente com versões anteriores. Recupera um ficheiro apagado ou danificado por engano.
• Instantâneo: regista o estado do servidor naquele momento. É bom para voltar atrás depressa antes de uma grande atualização. Mas depende do disco original, por isso não substitui uma cópia de segurança.
• Redundância de discos: os mesmos dados escritos em dois discos ao mesmo tempo. Protege-o quando um disco falha. Um ficheiro que apague é apagado dos dois discos, e os dados cifrados por ransomware ficam cifrados nos dois. Por isso, não é uma cópia de segurança.

Como aplicar o 3-2-1 num VPS

Pode contar a cópia de segurança diária do painel como uma das suas cópias. Mas a cópia que cumpre a condição «noutro local» é a que configura e controla por si. Os termos de serviço da Seturack também pedem que guarde à parte uma cópia dos seus dados importantes.

O que copiar

Copiar os ficheiros de uma base de dados em execução pode dar uma cópia inconsistente. Faça primeiro um dump. Estes comandos correm como root, tal como num 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

Quanto aos ficheiros, basta isto: /etc, os ficheiros do seu site, a pasta de dados da sua aplicação, os volumes do Docker se usar o Docker, e os ficheiros .env. Não copie o que pode voltar a transferir, como pacotes e imagens Docker. Se a sua aplicação tem uma chave de cifragem, guarde-a também à parte. Em algumas aplicações, uma cópia sem a chave é inútil.

A frequência das cópias depende da quantidade de dados que pode dar-se ao luxo de perder. Uma cópia por dia significa perder, no pior caso, até um dia de dados. Numa aplicação que regista encomendas ou pagamentos, é mais seguro fazer o dump da base de dados de hora a hora e enviá-lo para fora do servidor.

Uma cópia fora do servidor com o restic

O restic é uma ferramenta de cópias de segurança de código aberto que cifra as cópias e guarda uma só vez os dados repetidos. O exemplo abaixo grava a cópia noutro servidor, acedido por SFTP. O destino precisa de acesso SSH sem palavra-passe (por chave), porque uma cópia automática não consegue responder a um pedido de palavra-passe. Crie o ficheiro da palavra-passe (/root/.restic-password) num editor de texto e execute chmod 600 sobre ele.

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 perder a palavra-passe, os seus dados perdem-se para sempre. Guarde também a palavra-passe num gestor de palavras-passe. Ponha as duas linhas export, os dumps das bases de dados, o restic backup e o restic forget num script como /usr/local/bin/backup.sh, por essa 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 ficheiros de dump encherão o disco. Depois execute o script todas as noites, por exemplo a partir de /etc/cron.d/backup com esta linha:

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

O borg é uma ferramenta semelhante. Para cópias simples de ficheiros pode usar o rsync, e para enviar dados para armazenamento de objetos pode usar o rclone.

O teste a sério: restaurar

Uma cópia que não consegue restaurar não vale nada. Experimente logo depois de configurar e, a seguir, em intervalos regulares:

• Com o restic, extraia a cópia mais recente para uma pasta vazia e verifique os ficheiros: restic restore latest --target /tmp/restore-test
• Carregue um dump da base de dados numa base de dados temporária e veja as tabelas.
• No painel, clique no ícone Recuperar ficheiros dela ao lado de uma cópia, navegue lá dentro e transfira um ficheiro. Um restauro completo substitui todo o disco atual, por isso recuperar um único ficheiro é a forma mais segura de testar.

Escolha durante quanto tempo guarda as cópias consoante o atraso com que pode vir a reparar num problema. A cópia de segurança do painel guarda os últimos 7 dias, e não é possível recuar mais do que isso. Se puder precisar de versões mais antigas, guarde versões semanais e mensais na sua própria cópia. Para os pormenores da cópia de segurança do painel, veja o artigo sobre as cópias de segurança diárias.

Erros comuns

• Gravar a cópia de segurança no disco do mesmo servidor. Se o disco encher ou o servidor se perder, a cópia perde-se com ele.
• Guardar a palavra-passe ou a chave da cópia de segurança no mesmo sítio que a cópia.
• Não reparar que o script está a falhar. Acrescente uma notificação ao script, ou verifique de vez em quando a data da última cópia com restic snapshots.
• Não vigiar o enchimento do destino das cópias. Um destino cheio significa cópias que falham em silêncio.