Todo backup funciona até o dia em que é preciso usá-lo. O snapshot está na plataforma que acabou de cair. O tarball noturno vem falhando silenciosamente desde que um disco encheu em março. O dump do banco de dados era uma cópia de arquivo feita no meio de uma escrita, e não restaura nada. Backup é a única parte de um servidor que você não consegue avaliar só olhando para ela — só restaurando. Isto é como construir um que sobrevive a uma falha de hardware, às suas próprias mãos e a outra pessoa segurando as suas credenciais, sem entregar uma cópia legível da máquina para quem quer que a esteja guardando.
Quatro coisas destroem um servidor, e cada uma exige algo diferente
Desenhe o backup em torno da falha, não em torno da ferramenta. Quatro cenários respondem por essencialmente toda perda real, e cada um exige algo diferente da cópia que você mantém. Uma configuração que resolve um deles parece completamente adequada até esbarrar em outro.
Falha de hardware ou de host
O disco, o node ou o datacenter caem. Qualquer cópia guardada em outro lugar te recupera. Essa é a única falha que um snapshot na mesma plataforma resolve de forma confiável, e é exatamente por isso que tanta gente acredita que snapshots bastam.
As suas próprias mãos
Uma flag errada, um script de migração apontado para produção, uma limpeza que removeu mais do que deveria. O dano se replica instantaneamente para qualquer coisa que espelhe, então o que te salva é o histórico — uma versão de antes do erro, não uma cópia atual de depois dele.
Comprometimento e ransomware
Um invasor com root tem exatamente o mesmo alcance que a sua tarefa de backup tem: as mesmas credenciais, o mesmo destino, o mesmo agendamento. Se o servidor consegue apagar os próprios backups, eles serão apagados. Sobreviver depende de a cópia ser append-only ou estar completamente fora de alcance.
Perder a conta, não o servidor
Um atraso no pagamento, uma conta suspensa, uma remoção na jurisdição errada. O hardware está bem, e você simplesmente não consegue alcançá-lo. Só uma cópia sob um provedor diferente, com um caminho de pagamento diferente, ajuda aqui.
Anote contra qual dos quatro você está realmente se defendendo antes de escolher qualquer coisa. Uma cópia noturna para um segundo diretório no mesmo disco cobre exatamente um deles — o menos provável — enquanto parece, em tudo, um backup de verdade. A maioria das configurações que falham em produção falha porque ninguém jamais nomeou o cenário.
Snapshots não são backups
As palavras são usadas de forma intercambiável, mas descrevem objetos diferentes, com domínios de falha diferentes. Saber qual dos dois você tem decide se você tem alguma coisa, no fim das contas.
Use snapshots para aquilo em que eles realmente são excelentes: um desfazer de cinco segundos antes de você mexer no kernel, no bootloader ou no schema de um banco de dados. Tire um, faça a coisa arriscada, apague-o quando der certo. O que você nunca deve fazer é deixar "existe um snapshot" virar a razão para não existir um backup — um snapshot compartilha o destino da plataforma que o guarda, e uma conta suspensa leva os dois de uma vez.
3-2-1, e os dois números que todo mundo deixa de fora
A regra antiga sobrevive porque descreve independência, não um sistema de arquivamento: três cópias dos dados, em dois tipos diferentes de armazenamento, uma delas em outro lugar. Dois acréscimos cobrem falhas que eram raras quando a regra foi escrita e hoje são rotina.
- Três cópias. Os dados ativos mais dois backups. Duas cópias significam que você está a uma restauração malsucedida de distância de não ter nenhuma.
- Duas mídias, ou dois provedores. Em infraestrutura alugada, "mídia" na prática significa independência administrativa — uma segunda cópia na mesma conta, na mesma plataforma, paga do mesmo saldo, é uma cópia só, com passos extras.
- Uma fora do servidor. Prédio diferente, rede diferente, jurisdição diferente, se isso importar para você. /locations é a versão prática disso: escolha uma região que falhe de forma independente da que você está protegendo.
- Uma imutável ou offline. Uma cópia que o próprio servidor não consegue apagar, porque quem tem o servidor também tem as suas credenciais.
- Zero restaurações não verificadas. Um backup que você nunca restaurou é uma hipótese. O número que conta é quantas restaurações você já completou, não quantas tarefas reportaram sucesso.
Faça backup dos dados, reconstrua o resto
O instinto é fazer imagem de tudo. É caro, lento para restaurar, e preserva fielmente o binário comprometido, o estado de pacotes quebrado e o desvio de configuração que você nem lembra mais de ter criado. Um servidor guarda três tipos de conteúdo, e só um deles pertence ao backup.
- Inclua /etc, /home, /root, /srv, a raiz do seu site, o diretório de estado da sua aplicação, os volumes de contêiner nomeados, e um diretório com dumps recentes do banco de dados.
- Inclua a própria receita de implantação — arquivos compose, scripts em Ansible ou shell, as anotações que você escreveu às 2 da manhã. Mantenha isso em controle de versão também, mas coloque uma cópia no backup, para que a recuperação nunca dependa de um segundo serviço estar acessível.
- Exclua /proc, /sys, /dev, /run e os diretórios temporários. São interfaces do kernel e espaço de rascunho; copiá-los desperdiça tempo ou simplesmente trava a tarefa.
- Exclua caches de pacotes, diretórios de build, árvores de dependências e virtualenvs — qualquer coisa que uma etapa de build regenera. Em um servidor de aplicação típico, isso é a maior parte do disco.
- Exclua os arquivos ativos do banco de dados se você estiver fazendo o dump corretamente. Fazer backup dos dois significa que a cópia maior e inútil é a que alguém vai restaurar às três da manhã.
- Não exclua arquivos ocultos. Metade do que importa em uma máquina Linux começa com um ponto.
Bancos de dados não sobrevivem a uma cópia de arquivo
Esse é o motivo mais comum, de longe, para uma restauração falhar. Um banco de dados em execução mantém estado em memória e escreve fora de ordem; copiar os seus arquivos enquanto ele roda captura um estado rasgado, meio escrito, que pode restaurar, pode restaurar silenciosamente corrompido, ou pode simplesmente não restaurar. Faça um dump adequado, e depois faça backup do dump.
- PostgreSQL: pg_dump por banco de dados, ou pg_dumpall para o cluster inteiro, incluindo roles. Onde perder um dia é inaceitável, acrescente arquivamento de WAL para poder recuperar até um ponto no tempo, em vez de até a noite anterior.
- MySQL ou MariaDB: mysqldump com --single-transaction dá um snapshot consistente em InnoDB sem bloquear escritas. Em MyISAM, não dá — mais um motivo para não usar MyISAM. Para datasets grandes, uma ferramenta física como o mariabackup restaura muito mais rápido do que reproduzir um dump.
- SQLite: nunca copie o arquivo. Use o comando .backup ou VACUUM INTO, que tomam o lock corretamente. Copiar um banco de dados com um write-ahead log ativo é uma aposta que, mais cedo ou mais tarde, você vai perder.
- Redis: dispare um background save e faça backup do arquivo de snapshot resultante, ou rode em modo append-only e faça backup do log. Copiar um snapshot ativo no meio de uma escrita te dá um arquivo truncado, que carrega como um dataset vazio.
- Contêineres: o volume é o dado. Pare a stack pelos segundos que a cópia leva, ou rode a ferramenta de dump dentro do contêiner — mas não faça um tar do volume de um banco de dados em execução e chame isso de backup.
- Qualquer outra coisa com um processo persistente — índices de busca, filas de mensagens, daemons de ledger — tem o seu próprio comando de exportação consistente. Encontre-o agora, não durante a indisponibilidade.
Snapshots de sistema de arquivos resolvem isso pelo caminho oposto: LVM, ZFS e btrfs congelam uma visão consistente do volume em milissegundos, e você faz backup dessa visão congelada enquanto o banco de dados continua atendendo. Essa é a resposta certa para datasets em que um dump leva horas. Não é motivo para pular o dump de um banco de dados de 200 MB, onde o dump é mais simples, portátil entre versões do engine, e legível por um humano quando alguma coisa dá errado de um jeito estranho.
Escolhendo uma ferramenta
Quatro ferramentas cobrem quase todos os casos. A propriedade que mais importa é onde a criptografia acontece. Se os dados são criptografados só em trânsito, e depois em repouso pelo provedor de armazenamento, o provedor de armazenamento consegue lê-los — e o backup silenciosamente virou o ponto mais fraco de um sistema que você blindou em todo o resto.
Seja qual for a sua escolha, a senha ou a chave precisa existir em algum lugar que não seja o servidor que está sendo copiado. Essa é a armadilha que pega até gente cuidadosa: a chave do repositório guardada em /root, fielmente incluída no backup dentro do próprio repositório que ela destrava. Imprima-a, ou guarde-a em um gerenciador de senhas que você consiga abrir a partir de uma máquina que ainda esteja viva. Um repositório que você não consegue descriptografar é indistinguível de nenhum backup.
Onde a segunda cópia deve ficar
O destino é uma jurisdição e uma relação de cobrança tanto quanto é espaço em disco. Quatro opções, em uma ordem aproximada de quão independentes elas são do servidor que você está protegendo.
Um segundo servidor em outra região
A resposta direta: uma instância barata em um país diferente, alcançável via SSH, rodando nada além de sshd e um repositório. Um plano /vps de 1 GB comporta os backups de uma pequena frota, e a conta pode ser travada em um único comando forçado, para que uma chave roubada não abra shell nenhum.
Disco de armazenamento em massa
Assim que o dataset passa a ocupar centenas de gigabytes, a capacidade de HDD em um uplink com tráfego ilimitado custa muito menos por terabyte do que NVMe, e a escrita de backups não precisa da latência de um NVMe. O /storage foi feito para isso: disco protegido por RAID em escala de terabytes, root completo, sem inspeção de conteúdo.
Armazenamento de objetos compatível com S3
Conveniente, cobrado por gigabyte, e muitas vezes com suporte a bloqueio de objeto, que garante imutabilidade real. Leia o preço do egress antes de confiar nele — puxar um terabyte de volta em uma emergência é um péssimo momento para descobrir quanto custa a recuperação.
Hardware próprio
Um disco externo ou uma máquina em casa, que você busca (pull) em vez de enviar (push). Mais lento e manual, e a única cópia desta lista que nenhum provedor, ordem judicial ou disputa de cobrança pode tocar. Vale a pena manter para dados que você genuinamente não consegue recriar, mesmo que fique uma semana atrasado.
Equipare as propriedades de privacidade do backup às do servidor. Criptografar um disco com LUKS e depois enviar backups noturnos em texto claro para um bucket registrado no seu cartão desfaz todo o exercício: os dados agora são legíveis, e estão arquivados no seu nome. Se valia a pena pagar pelo servidor de forma anônima, também vale a pena pagar pela cópia da mesma forma — criptografe no lado do cliente, e compre o destino do mesmo jeito que você comprou a origem.
Construindo o backup, passo a passo
- 1
Decida os dois números primeiro
Quanto dado você pode se dar ao luxo de perder — o intervalo entre execuções — e quanto tempo você pode se dar ao luxo de ficar fora do ar. Tudo o mais decorre dessas duas respostas. Backups horários de um site estático são teatro; backups noturnos de um banco de dados de pedidos são uma decisão para tomar deliberadamente, não para herdar de um tutorial.
- 2
Crie o destino
Uma segunda instância em outra região, com sua própria chave SSH e um usuário dedicado sem privilégios cujo home é o repositório. Nada mais roda ali. Restrinja a chave a um comando forçado, para que uma credencial roubada só consiga anexar backups, nunca abrir um shell.
- 3
Gere a chave e guarde-a em outro lugar
Uma senha longa e aleatória, registrada em algum lugar que sobreviva à perda do servidor. Inicialize o repositório, depois prove que você consegue listar o seu conteúdo a partir de uma terceira máquina, usando somente o que você anotou. Se não conseguir, resolva isso antes de escrever um único backup.
- 4
Faça o dump dos bancos de dados primeiro
Um script curto que grava dumps consistentes em um diretório de staging e termina com um código de saída diferente de zero se algum deles falhar — executado antes do backup de arquivos, não em paralelo com ele. Uma tarefa que continua depois de um dump malsucedido é assim que as pessoas acabam com trinta dias de arquivos de zero bytes.
- 5
Faça backup dos caminhos que importam
Aponte a ferramenta para a lista de inclusão, aplique as exclusões e confira com atenção a primeira execução. Se um repositório novo de um servidor de 40 GB fica em 300 MB, alguma coisa está sendo ignorada silenciosamente; se fica em 38 GB, as suas exclusões não estão funcionando.
- 6
Agende, e torne a falha barulhenta
Um timer do systemd com um atraso aleatório, ou cron, se esse for o hábito. Depois, faça a tarefa reportar: um heartbeat para um monitor a cada sucesso, e um alerta quando o heartbeat parar de chegar. A falha silenciosa é o modo de falha normal dos backups, porque nada quebra visivelmente quando eles param — até que tudo quebra.
- 7
Defina a retenção e execute o prune de fato
De hora em hora por um dia, diariamente por uma quinzena, semanalmente por alguns meses, mensalmente por um ano. Depois, rode o prune e confirme que o repositório para de crescer. Uma retenção que é configurada mas nunca executada enche o destino e derruba os backups junto.
- 8
Restaure algo hoje
Não uma tarefa de teste — um arquivo de verdade, para um diretório de rascunho, aberto e conferido. Depois, marque uma data no calendário para a máquina inteira. A primeira restauração completa sempre revela alguma coisa: um caminho ausente, uma permissão, um certificado, um usuário de banco de dados que só existiu na máquina antiga.
Enviar o backup de dentro do servidor para fora é aceitar que qualquer pessoa com root nele pode destruir todas as cópias. Faça do jeito contrário — o host de backup se conecta, busca os dados e desconecta — e um servidor comprometido não consegue alcançar o repositório de jeito nenhum, porque não guarda nenhuma credencial para isso. O modelo pull dá mais trabalho para configurar, e é a maior melhoria isolada que a maioria das configurações consegue fazer.
Retenção, e por que mais tempo é mais barato do que parece
A retenção normalmente é definida pelo que cabe no disco, e depois esquecida. Ela merece uma reflexão deliberada, porque decide quais erros são recuperáveis. Uma janela de sete dias pega um arquivo apagado na terça-feira. Ela não pega uma corrupção que começou seis semanas atrás e só apareceu quando um relatório saiu errado, nem um invasor que ficou quieto na máquina por um mês antes de agir.
A deduplicação torna isso muito mais barato do que a tabela sugere: a segunda execução contra um servidor majoritariamente inalterado guarda somente o que mudou, então um ano de pontos de restauração mensais em uma máquina de 40 GB normalmente custa alguns gigabytes, não meio terabyte. Defina a política com base no que você precisa conseguir recuperar, depois confira a conta. Você geralmente vai descobrir que pode bancar a versão generosa.
Imutabilidade: a parte que impede o ransomware
Tudo o que foi dito até aqui presume que o adversário é a entropia. Se o adversário é uma pessoa com root, uma tarefa de backup comum é um manual de instruções — as credenciais estão na máquina, o destino está na configuração, e o repositório é apagado antes de a criptografia sequer começar. Quatro mecanismos quebram essa cadeia, e qualquer um deles muda o resultado.
- Repositórios append-only. O modo append-only do lado do servidor no Borg, ou o servidor REST do restic em modo append-only, aceitam dados novos e recusam exclusões. O servidor pode escrever; só você, de outro lugar, pode fazer o prune.
- Backups baseados em pull. O host de backup inicia a conexão e é o único que guarda as credenciais. O servidor de produção não tem chave, não tem endereço de destino, e não tem rota nenhuma até o repositório.
- Bloqueio de objeto. Armazenamento compatível com S3 com um período de retenção aplicado no nível do bucket, onde a exclusão é recusada pela própria camada de armazenamento, independentemente do que as credenciais permitiriam.
- Credenciais separadas por host. Uma máquina comprometida não deveria expor o histórico de todas as outras. Chaves distintas, caminhos distintos, restrições distintas.
- Uma cópia que esteja genuinamente offline. Um disco desconectado é imune a qualquer ataque remoto já criado. Fora de moda, e imbatível.
O simulado de restauração
Uma restauração é um procedimento, e um procedimento que ninguém nunca executou é ficção. Faça esse exercício uma vez agora e uma vez a cada seis meses, e anote o que você aprender — as anotações acabam tão valiosas quanto os dados.
- 1
Implante uma instância em branco
Mesma versão do sistema operacional, nada mais instalado. Um VPS de vida curta é suficiente, e o exercício inteiro custa menos que um almoço.
- 2
Restaure usando somente o que você anotou
O endereço do repositório, a senha, os comandos. Se você precisar de algo que só existe no servidor que está fingindo estar morto, você acabou de encontrar a falha — em um dia em que encontrá-la não custa nada.
- 3
Traga os dados de volta antes da aplicação
Carregue o dump do banco de dados, coloque os arquivos onde eles pertencem, depois corrija o dono e as permissões. O dono é a surpresa de sempre: os IDs numéricos de usuário da máquina antiga raramente batem com os da nova.
- 4
Inicie o serviço e realmente use-o
Não um comando de status — faça login, carregue uma página, rode uma consulta, envie uma mensagem. Um serviço que inicia não é a mesma coisa que um serviço que funciona.
- 5
Cronometre, e anote o número
Quanto tempo o processo inteiro levou? Esse é o seu tempo de recuperação real, e ele é quase sempre várias vezes maior do que a estimativa. Guarde as anotações junto com a senha, e atualize as duas sempre que a stack mudar.
O que isso custa, com honestidade
Backup é o seguro mais barato da infraestrutura, e é rotineiramente deixado de lado por causa do preço. Alguns números concretos para um servidor pequeno, presumindo que os dados comprimem e deduplicam do jeito que dados comuns costumam fazer.
Compare qualquer um desses valores ao custo da indisponibilidade que eles evitam. Colocar o número no papel é o ponto principal — o argumento contra os backups nunca é realmente sobre dinheiro, assim que o dinheiro é colocado no papel.
Onde o host se encaixa
Um plano de backup tem as mesmas duas dependências do servidor que ele protege: um lugar independente para colocar a cópia, e uma forma de pagar por ela que não crie um novo registro de quem você é. As duas importam mais aqui do que na origem, porque o backup é uma cópia completa de tudo o que a origem estava protegendo.
Todo plano /vps e /storage aqui é implantado a partir de um saldo pré-pago em cripto, sem KYC, em quinze regiões listadas em /locations — então a segunda cópia pode ficar sob uma jurisdição diferente da primeira, sem uma segunda verificação de identidade em nenhum ponto da cadeia. Snapshots instantâneos vêm incluídos em toda instância para o desfazer de cinco segundos, a largura de banda ilimitada significa que nem o primeiro upload nem a restauração de emergência viram um evento tarifado, e o /storage acrescenta disco protegido por RAID em escala de terabytes a partir de $8.99/mo, sem inspeção de conteúdo. /pay-with cobre as moedas aceitas, /offshore-hosting detalha o que a jurisdição realmente muda, e /guides tem os textos irmãos sobre criptografia de disco e sobre o que um host consegue e não consegue ver de uma máquina.
O checklist
- Nomeie a falha contra a qual você está se defendendo antes de escolher uma ferramenta.
- Trate snapshots como um botão de desfazer, nunca como o backup.
- Faça backup dos dados e da configuração; reconstrua o sistema operacional a partir de um script.
- Faça o dump de cada banco de dados com o seu próprio comando de exportação consistente, e faça backup do dump.
- Criptografe no lado do cliente, antes que qualquer coisa saia da máquina.
- Guarde a senha do repositório em algum lugar que sobreviva à perda do servidor.
- Coloque pelo menos uma cópia sob um provedor, uma região e um caminho de pagamento diferentes.
- Torne uma cópia append-only, baseada em pull ou offline, para que um root comprometido não consiga apagá-la.
- Alerte sobre a ausência de uma execução bem-sucedida — as falhas são silenciosas, e o silêncio é o sintoma.
- Restaure um arquivo hoje, e a máquina inteira duas vezes por ano. Cronometre e anote.
Os snapshots do provedor são suficientes por si só?
Não, e essa é a lacuna mais comum em configurações que, fora isso, são cuidadosas. Um snapshot vive na mesma plataforma que o volume que ele copia, então ele não sobrevive a uma falha em nível de plataforma, a uma suspensão de conta ou a um atraso de pagamento — três dos cenários em que você mais precisa dele. Ele também costuma guardar só um histórico curto, então não vai recuperar um arquivo apagado no mês passado nem uma corrupção que começou seis semanas atrás. Snapshots são excelentes como um desfazer de cinco segundos antes de uma mudança arriscada: mantenha-os, use-os todo dia, e mantenha um backup de verdade em outro lugar.
restic ou Borg — qual devo usar?
restic se o destino é armazenamento de objetos ou uma conta SSH simples, porque não precisa de nada instalado do outro lado e fala S3 nativamente. Borg se o destino é uma máquina Linux que você controla e você quer o modo append-only no servidor e uma compressão um pouco mais apertada. Os dois deduplicam, os dois criptografam e autenticam no lado do cliente, os dois são maduros e amplamente usados, e qualquer um dos dois é uma escolha defensável. A resposta errada é passar um mês comparando os dois enquanto o servidor fica sem backup nenhum — escolha um hoje à tarde, e mude de ideia depois, se algum dia isso importar.
Com que frequência eu devo fazer backup de um VPS?
O intervalo é simplesmente a quantidade máxima de trabalho que você está disposto a refazer. Para um site estático, semanal é honesto. Para qualquer coisa em que usuários escrevam, noturno é o mínimo, e de hora em hora sai barato assim que a deduplicação entra em ação — a segunda execução do dia normalmente guarda apenas alguns megabytes. Pese o valor dos dados de um dia contra o custo de guardar vinte e quatro pontos de restauração em vez de um, e a resposta normalmente é óbvia.
Eu devo fazer backup do disco inteiro, ou só dos meus dados?
Dados e configuração, em quase todos os casos. Uma imagem completa do disco restaura a máquina exatamente como ela estava, incluindo o comprometimento do qual você está se recuperando e o estado de pacotes que você já nem entende mais, e é mais lenta tanto para criar quanto para restaurar. Um backup em nível de arquivo de /etc, dos dados da sua aplicação e dos dumps do seu banco de dados, combinado com um script que reconstrói o sistema operacional, restaura mais rápido e de forma mais limpa. Faça a imagem do disco quando precisar de preservação forense bit a bit, ou quando a máquina for uma caixa-preta construída por outra pessoa.
Meu provedor diz que os discos são criptografados — o meu backup está criptografado?
Não em nenhum sentido que te ajude. A criptografia do lado do provedor protege contra um disco sendo retirado fisicamente de um rack; o provedor guarda a chave, então os dados continuam legíveis pelo provedor e por qualquer um que consiga obrigar o provedor a colaborar. A criptografia no lado do cliente — restic, Borg, a camada crypt do rclone, ou um arquivo criptografado — significa que o que chega ao destino não tem sentido nenhum sem uma senha que nunca saiu da sua máquina. Para uma stack crítica em privacidade, essa distinção é tudo o que importa, porque o backup é uma cópia completa de tudo o que o servidor estava protegendo.
Como eu evito que o ransomware criptografe também os meus backups?
Presuma que tudo o que o servidor consegue alcançar, um invasor com root também consegue destruir — as credenciais, o destino e o agendamento estão todos ali na máquina. Quebre esse alcance de uma de três formas: um repositório append-only que aceita gravações mas recusa exclusões, um modelo pull em que o host de backup se conecta de fora para dentro e o servidor não guarda credencial nenhuma, ou armazenamento de objetos com um bloqueio que a própria camada de armazenamento aplica. Depois, adicione uma retenção longa, para que um comprometimento lento e silencioso não simplesmente saia da janela antes que alguém perceba, e mantenha uma cópia offline onde nenhum ataque remoto consiga alcançar.
