Backup de dados

O que está incluído no serviço

Configuramos o backup automático de forma que a perda do servidor, uma invasão ou uma exclusão acidental não se transformem na perda do negócio. O trabalho inclui uma estratégia pela regra 3-2-1, snapshots criptografados e automáticos dos dados por agendamento, o envio das cópias para armazenamento em nuvem, uma política de retenção de versões e — obrigatoriamente — a verificação da restauração, não apenas da criação das cópias. Analisamos quais dados são de fato críticos: banco, arquivos de usuários, configuração do servidor — e incluímos nas cópias tudo o que é necessário para uma reconstrução completa do zero. A criptografia é configurada de modo que nem mesmo o dono do armazenamento consiga ler o conteúdo sem a sua chave. No fim, você recebe não a promessa de que "os backups estão sendo feitos", mas um procedimento testado pelo qual o serviço volta ao ar em minutos.

Como funciona na essência

O backup é construído sobre snapshots incrementais: depois da primeira cópia completa, o sistema salva apenas os blocos que mudaram, então os backups diários ocupam pouco espaço e são feitos rapidamente. A deduplicação remove os trechos de dados repetidos entre os snapshots, e a criptografia é feita do seu lado antes do envio para a nuvem, de modo que para fora vai um conjunto de bytes já ilegível. Cada snapshot é versionado, e é possível restaurar em qualquer ponto salvo, e não só no último. A regra 3-2-1 define o esquema de armazenamento: três cópias dos dados, em dois tipos diferentes de mídia, uma delas fora do local, para que um incêndio ou a falha da hospedagem não destruam tudo de uma vez. O passo-chave é a extração de teste periódica da cópia, porque um backup do qual nunca se restaurou não pode ser considerado um backup.

De onde veio a cultura de backup

É importante distinguir dois mecanismos diferentes. A tolerância a falhas de disco foi descrita pela equipe da Universidade da Califórnia em Berkeley — David Patterson, Garth Gibson e Randy Katz — no artigo sobre RAID em junho de 1988; o RAID protege contra a falha de um disco, mas não é uma cópia de segurança e não salva de uma exclusão ou de um ransomware. A ferramenta de cópia propriamente dita se tornou, por décadas, o rsync: Andrew Tridgell e Paul Mackerras apresentaram seu algoritmo e utilitário em 19 de junho de 1996, tornando pela primeira vez a transferência apenas das partes alteradas dos arquivos uma prática em massa. A própria fórmula de confiabilidade — a regra 3-2-1 — foi formulada pelo fotógrafo Peter Krogh em um livro sobre armazenamento digital, sintetizando a experiência de proteger arquivos insubstituíveis. Dessas três ideias — redundância, transferência incremental e armazenamento distribuído — nasceu a cultura moderna de backups, na qual nos apoiamos.

Por que a precisão da configuração é crítica

O backup é a área em que o erro se revela no momento mais inoportuno: quando os dados já foram perdidos e a cópia se mostra incompleta ou corrompida. A armadilha clássica é o backup ser criado por anos, mas a restauração nunca ser testada, e na hora da falha se descobre que na cópia não há o banco ou que a chave de criptografia se perdeu. Por isso o valor de engenharia do serviço não está em "ativar o backup", mas em um procedimento verificável: o que exatamente é copiado, com que frequência, para onde, quantas versões são mantidas e com que rapidez tudo volta ao ar. Uma proteção à parte são as cópias imutáveis, que um ransomware não consegue sobrescrever mesmo obtendo acesso ao servidor. Configuramos e documentamos todo o ciclo e verificamos a restauração na prática, em vez de acreditar que ela vai funcionar.

Com qual stack trabalhamos

A ferramenta principal é o restic: um sistema de backup com snapshots incrementais, deduplicação e criptografia de ponta a ponta, capaz de guardar as cópias em armazenamentos em nuvem pelo protocolo S3. Para parte das tarefas usamos o borg — um arquivador com deduplicação e modelo semelhante — e, para a simples sincronização de arquivos, o consagrado rsync. As cópias enviamos para um armazenamento de objetos compatível com S3 (por exemplo, uma nuvem com cobrança por volume e sem taxa por tráfego de saída), com chaves de acesso separadas por tarefa. A criptografia é configurada do lado do cliente, portanto o conteúdo das cópias fica indisponível até mesmo para o provedor de armazenamento. O stack é aberto e portável: o procedimento de restauração não depende de um fornecedor específico e permanece com você, junto com as chaves.

Quando surgiram as ferramentas-chave

As ferramentas de backup se consolidaram ao longo de mais de uma década. A ideia de redundância de disco RAID foi exposta no artigo da Universidade de Berkeley em junho de 1988. O utilitário rsync, que por muito tempo foi o padrão de transferência incremental, foi lançado em 19 de junho de 1996. Os sistemas modernos com deduplicação são mais novos: o restic, nossa ferramenta principal, foi publicado pelo autor Alexander Neumann como a versão 0.1.0 em 2015, e o borg se separou do projeto Attic nesse mesmo ano de 2015. Essas datas mostram que o backup criptografado e confiável com deduplicação é uma prática de engenharia madura, porém relativamente recente, que é preciso saber configurar para cada infraestrutura. Trabalhamos com as versões atuais e conhecemos as limitações de cada ferramenta, em vez de contar com um único botão universal.

Por que você pode confiar isso a nós

A experiência somada da nossa equipe em TI ultrapassa 45 anos, e conduzimos o backup a partir da nossa própria prática: nossos dados de produção vão criptografados em snapshots incrementais do restic para armazenamento em nuvem, e o procedimento de restauração está testado. Abordamos a tarefa como engenheiros: definimos os dados críticos, montamos o esquema 3-2-1, configuramos a criptografia e a retenção e, obrigatoriamente, executamos uma restauração de teste antes de declarar o backup como funcional. As chaves de criptografia e os acessos ficam com você — não mantemos os seus dados reféns na nossa conta. Avisamos com franqueza onde a economia nas cópias cria um risco real e onde a redundância é desnecessária. Como resultado, você recebe não uma linha "backup ativado", mas a capacidade verificada de restaurar o serviço em minutos após uma falha, invasão ou erro.