Backup de uma VPS em armazenamento offshore criptografado

Quase ninguém configura backups no dia em que implanta um servidor. Isso acontece depois — depois que um disco enche durante um upgrade, depois de uma exclusão no diretório errado, depois que uma migração deixa um banco de dados que inicia limpo e responde errado, depois que alguém invade. O intervalo entre rodar uma máquina que importa e guardar uma cópia que sobrevive a ela é a janela mais perigosa da auto-hospedagem, e a maioria das pessoas vive nela por meses sem perceber, porque nada dá errado por muito tempo — até que tudo dá errado de uma vez. Fechar essa janela não é difícil nem caro. O que faz parecer difícil é que a palavra "backup" é usada para quatro coisas diferentes, e só uma delas vai continuar lá no dia ruim.

As quatro coisas que não são um backup

Cada uma dessas coisas é genuinamente útil e vale a pena ter. Nenhuma delas é um backup, e acreditar o contrário é o motivo mais comum de as pessoas perderem dados que achavam estar seguros. A distinção não é picuinha — cada uma delas falha exatamente na situação em que você mais precisa de um backup.

• RAID é uptime, não um backup. Um array sobrevive a um disco morto sem sair do ar, e é por isso que os nossos servidores de armazenamento rodam em RAID-6 e toleram duas falhas ao mesmo tempo. Ele não sobrevive a um diretório apagado, um upgrade malsucedido, uma árvore de arquivos criptografada por outra pessoa ou uma tabela derrubada — cada uma dessas coisas é gravada fielmente em todos os discos no mesmo instante.
• Snapshots são um botão de desfazer, não um backup. Eles vivem no mesmo armazenamento que os dados, geralmente são visíveis para o root na mesma máquina, e qualquer coisa que destrua o volume ou o host leva os snapshots junto. Rápidos para reverter, inúteis quando a máquina se foi.
• Sincronização é replicação, não um backup. Uma ferramenta de sincronização existe para fazer o lado remoto igualar o lado local, então uma exclusão ou uma corrupção é propagada para a cópia tão rápido quanto a rede permitir. O Nextcloud, o Dropbox e o rclone sync se comportam assim por design.
• Histórico de versões e lixeiras são conveniência, não um backup. São recursos da própria aplicação, guardados no banco de dados da aplicação, com uma janela de retenção medida em dias. Quando é a aplicação que quebra, o próprio histórico dela vai junto.
• Uma cópia no mesmo servidor não conta como fora do local. Se a falha for a máquina, a conta do provedor, o hypervisor ou uma apreensão, todo arquivo nessa máquina está no mesmo domínio de falha, não importa em qual diretório ele esteja.

Um backup é uma cópia separada no espaço, separada no tempo e separada no controle. Separada no espaço para que um incêndio ou uma apreensão não leve as duas. Separada no tempo para que você possa voltar a antes do dano, em vez de a uma cópia fiel dele. Separada no controle para que credenciais roubadas da máquina em produção não consigam alcançá-la. Qualquer coisa que não tenha uma dessas três características é um recurso de conveniência fantasiado de backup.

A regra 3-2-1, e a versão que sobrevive a 2026

A regra antiga é três cópias dos dados, em dois tipos diferentes de armazenamento, com uma delas fora do local. Ela envelheceu bem porque, no fundo, é uma regra sobre falhas não correlacionadas, não sobre fitas magnéticas. Duas adições conquistaram o seu lugar desde então, e ambas existem por causa de coisas que não costumavam acontecer quando a regra foi escrita.

• Três cópias. Os dados em produção, mais outras duas. Duas cópias significam estar a uma falha de distância de um ponto único de falha, e pontos únicos de falha têm o hábito de falhar bem quando você ainda pretendia consertar o primeiro problema.
• Dois tipos de armazenamento. Hardware diferente, software diferente, idealmente um provedor diferente. Dois volumes no mesmo host compartilham um hypervisor, um painel de controle e uma conta — o que significa que compartilham também as formas de perder essa conta.
• Uma cópia fora do local. Fisicamente em outro lugar, em uma infraestrutura que não cai quando a sua cai. É essa cópia que importa em caso de incêndio, roubo, apreensão e uma conta fechada sem aviso.
• Uma cópia imutável ou offline. Tanto ransomware quanto um root comprometido procuram os backups primeiro, e um destino no qual o seu servidor consegue escrever é um destino que o seu servidor consegue apagar. Credenciais somente-acréscimo — que só permitem adicionar dados, nunca apagá-los — ou um design baseado em pull transformam isso de uma catástrofe em um incômodo.
• Zero restaurações não verificadas. Um backup que você nunca restaurou é uma hipótese. Essa é a adição que as pessoas mais pulam e mais lamentam ter pulado, porque uma tarefa de backup que reportou sucesso por dois anos pode ter passado esses dois anos gravando arquivos inutilizáveis.

O que incluir no backup: o estado, não a máquina inteira

O instinto é gerar uma imagem do servidor inteiro. Geralmente é o formato errado: backups de imagem são grandes, lentos, incômodos de restaurar seletivamente, e a maior parte do que contêm é um sistema operacional padrão que você reinstala em um minuto. O que você não consegue regenerar é o estado — as coisas que existem só por causa do que você fez.

• Bancos de dados, exportados via dump, não copiados diretamente. Um arquivo de banco de dados em produção copiado enquanto o motor está escrevendo é um arquivo corrompido que pode restaurar, pode restaurar errado, e não vai te dizer qual dos dois. Use a própria ferramenta de dump do motor, ou pare o serviço, ou tire um snapshot do sistema de arquivos e faça o dump a partir dele.
• Diretórios de dados da aplicação. Arquivos enviados, mídia, assets gerados — a árvore de arquivos para a qual o banco de dados aponta. Ela precisa ser capturada no mesmo instante que o seu banco de dados, ou você restaura um índice descrevendo arquivos que não estão lá.
• Configuração e as coisas que você editou manualmente. Configuração do servidor web e do proxy reverso, units do systemd, entradas de cron, regras de firewall, os vinte pequenos ajustes que você fez às duas da manhã e não vai lembrar depois.
• Segredos e chaves, tratados separadamente e com mais cuidado. Certificados TLS e suas chaves privadas, chaves de host SSH, tokens de API e, acima de tudo, arquivos de carteira e seeds. Eles merecem a própria cópia criptografada, que não fique só em uma máquina alugada.
• Definições de containers e volumes. Os arquivos compose e os arquivos de ambiente, além dos volumes nomeados — a parte que as pessoas esquecem, porque os containers em si são recriados trivialmente e os volumes deles não.
• A lista do que está instalado, não a instalação em si. Um inventário curto de pacotes, versões e o que roda onde restaura mais rápido e ocupa menos espaço do que uma imagem do sistema de arquivos raiz inteiro.

A linha divisória é simples: se você consegue regenerar algo a partir de um script ou de um gerenciador de pacotes em dez minutos, não faça backup disso — anote como fazer. Se algo existe só por causa de alguma coisa que você ou um usuário fez, isso precisa de uma cópia. Esse princípio vale desde um site pequeno, passando por uma instância do BTCPay, onde a carteira e o banco de dados são tudo e o resto é reinstalável, até um servidor Nextcloud, onde a árvore de arquivos e o banco de dados precisam ser capturados juntos, ou nenhum dos dois vale muita coisa.

Dimensionando o destino, e quanto isso realmente custa

As pessoas erram feio nessa conta, geralmente precificando a primeira cópia completa e multiplicando pelo número de dias que pretendem manter os backups. Uma ferramenta de backup moderna não funciona assim. Ela divide os dados em blocos, guarda cada bloco único uma única vez, e comprime o que dá para comprimir — então o segundo snapshot de um servidor que mudou pouco custa quase nada, e trinta snapshots diários ficam longe, muito longe, de custar trinta vezes o primeiro.

• Orce aproximadamente o tamanho do seu estado em produção, mais trinta a cinquenta por cento para o histórico, para uma política de retenção típica em um servidor que muda em um ritmo normal.
• A retenção pesa muito mais no crescimento do que a frequência. Snapshots de hora em hora guardados por dois dias saem mais baratos do que snapshots diários guardados por três anos. Decida até onde no passado você realmente iria, e depois configure a poda automática até esse ponto.
• Dados já comprimidos não comprimem de novo. Vídeo, fotos, arquivos compactados e blobs criptografados terminam perto do tamanho original, então um servidor cheio de mídia precisa de capacidade de verdade, não de configurações espertas.
• Bancos de dados deduplicam mal entre dumps, porque um dump compactado de um banco de dados ligeiramente diferente é um fluxo de bytes completamente diferente. Faça o dump sem compactação e deixe a ferramenta de backup cuidar da compressão, e o seu custo de armazenamento cai bastante.
• O primeiro envio é a única parte lenta. Depois disso, uma execução noturna move só o delta, que na maioria dos servidores é coisa de megabytes. A transferência aqui não tem limite, então o primeiro envio é uma questão de paciência, não de orçamento.

Na prática, esse é o seguro mais barato de toda a sua stack. Um servidor de armazenamento começa em $7.99/mo por 1 TB em RAID-6, o que já é bem mais do que o estado de um punhado de instâncias VPS vai ocupar, e o STO-2 a $12.99/mo dobra isso. Bibliotecas de mídia e retenção longa são onde a capacidade realmente importa: o STO-4 a $22.99/mo te dá 4 TB, o STO-8 a $39.99/mo te dá 8 TB. O destino fala rsync, SFTP e uma API compatível com S3, então qualquer ferramenta de backup relevante conversa com ele sem precisar de plugin, e os volumes são criptografados em repouso com AES-256, com suporte a chaves próprias — embora, como a próxima seção argumenta, você já deveria criptografar antes de os dados saírem da origem de qualquer forma.

Escolhendo uma ferramenta, e para que cada uma realmente serve

Não há necessidade de sofrer com essa escolha. Três ferramentas cobrem essencialmente todos os casos, todas são gratuitas, e a diferença entre elas importa menos do que a diferença entre ter uma e não ter nenhuma. Escolha pelo formato do seu problema, não por benchmark.

• restic — a recomendação padrão para a maioria dos servidores. Criptografado no lado do cliente, deduplicador, um único binário estático sem daemon, e escreve nativamente em SFTP, endpoints compatíveis com S3 e diretórios simples. O modo somente-acréscimo dele é o caminho mais fácil para um destino que um servidor comprometido não consegue apagar.
• BorgBackup — deduplicação e compressão excelentes, muito eficiente em links lentos, maduro e testado à exaustão. Ele quer o próprio agente disponível no destino para repositórios remotos, uma pequena restrição em troca de ser visivelmente mais leve no armazenamento.
• rclone — a ferramenta certa quando o trabalho é essencialmente mover dados entre object stores, ou quando você quer um espelho em vez de um histórico versionado. Combine-o com a própria camada crypt dele se for usá-lo diretamente, e lembre-se de que uma sincronização simples propaga exclusões.
• Ferramentas de dump nativas, sempre, para bancos de dados. O mysqldump, o pg_dump e seus equivalentes produzem uma cópia lógica consistente que o motor com certeza consegue ler de volta. Faça o dump para um arquivo, e depois deixe o restic ou o Borg pegarem esse arquivo — não tente substituir o dump por uma cópia esperta no nível de arquivo.
• Snapshots do provedor só como uma camada local rápida. Tire-os para reverter rapidamente em torno de upgrades arriscados, e nunca os conte como uma das suas três cópias.

Passo a passo: um backup criptografado funcionando em uma única sessão

1. 01Implante o destino e blinde-oUm servidor de armazenamento em uma região diferente da dos servidores que ele protege. SSH só por chave, o próprio usuário, e nenhuma credencial reaproveitada das máquinas que vão escrever nele.
2. 02Decida a lista do que precisa sobreviver antes de tocar em qualquer ferramentaAnote cada caminho e cada banco de dados que precisa sobreviver. Dez minutos com um arquivo de texto agora evitam a restauração em que você descobre o único diretório que ninguém listou.
3. 03Inicialize um repositório criptografadoGere uma senha forte para o repositório, inicialize-o via SFTP ou S3, e guarde essa senha em algum lugar que não seja o servidor sendo protegido. Um repositório cuja chave existe só na máquina morta não é recuperável.
4. 04Faça o dump dos bancos de dados primeiro, e só depois arquiveUm script wrapper que faz o dump de cada banco de dados para um diretório temporário e depois roda uma única passada de backup sobre os dumps e a árvore de arquivos juntos. É essa ordem que mantém o banco de dados e os arquivos consistentes entre si.
5. 05Rode o primeiro backup e acompanhe até o fimA primeira passada é a demorada. Rode-a em um multiplexador de terminal para que uma conexão perdida não a mate, e anote quanto tempo levou — agora você também sabe a sua janela de restauração.
6. 06Defina a retenção e configure a poda automáticaAlgo como sete snapshots diários, quatro semanais e seis mensais atende à maioria dos servidores. Configure a poda na mesma tarefa, ou o repositório cresce até o dia em que para de funcionar.
7. 07Agende, depois faça a falha soar altoUm timer noturno ou uma entrada de cron, mais um alerta para quando a tarefa não reportar sucesso. Uma tarefa de backup silenciosa é indistinguível de nenhuma tarefa de backup, por quantos meses forem necessários até alguém notar.
8. 08Restaure algo hoje, a partir do backup, em uma máquina diferenteNão uma listagem do arquivo — uma restauração de verdade de um arquivo real e um banco de dados real em um servidor descartável. Até você ter feito isso uma vez, você tem um script de backup, não um backup.

Fazendo a cópia sobreviver ao que matou o servidor

Essa é a parte que separa um backup de um mero incômodo para um invasor. Se o servidor guarda credenciais capazes de apagar os backups, então um root comprometido, uma passagem de ransomware ou um script malfeito alcançam as duas cópias no mesmo minuto. A correção é estrutural, não uma questão de senhas mais fortes.

• Use, a partir da origem, credenciais somente-acréscimo. O restic e o Borg têm um modo em que a máquina que escreve consegue criar novos snapshots, mas não consegue apagar nem podar os existentes. A poda roda então a partir de outro lugar, em um cronograma, com uma chave separada.
• Prefira um design pull sempre que puder. Um destino que busca os dados na origem, em vez de uma origem que os empurra até o destino, significa que a origem nunca guarda credenciais para o arquivo.
• Nunca reaproveite chaves SSH ou senhas de repositório entre servidores. Uma máquina comprometida deveria custar os backups de uma máquina, não da frota inteira.
• Mantenha pelo menos uma cópia em uma jurisdição diferente e em um domínio de falha diferente. Diversidade de região não é paranoia — é a diferença entre um incidente de hardware e uma perda total.
• Guarde a chave do repositório totalmente fora da infraestrutura. Um gerenciador de senhas, um token de hardware, papel em um cofre. Qualquer lugar, menos as máquinas que o repositório protege.
• Fique de olho em backups que começam a ter sucesso rápido demais, de forma suspeita. Uma tarefa que costumava levar vinte minutos e agora leva quarenta segundos geralmente está fazendo backup de um diretório vazio ou desmontado, e vai continuar reportando sucesso enquanto faz isso.

A escolha da região é uma decisão de verdade aqui, não um detalhe, porque o seu backup e o seu servidor de produção não deveriam poder ser apreendidos na mesma ação. Se isso importa para o que você roda, escolher a localização de forma deliberada vale alguns minutos, e colocar o destino em um regime legal diferente do da origem é exatamente o ponto do exercício.

Restaurar: a parte que ninguém ensaia

Restaurações falham por motivos banais, e falham no pior momento possível porque essa é a única vez que a maioria das pessoas tenta uma. Cada falha abaixo é descoberta em minutos durante um simulado, e em horas durante uma queda de verdade.

• A senha do repositório só existia no servidor que morreu, então os arquivos estão intactos e permanentemente ilegíveis.
• O banco de dados restaurou, mas a árvore de arquivos veio de uma execução três horas depois, então a aplicação mostra registros cujos arquivos não existem.
• O backup capturava um diretório que tinha silenciosamente parado de ser montado, então ele arquivou fielmente uma pasta vazia todas as noites, por um ano.
• Ninguém sabia a ordem de restauração — banco de dados primeiro ou arquivos primeiro, serviço parado ou rodando — e o estado meio-restaurado teve que ser descartado, e tudo começou de novo.
• A restauração leva onze horas pelo link disponível, algo que ninguém tinha medido, e o plano de recuperação partia do princípio de uma hora.
• Dono e permissões dos arquivos voltaram errados, então está tudo presente e a aplicação se recusa a iniciar.
• Só o snapshot mais novo foi testado, e a corrupção que está sendo recuperada começou seis semanas atrás.

Um simulado duas vezes por ano resolve tudo isso. Implante uma VPS descartável, restaure nela a partir do repositório real, inicie o serviço, olhe os dados, destrua a máquina. Custa uns dois dólares e uma hora, e transforma o sistema de backup inteiro de uma crença em um fato. Faça isso uma vez com o runbook aberto, e corrija o runbook em cada ponto onde ele mentiu para você.

A camada de privacidade: um backup pode desfazer o seu anonimato

Esta parte é específica de rodar offshore, e só é fácil de acertar se você pensar nela antes do primeiro envio, não depois. Um backup é uma cópia completa, indexada e de vida longa da sua infraestrutura, sentada em outro lugar, o que a torna exatamente tão sensível quanto o original — e consideravelmente mais fácil de esquecer que existe.

• Nomes de arquivo e estrutura de diretórios são metadados, mesmo quando o conteúdo está criptografado. A criptografia do lado do cliente no restic e no Borg cobre os nomes também; um espelho rsync simples não cobre, e uma listagem de diretório costuma ser suficiente para identificar o que um servidor é e quem o administra.
• A conta do destino faz parte da história. Um cofre de backup alugado com um cartão no seu nome legal vincula esse nome a tudo o que o cofre guarda, não importa quão cuidadosamente a máquina de origem tenha sido mantida limpa.
• O tráfego de backup é uma ligação persistente, agendada e de alto volume entre dois endereços. É um dos padrões mais legíveis que um servidor produz, e ele aponta para o destino todas as noites, sem falta.
• Snapshots antigos sobrevivem às decisões que os criaram. Algo que você parou de guardar há um ano ainda está no arquivo se a retenção nunca o podou, o que é uma boa propriedade para recuperação e uma péssima para exposição.
• Logs e histórico do shell são varridos junto com tudo o mais. O arquivo frequentemente contém os endereços IP, comandos e credenciais com os quais você tomou cuidado na máquina em produção.

As correções são comuns. Use uma ferramenta que criptografe os nomes, não só o conteúdo. Alugue o destino do mesmo jeito que você alugou a origem — de uma hospedagem que nunca perguntou quem você é, paga a partir de um saldo em cripto, com uma recarga em Monero se você também quiser fechar o rastro do pagamento. Encaminhe a transferência por um túnel WireGuard se o padrão em si te incomodar. E aplique os mesmos primeiros dez minutos de blindagem na máquina de armazenamento que você aplicou na produção, porque uma máquina que guarda uma cópia de tudo não é um alvo de menor valor do que o original — é frequentemente um alvo maior.

Erros que custam os dados das pessoas

• Confiar no RAID, em snapshots ou em uma pasta sincronizada como se fossem o backup, e descobrir em qual categoria eles realmente estavam no dia em que isso importou.
• Manter a única cópia no mesmo servidor, na mesma conta ou no mesmo provedor da coisa que está sendo protegida.
• Copiar o arquivo de um banco de dados em produção em vez de fazer o dump dele, e restaurar um arquivo que está sutil e silenciosamente errado.
• Fazer backup da árvore de arquivos e do banco de dados em momentos diferentes, de forma que nenhum dos dois bate com o outro na hora de restaurar.
• Guardar a senha do repositório na mesma máquina que o repositório protege.
• Dar à origem permissão total de exclusão sobre o destino, de forma que um único comprometimento leve os arquivos junto.
• Nunca podar, até o destino encher e a tarefa noturna estar falhando silenciosamente há semanas.
• Fazer backup de centenas de gigabytes de dados públicos da blockchain enquanto o arquivo da carteira não está em nenhum dos backups.
• Configurar alertas para falha, mas nunca para ausência, de forma que uma tarefa que parou de rodar completamente não reporta absolutamente nada.
• Testar só o snapshot mais recente, e descobrir durante um incidente de verdade que a corrupção é anterior a ele.

Backups são a coisa menos interessante que você vai configurar, e a única cuja ausência é irrecuperável. Tudo o mais em um servidor pode ser reconstruído com um gerenciador de pacotes e uma tarde; o estado, não. Dedique uma sessão a isso: liste o que precisa sobreviver, faça o dump dos bancos de dados, envie um arquivo criptografado para um servidor de armazenamento em outro país, configure a poda automática, alerte no silêncio, e restaure algo real antes de fechar o terminal. Depois, deixe quieto. A medida de um bom sistema de backup é você esquecer que ele existe, até a manhã em que ele transforma uma catástrofe em uma hora levemente irritante.