Monte seu próprio sistema de backup – Parte 1: estratégia antes dos scripts

• A importância do backup costuma ser frequentemente subestimada
• Muitas pessoas se acomodam na dependência da nuvem e não percebem sua responsabilidade na proteção dos dados
• Confiar em cópias simples sem estabelecer um plano de backup traz alto risco
• Os métodos de backup do disco inteiro ou de arquivos individuais têm, cada um, vantagens e desvantagens
• Um backup confiável depende do uso de snapshots e de garantir armazenamento externo

---

A importância dos backups e a realidade

• Backup é uma área que muita gente não leva a sério
• Inúmeros dados são perdidos por métodos incorretos ou erros conceituais (ex.: RAID não é backup)
• Os dados são um ativo importante e devem ser preservados de várias formas

Equívocos sobre nuvem e backup

• É comum confiar todos os dados à nuvem sem sequer perguntar como eles estão realmente sendo protegidos
• Até os principais provedores de nuvem adotam o modelo de responsabilidade compartilhada
  • Eles fornecem a segurança da infraestrutura, mas a responsabilidade pela proteção dos dados é do usuário
• Mesmo em ambientes de nuvem, servidores privados e Kubernetes, o risco da ausência de backup é frequente

A experiência do autor com recuperação de dados

• O autor já passou por vários casos de perda de dados, como incêndio em datacenter, alagamento de sala de servidores, terremoto, ransomware, ataques maliciosos e erros de administrador
• Em servidores conectados à internet (e-commerce, e-mail etc.), tanto a integridade dos dados quanto a continuidade do serviço são importantes
• Backup não é uma simples cópia. Em especial, copiar arquivos de banco de dados em uso aumenta a chance de não ser possível recuperá-los

Perguntas essenciais para definir uma estratégia de backup

• "Quanto risco você está disposto a assumir?", "Quais dados precisam ser protegidos?", "Quanto tempo de indisponibilidade é aceitável em caso de perda de dados?", "Quanto espaço de armazenamento está disponível?"
• Manter o backup na mesma máquina não serve de nada em caso de falha da máquina. Fazer backup em armazenamento externo é mais seguro
• Também é preciso considerar fatores práticos como largura de banda da rede, velocidade de recuperação e espaço de armazenamento

Backup do disco inteiro vs. backup por arquivo

Backup do disco inteiro

• Vantagens
  • Permite recuperação completa. É possível restaurar rapidamente o sistema ao estado anterior
  • É útil quando combinado com sistemas de virtualização. Soluções como Proxmox oferecem esse tipo de backup com facilidade
  • Algumas soluções também permitem recuperar arquivos individuais a partir de um backup completo
• Desvantagens
  • No caso de servidores físicos, exige downtime
  • Consome muito espaço, armazenando até dados desnecessários
  • Dependendo das características do sistema de arquivos, pode ser lento ou apresentar problemas de compatibilidade

Backup por arquivo individual

• Vantagens
  • Pode ser feito com utilitários básicos do sistema (tar, cp, rsync etc.)
  • Permite fazer backup apenas das alterações, economizando espaço e tráfego de transferência
  • Garante flexibilidade para recuperação individual, migração, compressão e deduplicação
  • Pode operar sem interromper o sistema
• Desvantagens
  • Cópias simples podem exigir muito espaço de armazenamento
  • Fazer backup de um sistema de arquivos em uso sem snapshot pode causar inconsistências e erros

Backup com uso de snapshots

• Quando o alvo do backup é um sistema de arquivos em uso, os dados podem mudar entre o "início" e o "fim" do backup, comprometendo a consistência dos dados
• Bancos de dados abertos, como MySQL e histórico do navegador, podem se tornar irrecuperáveis se apenas os arquivos forem copiados
• Para garantir um backup consistente, é preciso usar primeiro o recurso de snapshot do sistema de arquivos
• Métodos mais comuns
  • Snapshots nativos do sistema de arquivos (sistemas com suporte a BTRFS, ZFS)
  • Snapshot do LVM: pode desperdiçar espaço e, ao remover o snapshot, há risco de interrupção do sistema
  • DattoBD: às vezes apresenta problemas de estabilidade, mas pode ser usado em conjunto com UrBackup

Método de backup: Push vs Pull

• Push: o sistema a ser copiado se conecta ao servidor e envia os dados
• Pull: um servidor central de backup se conecta a cada servidor para executar o backup
• Em termos de segurança, o método Pull, no qual o servidor de backup bloqueia conexões externas e só acessa os clientes quando necessário, é mais seguro
  • Para evitar a exclusão dos dados de backup em caso de invasão ou ransomware, os snapshots do próprio servidor de backup também devem ser mantidos separadamente por um longo período

Principais características de um sistema de backup recomendado

• Recuperação imediata e processamento rápido
• Armazenamento em local externo (embora snapshots locais devam ser mantidos para rollback imediato)
• Recomenda-se não usar nuvens comerciais como Google Drive ou Dropbox. Os dados devem permanecer sob seu próprio controle
• Gestão eficiente de espaço com compressão, deduplicação etc.
• A quantidade de componentes adicionais necessários para operar deve ser mínima

Planos para a série

• Serão apresentados vários cenários de backup, os servidores realmente utilizados, configurações principais e diferentes softwares e tecnologias
• No próximo artigo da série, será mostrado como montar um servidor de backup baseado em FreeBSD

[GN⁺]

Comentários do Hacker News

• Em máquinas em que o backup obrigatoriamente precisa ser do tipo “push”, é necessário limitar o acesso para que só possam alcançar o próprio espaço; e, mais importante ainda, o servidor de backup deve manter snapshots do próprio filesystem por um certo período por questão de segurança. Assim, mesmo no pior cenário, em que a carga de trabalho seja comprometida, consiga acessar o servidor de backup e apague os backups para exigir resgate, ainda restarão snapshots no servidor. O método de que mais gosto é permitir que o cliente apenas grave novos backups e não possa apagar nada; a exclusão fica para um processo separado, manual ou via cron. Isso pode ser implementado em rsync/ssh com o recurso de allowed command em .ssh/authorized_keys.

  • Eu uso as duas abordagens. É preciso manter backup em dois lugares, mas essa estrutura de backup duplo já era algo que eu buscava. As fontes de backup fazem push para uma localização intermediária, e o repositório principal de backup faz pull a partir dela. A localização intermediária guarda snapshots com capacidade pequena, mas o storage principal e as fontes não se autenticam entre si de forma alguma; cada um só consegue autenticar com a localização intermediária, sem autenticação reversa. Mesmo que um ou dois desses três pontos sejam comprometidos, há boa chance de o restante continuar seguro. O backup de certificados é tratado totalmente à parte para evitar que tudo acabe armazenado em servidores conectados à internet. Os dados realmente importantes ainda recebem uma camada extra com backup offline. Essa separação de arquitetura torna a verificação real dos backups mais trabalhosa, mas o storage de backup valida checksums periodicamente e envia os resultados ao host intermediário, comparando com os hashes gerados no host de origem para detectar eventos de corrupção. No fim, isso vira uma espécie de backup “soft offline”, em que a origem não consegue danificar diretamente os próprios snapshots de backup.

  • Outra opção é usar um contêiner separado ou um usuário dedicado a backup. Com systemd-nspawn, por exemplo, dá para usar como uma espécie de chroot jail leve e até impedir a execução de rm lá dentro. É só criar um chroot com pacman/pacstrap, depois gerenciar com systemd-nspawn/machinectl. Essa abordagem é bem flexível porque, como no systemd normal, permite vários controles: controle de acesso, restrição de caminhos de arquivos, limites de memória/CPU, permitir acesso apenas de determinadas faixas de IP, granularidade nas condições de boot etc. Também dá para aproveitar subvolumes BTRFS e, se necessário, isolar tudo completamente com systemd-vmspawn. Automatizar clonagem com importctl também é bem conveniente.

  • Eu prefiro um modelo de pull em que “o servidor de backup não tem permissão nenhuma sobre o servidor de origem”. Mesmo que o servidor em produção seja comprometido com acesso root, o sistema de backup não é afetado.

  • Estou usando rclone copy para backup e só com chaves de API sem permissão para apagar objetos. Se sincronizar com algo como rclone sync, pode acabar apagando tudo, então assim é mais seguro.

  • Eu gostaria que o syncoid tivesse uma opção em que “o cliente só copia snapshots/backups e o servidor de backup gerencia as exclusões diretamente”. Hoje é preciso conceder permissão de exclusão, o que é uma pena.

• É impressionante como tanta gente não dá importância a backups. Isso vale para empresas grandes e pequenas. Uma empresa que consulto, com faturamento anual de 1 bilhão de euros, não tinha backup próprio e dependia apenas de cópias de disco feitas irregularmente pelo provedor do datacenter. Nunca tinham testado recuperação por conta própria. Pouco tempo atrás, por erro de um usuário, o banco de produção foi completamente destruído, e o backup mais recente era de 4 dias antes, então foi preciso recriar manualmente todas as transações desse intervalo. E, mesmo depois de um incidente desses, ninguém ficou chocado; a vida simplesmente seguiu normalmente.

  • Parece que, se isso não for realmente fatal para o negócio, muita gente acha aceitável.

  • Também é comum ver requisitos de backup serem complicados demais sem necessidade.

  • Talvez também existam questões legais. Por causa de processos ou obrigações de retenção legal, o próprio backup pode virar um fator de risco.

  • Isso é um efeito colateral de políticas de recuperação de desastre aprovadas em auditorias SOC 2. Na empresa em que trabalhei, revisamos as políticas de recuperação de desastre de todos os times, todas aprovadas em SOC 2, e a conclusão foi que, se acontecesse mesmo um desastre de grande porte, provavelmente seria mais rápido fechar a empresa e ir para casa do que restaurar tudo de verdade.

  • Se essa perda de 4 dias inteiros do banco de produção aconteceu mesmo, eu queria saber se os clientes não ficaram furiosos. Numa empresa desse tamanho, parece algo com potencial de impacto enorme, então fico curioso sobre como lidaram com isso na prática.

• Obrigado por compartilhar. Trabalho há 10 anos desenvolvendo software de backup e recuperação de desastres, e há uma máxima que sempre aparece: “eu não diria a um amigo para construir sua própria solução de backup/DR”. Montar BCDR está cheio de armadilhas fáceis de ignorar. Queria compartilhar alguns pontos-chave. Backup não é “recuperação de desastre”. Numa falha real, a restauração precisa acontecer em minutos ou poucas horas para preservar a confiança no negócio. O que importa são RTO e RPO. Replicação de arquivos via cópia com rsync não é backup pontual, porque o filesystem continua mudando o tempo todo. Para um backup pontual de verdade, é preciso um backup “crash-consistent” ou “application-consistent”; neste último, a aplicação importante grava o estado em disco e é pausada durante o backup. Recursos como Microsoft VSS existem exatamente para isso. Nunca se deve confiar cegamente em cópias com rsync ou até mesmo em backups crash-consistent. Em storage, a lei de Murphy sempre se aplica, então é indispensável ter backups em vários lugares, a estratégia 3-2-1. Pela minha experiência, todo tipo de disco falha. NVMe SSD > SSD > HDD em durabilidade, mas não há exceções. Eu escreveria mais, mas já está tarde, então fico por aqui.

  • A analogia do 3-2-1 é de outra época. Hoje a capacidade de armazenar dados em lugares diferentes é praticamente ilimitada, então snapshots locais, replicação remota e backups duplos ou triplos em formatos distintos são ainda mais importantes. Eu uso snapshots nativos com zfs e mais Borg por cima, e com essa combinação estou coberto para praticamente qualquer desastre.

  • Essa máxima me lembrou algo parecido que ouvi num show do Alice in Chains. Soluções BCDR são um símbolo de confiança entre empresas. Esses sistemas protegem volumes de dados na casa de dezenas ou centenas de trilhões, e, se eu fosse CTO, nunca deixaria o backup da empresa nas mãos de uma abordagem open source. O gasto corporativo em TI cresce de forma gradual conforme o valor dos ativos e a estratégia anti-vendor lock-in. Pela experiência de profissionais da área, o ponto central contra ransomware é imutabilidade, backup WORM. Também já vi muitos casos de problemas em TI governamental por descumprimento regulatório. Fornecedores de BCDR adoram vender ransomware como argumento comercial, mas a imutabilidade de verdade se prova quando há replicação de dados em vários ambientes. É aí que a estratégia 3-2-1 mostra seu valor. Gostaria de ouvir mais opiniões sobre outros princípios de backup.

  • Para quem usa NAS, é melhor não usar discos do mesmo fabricante e do mesmo modelo nos dois lados.

  • Concordo totalmente com a ideia de “backup em vários lugares é obrigatório (3-2-1)”. Mas, para a maioria das pessoas, o “1” (off-site) é impraticável, e no fim deixa de fazer sentido montar a própria solução a menos que você use um serviço de backup. Eu não conheço ninguém fora da minha cidade que vá manter um computador ligado 24 horas por dia para mim.

  • Sobre “nunca se deve confiar em cópia com rsync ou mesmo em backup crash-consistent”, isso leva à conclusão de que, como qualquer sistema/serviço pode ser reconstituído com ferramentas de infraestrutura, só é preciso fazer backup ativo do banco de dados e do armazenamento de arquivos/objetos. Fazer backup da VM inteira é complicado e, no fundo, pouco útil.

• O texto é bom e bem organizado, mas senti falta de um ponto importante: um sistema de backup realmente bom precisa deixar claros a velocidade e o procedimento de recuperação. Já vi várias vezes casos em que as pessoas se sentem seguras porque “o backup está funcionando”, mas, quando chega a hora de restaurar, só parte dos dados volta ou o processo leva vários dias, causando prejuízo enorme. Há uma ferramenta chamada restic que permite backup em snapshots com deduplicação por arquivo, o que é útil quando não se tem um filesystem com snapshots como o ZFS. E, quando o backup é no modelo “push”, ransomware pode apagar o backup também, então o certo seria o modelo “pull”. Se for push, eu preferiria usar mídia somente leitura, como Bluray, ou no mínimo algo como auto-snapshot/ZFS para permitir recuperação em um ponto no tempo.

  • Mesmo que ransomware consiga apagar backups do tipo push, isso não é problema se as permissões do servidor forem bem restritas. Borg e Restic conseguem garantir append-only via ssh, e localmente eu faço rotação de discos de backup offline como última linha de defesa. O método prático está aqui.

  • Fico na dúvida se, no modo append-only do restic, fazendo pruning periodicamente apenas no lado do servidor, já não seria suficiente sem precisar de uma arquitetura pull. Pelo que sei, essa é a recomendação oficial do restic contra ransomware.

  • “Velocidade de recuperação” realmente depende muito do requisito. Se o backup das fotos da família levar 6 meses para ser restaurado, para mim está tudo bem.

  • Em vez de mídia somente leitura, um servidor push com permissões restritas também é uma alternativa. Por exemplo, permitir no ssh apenas scp, restringir a um ambiente chroot e fazer backup em rotação diária de diretórios; assim, mesmo com ransomware, não dá para apagar dados antigos. Meu procedimento de backup usa exatamente um servidor ssh que só permite chroot + scp, e ainda mantenho mídia somente leitura em paralelo.

• Eu nem preciso de um sistema de backup separado; para mim, bastaria um jeito padronizado e eficiente de reunir 25 anos de fotos de 4 pessoas da família — celular, câmera, downloads, digitalizações etc. — mas ainda não encontrei uma solução realmente satisfatória.

  • Eu hospedo o Immich no meu NAS e faço backup diário da mídia e do dump do banco do Immich para o AWS S3 Deep Archive. O Immich já entrega bem os recursos do Google Photos, e, se você jogar fotos e digitalizações do desktop no NAS, ele importa tudo automaticamente. Para usuários do HN, não é algo difícil de configurar.

  • Brincando se “25 anos de fotos” é uma unidade de medida norte-americana, eu diria que, na prática, você precisa sim de um sistema de backup. Eu rodo syncthing em malha entre gnu/linux/windows/android, tiro snapshots regulares do arquivo em duas VMs Debian e ainda faço backup secundário com borgbackup. Meu RPO é de 24 horas, mas eu poderia reduzir se quisesse. O problema é que, em dispositivos Apple, o syncthing não roda em segundo plano, então essa configuração não encaixa bem. No meu caso, são 500 GB de fotos e dezenas ou centenas de GB de outros documentos, mas o backup baseado em diff continua eficiente.

  • Downloads e digitalizações, se não forem realmente importantes, no fim são dados descartáveis. Eu sincronizo celular e câmera com Nextcloud e deixo o backup funcionar apenas dentro da rede doméstica. Depois o NAS faz backup diário e checagem de integridade. A etapa final é usar um backup em nuvem confiável ou um disco na casa de outra pessoa. Aí você fecha até o backup secundário.

  • Soluções self-hosted como PhotoPrism ou Immich ajudam bastante com deduplicação, busca e etiquetagem de fotos. Para backup em nuvem, dá para usar Backblaze B2 + Cryptomator com armazenamento criptografado e script próprio de upload. Sai por volta de US$ 1 por TB por mês.

  • Eu uso syncthing e, embora oficialmente o Android não seja suportado, com uma versão fork funciona bem. Além disso, recomendo ente.io ou Immich self-hosted para backup de fotos. Documentos eu prefiro gerenciar separadamente com algo como paperless ngx.

• O Dirvish é um wrapper leve para rsync que realmente vale a pena experimentar. Ele oferece recursos excelentes como rotação, incremental, retenção, scripts de pré e pós-processamento etc. Salvou meus dados por mais de 20 anos. Também combina muito bem com os pontos levantados no artigo. site oficial do dirvish, site oficial do rsync

  • Fiquei curioso: em que exatamente o dirvish é mais fácil ou melhor do que o rsync puro?

• Eu adoto um método bem preguiçoso e, ainda assim, consigo me proteger de falha de hardware e até roubo. Uso armazenamento temporário dentro do desktop, disco externo em casa e disco externo off-site — todos Samsung T7 Shield. Faço cópia diária do temporário ou após o trabalho com robocopy /MIR, backup semanal para o disco externo e, uma vez por mês, troco o disco externo que fica fora de casa.

  • Os discos externos precisam ser de lotes diferentes, ou melhor ainda, modelos diferentes. Se forem do mesmo modelo e mesmo lote, a chance de falharem juntos costuma ser alta, especialmente quando você joga uma carga pesada de recuperação em cima deles.

• O timing foi bom, então compartilho minha configuração do archlinux e minha estratégia de backup. Também publiquei scripts de automação de configuração/backup e uma camada de automação para borg.

  • Eu automatizei com python + borg snapshots de 51 block devices do SAN, backup de 71 filesystems e sincronização com S3. A restauração foi testada na prática a partir de um local off-site, e até o boot das VMs funcionou sem problemas. A automação ainda é complexa e inacabada, então a recuperação é lenta, mas consegui montar tudo com custo muito baixo. Borg é realmente muito poderoso. Isso é algo que qualquer um pode tentar e, no fim, sai muito econômico.

• Meus dados realmente valiosos somam menos de 100 MiB, então faço backup duas vezes por semana só dos caminhos selecionados com tar + compressão + criptografia, mantenho uma rotação de alguns meses e guardo cópias dentro e fora de casa. Quase não exige verificação nem manutenção, e com algumas linhas de script em sh isso automatiza sem dor de cabeça.

  • Se eu morresse de repente amanhã, vale a pena pensar em quais dados minha família e meus descendentes realmente precisariam recuperar. Talvez, em vez de centenas de milhares de arquivos, bastem só algumas fotos, vídeos e textos essenciais.

  • Esse comentário me fez repensar quais dados são realmente valiosos para mim. Minhas fotos ocupam no mínimo alguns GB mesmo comprimidas; contatos e outras coisas menos importantes são pequenos; no geral, eu aceitaria perder quase todo o resto. Eu provavelmente preciso guardar melhor minhas chaves de recuperação, embora curiosamente as contas mais importantes nem tenham chave de recuperação. Só as fotos já chegam perto de 2 TB, triste destino de quem fotografa por hobby.

• A parte mais difícil da consistência de backup é que fazer backup consistente de dados de aplicação sem derrubar o serviço é, na prática, quase impossível. Com snapshots de disco, sempre existe a chance de capturar um serviço no meio de uma gravação, então a restauração pode voltar já corrompida. Dumps de banco aliviam bastante esse problema, mas muitas vezes precisam ser feitos de fora do serviço, então podem ocorrer durante consultas em andamento. Se alguém tiver experiência prática com isso, eu gostaria muito de ouvir.

  • Em geral, bancos de dados são robustos o bastante para que snapshots de disco tirados a qualquer momento sejam suficientes como backup. O que me preocuparia são situações especiais, como cache sem bateria, mas em nuvem e em infraestruturas mais modernas isso quase não existe mais.

  • Fora o banco, a estratégia também depende de haver mais estado de aplicação para capturar, por exemplo se cache também precisa ser salvo. pg_dump/mysqldump realmente permitem snapshots seguros de banco em produção, mas podem ser lentos e gerar dumps grandes. Para evitar isso, já vi em grandes bancos PostgreSQL a prática de manter uma réplica read-only só para backup, pausar a replicação, executar o backup e depois retomar a replicação.