Backup de VPS: o desenho 3-2-1 numa caixa só

Uma VPS só comporta, sim, um desenho 3-2-1 completo: três cópias dos dados, em dois lugares que não falham juntos, com uma fora do provedor. A primeira camada são os dados vivos e os dumps consistentes na própria caixa. A segunda é o backup automático do provedor: na Hetzner, 20% do preço do plano por 7 cópias diárias rotativas (~€1,20/mês num servidor de €5,99). A terceira é uma cópia puxada para fora do provedor, a única que sobrevive à perda da conta. O erro mais comum não é fazer pouco backup. É contar o backup do provedor como se fosse a cópia externa. Ele mora na mesma conta, atrás da mesma credencial e da mesma fatura que o servidor: o que derruba um, derruba os dois.

Este post descreve o desenho de cópias que uma infraestrutura real usa: uma VPS que serve tudo atrás de Cloudflare Tunnel. Nela rodam os serviços cujos componentes de custo já apareceram aqui. Vamos camada por camada, com o que cada uma custa e contra o que cada uma protege. O sistema de alarme dessa rotina tem post próprio: o dead-man switch, que transforma silêncio em alerta, e o ensaio de restore que sabe falhar. Aqui o assunto é o desenho das cópias e a conta.

---

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

A formulação clássica, popularizada pelo fotógrafo Peter Krogh: 3 cópias dos dados (a de produção conta), em 2 mídias diferentes, com 1 fora do local. Ela nasceu no mundo de discos e fitas. Para uma VPS em nuvem, a tradução honesta troca as palavras sem trocar a ideia:

• “2 mídias diferentes” vira 2 domínios de falha diferentes. Ou seja, duas cópias que não morrem pelo mesmo motivo. O disco do servidor e o backup do provedor qualificam: a perda do host leva um e não o outro.
• “1 fora do local” vira 1 fora do domínio administrativo: fora do provedor, da conta, da credencial. É o número que quase todo mundo marca errado, e é o assunto da seção mais importante deste post.

Como o 3-2-1 se encaixa numa VPS só?

O mapa completo do desenho, do dado vivo à cópia mais distante:

Cópia	Onde mora	Contra o que protege	Atraso máximo (RPO)
Dados vivos	disco da VPS	—	—
Dumps a cada 6h	o mesmo disco	erro lógico: DROP TABLE, migração ruim, bug de aplicação	6h
Backup do provedor (diário, 7 rotativos)	mesmo provedor, fora do host	perda do disco ou do host	24h
Pull noturno para fora	outra máquina, outro teto, outra conta	perda do provedor, da conta, invasão da caixa	~30h

Contando com honestidade: os dumps na própria caixa não somam durabilidade, porque moram no mesmo disco que pretendem salvar. As três cópias do “3” são os dados vivos, o backup do provedor e a cópia de fora. Mas os dumps não estão ali de enfeite. Eles são o artefato que as outras camadas copiam, e a razão fica clara já na primeira pergunta.

Por que fazer dump se o provedor já tira snapshot?

Porque snapshot de disco de servidor ligado é, na melhor das hipóteses, crash-consistent: é a foto do disco como ele estaria depois de puxar o cabo de energia. Pense num Postgres no meio de um checkpoint, ou num SQLite com WAL cheio. O snapshot os captura no meio do movimento, e a restauração vira uma recuperação de queda, não uma volta limpa.

O desenho resolve isso invertendo a dependência: quem garante consistência é a aplicação, não o snapshot. Um cron na caixa gera, a cada 6 horas, dumps que cada motor sabe produzir consistentes com o banco em uso. São pg_dump comprimido para os Postgres, a API .backup() do SQLite (consistente mesmo com o banco em WAL) e tarballs para volumes de arquivos e configuração. O snapshot do provedor e a cópia de fora não copiam os arquivos vivos do banco. Copiam os dumps, que, esses sim, restauram limpo.

Custo da camada: espaço em disco que o plano já inclui. Num servidor com 40 GB de NVMe, alguns GB de dumps rotacionados não aparecem na fatura.

Backup ou snapshot na Hetzner?

A Hetzner oferece os dois, e a diferença importa para a conta (hetzner.com/cloud e docs.hetzner.com, conferidos em 25/08/2026):

• Cloud Backups: automáticos, diários, 7 slots rotativos por servidor. São ligados com um clique, por 20% do preço mensal do plano. Num CX23 de €5,99/mês, cerca de €1,20/mês. É a camada 2 deste desenho: barata, sem operação manual, guardada fora do host do servidor.
• Snapshots: manuais, cobrados por GB de uso real por mês, vivem até serem apagados. Servem para o momento “antes desta migração grande, congela tudo”. Não servem para rotina, porque ninguém aperta botão todo dia (o preço por GB está na mesma página de preços).

Para a rotina, a escolha é o backup automático. E vale dizer o óbvio que a fatura esconde: 20% do plano é um dos seguros mais baratos que existem em infraestrutura. A caixa desta casa o mantém ligado.

O que essa camada cobre: o disco morre, o host pega fogo, o hardware falha. Restaura-se do backup de ontem no painel, em minutos. O que ela não cobre é o assunto da próxima seção.

Por que o backup do provedor não conta como cópia externa?

Porque o “1” do 3-2-1 não mede distância geográfica. Mede independência administrativa. O backup do provedor mora:

• atrás da mesma credencial: o mesmo token de API que destrói o servidor destrói os backups dele. Uma credencial vazada, ou um atacante com acesso ao painel, leva as duas cópias na mesma tarde.
• na mesma conta e na mesma fatura: basta uma disputa de cobrança, um cartão recusado no mês errado, uma suspensão por denúncia. A conta bloqueada tranca o servidor e os backups juntos.
• no mesmo provedor: um incidente que afete o provedor inteiro, seja técnico, comercial ou jurídico, afeta as duas cópias de uma vez.

Nada disso é crítica à Hetzner. É estrutural, e vale para qualquer provedor. Snapshot do provedor protege contra falha de hardware. Cópia externa protege contra falha de relacionamento: conta, credencial, contrato. São perguntas diferentes, e o 3-2-1 exige resposta para as duas.

A consequência prática: enquanto a única cópia fora do host morar no mesmo painel que o servidor, o desenho tem duas camadas, não três.

Como montar a cópia de fora — e por que ela puxa, em vez de empurrar?

A terceira camada desta infraestrutura é a mais simples de todas: uma máquina fora do provedor, um computador doméstico serve, que puxa os dumps da VPS toda madrugada. A cópia usa rsync sobre SSH, o comando que sincroniza arquivos entre máquinas. A direção não é detalhe:

• A VPS não tem credencial nenhuma para alcançar a máquina de backup. Um invasor com root na caixa vê os dumps locais e pode destruí-los. As cópias de fora ele não alcança, porque não existe caminho de lá para cá. No desenho invertido, com a VPS empurrando para um storage, a credencial de escrita mora exatamente na máquina que o invasor controla.
• O que chegou não se sobrescreve. O rsync roda com --ignore-existing e nunca com --delete: do ponto de vista da origem, um snapshot que chegou é imutável. A poda é local, por idade (60 dias), feita pelo lado que puxa. A origem não tem como encolher a retenção.
• Integridade na chegada: arquivo comprimido recém-chegado passa por gunzip -t. Um .gz truncado por queda de conexão é apagado na hora e repuxado na noite seguinte, em vez de ficar 60 dias fingindo ser backup.
• Idade pela mtime, não pelo sucesso do pull. O rsync -a preserva a mtime, a data de modificação do arquivo. Ela marca a hora em que a VPS gerou o dump, não a hora em que a cópia chegou. A distinção paga o custo de existir. Se o cron de dumps morrer na VPS, o pull noturno continua “dando certo” para sempre, copiando nada de novo com código de saída zero. O que se vigia é a idade do arquivo mais recente (aqui, alarme acima de 30 horas), não o sucesso da cópia.

Um purista notará que a máquina de fora não é um datacenter, e é verdade. Mas o critério da camada é independência administrativa: outro teto, outra conta, outro domínio de falha. Quem preferir, troca a máquina doméstica por um object storage em outro provedor, e o desenho não muda. O que não pode é a cópia “externa” morar no mesmo painel que o servidor.

Quanto custa o desenho completo?

Preços públicos da Hetzner Cloud, conferidos em 25/08/2026 (sem impostos):

Camada	Item	Custo mensal
—	VPS CX23 (2 vCPU / 4 GB / 40 GB NVMe) + IPv4	€5,99 + €0,50
1	Dumps a cada 6h na própria caixa	€0 — espaço já incluso no plano
2	Hetzner Cloud Backups (7 diários rotativos)	~€1,20 — 20% do plano
3	Pull noturno para máquina própria fora do provedor	€0 de fatura — o custo é operar

O 3-2-1 completo de uma caixa de €6,49 custa ~€1,20/mês de fatura. O resto do custo não aparece em fatura nenhuma. É exatamente por isso que ele é perigoso.

Onde esse desenho quebra primeiro?

Nas camadas 1 e 2, alguém profissional vigia: o provedor opera os backups dele, e o cron da caixa está a um docker logs de distância. Já a camada 3 é artesanal, justamente a que protege contra os piores cenários: um agendador doméstico, uma máquina que dorme, uma credencial SSH que expira.

Aconteceu aqui, e a lição vale mais que o constrangimento: o job noturno ficou 14 dias sem rodar. Ele tinha sido descarregado do agendador do sistema, sem uma linha de erro em lugar nenhum, porque job que não roda não falha. Foram duas semanas em que as camadas 1 e 2 seguiram perfeitas e a única cópia fora do provedor envelhecia em silêncio. A correção não foi “prestar mais atenção”. Foi inverter o sinal: o job passou a avisar quando dá certo, e o silêncio virou alarme com prazo. Esse desenho está detalhado no post sobre dead-man switch e ensaio de restore, junto com o ensaio que prova que os arquivos não só chegam como voltam. Considero essa leitura a segunda metade obrigatória deste post.

A fronteira entre os dois posts é a mesma fronteira do problema: este descreve onde as cópias moram; o outro, como saber que elas continuam existindo. Um desenho de cópias sem vigia apodrece começando pela camada mais importante.

---

O resumo que você leva

1. 3-2-1 numa VPS só: dados vivos + backup do provedor + cópia fora do provedor. Os dumps locais são o quarto elemento: não somam durabilidade, mas são o artefato consistente que as outras camadas copiam.
2. Snapshot de servidor ligado é crash-consistent. Consistência quem garante é a aplicação: pg_dump, .backup() do SQLite, na cadência que o seu RPO pede.
3. Ligue o backup do provedor. Na Hetzner, 20% do plano por 7 cópias diárias (preço de 25/08/2026) é seguro barato contra perda de hardware.
4. Mas ele não é a cópia externa. Mesma conta, mesma credencial, mesma fatura = mesmo domínio de falha. O “1” do 3-2-1 mede independência administrativa, não distância.
5. A cópia de fora puxa, não empurra: a VPS não deve ter caminho até a máquina de backup. Sem --delete, poda por idade no lado que puxa, integridade verificada na chegada.
6. Vigie a idade do que chegou, não o sucesso da cópia. A mtime preservada pelo rsync conta quando o dump foi gerado, e é ela que denuncia um cron morto na origem.
7. A fatura do desenho inteiro é ~20% do plano. O custo real é a vigilância da camada artesanal: dead-man switch e ensaio de restore, no post vizinho.