Backups criptografados fora do site: 3-2-1 no seu próprio VPS offshore

Um snapshot não é um backup

O snapshot no seu painel é uma coisa genuinamente útil, e você deveria tirar um antes de qualquer mudança arriscada. Só que ele também não é um backup, e a diferença não é pedantismo — ela é a lista inteira de situações que você está tentando sobreviver. Um snapshot vive no mesmo host, dentro da mesma conta, atrás das mesmas credenciais que a máquina que ele protege. Ele responde bem a exatamente uma pergunta: como eu desfaço os últimos vinte minutos? Ele não responde a nenhuma das outras. Se a conta some, o snapshot some junto. Se a região fica inacessível, o rollback também fica. Se um invasor chega ao painel, ele chega aos snapshots também. E se os dados já estavam corrompidos quando o snapshot foi tirado, você preservou a corrupção com uma fidelidade admirável.

O mesmo vale para as duas coisas que as pessoas mais confundem com backup. RAID não é um backup: ele protege contra a morte de um disco, e replica um rm -rf para o espelho na velocidade máxima. Replicação não é um backup pelo mesmo motivo — ela é projetada para tornar a segunda cópia idêntica à primeira o mais rápido possível, inclusive quando a primeira cópia acabou de ser destruída. Em um host sem KYC, o ramo da conta nessa lista é mais afiado do que em qualquer outro lugar: o registro é um nome de usuário, uma senha e oito códigos de recuperação, sem e-mail ou documento em nenhuma parte do processo, então não existe uma escada de suporte para subir se você os perder. Isso é o produto funcionando como projetado. Também significa que a cópia que realmente importa é aquela que não está alcançável a partir das credenciais que você pode perder.

3-2-1, reescrita para um servidor que ninguém consegue identificar

A regra antiga continua valendo: três cópias de qualquer coisa que importa para você, em dois sistemas diferentes, com uma delas fora do site. A extensão moderna, que as pessoas escrevem como 3-2-1-1-0, acrescenta as duas cláusulas mais importantes em 2026 — uma cópia que é imutável ou offline, e zero erros quando você verifica. Mapeada para um único servidor, isso se lê assim: a cópia um são os dados ativos; a cópia dois é o snapshot do lado do provedor ou o complemento de backups diários criptografados, que resolve o erro comum das duas da manhã sem nenhum esforço da sua parte; a cópia três é um repositório criptografado em uma segunda máquina, em uma região diferente, que a primeira máquina não tem autoridade para apagar. Só a terceira cópia sobrevive à perda da conta da primeira máquina, e só a terceira cópia é sua no sentido de que ninguém mais pode ser obrigado a produzi-la.

Seja deliberado sobre o que "fora do site" significa. Outro rack no mesmo prédio não é fora do site em nenhum sentido que importe, e outra região sob a mesma lei é só metade do caminho — um único instrumento legal que alcança uma máquina não deveria automaticamente alcançar as duas. Com 6 regiões para escolher, essa é uma decisão que você toma uma vez, no momento da implantação, e nunca mais revisita. Vale dizer com todas as letras, no entanto: dois servidores aqui ainda são dois servidores em um único provedor, o que é um risco correlacionado por melhor que seja o isolamento entre eles. Se o seu modelo de ameaça realmente inclui perder a nós, a terceira cópia pertence a outro lugar completamente diferente — uma máquina em casa, o rack de um amigo, um host diferente em outro continente. Tudo neste guia funciona de forma idêntica onde quer que o destino esteja; a única coisa que muda é o endereço em uma variável de ambiente.

Criptografe antes que os dados saiam da máquina

O destino deveria ser um lugar que armazena bytes que não consegue ler. Isso não é uma política que você aceita de um provedor, é uma propriedade que você constrói: os dados são divididos em chunks, comprimidos, criptografados e autenticados na origem, e o que atravessa a rede já chega opaco. Os modos repokey e keyfile do Borg criptografam cada chunk com AES-256 em modo contador e o autenticam, e as variantes -blake2 trocam o HMAC-SHA256 por BLAKE2b, que é mensuravelmente mais rápido em CPUs de 64 bits modernas. O conteúdo dos arquivos, os nomes dos arquivos e o manifesto do archive que os lista ficam todos criptografados; o destino guarda arquivos de segmento numerados e um índice que não consegue interpretar. O restic entrega a mesma estrutura, com uma mecânica interna diferente. De um jeito ou de outro, o modelo mental correto é que você está alugando espaço em disco, não confiança.

Duas ressalvas honestas. Primeiro, o que ainda vaza: quem detém o disco de destino consegue ver quanto dado chega e quando chega. O tamanho do repositório e o momento das escritas ficam visíveis mesmo quando o conteúdo não fica, o que para a maioria das pessoas é irrelevante e para algumas poucas não é. Segundo, a criptografia em repouso no destino — LUKS na máquina de backup — defende contra o disco sair do prédio, não contra o host em execução, então ela complementa a criptografia do lado do cliente em vez de substituí-la. E aí vem a parte que arruína as pessoas: com repokey, o material da chave vive dentro do repositório, protegido pela sua frase secreta, então perder o repositório também perde a chave; com keyfile, ele vive só na origem, então perder a origem perde todos os archives que você já fez. Nenhum dos dois é seguro até você ter exportado a chave e colocado essa exportação em algum lugar que não seja nenhuma das duas máquinas. Faça isso no passo três, não "depois".

Borg, restic, rclone: escolha um e saiba por quê

Duas ferramentas são respostas corretas aqui, e a escolha depende genuinamente do destino. O Borg faz deduplicação em nível de chunk, compressão e criptografia autenticada, e — o motivo pelo qual ele é o exemplo prático usado abaixo — vem com um modo append-only real do lado do servidor, que você ganha de graça sobre SSH puro, sem daemon para rodar e sem porta extra para abrir. Ele precisa do borg instalado nas duas pontas e fala o seu próprio protocolo. O restic oferece as mesmas garantias sendo agnóstico quanto ao back-end: SFTP, armazenamento de objetos compatível com S3, Backblaze B2, ou o seu próprio rest-server. Não é preciso instalar nada em um destino SFTP simples, o que é conveniente, mas o append-only passa a depender do rest-server --append-only ou de uma política de bucket, em vez de uma restrição via SSH. Regra prática: Borg quando o destino é um servidor que você controla, restic quando é armazenamento de objetos ou quando você quer uma única ferramenta para vários back-ends.

O que não usar, porque é o jeito mais comum de isso dar errado. O rclone é uma ferramenta de sincronização. O remote crypt dele até entrega criptografia do lado do cliente, mas uma sincronização propaga exclusões — o arquivo que você perdeu às 03:00 é fielmente removido do destino às 03:15, que é exatamente a falha que você estava tentando sobreviver. Ele é excelente para empurrar um repositório Borg ou restic já pronto para um terceiro local; não é um backup. A mesma objeção vale para um rsync --delete puro no cron, que é um espelho vestido de backup. Um tar | gpg para um caminho remoto é um backup de verdade, mas sem deduplicação, sem lógica de retenção, e com uma restauração que significa percorrer uma cadeia inteira de incrementos para recuperar um único arquivo. Use as ferramentas que foram feitas para isso; elas vêm empacotadas em toda distribuição mencionada neste guia.

Append-only, ou o invasor também apaga os seus backups

Aqui está o cenário que separa um sistema de backup de um script de backup. Alguém consegue root na sua máquina de produção — pela aplicação, por uma dependência, por uma chave vazada, não importa como. A primeira coisa que um ransomware competente faz, e a primeira coisa que um humano competente faz, é procurar os backups, porque uma vítima com backups funcionando não paga e não entra em pânico. A sua tarefa noturna roda sem supervisão, então as suas credenciais estão necessariamente naquela máquina. Se a tarefa consegue apagar archives, o invasor consegue apagar archives, e você só descobre isso no exato momento em que precisa deles. Esse não é um modo de falha hipotético; é o normal.

O ajuste é pequeno, e é a linha mais importante deste guia. No destino, prenda a chave automatizada a um único comando no authorized_keys: command="borg serve --append-only --restrict-to-path /srv/borg",restrict. Essa chave agora só consegue fazer exatamente uma coisa — adicionar dados a um repositório sob um único caminho. Ela não consegue abrir um shell, não consegue encaminhar uma porta, não consegue listar o seu sistema de arquivos, e não consegue remover um único archive. A palavra-chave restrict (OpenSSH 7.2 em diante) desliga a alocação de pty e todo tipo de encaminhamento em uma única palavra, então a restrição não se degrada conforme novas opções vão sendo adicionadas. Agora a ressalva honesta que a maioria dos tutoriais pula: enquanto o append-only está em vigor, borg prune e borg compact parecem ter sucesso, mas não liberam nada de verdade — a exclusão fica registrada em uma transação que a próxima sessão append-only desfaz. A retenção, portanto, precisa de uma segunda chave, sem restrições, que você usa manualmente a partir do seu laptop e nunca guarda na origem. Duas chaves, duas tarefas: a noturna só consegue escrever; a de manutenção consegue apagar e vive em algum lugar que a máquina comprometida não alcança. Mantenha essa chave à mão para mais um propósito — uma tarefa encerrada no meio da execução deixa um lock obsoleto, e borg break-lock é uma escrita.

Onde a segunda cópia deve ficar

Backup é a única carga de trabalho em que latência não importa, então ignore o instinto usual de colocar a máquina perto dos seus usuários e escolha em função da lei e da independência. Um país diferente do de produção é o mínimo; uma família jurídica diferente é melhor ainda. Cada uma das nossas regiões responde a uma pergunta diferente — a Romênia é o carro-chefe, onde notificações de DMCA simplesmente não são processadas, a Suíça fica fora da UE, protegida por estatutos de proteção de dados incomumente rígidos, a Islândia tem o arcabouço da IMMI, o Panamá não tem lei de retenção obrigatória de dados nem via expressa para pedidos estrangeiros, a Malásia coloca uma cópia totalmente fora do alcance da Five Eyes, e a Holanda é o hub de peering. Qual localização offshore você deveria escolher? trabalha essas escolhas com o devido cuidado; para um destino de backup, a resposta costuma ser "onde quer que a produção não esteja". As portas não têm medição de tráfego em nenhum plano, então o primeiro upload completo fica limitado pela velocidade com que a origem consegue ler o próprio disco, não por uma franquia de transferência que você precisa racionar.

O dimensionamento é menos dramático do que as pessoas esperam. Deduplicação mais zstd significa que o repositório costuma ser uma fração da origem, e depois da primeira execução só os chunks alterados atravessam a rede — um servidor movimentado de 40 GB, com uma taxa de mudança normal, se estabiliza em algumas centenas de megabytes por noite, então um ano de archives diários custa bem menos disco do que um ano de tarballs diários custaria. O menor plano da escada já é um destino perfeitamente adequado; suba de plano só se você estiver guardando um histórico profundo de algo genuinamente grande, e leia as especificações exatas na página de planos em vez de confiar em um número escrito em um guia, onde ele acabaria desatualizado. Uma regra sobre a máquina em si: não dê mais nada para ela fazer. Nenhum servidor web, nenhum banco de dados, nenhum serviço público além de SSH com chave. Um destino de backup que também hospeda um projeto paralelo é um destino de backup com a superfície de ataque do projeto paralelo, e ele deveria receber o tratamento completo da primeira hora antes de receber um único archive.

Um backup que você não restaurou é um boato

Sistemas de backup raramente falham fazendo barulho. Eles falham porque um padrão de exclusão engoliu silenciosamente o diretório de dados, ou porque um banco de dados foi copiado arquivo por arquivo enquanto havia escritas em andamento, e o dump restaura para uma tabela corrompida, ou porque o temporizador vem falhando há seis semanas por trás de uma atualização de distribuição e ninguém lê a caixa de correio local do sistema. O único teste que detecta qualquer uma dessas coisas é uma restauração. Faça isso em uma agenda fixa: escolha um archive ao acaso, extraia-o em um diretório temporário, compare um punhado de arquivos com a produção usando diff, suba o banco de dados a partir do dump e rode uma consulta, e anote quanto tempo o processo inteiro levou. Esse número é o seu tempo de recuperação real — não aquele que você presumia — e é a única cifra que vale a pena citar para si mesmo às três da manhã. Pelo menos uma vez, faça o simulado a partir de uma máquina em branco, porque esse é o cenário real: um VPS novo, uma frase secreta vinda do seu gerenciador de senhas, uma chave exportada de onde quer que você a tenha guardado, e mais nada.

O monitoramento merece o mesmo ceticismo que você aplicou ao resto da pilha. A recomendação padrão é um dead man's switch de terceiros, que a sua tarefa notifica a cada sucesso, e que discretamente conta a um serviço externo os seus hostnames, a sua agenda e quando a sua infraestrutura está com problema — uma coisa estranha de acoplar a uma máquina que você comprou deliberadamente sem deixar identidade nenhuma em lugar algum. Você não precisa disso. A atualidade dá para checar a partir do destino sem precisar da chave: o arquivo de segmento mais novo do repositório carrega um timestamp, então um cron de cinco linhas na máquina de backup, que grita quando nada chega em vinte e cinco horas, não custa nada e não revela nada. A integridade também tem uma checagem que dispensa a chave — o borg check --repository-only roda localmente no destino e valida a estrutura dos segmentos sem nunca ver os seus dados. Rode a passagem profunda --verify-data de vez em quando, a partir da origem, com a chave de manutenção, que é onde essa chave pertence.

Quanto custa, e onde isso se encaixa na pilha

As contas nem chegam perto de empatar. Um segundo VPS a partir de $8.00/mês, financiado a partir do mesmo saldo pré-pago, com recargas a partir de $30.00, online em cerca de 15 min, contra o custo de perder o que quer que esteja na primeira máquina. Use-o junto com os backups do lado do provedor, não no lugar deles: o complemento de backups diários criptografados resolve o caso de você ter apagado o diretório errado, sem nenhum trabalho da sua parte e sem precisar pensar às três da manhã, enquanto o que você construiu aqui é a cópia que continua sua quando a conta, a região ou o provedor é que desaparece. Eles cobrem falhas diferentes, e nenhum substitui o outro, que é todo o sentido de contar até três.

Vale terminar mostrando onde os backups se encaixam em relação a tudo o mais, porque são quatro controles que falham de forma independente. O que o host sabe sobre você é a primeira, e aqui isso é próximo de nada — um nome de usuário e um saldo em cripto, o assunto de pagar por hosting de forma anônima. Qual lei se aplica é a segunda, decidida por onde o hardware está, e não por onde você está. O que a máquina permite é a terceira, que é a primeira hora após a implantação e é sua, e só sua, para configurar. E o que sobrevive à máquina é a quarta — a única que é uma promessa que você faz ao seu eu futuro, e a única da qual ninguém vai te lembrar até o dia em que for tarde demais para começar. Uma hora hoje à noite, e um simulado de restauração marcado no calendário. É basicamente isso.

Passo a passo

1. 01

   Implante o destino de backup e não dê mais nada para ele fazer

   Implante um segundo VPS em uma região que não seja onde a produção mora, e trate-o como um equipamento de propósito único. Rode nele o checklist padrão da primeira hora — SSH só com chave, firewall com bloqueio padrão nas duas famílias de IP, atualizações de segurança automáticas — e depois não abra mais nada. A única porta de entrada nessa máquina é o SSH.

   ssh root@198.51.100.7
   apt update && apt full-upgrade -y
   hostnamectl set-hostname vault-01
   apt install -y borgbackup ufw unattended-upgrades
   ufw default deny incoming && ufw default allow outgoing
   ufw limit 22/tcp && ufw enable

2. 02

   Crie uma conta borg restrita com duas chaves

   Gere dois pares de chaves na origem: um para a tarefa noturna (sem frase secreta — ela precisa rodar sem supervisão) e um para manutenção, que você mantém só no seu laptop. No destino, crie um usuário borg sem privilégios e prenda cada chave a um comando forçado. A chave da tarefa recebe --append-only; a chave de manutenção não. Esse único arquivo é o que impede um invasor na origem de apagar o seu histórico.

   # on the source
   ssh-keygen -t ed25519 -N "" -f /root/.ssh/borg_job -C "job@edge-01"
   # on your laptop
   ssh-keygen -t ed25519 -f ~/.ssh/borg_maint -C "maint@laptop"
   
   # on the target
   adduser --disabled-password --gecos "" borg
   install -d -m 700 -o borg -g borg /home/borg/.ssh /srv/borg
   cat > /home/borg/.ssh/authorized_keys <<'EOF'
   command="borg serve --append-only --restrict-to-path /srv/borg",restrict ssh-ed25519 AAAA...job@edge-01
   command="borg serve --restrict-to-path /srv/borg",restrict ssh-ed25519 AAAA...maint@laptop
   EOF
   chown borg:borg /home/borg/.ssh/authorized_keys
   chmod 600 /home/borg/.ssh/authorized_keys

3. 03

   Inicialize o repositório, depois tire a chave das duas máquinas

   Inicialize com a chave de manutenção, a partir do seu laptop — criar um repositório não é um append. Um repositório por host de origem mantém a retenção trivial e o raio de explosão pequeno. Depois exporte a chave duas vezes, em dois formatos, e mova as duas exportações para algum lugar que não seja nem a origem nem o destino: um gerenciador de senhas, um pendrive USB criptografado, uma folha de papel em uma gaveta. Um repositório cuja chave só existe dentro dele mesmo é cara ou coroa.

   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i ~/.ssh/borg_maint'
   borg init --encryption=repokey-blake2
   
   borg key export :: /tmp/edge-01.borgkey
   borg key export --paper :: /tmp/edge-01.paper
   # move both off this machine, then shred the copies
   shred -u /tmp/edge-01.borgkey /tmp/edge-01.paper

4. 04

   Congele o estado da aplicação antes de ler o disco

   Copiar o diretório de um banco de dados ativo arquivo por arquivo produz um arquivo que parece um banco de dados e restaura como uma cena de crime. Faça o dump primeiro, faça backup do dump, e exclua o diretório de dados bruto. A mesma lógica vale para qualquer coisa com um formato em disco que você não controla: tire um dump dela, ou pare-a pelos segundos que o snapshot leva.

   install -d -m 700 /var/backups/dumps
   mariadb-dump --single-transaction --quick --all-databases \
     > /var/backups/dumps/mariadb.sql
   # PostgreSQL:
   # sudo -u postgres pg_dumpall > /var/backups/dumps/pg.sql
   chmod 600 /var/backups/dumps/*.sql

5. 05

   Escreva a tarefa de backup e coloque-a em um temporizador

   Mantenha o script chato e deixe que ele falhe fazendo barulho. A frase secreta vem de um arquivo com permissão 600 via BORG_PASSCOMMAND, então ela nunca aparece na lista de processos. Nomeie os archives com o host e um timestamp ISO, para que fiquem ordenados. Repare no que não está neste script: nenhum prune, nenhum delete — a chave da tarefa não conseguiria executá-los de qualquer forma. Um temporizador com Persistent=true recupera o atraso depois de uma reinicialização, e um atraso aleatório evita que todas as suas máquinas façam upload no mesmo segundo.

   cat > /usr/local/sbin/borg-backup.sh <<'EOF'
   #!/bin/bash
   set -euo pipefail
   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i /root/.ssh/borg_job -o BatchMode=yes'
   export BORG_PASSCOMMAND='cat /root/.config/borg/passphrase'
   borg create --stats --compression zstd,6 --one-file-system \
     --exclude-caches --exclude '/var/cache/*' \
     --exclude '/var/lib/mysql' --exclude '/home/*/.cache' \
     ::'{hostname}-{now:%Y-%m-%dT%H:%M}' \
     /etc /root /home /srv /var/www /var/backups/dumps
   EOF
   chmod 700 /usr/local/sbin/borg-backup.sh
   
   cat > /etc/systemd/system/borg-backup.service <<'EOF'
   [Unit]
   Description=Off-site Borg backup
   [Service]
   Type=oneshot
   Nice=10
   IOSchedulingClass=idle
   ExecStart=/usr/local/sbin/borg-backup.sh
   EOF
   
   cat > /etc/systemd/system/borg-backup.timer <<'EOF'
   [Unit]
   Description=Nightly off-site Borg backup
   [Timer]
   OnCalendar=*-*-* 03:17:00
   RandomizedDelaySec=900
   Persistent=true
   [Install]
   WantedBy=timers.target
   EOF
   systemctl daemon-reload
   systemctl enable --now borg-backup.timer

6. 06

   Prune com a chave de manutenção, compact no destino

   A retenção não pode rodar a partir da origem, porque a chave da origem é append-only, e as suas exclusões seriam desfeitas silenciosamente. Rode-a a partir do seu laptop, na cadência que fizer sentido para você — mensalmente já é mais do que suficiente. O prune decide quais archives manter; o compact é o que de fato libera o disco. Faça um --dry-run primeiro e leia a lista antes de deixar que ele apague qualquer coisa.

   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i ~/.ssh/borg_maint'
   
   borg prune --dry-run --list \
     --keep-daily 7 --keep-weekly 4 --keep-monthly 6
   borg prune --list --stats \
     --keep-daily 7 --keep-weekly 4 --keep-monthly 6
   borg compact --progress

7. 07

   Faça o simulado de restauração, depois escreva o runbook

   Restaure antes de precisar. Extraia um archive de verdade em um diretório temporário, compare alguns arquivos com os originais, e carregue o dump do banco de dados em um esquema descartável. Depois acrescente as duas checagens que rodam sem a sua atenção: um alarme de atualidade no destino que dispensa a chave, e uma passagem periódica de verificação de integridade. Por fim, anote os três fatos que você vai querer no seu pior dia — onde a chave exportada está guardada, onde a frase secreta está guardada, e os comandos exatos abaixo.

   borg list ::
   mkdir -p /var/tmp/drill && cd /var/tmp/drill
   borg extract --list ::edge-01-2026-08-31T03:17 etc/nginx
   diff -r etc/nginx /etc/nginx && echo 'restore OK'
   
   # on the target, no key needed:
   borg check --repository-only /srv/borg/edge-01
   find /srv/borg/edge-01/data -type f -mmin -1500 | head -1   # empty = stale