Backups de um VPS: o que verificar antes de contratar

As perguntas a fazer

Frequência e conservação: o que pode perder

Duas durações resumem uma política de cópias de segurança:

• A perda máxima admissível (RPO, recovery point objective): a quantidade de trabalho que aceita perder. Uma cópia de segurança todas as noites significa no máximo 24 horas; uma base de dados que regista encomendas durante todo o dia ganha em acrescentar-lhe o arquivo contínuo do seu registo de transações.
• A duração máxima de interrupção (RTO, recovery time objective): o tempo durante o qual o serviço pode ficar parado. Depende do volume a restaurar, e sobretudo de quem restaura, e quando.

A conservação responde a outra pergunta: até onde pode recuar? Uma eliminação notada no dia seguinte recupera-se com a cópia da véspera. Uma intrusão discreta, uma corrupção silenciosa ou um erro num processamento automático notam-se por vezes mais tarde: é preciso então um ponto de restauro anterior ao problema. Para os arquivos de longo prazo, contabilísticos ou regulamentares, uma exportação mensal guardada à parte completa a cópia de segurança do servidor.

Onde estão as cópias de segurança, e quem as pode apagar

Uma cópia de segurança protege do que acontece ao servidor. Por isso, vive noutro sítio:

• Um espelho de discos (RAID) protege de uma avaria de disco, e copia fielmente para o segundo disco uma eliminação ou uma cifragem maliciosa feita no primeiro. É uma proteção do hardware, não uma cópia de segurança.
• Um instantâneo (snapshot) no mesmo armazenamento permite voltar atrás depressa depois de uma atualização falhada, mas desaparece com o armazenamento que o contém.
• Uma cópia de segurança fora da máquina, num armazenamento separado, sobrevive à perda do servidor. Cifrada antes de sair, fica ilegível para quem não tem a chave.

Um ponto muitas vezes esquecido: uma cópia de segurança que pode ser apagada a partir do servidor pode sê-lo também por um intruso que tomou o controlo do servidor. As cópias de segurança feitas e guardadas pelo fornecedor de alojamento, fora do alcance do servidor copiado, escapam a esse risco.

O caso das bases de dados

Uma base de dados escreve em permanência. Uma cópia dos seus ficheiros feita enquanto está a funcionar captura-a tal como estaria depois de um corte de energia: o PostgreSQL e o MySQL sabem recuperar a partir desse estado, reproduzindo o seu registo. Para um restauro fino, tabela a tabela, ou para outra versão, acrescenta-se uma cópia de segurança lógica:

pg_dump -Fc -d minha_base -f /backups/minha_base-$(date +%F).dump
mysqldump --single-transaction --routines minha_base | gzip > /backups/minha_base-$(date +%F).sql.gz

Programadas todas as noites por uma tarefa agendada, antes da hora da cópia de segurança do servidor, estas exportações ficam incluídas nela, e podem também ser copiadas para um armazenamento seu.

A regra 3-2-1

A regra que as agências de cibersegurança recomendam cabe em três números: 3 cópias dos seus dados, em 2 suportes diferentes, das quais 1 fora do local. Num VPS, traduz-se assim: os dados em serviço no servidor, a cópia de segurança feita pelo fornecedor fora da máquina, e uma exportação regular do que mais conta (a base de dados, os ficheiros enviados pelos seus utilizadores) para um armazenamento seu.

restic -r sftp:utilizador@armazenamento.example.com:/backups init
restic -r sftp:utilizador@armazenamento.example.com:/backups backup /backups

Testar um restauro

Uma cópia de segurança prova-se restaurando-a. Uma vez por trimestre, e depois de cada alteração importante do servidor:

1. Peça ou lance o restauro num servidor de teste, ao lado da produção.
2. Verifique que a aplicação arranca e responde.
3. Compare alguns números com a produção: número de linhas das tabelas principais, data do último registo.
4. Anote o tempo que a operação levou: é a sua duração de interrupção real.

Num VPS gerido, estas cópias de segurança, a sua conservação fora da máquina e o próprio restauro ficam a cargo do fornecedor: basta pedir, e ele restaura.

Se o servidor guarda dados pessoais, o RGPD (artigo 32.º), na União Europeia, prevê a capacidade de restabelecer a disponibilidade e o acesso aos dados pessoais de forma atempada no caso de um incidente físico ou técnico, e um processo para testar, apreciar e avaliar regularmente a eficácia das medidas técnicas e organizativas. Um teste de restauro datado é a prova mais simples.