Backup e restauração de VPS: criptografado, remoto e realmente testado

Snapshots não são backups — e você quer os dois

Um snapshot é uma cópia pontual de um volume que vive na mesma malha de armazenamento que o volume copiado. Isso não é uma crítica, é uma descrição, e explica precisamente no que um snapshot é excelente e o que ele não consegue fazer. Todo plano aqui inclui snapshots por hora com sete dias de retenção, restaurar um leva cerca de trinta segundos, e eles são a resposta correta para o incidente mais comum de todos em operações de servidor: você editou um arquivo de configuração às quatro da tarde e o serviço não inicia mais desde então. Para esse tipo de falha, nada mais chega perto — é mais rápido que qualquer ferramenta de backup, já está em execução, e não custa nada a mais.

O que um snapshot não consegue fazer é sobreviver àquilo em que está armazenado. Ele compartilha o destino do volume, do host, do hipervisor e, na maioria dos projetos, da conta. Se a máquina é apreendida, se a conta é encerrada, se o datacenter tem um dia muito ruim, os snapshots vão junto — eles são uma cópia dos dados, não uma cópia independente. Essa distinção não é acadêmica em um provedor que deliberadamente não consegue identificá-lo: não há caminho de suporte que reconstrua seu servidor a partir dos registros de outra pessoa, nenhum fluxo de recuperação vinculado a um número de telefone, e nenhum histórico de cobrança com seu nome legal associado. O que você tirou é o que você tem.

Uma janela de sete dias também não ajuda com os dois tipos de falha lenta. O arquivo que você excluiu cinco semanas atrás já sumiu de todo snapshot bem antes de você perceber. A corrupção silenciosa — uma aplicação com defeito gravando dados sutilmente errados, uma migração malfeita, um cliente de sincronização propagando fielmente um erro — costuma ser descoberta um mês depois, momento em que toda cópia retida já contém a corrupção. Backups com retenção mais longa e um histórico genuíno são o que cobre esses casos, e cobrem exatamente porque não são espelhos contínuos do estado atual.

O modelo que vale a pena internalizar aqui é antigo e continua correto. A regra 3-2-1 pede três cópias dos dados, em dois tipos diferentes de armazenamento, com uma delas remota. O adendo moderno acrescenta mais dois dígitos — 3-2-1-1-0 — em que o um extra é uma cópia imutável ou offline, e o zero é o número de erros na sua última verificação. Os dígitos são um mnemônico, não um padrão, mas codificam as três propriedades que realmente importam: independência, imutabilidade e evidência de que a coisa funciona. Snapshots por hora te dão uma das três.

Leia essa tabela como um argumento a favor de rodar os dois em vez de escolher entre eles. Snapshots cuidam de frequência e velocidade; backups cuidam de independência e histórico. Eles custam coisas diferentes, falham de formas distintas, e a combinação é muito mais forte do que qualquer um dos dois em dobro.

Os dois números que decidem tudo o resto

Antes de instalar qualquer ferramenta, anote dois números. O objetivo de ponto de recuperação (RPO) é quanto dado você pode se dar ao luxo de perder, medido em tempo — se a última cópia utilizável tem seis horas, seu RPO é de seis horas e as seis horas de trabalho no meio se foram. O objetivo de tempo de recuperação (RTO) é quanto tempo você pode se dar ao luxo de ficar indisponível enquanto reconstrói. Tudo o que vem depois — cronograma, método, onde fica a segunda cópia, quanto você gasta — decorre desses dois números, e escolher a ferramenta antes de escolher esses números é como as pessoas acabam com uma resposta elaborada para uma pergunta que ninguém fez.

Perguntado de forma casual, a maioria das pessoas diz zero e zero. Isso não é um orçamento, é um desejo, e tem um preço embutido que vale a pena declarar sem rodeios: um RPO perto de zero significa replicação contínua em vez de cópias programadas, e um RTO perto de zero significa uma segunda máquina em standby, já em execução. Os dois são viáveis de construir, e os dois praticamente dobram o custo operacional daquilo que você está protegendo. Para a grande maioria das cargas de trabalho auto-hospedadas, as respostas honestas ficam entre uma hora e um dia para o ponto de recuperação, e algumas horas para o tempo de recuperação, o que é atendido confortavelmente por um backup criptografado programado e uma reconstrução documentada.

Os números também variam por conjunto de dados na mesma máquina, e é esse detalhe que os torna úteis. O e-mail é o exemplo mais nítido: uma mensagem que chegou vinte minutos atrás não existe em nenhum outro lugar, não pode ser regenerada, e quem a enviou não faz ideia de que precisa reenviá-la — então um servidor de e-mail quer um ponto de recuperação medido em minutos, mesmo que o software em si se reinstale em uma tarde. Um nó Bitcoin inverte isso completamente: os dados da blockchain são várias centenas de gigabytes que qualquer peer da rede terá prazer em reenviar, então fazer backup deles é, em grande parte, desperdício de disco, enquanto o arquivo da carteira ao lado deles é irrecuperável e vale a pena proteger como uma chave privada, porque é exatamente isso que é.

Essa última linha merece ser dita em voz alta, porque um guia sobre backups tem um incentivo óbvio para não dizê-la. Algumas máquinas não precisam de um. Um agente de build cujo estado inteiro vem de um repositório git, um sandbox descartável, um proxy reverso sem estado cuja configuração vive em controle de versão — para esses, os snapshots por hora incluídos no plano são uma resposta completa e defensável, e a quantidade correta de engenharia de backup é nenhuma. Saber quais dos seus servidores estão nessa categoria vale mais do que fazer backup malfeito de todos eles.

O que copiar — e a pilha bem maior que você deve deixar de fora

O instinto é fazer uma imagem do disco inteiro, e em uma máquina virtual alugada esse instinto está errado. O sistema operacional é descartável: aqui, uma instância nova é provisionada em uma mediana de quarenta e um segundos, e reinstalar pacotes a partir de um mirror de distribuição é mais rápido e mais confiável do que restaurá-los a partir da sua própria cópia. O que não é descartável é um conjunto surpreendentemente pequeno, e a disciplina de nomear esse conjunto explicitamente é a maior parte do trabalho — um backup que você consegue descrever em um parágrafo é um backup que você consegue verificar, enquanto uma imagem de disco inteiro é algo que você só pode torcer para que funcione.

O conjunto insubstituível costuma ter quatro partes. Primeiro, os dados da aplicação: o maildir, o diretório de dados, o repositório de mídia, a pasta de uploads. Segundo, os bancos de dados, que precisam de um tratamento próprio e ganham a próxima seção. Terceiro, os segredos — e essa é a categoria que as pessoas esquecem até que ela saia caro. As chaves privadas TLS e a chave da conta ACME, as chaves de host SSH, caso você prefira não reconfiar na fingerprint em cada cliente, a chave de assinatura DKIM sem a qual seu e-mail começa a falhar na autenticação, as chaves privadas WireGuard, e acima de tudo a chave privada do serviço onion, que é o endereço .onion: perca-a e o endereço se vai permanentemente, sem nenhum registro em lugar nenhum a quem recorrer. Quarto, o punhado de arquivos em /etc que você de fato alterou, além das unidades do systemd, entradas do cron e do conjunto de regras de firewall que fazem a máquina se comportar do jeito que se comporta.

A pilha a deixar de fora é bem maior e, uma vez dita, quase óbvia. Pseudo-sistemas de arquivos como /proc, /sys e /dev são visões do kernel, não dados. Caches de pacotes, imagens de container, ambientes virtuais e diretórios de dependências são todos rederiváveis a partir de um lockfile em segundos. Logs além da sua política de retenção são ruído que deduplica mal e infla cada execução seguinte. E grandes conjuntos de dados ressincronizáveis — estado de blockchain, um mirror público, uma biblioteca de mídia que você pode re-ripar — merecem uma decisão explícita em vez de um padrão: fazer backup de trezentos gigabytes de dados de blockchain custa dinheiro de verdade todo mês para evitar uma re-sincronização que você poderia rodar de graça enquanto o serviço fica degradado mas funcional.

A parte em que quase todo mundo subinveste é a resposta para "restaurar em quê?". Dados sem um destino não são uma recuperação. Se o jeito como seu servidor foi construído existe só na sua memória e em um histórico de shell que você já perdeu, seu tempo de recuperação é ilimitado, não importa quão bom seja o repositório. A correção é barata e sem graça: mantenha os passos de provisionamento como um script ou um runbook em texto simples, coloque-o dentro do repositório de backup para que seja restaurado junto com os dados, e atualize-o sempre que você mudar a máquina. Até cem linhas de notas — pacotes, versões, locais dos arquivos de configuração, registros DNS, a ordem em que os serviços precisam iniciar — transformam uma semana ruim em uma tarde ruim.

Uma nuance que vale a pena destacar para quem usa criptografia de disco inteiro: o cabeçalho LUKS e seus slots de chave também fazem parte do seu conjunto insubstituível. Um cabeçalho corrompido transforma um disco perfeitamente intacto em ruído aleatório, o cabeçalho tem apenas alguns megabytes, e fazer backup dele não custa nada. Guarde-o com o mesmo cuidado que a frase secreta — quem tiver os dois, tem o disco.

Bancos de dados: o arquivo que você copia não é o banco de dados

Esta é, de longe, a forma mais comum de um backup que, fora isso, é competente, acabar sendo inútil. Um motor de banco de dados mantém estado em memória, em um log de write-ahead ou redo, e em arquivos de dados que estão sendo modificados continuamente. Copiar esses arquivos enquanto o motor está em execução os captura em instantes diferentes — a página quatro de uma tabela de antes de uma transação, a página cinco de depois — e o resultado é um conjunto de arquivos que são individualmente íntegros e coletivamente inconsistentes. A parte cruel é que essa cópia geralmente restaura. Ela sobe, responde a consultas, e o dano só aparece semanas depois, como um índice corrompido ou uma linha que viola uma restrição que o motor jura que impõe. Um backup que falha ruidosamente é muito melhor do que um que falha silenciosamente.

A abordagem correta depende do motor e está bem documentada em cada caso. Para MariaDB e MySQL, um dump lógico feito dentro de uma única transação consistente é adequado para qualquer coisa até algumas dezenas de gigabytes; além disso, o Mariabackup realiza uma cópia física a quente enquanto o servidor roda. Para PostgreSQL, o pg_dump te dá um snapshot lógico portátil, e o pg_basebackup combinado com write-ahead logs arquivados te dá recuperação pontual no tempo — a capacidade de restaurar para as 14:32 em vez de para o momento em que o último dump aconteceu de rodar. Para SQLite, use o backup online embutido ou o VACUUM INTO; usar cp em um arquivo de banco de dados ativo é exatamente o erro descrito acima, e o SQLite é o motor em que as pessoas cometem esse erro com mais frequência, porque parece um arquivo comum.

A consistência entre o banco de dados e os arquivos que ele descreve é a segunda metade do problema, e é a metade que morde especificamente softwares de sincronização de arquivos e fóruns. O banco de dados diz que um arquivo existe em um caminho; o sistema de arquivos é onde os bytes vivem; se você faz o dump do banco às 02:00 e copia o diretório de dados às 02:40, tudo o que foi criado nesse meio-tempo existe como bytes sem linha correspondente, ou como linha sem bytes correspondentes. Aplicações que oferecem um modo de manutenção — o Nextcloud é o exemplo óbvio — resolvem isso recusando gravações brevemente enquanto os dois são capturados. Onde isso é inaceitável, um snapshot de sistema de arquivos ou de volume tirado em um único instante te dá um par consistente para copiar com calma, o que é o mesmo truque que os snapshots por hora usam.

Um pequeno detalhe operacional se paga imediatamente: grave os dumps sem compressão e deixe a ferramenta de backup cuidar da compressão. Tanto o restic quanto o borg deduplicam por chunking definido por conteúdo, então dois dumps feitos com um dia de diferença compartilham a esmagadora maioria dos seus chunks, e o segundo custa quase nada para armazenar. Comprima o dump primeiro, e um único byte alterado perto do início se propaga em cascata por todo o fluxo comprimido, nenhum chunk bate com nada, e cada execução armazena uma cópia completa. É comum encontrar equipes cujo repositório cresce o tamanho total do banco de dados a cada dia, exatamente por esse motivo — a correção é apagar um pipe de um shell script.

Por fim, decida deliberadamente se você precisa de recuperação pontual no tempo, porque essa é a resposta para uma falha que o dump diário não consegue resolver. Se alguém roda uma query destrutiva às 14:32 e você descobre isso às 17:00, restaurar o dump da noite anterior perde um dia inteiro de trabalho. O arquivamento contínuo, em vez disso, reproduz o log até as 14:31. Isso custa mais armazenamento e bem mais complexidade operacional, então não é um padrão — mas para qualquer coisa em que um humano com acesso de escrita possa destruir dados mais rápido do que você consegue perceber, é a diferença entre um incidente e uma catástrofe.

Criptografe antes que saia: restic, borg, e a chave que você não pode perder

A propriedade que torna tudo o mais neste guia possível é a criptografia do lado do cliente: os dados são criptografados na máquina que os produziu, antes que um único byte atravesse a rede, usando uma chave que o destino nunca vê. Essa única decisão de projeto transforma o destino do backup em armazenamento não confiável, e armazenamento não confiável pode viver em qualquer lugar — um servidor barato em outro país, um armazenamento de objetos, o NAS de um amigo — sem que nenhum deles esteja em posição de ler seus dados. Provedores que criptografam do lado do servidor estão te protegendo de um conjunto de ameaças diferente e muito mais estreito, e essa diferença importa mais exatamente nas situações para as quais você está comprando hospedagem offshore para sobreviver.

Restic e Borg fazem isso corretamente, e a escolha entre os dois é genuinamente difícil. O Restic é um único binário estático sem dependências, fala nativamente uma longa lista de backends — SFTP, armazenamento de objetos compatível com S3, caminhos locais simples — e é o mais fácil dos dois de rodar a partir de um container ou de uma imagem mínima. O Borg é a ferramenta mais antiga e, em alguns aspectos, mais cirúrgica, com opções de compressão mais fortes, excelente suporte a append-only do lado do servidor, e um formato de repositório que muita gente considera mais fácil de entender; ele exige o borg instalado nas duas pontas ao passar por SSH, o que é uma pequena restrição que às vezes decide a questão.

Seja qual for a sua escolha, a frase secreta agora é o que realmente importa, e ela merece ser tratada como você trataria a seed de uma carteira. Ela não pode viver apenas na máquina que protege — uma frase secreta guardada ao lado dos dados que ela criptografa não protege você de absolutamente nada, porque todo cenário que toma o servidor leva a chave junto. Guarde-a em um gerenciador de senhas em outro dispositivo, ou em papel em outro prédio, e idealmente em ambos. O Borg permite exportar a chave do repositório para um arquivo separado, o restic permite que um repositório carregue várias chaves independentes, e qualquer um dos dois mecanismos oferece uma segunda forma de acesso que não depende de lembrar uma string. Não existe recuperação, link de redefinição ou chamado de suporte que reverta isso: um repositório criptografado sem a sua chave é indistinguível de dados aleatórios, e esse é exatamente o ponto.

Vale a pena ser explícito sobre por que o simples rsync para outro servidor não é um substituto, já que é a primeira coisa que as pessoas tentam. O rsync produz um espelho, e um espelho não tem histórico: exclua um arquivo hoje e a execução desta noite o excluirá fielmente lá também. Ele não tem deduplicação, então manter trinta dias significa trinta cópias, a menos que você se vire com hard links. Ele não tem criptografia em repouso embutida, então o destino lê tudo. E ele não tem nenhuma forma de verificação além de reler a origem. É um excelente transporte e um backup ruim, e a diferença aparece no dia em que você precisa da versão de três semanas atrás.

Append-only, ou é uma cópia em vez de um backup

Eis o cenário que decide a arquitetura. Alguém consegue root no seu servidor — via uma aplicação sem patch, um token vazado, uma dependência que se tornou hostil. Essa pessoa agora está dentro de uma máquina que guarda credenciais válidas para o seu próprio destino de backup, porque é assim que os backups agendados funcionam. Tudo que essa máquina pode excluir, essa pessoa pode excluir, e excluir os backups não é uma reflexão tardia em uma invasão moderna, é o passo um. O mesmo se aplica sem um adversário: um script bem-intencionado com uma variável errada, rodando como root, é perfeitamente capaz de podar um repositório até não sobrar nada.

O controle que fecha essa brecha é a imposição de append-only do lado que recebe. Configurado dessa forma, o cliente pode criar novos snapshots e não pode remover ou reescrever os antigos — a restrição é imposta pelo processo no host de backup, não pela boa vontade do cliente. O Borg implementa isso com borg serve --append-only, fixado à chave no authorized_keys do destino, de modo que o cliente não possa pedir mais nada. O Restic tem a mesma estrutura via rest-server com --append-only. No armazenamento de objetos, o equivalente é versionamento somado a uma política de retenção com object lock, que alcança o mesmo resultado por um mecanismo diferente.

A configuração de SSH responsável por isso merece ser feita com exatidão, porque é a linha que sustenta tudo. No authorized_keys do usuário de backup, prefixe a chave do cliente com um comando forçado e as restrições que o manual do sshd documenta: command="borg serve --append-only --restrict-to-path /srv/backups/web01",restrict. Essa única linha significa que uma chave roubada do cliente não consegue abrir um shell, não consegue encaminhar uma porta, não consegue tocar no repositório de outro host, e não consegue excluir nada. Dê a cada cliente sua própria chave e seu próprio caminho.

O que levanta a pergunta óbvia: se o cliente nunca pode excluir, o que remove os snapshots antigos? A poda acontece em outro lugar, em um cronograma, com uma credencial que a máquina protegida nunca teve. Na prática, isso significa que o host de backup poda seus próprios repositórios a partir de um cron local, ou uma terceira máquina pequena guarda a chave privilegiada e executa a retenção semanalmente. O Borg tem uma peculiaridade conhecida aqui — um repositório append-only precisa ter sua compactação executada do lado do servidor, e não pelo cliente — e tratar o host de backup como o dono da retenção resolve isso de forma limpa. O princípio se generaliza: a máquina que grava os backups nunca deve ser a máquina que pode destruí-los.

A retenção em si é uma questão de política com uma resposta convencional que funciona: manter os últimos vários diários, quatro ou cinco semanais, e de seis a doze mensais. As duas ferramentas expressam isso declarativamente, então você declara o formato que quer e deixa a ferramenta decidir quais snapshots o satisfazem. Os mensais são o que capturam a corrupção lenta, e também são os primeiros que as pessoas cortam quando o repositório cresce — o que é exatamente ao contrário, já que um mensal comprimido e deduplicado de um conjunto de dados que quase não muda custa quase nada.

Para onde vai a segunda cópia quando ninguém pode identificar você

O off-site carrega grande parte do peso na regra 3-2-1, e em um provedor sem KYC significa algo mais específico do que "outro prédio". Significa uma cópia cuja sobrevivência não depende da mesma empresa, da mesma conta, da mesma relação de pagamento ou da mesma jurisdição legal que o original. Dois servidores em uma conta são dois servidores com um único destino, por mais distantes que estejam os datacenters: uma conta encerrada por qualquer motivo leva os dois junto, e um instrumento legal notificado a uma entidade alcança tudo o que essa entidade possui. Independência é uma propriedade da relação, não apenas da geografia.

A versão prática disso é mais fácil do que parece, porque o mesmo painel já oferece quatro jurisdições. Uma instância de produção na Holanda com o repositório enviado para um plano Starter na Islândia custa $8.50 por mês e coloca sua recuperação fora do alcance de qualquer processo nacional isolado — e, como as jurisdições diferem no que realmente resistem, o pareamento merece um momento de reflexão, e não um cara ou coroa. Como o repositório é criptografado antes de sair da origem, o host de backup não é confiável por design: o que você está comprando com a segunda localização é disponibilidade e distância legal, não confidencialidade. Confidencialidade você já tem.

Para uma terceira cópia genuinamente independente, a arquitetura mais forte inverte o sentido da conexão. Em vez de o servidor enviar para um destino cujas credenciais ele guarda, uma máquina que você controla — uma caixa em casa, um NAS, um notebook que acorda em um horário programado — puxa a partir do servidor. A máquina de produção então não guarda nenhuma credencial para nenhum destino de backup, o que torna o cenário de comprometimento da seção anterior estruturalmente impossível, e não apenas mitigado. Isso custa a você uma máquina que precisa estar acessível ou acordada no horário programado, e é por isso que ela complementa uma cópia off-site enviada, em vez de substituí-la.

Duas restrições específicas desse tipo de hospedagem merecem ser ditas sem enfeites. Não existe recuperação de conta: nenhum documento de identidade para apresentar, nenhum número de telefone para receber um código, nenhum atendente que possa confirmar que você é você. Essa é a mesma propriedade pela qual você paga no cadastro, e ela se aplica simetricamente — o que torna a frase secreta e o runbook estruturais, de um jeito que simplesmente não são em um provedor convencional. E se o destino do backup precisa ser pago, ele precisa ser pago de forma anônima também, ou a segunda cópia reintroduz discretamente o vínculo de identidade que a primeira foi projetada para evitar. Pagar pelas duas máquinas com a mesma carteira de criptomoedas é tranquilo; pagar o backup com cartão é uma decisão, não um descuido.

O simulado, e como você descobre que ele parou de funcionar

Jobs de backup normalmente não falham de forma dramática. Eles falham aos poucos: um padrão de exclusão ampliado durante uma limpeza, uma credencial rotacionada apenas de um lado, um disco enchendo no destino, uma entrada de cron perdida em uma atualização de distribuição. Em todos esses casos, a máquina continua rodando, nada dispara um alerta, e o repositório silenciosamente para de crescer. O design que detecta isso não é "alertar em caso de falha" — um job que não roda mais não pode reportar sua própria falha — mas sim alertar na ausência de sucesso. Faça cada execução bem-sucedida enviar um ping para um endpoint de dead-man's-switch, e faça esse endpoint disparar um alarme quando o ping não chegar no horário. São dez minutos de configuração, e é a diferença entre perceber em um dia e perceber durante uma restauração.

A verificação de integridade é a segunda metade. As duas ferramentas conseguem verificar se os metadados do repositório são coerentes, e, de forma mais útil, se os chunks armazenados realmente descriptografam e correspondem aos seus hashes. Ler tudo é caro em banda, então as duas oferecem uma forma parcial — o restic verifica uma porcentagem dos dados a cada execução, o borg verifica dados sob demanda — e uma cadência sensata é uma verificação completa de metadados semanal e uma verificação parcial de dados mensal, dimensionadas para que uma passagem completa aconteça ao longo de um trimestre. Armazenamento sofre degradação, e o objetivo de verificar é descobrir isso enquanto você ainda tem outra cópia.

Nada disso é prova de que você consegue restaurar. Essa prova tem exatamente uma fonte, que é restaurar de fato. Implante uma instância nova — o menor plano custa $8.50 e você vai destruí-la dentro de uma hora — restaure o repositório nela, e então faça a parte que as pessoas pulam: inicie a aplicação e olhe para dados reais. Faça login. Abra um documento do mês passado. Envie uma mensagem de teste pelo servidor de e-mail. Consulte uma tabela que deveria ter as linhas de ontem. Os arquivos existirem não é o teste; o serviço funcionar em cima deles é. Faça isso na primeira vez que configurar o backup, e depois em um intervalo no calendário que você realmente cumpra, porque o simulado também valida o runbook, e o runbook decai mais rápido do que os dados.

O runbook merece seu próprio parágrafo porque é o item mais barato aqui e o que mais costuma faltar. Anote, em ordem: onde o repositório vive e como alcançá-lo, onde a frase secreta é guardada, como provisionar uma máquina substituta, quais pacotes e versões instalar, o que restaurar e em que ordem, quais registros de DNS alterar, e como confirmar que funcionou. Mantenha-o fora da máquina que ele descreve — no próprio repositório, em um gerenciador de senhas, no papel — e presuma que a pessoa que vai lê-lo está cansada, trabalhando em um horário desagradável, e possivelmente não é você. Essa última suposição é o que transforma um conjunto de anotações em algo que um colega ou um familiar consegue executar.

Reunido, o design inteiro é nada extraordinário, e essa é a sua virtude: os snapshots horários que seu plano já inclui para os acidentes dos últimos dias, um repositório criptografado enviado toda noite para uma segunda jurisdição onde não pode ser excluído, uma frase secreta em algum lugar que o servidor nunca viu, um ping que reclama quando o job fica quieto, e um ensaio marcado no calendário. Nada nessa lista é difícil, a maior parte é trabalho de uma tarde, e o conjunto todo custa por mês menos do que o café que você compraria enquanto reconstrói tudo do zero. Se você está montando isso agora, a segunda máquina leva cerca de um minuto para ser provisionada — comece pela restauração que você nunca testou, porque é a única parte disso que te diz a verdade.