Sobre backups que falham e backups que funcionam
“Não é questão de se você vai perder dados, mas quando você vai perdê-los.”
Recentemente meu computador pessoal teve que ser reinstalado.
Essa máquina em questão rodava uma instância do Fedora Workstation 41 que foi posteriormente atualizada para a versão 42 da distribuição. A instalação padrão do Fedora formata as partições de sistema usando btrfs, o que me possibilitou configurar snapshots automáticos do disco através de um utilitário chamado btrbk. De tempos em tempos, o btrbk fazia um snapshot dos subvolumes “/” e “/home”, de modo que se algum problema acontecesse, bastaria aplicar um dos snapshots salvos e voilá, sistema recuperado.
Porém, havia uma pedra no caminho 🪨
O procedimento de restauração dos snapshots nunca foi testado. Eu confiei na documentação e na configuração que implementei no meu sistema. O fato de que os snapshots eram gerados tal como planejado foram, na época, suficientes para que eu inferisse que o processo de restauração funcionaria.
E é claro que as coisas deram errado.
O problema
Eu havia configurado os repositórios do Terra para instalar o Ghostty, um emulador de terminal rico em recursos e multiplataforma que usa interface de usuário nativa da plataforma (GTK no caso do Linux) e aceleração via GPU.
Tudo certo, tudo bonitinho, nada a declarar.
Acontece que por algum motivo que desconheço, os pacotes do Terra passaram a substituir os pacotes vindos do repositório oficial do Fedora. E com essas substituições, vieram também diversos problemas de dependências, um tipo de erro que me levou de volta as primeiras distribuições Linux que instalei por meados de 2000-2001.
Tentei trocar os pacotes que consegui identificar via “dnf swap”, porém a integridade e segurança do sistema já haviam sido comprometidas. Para corrigir isso, eu precisava voltar o estado da máquina para um ponto onde eu tivesse certeza de que os pacotes haviam sido entregues através dos repositórios da Fedora, remover os repositórios do Terra e então atualizar o sistema novamente.
Entra o btrbk.
Como eu havia comentado, o btrbk é uma ferramenta de backup para subvolumes btrfs. Ele aproveita os recursos específicos do sistema de arquivos btrfs para criar instantâneos atômicos (atomic snapshots) e transferi-los incrementalmente para os locais de backup configurados pelo usuário (via um arquivo de configuração).
Essa idéia não é nova: tanto o Windows quando o macOS possuem seus próprios sistemas de snapshots (Pontos de Restauraçao e Time Machine, respectivamente). Eu simplesmente reimplementei esse fluxo de trabalho no meu Fedora 🎩
Pois bem. Segui as instruções contidas na documentação da ferramenta e… nada aconteceu. Uma pequena mensagem de erro me mostra que o processo falhou e que o snapshot não pôde ser aplicado. Tentei outro snapshot e o mesmo erro aconteceu. Revisei o arquivo de configuração e tudo parecia certo. Tentei de novo e o sistema congelou. Reiniciei o sistema e ele voltou a dar sinais de vida, porém nenhum ponto de restauração pôde ser aplicado.
Pode ter sido uma configuração equivocada. Pode ter sido o upgrade do sistema que bagunçou alguma coisa e afetou o btrbk. Quem sabe um bug não reportado? Difícil dizer. No final, a única coisa que posso afirmar é que minha estratégia de backup não funcionou quando eu mais precisava.
Por um momento, sinto-me um cardiologista que aconselha os seus pacientes sobre os malefícios do tabaco, mas que ao chegar em casa mama um maço de Marlboro com a potência de uma turbina de avião. Como eu, um profissional de TI, que literalmente é pago para falar aos meus clientes que um backup não verificado é apenas uma ilusão de segurança, é pego com as calças na mão? Como eu pude ser tão burro?
A síndrome do impostor só não bateu mais forte porque ao menos eu segui uma das minhas próprias sugestões, a regra 3-2-1: mantenha 3 cópias dos seus dados, em 2 tipos diferentes de mídias, com 1 cópia off-site. Restaurar esse sistema daria um pouco mais de trabalho, mas tudo indicava que seria possível fazê-lo.
A solução
Resolvi começar com a reinstalação do sistema, utilizando as mesmas configurações do sistema antigo - basicamente segui a instalação padrão do Fedora, adicionalmente habilitando a criptografia dos volumes via LUKS (Linux Unified Key Setup).
Para restaurar o sistema integralmente, utilizei uma séria de ferramentas que já estavam configuradas no meu sistema antes da catástrofe acontecer. São elas:
Déjà Dup Backups - Uma das duas ferramentas de backup que fazem parte do GNOME Circle
Chezmoi - Gerenciados de dotfiles (os arquivos de configuração que ficam no seu diretório home, geralmente começando com “ponto”)
SaveDesktop - Ferramenta que salva uma série de informações sobre o seu desktop (ícones, fontes, extensões, flatpaks, etc)
Restaurar os arquivos do meu diretório home foi o primeiro passo. O Déjà Dup é capaz de utilizar a nuvem como destino da cópia de segurança, e ele não depende das contas online do GNOME para tal. Bastou instalar o flatpak, ir a aba de Restore do programa, configurar o aceso ao meu backend (no caso, OneDrive) e requisitar a versão e os arquivos que eu precisava para ter o meu home novamente populado com todos os meus artefatos de trabalho.
Tudo guardadinho na nuvem ☁️
Aproveitei o ensejo para restaurar um arquivo de configuração bastante especial: o chezmoi.toml é o arquivo de configuração do Chezmoi e nele estão gravadas as chaves AGE (Actually Good Encryption) que uso para criptografar todos os dotfiles que eu mando para um repositório privado no GitHub.
Restaurar esses arquivos também foi fácil. Criei uma chave SSH temporária e adicionei-a ao meu Github. Instalei o brew e na sequência instalei o chezmoi. Depois, bastou executar o seguinte comando:
Com os meus dotfiles restaurados, a vida começou a ficar uma pouco mais leve e divertida 🦦
Um dos arquivos gerenciados pelo chezmoi é o meu Brewfile. Brewfiles fornecem uma interface declarativa para instalar e atualizar pacotes com o Homebrew e iniciar serviços com brew services.
Bastou executar mais um comando:
E todos os meus taps (os repositórios do brew) , formulae (pacotes) e serviços estavam instalados sem maiores problemas!
Um brinde ao Homebrew!
Para completar, instalei o oh-my-zsh e o Ultimate Vim e as principais ferramentas e configurações estavam reimplementadas no novo sistema!
Ficaram faltando os meus flatpaks e as configurações do GNOME, mas eu tinha uma solução para isso 😉
Entra em cena o SaveDesktop. Essa pequena ferramenta não é perfeita (o backup periódico simplesmente não funciona) mas como eu sou disciplinado, eu executo-o toda vez que uma extensão do GNOME é atualizada.
Além das extensões, essa mini maravilha moderna permite salvar uma série de outros dados, a saber:
Ícones, fontes e temas
Configurações diversas do GNOME
Papéis de parede (incluindo papéis de parede dinâmicos, desde que o mesmo nome de usuário seja mantido)
Aplicativos Flatpak e seus respectivos dados de usuário
Outros itens relacionados ao seu ambiente de trabalho (por exemplo, extensões e applets do Cinnamon, widgets do KDE Plasma, extensões do Nautilus, dentre outros)
SaveDesktop em ação.
Importei o arquivo gerado pelo SaveDesktop através da aba Import (como é óbvio) e em segundos todos os itens faltantes estavam restaurados: as extensões do GNOME foram restauradas, bem como as suas configurações (uma grata surpresa, já que eu tinha uma série de customizações espalhadas por mais de 15 delas). Os flatpaks foram reinstalados e com exceção de alguns probleminhas com o NewsFlash (que precisou ser reinstalado e reconfigurado), tudo estava funcionando tal como antes do incidente.
Flatpaks são como pequenos anjos digitais.
Ainda precisei fazer alguns passos adicionais, como instalar o Visual Studio Code e ressincronizar as minhas configurações e habilitar as minhas chaves Yubico via PAM (Pluggable Authentication Modules), mas o principal foi que a cagada estava corrigida e eu voltei a ter meu sistema tal como ele deveria estar: recebendo as atualizações do repositório correto e com as configurações que coletei durante anos de uso do sistema aplicadas e funcionando!
Aprendizados
Apesar de tudo, consegui extrair alguns aprendizados novos bastante interessantes.
Por exemplo, você pode integrar a execução do brew bundle diretamente no Chezmoi. As instruções são para macOS, mas eu consegui configurar algo parecido em Linux. Você pode encontrá-las aqui, e o que eu fiz foi basicamente substituir o script run_before por um script run_after:
{{- if eq .chezmoi.os "Linux" -}}
#!/bin/bash
brew bundle --file $HOME/Brewfile
{{ end -}}Também atualizei o backup local que eu faço de tempos em tempos no meu sistema. Agora utilizo um disco externo de 64 GB formatado em F2FS. Para completar, criei uma regra udev que identifica quando o disco é montado no sistema e automaticamente executa o meu script de backup, que também foi atualizado para incluir uma série de diretórios que eram negligenciados inicialmente (armazenamento é muito barato hoje em dia; mais vale ter uma cópia de segurança gorda do que se arrepender depois). O que me lembra:
“Melhor ter e não precisar, do que precisar e não ter.”
Primeiro, você precisa de um script de backup. Você pode copiar o meu script aqui ou criar o seu próprio baseado nas suas necessidades.
Crie um wrapper para esse script e coloque-o em /usr/local/bin. No meu caso, o script tem o criativo nome de backup_wrapper (/usr/local/bin/backup_wrapper.sh):
#!/bin/bash # Log de atividades echo "$(date): Backup iniciado" >> /var/log/backup.log # Mais vale esperar um pouquinho antes de começar a execução do script sleep 10 # su - seu_usuario -c "/caminho/para/seu/script/de/backup.sh" >> /var/log/backup.log 2>&1 exit 0
Não esqueça de tornar os scripts executáveis:
$ sudo chmod +x /usr/local/bin/backup_wrapper.sh $ chmod +x /caminho/para/seu/script/de/backup.sh
Depois você precisa criar um arquivo com a regra udev referente ao backup:
$ sudo nano /etc/udev/rules.d/99-backup-pendrive.rules
Depois, inclua o seguinte código:
ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_UUID}=="UUID-DO-SEU-DISPOSITIVO", RUN+="/usr/bin/systemd-run --no-block /usr/local/bin/backup_wrapper.sh"Para descobrir o UUID do seu disco externo, basta executar “sudo blkid”.
Não esqueça de atualizar o subsistema do udev através dos seguintes comandos:
$ sudo udevadm control --reload-rules $ sudo udevadm trigger
Considerações finais: Por que o backup não é opcional
Quando pensamos em backup, não estamos falando apenas de uma medida técnica, mas de um seguro para nossas memórias, nosso trabalho e nossa tranquilidade. Assim como não dirigimos sem cinto de segurança, não devemos “dirigir” os nossos sistemas (sejam eles o seu PC ou até mesmo o servidor da empresa onde você trabalha) sem a proteção adequada para os nossos preciosos dados.
O investimento em uma estratégia de backup é minúsculo quando comparado ao valor incalculável do que protegemos. E com as opções disponíveis hoje—muitas delas livres e de código aberto—não há mais desculpas para adiar esta decisão.
Agora, tão importante quanto a estratégia de backup é testar os procedimentos (técnicos e funcionais) que você desenhou. Confie, mas verifique seus backups. Eles não existem até serem testados, lembre-se disso!
Espero que vocês tenham gostado dessa postagem. Se tiverem dúvidas ou quiserem complementar alguma informação, não deixem de comentar! E até a próxima!
