Como Escolher uma Estratégia de Backup Eficaz

Introdução

Os backups são muito importantes para servidores na 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 desativadas enquanto retê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, o quão importante é ter failover imediato e que tipo de problemas você está antecipando.

Neste guia, você explorará 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 única, 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 adapta 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 frequentemente se sobrepõem e, em muitos casos, são confundidas. Esses 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á um failover imediato no caso de um problema de sistema. Um failover significa que se um conjunto de dados (ou um host) se tornar indisponível, uma cópia perfeita é imediatamente substituída em produção para ocupar o seu lugar. Isso resulta em quase nenhum tempo de inatividade perceptível, e a aplicação ou site pode continuar a atender solicitações como se nada tivesse acontecido. Enquanto isso, o administrador do sistema (neste caso, você) tem a oportunidade de corrigir o problema e retornar 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 oferece 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 serão redundantes no sentido de que se um disco falhar, o outro 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 é normalmente realizada em cada cópia dos dados. Isso inclui operações maliciosas ou acidentais. Por definição, uma solução de backup também deve permitir que você restaure a partir de um ponto anterior onde os dados são conhecidos como bons.

Backup

Em geral, você precisa manter backups funcionais de seus dados importantes. Dependendo da sua situação, isso poderia significar fazer backup de dados de aplicativos ou usuários, ou de um site ou máquina inteira. A ideia por trás dos backups é que, em caso de perda de sistema, máquina ou dados, você pode restaurar, redesenhar ou acessar de outra forma seus dados. Restaurar a partir de um backup pode exigir tempo de inatividade, mas pode significar a diferença entre começar a partir 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 copiado.

Em termos de métodos, existem vários níveis diferentes de backups. Esses podem ser camadas conforme necessário para lidar com 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 alterações que você está monitorando ativamente. No entanto, essa configuração falharia no caso de uma falha de disco ou algo mais complexo. 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 redundância e backups são frequentemente usados em combinação um com o outro.

Parte 2 — Backup em Nível de Arquivo

Uma das formas mais familiares de fazer backup é um backup em nível de arquivo. Esse tipo de backup usa ferramentas normais de cópia de 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 na 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-se um disco removível, sdc, como /mnt/my-backup e então copia-se o diretório /etc para o disco. Em seguida, desmonta-se 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. Uma análise 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 sobre uma rede fornecendo 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/

Isto irá fazer 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, eles não são uma solução completa por si só. Para automatizar backups usando Rsync, você precisaria criar seus próprios procedimentos automatizados, agendamento de backup, rotação de logs, e assim por diante. Embora isso possa ser apropriado para alguns implantações muito pequenas que não desejam fazer uso de serviços externos, ou implantações muito grandes que têm recursos dedicados para manter scripts muito granulares para diversos fins, muitos usuários podem querer investir em uma oferta de backup dedicada.

Bacula

O Bacula é uma solução complexa e flexível que funciona em um modelo cliente-servidor. O 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

O 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 um certo 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. GPG, assim como o Rsync, aplica 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, o que significa que menos transferências não sequenciais precisam ser iniciadas para concluir a cópia.

Usando dd para Realizar Backups em Nível de Bloco

O método mais comum para realizar backups em nível de bloco é com a utilidade dd. O dd pode ser usado para criar imagens completas de disco e também é frequentemente usado 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

Nesse 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ê pode apagar um disco inteiro por engano.

Por exemplo, para fazer backup de uma partição contendo seus documentos, 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 — Backups com Versionamento

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

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

cp file1 file1.bak
nano file1

Você poderia até mesmo automatizar este processo criando arquivos ocultos carimbados com timestamp toda vez que você modificar um arquivo com seu editor. Por exemplo, você poderia colocar isso no seu arquivo ~/.bashrc, para que toda vez que você executar o nano a partir do seu shell bash (ou seja, $), ele automaticamente crie um backup carimbado com 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, na medida em que você edita os arquivos manualmente com o nano, mas é limitado em escopo e pode rapidamente encher um disco. Você pode ver como isso poderia acabar sendo pior do que copiar manualmente os arquivos que você pretende editar.

Uma alternativa que resolve muitos dos problemas inerentes a este design é usar o Git como um 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 Efetivamente.

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 têm este serviço ativado. Você pode ativá-lo 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 redeploy a partir do backup ou usá-lo como base para novos droplets.

Para imagens únicas 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 do DigitalOcean na documentação Containers e Imagens.

GitOps

Finalmente, vale ressaltar que há circunstâncias em que você não necessariamente estará procurando implementar backups em uma base por servidor. Por exemplo, se sua implantação seguir 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 seus próprios repositórios 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 vários conceitos e soluções de backup. Em seguida, você pode querer revisar soluções para habilitar redundância.