Como montar a política de backup do seu servidor dedicado: regra 3-2-1, retenção GFS e testes de restauração

Como montar a política de backup do servidor dedicado: RPO e RTO, regra 3-2-1, retenção GFS, cópia imutável e rotina de testes de restauração.

Para que serve

Sem o serviço de Gerenciamento contratado, o backup do servidor dedicado é responsabilidade sua. Antes de escolher ferramenta (restic, Veeam, Proxmox Backup Server, dumps de banco), vale decidir o que proteger, com que frequência, por quanto tempo guardar e como provar que a restauração funciona. Este artigo ajuda você a escrever essa política de backup em uma página e a montar uma rotina de testes. Os demais artigos desta categoria mostram como executar cada parte.

Pré-requisitos

• Lista dos serviços que rodam no servidor (VMs, bancos de dados, sites, ERP, compartilhamentos).
• Uma conversa com o responsável pelo negócio sobre quanto dado se aceita perder e quanto tempo parado se tolera.
• Um destino de backup fora do servidor: outro servidor, um Proxmox Backup Server, ou armazenamento de objetos (Backblaze B2, Wasabi, Amazon S3 ou equivalente).

Como montar a política de backup passo a passo

1. Defina RPO e RTO por serviço. RPO (Recovery Point Objective) é a quantidade máxima de dados que se aceita perder, medida em tempo. RTO (Recovery Time Objective) é quanto tempo o serviço pode ficar fora até voltar. Um ERP com notas fiscais pode exigir RPO de 15 minutos; um site institucional aceita 24 horas. O RPO define a frequência do backup; o RTO define o tipo (uma VM inteira volta mais rápido que uma reinstalação manual).

2. Separe as camadas do que proteger. Em um servidor com Proxmox VE, pense em três níveis:

   • Host: /etc/pve, /etc/network/interfaces, regras de firewall, scripts em /root e cron. São poucos megabytes e aceleram muito uma reinstalação.
   • VMs e contêineres inteiros: backup com vzdump ou Proxmox Backup Server (veja também o artigo «Como fazer backup no Proxmox: VMs com vzdump e Proxmox Backup Server»). Resolve o RTO.
   • Dados de aplicação: dumps consistentes de MySQL/MariaDB, PostgreSQL e SQL Server feitos de dentro da VM, em frequência maior que a da VM inteira. Resolve o RPO e permite restaurar uma tabela sem voltar a máquina toda.

3. Aplique a regra 3-2-1 (e a variante 3-2-1-1-0). Mantenha 3 cópias dos dados (a produção mais duas), em 2 tipos de armazenamento diferentes, com 1 delas fora do datacenter. A versão estendida acrescenta 1 cópia imutável ou desconectada (que um invasor com acesso ao servidor não consegue apagar) e 0 erros na verificação da restauração. Na prática, para um dedicado:

   Cópia	Onde	Para quê
   Produção	NVMe do servidor	Uso diário
   Cópia local	Disco SSD separado do pool principal, ou um PBS em outro servidor	Restauração rápida (RTO baixo)
   Cópia externa	Armazenamento de objetos ou servidor em outro datacenter	Desastre, perda total do servidor, ransomware

4. Escolha a retenção com o esquema GFS. GFS (avô-pai-filho, do inglês Grandfather-Father-Son) guarda muitos pontos recentes e poucos pontos antigos. Um ponto de partida razoável:

   Nível	Quantidade	Cobre
   Diário (filho)	7 a 14	Erros percebidos na mesma semana
   Semanal (pai)	4 a 5	Último mês
   Mensal (avô)	6 a 12	Problemas descobertos tarde, auditoria
   Anual	Conforme exigência legal/contábil	Fechamentos de exercício

   As ferramentas já trazem isso pronto: restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12, as opções keep-daily/keep-weekly/keep-monthly do Proxmox e do PBS, e a retenção GFS do Veeam. Dados com ransomware costumam ser percebidos dias depois, por isso não economize nos semanais e mensais.

5. Proteja a cópia externa contra exclusão. Se as credenciais do armazenamento ficam no servidor, quem invadir o servidor pode apagar os backups. Use chaves de acesso restritas a um único bucket, ative bloqueio de objetos (Object Lock) quando a ferramenta suportar, ou faça o servidor de backup puxar os dados em vez de o servidor de produção empurrar. Guarde senhas e chaves de criptografia dos backups fora do servidor (cofre de senhas da equipe).

6. Calcule o espaço e o custo. Some o volume de dados, aplique a taxa de mudança diária estimada (5% a 10% é comum em servidores de aplicação) e multiplique pelos pontos de retenção. Atenção a provedores com retenção mínima: na Wasabi, por exemplo, objetos apagados antes de 90 dias (plano pay-as-you-go) continuam sendo cobrados até completar o período, então podar antes disso não economiza.

7. Monitore cada job. Backup que falha em silêncio é o problema mais comum. Faça cada script terminar com um aviso de sucesso para um serviço de monitoramento de cron (ex.: um endpoint do Healthchecks ou do Uptime Kuma) ou envie e-mail em caso de erro; veja também o artigo «Como receber alertas do servidor no Telegram, e-mail ou WhatsApp». Revise semanalmente se a data do último backup bate com o esperado.

8. Escreva o runbook de restauração. Um documento curto com: onde estão os backups, como acessar (credenciais no cofre), comandos para restaurar cada serviço, ordem de subida (banco antes da aplicação) e contatos. Em um incidente, ninguém deveria precisar lembrar de cabeça.

Rotina de testes de restauração

Backup só existe depois que uma restauração deu certo. Sugestão de calendário:

Ao restaurar uma VM para teste no mesmo Proxmox, mantenha a placa de rede desconectada ou em uma bridge isolada para não haver conflito de IP nem envio de e-mails e integrações em duplicidade.

Como saber se funcionou

• Cada serviço tem RPO, RTO, frequência, retenção e destino documentados.
• Existe ao menos uma cópia fora do servidor e uma que não pode ser apagada com as credenciais do servidor.
• O último teste de restauração está registrado (data, o que foi restaurado, tempo gasto, problemas encontrados).

Problemas comuns

"O backup roda todo dia, mas o arquivo está corrompido"

Geralmente o dump foi feito com o banco em uso sem a opção de consistência, ou o disco de destino encheu no meio. Use as opções de cópia consistente de cada banco e alertas de espaço em disco.

A retenção não apaga nada e o disco enche

Verifique se o comando de poda (prune) está agendado, e não só o de marcação (forget). Em armazenamento de objetos com versionamento, configure a regra de ciclo de vida que remove versões ocultas.

A senha do repositório se perdeu

Backups criptografados sem a senha são irrecuperáveis. Guarde-a em pelo menos dois lugares fora do servidor.

Perguntas frequentes

O que é a regra 3-2-1 de backup?

São 3 cópias dos dados (a produção e mais duas), em 2 tipos de armazenamento diferentes, com 1 cópia fora do datacenter. A variante 3-2-1-1-0 acrescenta uma cópia imutável ou desconectada e zero erros nos testes de restauração.

Qual a diferença entre RPO e RTO?

RPO é quanto dado você aceita perder, medido em tempo, e define a frequência do backup. RTO é quanto tempo o serviço pode ficar parado até voltar, e define o tipo de backup e de restauração.

RAID ou snapshot substituem o backup?

Não. RAID protege contra a falha de um disco e o snapshot fica no mesmo pool que ele protege. Nenhum dos dois resolve exclusão acidental, ransomware ou perda do servidor.

A E-Consulters faz o backup do meu servidor?

Não. Sem o serviço de Gerenciamento contratado, o backup é responsabilidade do cliente, e a E-Consulters não oferece storage de backup. Use outro servidor seu ou um armazenamento de objetos externo.

De quanto em quanto tempo devo testar a restauração?

Confira o resultado dos jobs todo dia, verifique a integridade semanalmente, restaure um banco por mês e uma VM inteira por trimestre, como na tabela deste artigo.

Leitura complementar

• restic: políticas de remoção de snapshots
• Simulador de retenção do Proxmox Backup Server
• Backblaze: a estratégia 3-2-1

Precisa de ajuda?

Se tiver dúvidas sobre como aplicar esta política ao seu servidor, abra um ticket na área do cliente ou fale com o suporte 24/7 pelo seu grupo de WhatsApp.