Como Escolher uma Estratégia de Backup Efetiva

Introdução

Os backups são muito importantes para servidores em nuvem. Quer você esteja executando um único projeto com todos os seus dados armazenados em um único servidor, ou implantando diretamente do Git para VMs que são criadas e destruídas enquanto mantêm um conjunto mínimo de registros, você sempre deve planejar um cenário de falha. Isso pode significar muitas coisas diferentes, dependendo de quais aplicativos você está usando, quão importante é ter failover imediato e que tipo de problemas você está antecipando.

Neste guia, você explorará as diferentes abordagens para fornecer backups e redundância de dados. Como diferentes casos de uso exigem soluções diferentes, este artigo não poderá lhe dar uma resposta universal, mas você aprenderá o que é importante em diferentes cenários e quais implementações são mais adequadas para sua operação.

Na primeira parte deste guia, você examinará várias soluções de backup e revisará os méritos relativos de cada uma para que possa escolher a abordagem que se adapte ao seu ambiente. Na parte dois, você explorará opções de redundância.

Parte 1 — Qual a Diferença Entre Redundância e Backup?

As definições dos termos redundante e backup muitas vezes se sobrepõem e, em muitos casos, são confundidas. São dois conceitos distintos que estão relacionados, mas são diferentes. Algumas soluções fornecem ambos.

Redundância

A redundância de dados significa que há uma troca automática imediata em caso de problema no sistema. Uma troca automática significa que se um conjunto de dados (ou um host) se tornar indisponível, outra cópia perfeita é imediatamente colocada em produção para ocupar seu lugar. Isso resulta em quase nenhum tempo de inatividade perceptível, e a aplicação ou site pode continuar atendendo às solicitações como se nada tivesse acontecido. Enquanto isso, o administrador do sistema (neste caso, você) tem a oportunidade de corrigir o problema e devolver o sistema a um estado totalmente operacional.

No entanto, uma solução de redundância geralmente não é também uma solução de backup. O armazenamento redundante não necessariamente fornece proteção contra uma falha que afeta toda a máquina ou sistema. Por exemplo, se você tiver um RAID espelhado configurado (como RAID 1), seus dados são redundantes no sentido de que se uma unidade falhar, a outra ainda estará disponível. No entanto, se a própria máquina falhar, todos os seus dados podem ser perdidos.

Com soluções de redundância como o MySQL Group Replication, cada operação é tipicamente realizada em todas as cópias dos dados. Isso inclui operações maliciosas ou acidentais. Por definição, uma solução de backup também deve permitir que você restaure de um ponto anterior onde os dados são conhecidos por estar bons.

Backup

Em geral, você precisa manter backups funcionais para seus dados importantes. Dependendo da sua situação, isso poderia significar fazer backup de dados de aplicativos ou usuários, ou de um site inteiro ou máquina. A ideia por trás dos backups é que, no caso de uma perda de sistema, máquina ou dados, você possa restaurar, reimplantar ou acessar seus dados de outra forma. Restaurar a partir de um backup pode exigir tempo de inatividade, mas pode significar a diferença entre começar de um dia atrás e começar do zero. Tudo o que você não pode se dar ao luxo de perder deve, por definição, ser backup.

Em termos de métodos, existem vários níveis diferentes de backups. Estes podem ser camadas conforme necessário para dar conta de diferentes tipos de problemas. Por exemplo, você pode fazer backup de um arquivo de configuração antes de modificá-lo para poder reverter para suas configurações antigas caso ocorra algum problema. Isso é ideal para pequenas mudanças que você está monitorando ativamente. No entanto, essa configuração falharia no caso de uma falha de disco ou qualquer coisa mais complexa. Você também deve ter backups regulares e automatizados para um local remoto.

Os backups por si só não fornecem failover automático. Isso significa que suas falhas podem não custar nenhum dado (supondo que seus backups estejam 100% atualizados), mas podem custar tempo de atividade. Esta é uma das razões pelas quais a redundância e os backups são frequentemente usados em combinação um com o outro.

Parte 2 — Backup em Nível de Arquivo

Um dos tipos mais familiares de backup é o backup em nível de arquivo. Esse tipo de backup usa ferramentas normais de cópia em nível de sistema de arquivos para transferir arquivos para outro local ou dispositivo.

Como Usar o Comando cp

Em teoria, você poderia fazer backup de uma máquina Linux, como seu servidor em nuvem, com o comando cp. Isso copia arquivos de uma localização local para outra. Em um computador local, você poderia montar um drive removível e, em seguida, copiar arquivos para ele:

mount /dev/sdc /mnt/my-backup
cp -a /etc/* /mnt/my-backup
umount /dev/sdc

Neste exemplo, monta um disco removível, sdc, como /mnt/my-backup e, em seguida, copia o diretório /etc para o disco. Em seguida, desmonta o drive, que pode ser armazenado em outro lugar.

Como Usar o Rsync

A better alternative to cp is the rsync command. Rsync is a powerful tool that provides a wide array of options for replicating files and directories across many different environments, with built-in checksum validation and other features. Rsync can perform the equivalent of the cp operation above like so:

mount /dev/sdc /mnt/my-backup
rsync -azvP /etc/* /mnt/my-backup
umount /dev/sdc

-azvP é um conjunto típico de opções do Rsync. Como explicação do que cada uma delas faz:

• a enables “Archive Mode” for this copy operation, which preserves file modification times, owners, and so on. It is also the equivalent of providing each of the -rlptgoD options individually (yes, really). Notably, the -r option tells Rsync to recurse into subdirectories to copy nested files and folders as well. This option is common to many other copy operations, such as cp and scp.
• z compresses data during the transfer itself, if possible. This is useful for any transfers over slow connections, especially when transferring data that compresses very effectively, like logs and other text.
• v enables verbose mode, so you can read more details of your transfer while it is in progress.
• P tells Rsync to retain partial copies of any files that do not transfer completely, so that transfers can be resumed later.

Você pode revisar outras opções do rsync na sua página de manual.

Claro, em um ambiente de nuvem, você normalmente não estaria montando e copiando arquivos para um disco montado toda vez. O Rsync também pode realizar backups remotos pela rede, fornecendo uma sintaxe no estilo SSH. Isso funcionará em qualquer host para o qual você possa fazer SSH, desde que o Rsync esteja instalado em ambas as extremidades. Como o Rsync é considerado uma ferramenta central do Linux, essa é quase sempre uma suposição segura, mesmo se você estiver trabalhando localmente em uma máquina Mac ou Windows.

rsync -azvP /etc/* username@remote_host:/backup/

Isso fará backup do diretório /etc da máquina local para um diretório no remote_host localizado em /backup. Isso terá sucesso se você tiver permissão para escrever neste diretório e houver espaço disponível.

Você também pode revisar mais informações sobre como usar o Rsync para sincronizar diretórios locais e remotos.

Como Usar Outras Ferramentas de Backup

Embora cp e rsync sejam úteis e ubíquos, por si só não são uma solução completa. Para automatizar backups usando Rsync, seria necessário criar seus próprios procedimentos automatizados, agenda de backup, rotação de logs, e assim por diante. Embora isso possa ser apropriado para implantações muito pequenas que não desejam usar serviços externos, ou implantações muito grandes que possuem recursos dedicados para manter scripts muito granulares para diversos fins, muitos usuários podem querer investir em uma oferta de backup dedicada.

Bacula

Bacula é uma solução complexa e flexível que funciona em um modelo cliente-servidor. Bacula é projetado com conceitos separados de clientes, locais de backup e diretores (o componente que orquestra o backup real). Ele também configura cada tarefa de backup em uma unidade chamada “job”.

Isso permite uma configuração extremamente granular e flexível. Você pode fazer backup de vários clientes para um dispositivo de armazenamento, um cliente para vários dispositivos de armazenamento e modificar o esquema de backup adicionando nós ou ajustando seus detalhes. Ele funciona bem em um ambiente de rede e é expansível e modular, tornando-o ótimo para fazer backup de um site ou aplicativo distribuído em vários servidores.

Duplicity

Duplicity é outra ferramenta de backup de código aberto. Ele usa criptografia GPG por padrão para transferências.

O benefício óbvio de usar criptografia GPG para backups de arquivos é que os dados não são armazenados em texto simples. Apenas o proprietário da chave GPG pode descriptografar os dados. Isso fornece algum nível de segurança para compensar as medidas de segurança adicionais necessárias quando seus dados são armazenados em vários locais.

Outro benefício que pode não ser aparente para aqueles que não usam GPG regularmente é que cada transação precisa ser verificada para ser completamente precisa. O GPG, assim como o Rsync, impõe verificação de hash para garantir que não houve perda de dados durante a transferência. Isso significa que ao restaurar dados de um backup, você terá uma probabilidade significativamente menor de encontrar corrupção de arquivos.

Parte 3 — Backups em Nível de Bloco

A slightly less common, but important alternative to file-level backups are block-level backups. This style of backup is also known as “imaging” because it can be used to duplicate and restore entire devices. Block-level backups allow you to copy on a deeper level than a file. While a file-based backup might copy file1, file2, and file3 to a backup location, a block-based backup system would copy the entire “block” that those files reside on. Another way of explaining the same concept is to say that block-level backups copy information bit after bit. They do not know about the files that may span those bits.

Uma vantagem dos backups em nível de bloco é que eles são tipicamente mais rápidos. Enquanto os backups baseados em arquivos geralmente iniciam uma nova transferência para cada arquivo separado, um backup baseado em bloco transferirá blocos, significando que menos transferências não sequenciais precisam ser iniciadas para completar a cópia.

Usando dd para Realizar Backups em Nível de Bloco

O método mais comum de realizar backups em nível de bloco é com o utilitário dd. O dd pode ser usado para criar imagens de disco inteiras e também é frequentemente utilizado ao arquivar mídias removíveis como CDs ou DVDs. Isso significa que você pode fazer backup de uma partição ou disco para um único arquivo ou dispositivo bruto sem quaisquer etapas preliminares.

Para usar o dd, você precisa especificar uma localização de entrada e uma localização de saída, assim:

dd if=/path/of/original/device of=/path/to/place/backup

Neste cenário, o argumento if= especifica o dispositivo ou localização de entrada. O argumento of= especifica o arquivo ou localização de saída. Tenha cuidado para não confundir estes, ou você poderia apagar um disco inteiro por engano.

Por exemplo, para fazer backup de uma partição contendo seus documentos, que está localizada em /dev/sda3, você pode criar uma imagem desse diretório fornecendo um caminho de saída para um arquivo .img:

dd if=/dev/sda3 of=~/documents.img

Parte 4 — Versionamento de Backups

Uma das principais motivações para fazer backup de dados é poder restaurar uma versão anterior de um arquivo no caso de uma mudança ou exclusão indesejada. Enquanto todos os mecanismos de backup mencionados até agora podem fornecer isso, você também pode implementar uma solução mais granular.

Por exemplo, uma maneira manual de fazer isso seria criar um backup de um arquivo antes de editá-lo no nano:

cp file1 file1.bak
nano file1

Você poderia até automatizar esse processo criando arquivos ocultos marcados com data e hora toda vez que modificar um arquivo com seu editor. Por exemplo, você poderia colocar isso no seu arquivo ~/.bashrc, para que toda vez que você execute o nano do seu shell bash (ou seja, $), ele crie automaticamente um backup marcado com o ano (%y), mês (%m), dia (%d), e assim por diante:

nano() { cp $1 .${1}.`date +%y-%m-%d_%H.%M.%S`.bak; /usr/bin/nano $1; }

Isso funcionaria até certo ponto se você editasse arquivos manualmente com o nano, mas é limitado em escopo e pode rapidamente encher um disco. Você pode ver como isso pode acabar sendo pior do que copiar manualmente os arquivos que você vai editar.

Uma alternativa que resolve muitos dos problemas inerentes a esse design é usar o Git como sistema de controle de versão. Embora tenha sido desenvolvido principalmente para focar na versionamento de texto simples, geralmente código-fonte, linha por linha, você pode usar o Git para rastrear quase qualquer tipo de arquivo. Para saber mais, você pode revisar Como usar o Git de forma eficaz.

Parte 5 — Backups em Nível de Servidor

A maioria dos provedores de hospedagem também oferecerá sua própria funcionalidade de backup opcional. A função de backup da DigitalOcean realiza regularmente backups automatizados para droplets que habilitaram esse serviço. Você pode ativar isso durante a criação do droplet marcando a caixa de seleção “Backups”.

Isso fará backup da imagem completa do seu servidor na nuvem regularmente. Isso significa que você pode implantar novamente a partir do backup ou usá-lo como base para novos droplets.

Para imagens pontuais do seu sistema, você também pode criar snapshots. Eles funcionam de maneira semelhante aos backups, mas não são automatizados. Embora seja possível tirar um snapshot de um sistema em execução em alguns contextos, nem sempre é recomendado, dependendo de como você está gravando no seu sistema de arquivos:

Você pode aprender mais sobre backups e snapshots da DigitalOcean na documentação de Containers e Imagens.

GitOps

Finalmente, vale ressaltar que existem algumas circunstâncias em que você não necessariamente estará buscando implementar backups em uma base por servidor. Por exemplo, se sua implantação segue os princípios do GitOps, você pode tratar muitos de seus servidores individuais na nuvem como descartáveis e, em vez disso, tratar fontes de dados remotas como repositórios Git como a fonte efetiva da verdade para seus dados. Implantações complexas e modernas como essa podem ser mais escaláveis e menos propensas a falhas em muitos casos. No entanto, você ainda vai querer implementar uma estratégia de backup para os seus próprios bancos de dados, ou para um servidor de log centralizado para o qual cada um desses servidores descartáveis possa estar enviando informações. Considere quais aspectos de sua implantação podem não precisar de backup e quais precisam.

Conclusão

Neste artigo, você explorou diversos conceitos e soluções de backup. Em seguida, você pode querer revisar soluções para habilitar redundância.