Backups de VPS Que Restauram de Verdade

Uma estratégia de backup nunca é testada na noite em que o servidor morre. Ela é testada semanas antes, em três decisões silenciosas que ninguém anota: para onde vai a cópia, quem tem permissão para apagá-la, e se alguém já de fato restaurou uma para conferir.

Uma hospedagem que nunca pediu sua identidade abre mão de algo em troca, e este é o lugar certo para dizer isso sem rodeios. Não existe gerente de conta para ligar, nem chamado que ressuscite um volume apagado, e nossa própria política de retenção é direta quanto ao motivo: os dados do servidor são destruídos em até 24 horas após o encerramento, os discos são apagados criptograficamente em vez de formatados, e nenhum backup é retido. É a mesma característica que torna a plataforma atraente, vista do outro lado. Tudo o que você queira recuperar depois de uma noite ruim já precisa estar em outro lugar — e é você quem o coloca lá.

O que realmente destrói servidores

Quase ninguém perde um servidor do jeito que imagina. Falha catastrófica de hardware é real, mas rara, e é o único caso contra o qual uma hospedagem competente já se blinda. As perdas que realmente acontecem são mais banais, e cada uma delas derrota um tipo diferente de cópia — por isso "eu tenho backup" não é resposta enquanto você não disser a qual dessas situações ele sobrevive.

Leia essa tabela como uma checklist, não como uma lista de medos. Uma cópia noturna para um segundo disco na mesma máquina responde só à primeira linha. Um snapshot no mesmo painel responde às linhas um e dois. Só uma cópia guardada em algum lugar que o servidor não alcança, sob uma chave que você ainda tem, responde às cinco.

Snapshot não é backup, e sua hospedagem também não é

Snapshots são excelentes no que fazem: revertem uma atualização que deu errado, em segundos, sem transferência nenhuma. O que eles não conseguem fazer é sobreviver ao que derrubou o servidor, porque compartilham todos os domínios de falha com ele — o mesmo provedor, a mesma conta, o mesmo token de cobrança, o mesmo país, muitas vezes o mesmo cluster de armazenamento. Um snapshot te protege de você mesmo. Um backup te protege de tudo o mais.

Essa distinção importa mais aqui do que numa hospedagem tradicional, porque as redes de segurança de sempre foram removidas de propósito. Ninguém acessa os servidores dos clientes, então ninguém percebe que seu job de backup vem falhando desde março. Não há identidade vinculada à conta, então não existe um caminho humano do tipo "prove quem você é e nós restauramos". E o encerramento é definitivo mesmo: um saldo vencido é um evento de perda de dados, não um evento de cobrança.

3-2-1, reescrita para quem nunca mostrou documento

A regra clássica diz três cópias, em dois tipos de mídia, uma delas fora do local. Ela foi escrita para uma era de fita magnética e disco rígido giratório, e a cláusula da mídia silenciosamente deixou de significar alguma coisa: seu disco de produção é NVMe, o disco do seu destino de backup também é NVMe, e chamar isso de "duas mídias" é uma história que você conta para si mesmo. A cláusula que vale a pena manter é a da distância, e para infraestrutura offshore distância não se mede em quilômetros.

Reescreva como três cópias, dois provedores, duas jurisdições. As falhas que derrubam as duas cópias ao mesmo tempo quase nunca são físicas — são uma conta à qual você perdeu acesso, um provedor que teve uma semana ruim, ou um instrumento jurídico que alcança um país e não tem efeito em outro. Dois servidores no mesmo rack são uma cópia com passos extras; dois servidores sob o mesmo regime legal são pouco melhores. Nosso guia de jurisdições explica como escolher uma segunda que não apenas espelhe a exposição da primeira.

Na prática isso sai barato. Um destino de backup não precisa de núcleos, e mal precisa de rede — precisa de disco e de um endereço. O menor plano de VPS em uma das nossas outras sete localizações já é um destino competente para restic ou Borg, e para arquivos medidos em terabytes um servidor dedicado com discos de verdade custa menos por terabyte do que qualquer object storage. Onde o dado é genuinamente grande e raramente lido, a economia favorece o bare metal por uma margem larga.

Uma coisa que as pessoas acertam na produção e erram no destino de backup: pagar da mesma forma. Um segundo servidor comprado com um cartão no seu próprio nome religa discretamente a identidade que você se esforçou para remover do primeiro, e agora ele guarda uma cópia completa de tudo o que está nele. Se o servidor de produção é pago em Monero, o de backup merece o mesmo tratamento.

A terceira cópia é a que a maioria pula, e é a única imune a todas as falhas remotas ao mesmo tempo: um disco que você segura fisicamente, atualizado de vez em quando, mantido offline. Uma vez por mês já basta para a maioria das pessoas. Custa a atenção de um cafezinho, e é a cópia que sobrevive aos cenários que as outras duas compartilham.

Push, pull, e o erro que deixa uma noite ruim comer as duas cópias

Este é o arranjo que quase todo mundo monta primeiro. Um job no servidor de produção roda toda noite, guarda uma chave ou um token do destino de backup, conecta e envia (push). Funciona, é simples, e tem uma propriedade que só fica visível no pior dia da vida do servidor: quem controla a máquina de produção também controla os backups.

Isso não é hipótese. Apagar ou criptografar os backups da vítima antes de se anunciar é prática padrão para quem faz isso comercialmente — as credenciais estão sentadas num cron job ou num arquivo de ambiente, e encontrá-las leva cerca de um minuto. Uma cópia que seu invasor consegue apagar não é uma segunda cópia. É um espelho da primeira com atraso.

Existem duas soluções limpas, e elas combinam bem com o hardening básico que você já deveria ter feito.

• Destinos append-only. As duas ferramentas principais suportam um modo em que o cliente pode adicionar dados, mas não removê-los. O Borg faz isso fixando a chave SSH no destino em borg serve --append-only; o restic faz isso com um servidor REST iniciado com --append-only. O servidor de produção escreve todas as noites e é estruturalmente incapaz de destruir o histórico. A limpeza de snapshots antigos então acontece no destino, numa sessão que a máquina de produção não consegue iniciar.
• Pull em vez de push. Inverta a direção: o host de backup conecta na produção, lê e armazena. A produção não guarda nenhuma credencial do destino, então não há nada para roubar. Restrinja a chave usada do lado da produção com restrict e um command= forçado, para que uma chave de backup roubada não vire um shell.

Pull é o modelo mais forte e dá um pouco mais de trabalho para manter; append-only é praticamente de graça se você já usa Borg ou restic. Qualquer um dos dois transforma "o invasor apagou meus backups" de um resultado em uma tentativa. Se você levar uma única coisa deste guia, leve esta seção.

Criptografe na origem, depois decida quem fica com a chave

As duas ferramentas sérias criptografam na máquina que está sendo copiada, antes de qualquer coisa cruzar a rede. O destino armazena blobs que não consegue interpretar — o que é exatamente o que torna segura a cópia entre provedores diferentes. Seu segundo host não precisa ser confiável, nem simpático; precisa estar acessível e ter disco. Essa única característica é o que transforma "um servidor num país sobre o qual não sei nada" de um risco em infraestrutura.

Esse é um mecanismo diferente de criptografar o próprio disco do servidor, e os dois respondem a perguntas diferentes — nosso guia sobre criptografia de disco completo em um VPS detalha o que a criptografia de disco protege e o que ela não protege enquanto a máquina está ligada. A criptografia de backup é a mais fácil e a mais valiosa das duas, porque o modelo de ameaça é honesto: o dado está em repouso, em um hardware que você não controla, e a chave nunca vai para lá.

O que transfere todo o risco para a custódia da chave. A senha agora é um ponto único de perda total, e é um ponto único pior do que as pessoas esperam, porque perdê-la é silencioso — nada quebra, os backups continuam rodando, e você só descobre no exato momento em que precisava deles. Três hábitos resolvem isso:

• Mantenha a senha no servidor apenas como um arquivo legível somente pelo root, referenciado com --password-file, para que ela nunca apareça numa lista de processos ou num histórico de shell.
• Mantenha uma cópia legível por humanos fora de todas as máquinas envolvidas. Papel numa gaveta genuinamente bate um gerenciador de senhas sincronizado com uma conta que você também pode perder.
• Adicione uma segunda chave ao repositório — restic key add, ou uma chave do Borg exportada — para que uma senha esquecida seja um incômodo, e não o fim do arquivo.

A regra por trás das três: se a única cópia da chave mora na máquina que o backup existe para substituir, você não tem um backup. Você tem uma pilha criptografada de blocos e uma história sobre ela.

Escolhendo uma ferramenta, em uma tabela

A escolha da ferramenta importa menos do que a direção da conexão e o estado da sua chave, por isso ela vem em sexto lugar e não em primeiro. Dito isso, as diferenças são reais, e escolher o formato errado para o trabalho cria retrabalho depois.

Para um único servidor, restic para um segundo VPS é o caminho mais curto até algo correto. Para uma seedbox, um arquivo de mídia ou qualquer coisa com muitos arquivos grandes e parecidos, a deduplicação do Borg é a diferença entre um disco cheio e um disco confortável — o guia de seedbox detalha melhor o lado de armazenamento dessa carga de trabalho.

Tudo o que está rodando não é um arquivo

O backup corrompido mais comum do mundo é uma cópia direta de arquivo de um banco de dados vivo. Ela completa sem erro nenhum, pesa o tamanho certo, e ao restaurar vira uma tabela que o engine se recusa a abrir. O banco estava no meio de uma escrita quando a cópia passou por ele; o que você salvou é a foto de uma página sendo virada.

Três saídas, em ordem crescente de esforço. Dump: mysqldump --single-transaction gera um dump consistente do InnoDB sem travar quem escreve, e pg_dump faz o mesmo para o PostgreSQL. Snapshot: congele o sistema de arquivos ou tire um snapshot de LVM ou ZFS, copie a partir do snapshot, libere-o — é assim que se lida com conjuntos de dados grandes demais para dar dump toda noite. Ou pare: para um serviço pequeno, dois minutos de indisponibilidade às 4h da manhã é uma estratégia de consistência perfeitamente respeitável, e é a única sem casos extremos.

A mesma lógica vai além dos bancos de dados. A camada gravável de um container é descartável, mas seus volumes não são, e o arquivo docker compose e o ambiente ao lado deles também não — um backup que restaura os dados mas não a definição deixa você reconstruindo a stack de memória. Filas de mensagens, Redis com persistência ativada, e um spool de e-mail sendo escrito por um MTA merecem o mesmo tratamento: parar, tirar snapshot ou dar dump, mas nunca copiar direto e torcer.

O que fazer backup, e as partes que todo mundo esquece

A maioria das pessoas faz backup do óbvio — o banco de dados e o diretório da aplicação — e reconstrói o resto na mão, sob pressão. É na reconstrução que as horas se vão. Um backup que te devolve a um sistema funcionando, em vez de uma pilha de dados corretos, inclui a camada chata:

• /etc por completo, mais as units e timers do systemd que você escreveu, e quaisquer crontabs que vivam fora dele.
• Certificados TLS e suas chaves privadas, ou no mínimo a chave da conta ACME, para que os certificados renovem em vez de recomeçar do zero.
• Regras de firewall e a lista de pacotes, que juntas reconstroem a forma da máquina mais rápido do que qualquer memória dela.
• Segredos de aplicação e arquivos de ambiente — aqueles deliberadamente excluídos do seu repositório de código, e por isso presentes em nenhum outro lugar.
• Registros DNS exportados como texto, incluindo entradas de DNS reverso e PTR, que vivem no provedor e não no servidor.

Um restore que você nunca testou é um boato

O software de backup se autoavalia, e é honesto sobre a coisa errada. "Snapshot concluído" significa que dados foram gravados num repositório. Isso não diz nada sobre se o repositório pode ser lido numa máquina que não é esta, por uma pessoa que não lembra o que configurou há onze meses.

Comece pelas checagens de integridade baratas — restic check --read-data-subset=5% ou borg check --verify-data numa rotina agendada — e entenda que elas verificam o arquivo, não a sua capacidade de usá-lo. O teste de verdade é diferente e leva uma tarde, uma única vez. Contrate um servidor novo cobrado por hora, numa localização que você não usa normalmente. Restaure nele com nada além do endereço do repositório, a senha, e suas próprias anotações. Suba o serviço. Cronometre tudo. Depois destrua a máquina. Custo total: alguns dólares, e é o único exercício que produz um número em que você pode confiar.

O que ele expõe com confiabilidade nunca são os dados. É o pacote faltando que ninguém anotou, a configuração que vivia fora dos caminhos copiados, a senha que só existiu no histórico de shell do servidor que você está tentando substituir, e a versão da ferramenta que lê o formato do seu repositório. Cada uma dessas coisas é trivial de corrigir com antecedência e péssima de descobrir durante uma interrupção.

Anote os dois números que o teste te dá: quanto tempo um restore levou, e quanto trabalho a rotina pode perder. Essa é a política de backup. Tudo acima é detalhe de implementação a serviço desses dois números.

Automatizando para que continue acontecendo

Rode o job a partir de um timer do systemd, em vez de cron. Você ganha logs num lugar só, um registro real da última execução, e um agendamento que sobrevive a reboots — nada disso o cron te dá sem trabalho extra. Mantenha a senha fora do próprio arquivo de unit, que qualquer pessoa com acesso ao shell consegue ler direto com systemctl cat.

Depois resolva o modo de falha que realmente pega as pessoas, que não é um erro, e sim o silêncio. Um backup que parou de rodar há seis semanas parece exatamente igual a um que rodou perfeitamente, porque os dois não produzem saída nenhuma. Alerte sobre ausência, não sobre falha. Faça o job avisar um monitor quando tiver sucesso, e deixe o monitor reclamar quando o aviso não chegar — e coloque esse monitor em qualquer lugar, menos no servidor que ele observa, já que uma máquina fora do ar não consegue avisar que está fora do ar.

Defina a retenção de forma deliberada, não por padrão. Algo como --keep-daily 7 --keep-weekly 4 --keep-monthly 6 cobre os erros que você percebe hoje à noite e a corrupção que você percebe na primavera, sem crescer para sempre. Rode a limpeza do lado do destino se você já foi para append-only, que é justamente o ponto de ter ido para append-only. O volume de transferência raramente é a restrição na nossa rede — a banda é ilimitada em todos os planos — então programe pensando em consistência, não em cota, e confira o horário contra o seu próprio período de baixo movimento. Os hábitos mais amplos em torno disso tudo estão no guia de OpSec de servidor.

A versão resumida

Se você não fizer mais nada com esta página, faça estas seis coisas, mais ou menos nesta ordem:

• Coloque uma cópia num segundo provedor, numa segunda jurisdição, paga da mesma forma privada que a primeira.
• Torne essa cópia append-only, ou puxe-a a partir do destino, para que um servidor comprometido não consiga destruí-la.
• Deixe a ferramenta criptografar na origem, e mantenha a chave fora das duas máquinas envolvidas.
• Dê dump nos bancos de dados e pare ou tire snapshot de tudo que estiver rodando; nunca copie o estado ao vivo diretamente.
• Faça backup das chaves de identidade separadamente — onion, WireGuard, DKIM, seeds de node — porque essas não podem ser regeneradas.
• Restaure num servidor descartável uma vez, cronometre, e anote o que estava faltando.

Nada disso é exótico, e nada disso toma um fim de semana. É uma tarde de configuração e um teste, contra uma categoria de perda que encerra projetos. Numa plataforma que deliberadamente não guarda nada sobre você, a cópia que você mesmo fez é a única que existe — que é o custo do arranjo, e um custo justo. Suba um segundo servidor numa jurisdição que não seja a sua primeira, e dê ao backup de hoje à noite um lugar para pousar.