Backup de Instância Mastodon: O que um Administrador Deve Executar Diariamente

Gerenciar uma instância Mastodon significa ser responsável pelos dados dos usuários, arquivos de mídia e integridade do banco de dados. Uma única falha no servidor ou evento de corrupção pode apagar meses de postagens, contas e relacionamentos se você não tiver backup. Muitos administradores confiam apenas em dumps do banco e esquecem das mídias ou arquivos de configuração. Este artigo explica exatamente quais componentes precisam de backup diário, as ferramentas para automatizá-los e como verificar se seus backups realmente funcionam.

Por que o Mastodon Exige Backups Separados para Banco, Mídia e Config

O Mastodon armazena dados em três locais separados no servidor. O banco PostgreSQL contém dados estruturados: contas, status, seguidores, bloqueios e configurações. Arquivos de mídia como imagens e vídeos residem no sistema de arquivos em /opt/mastodon/public/system. Segredos de configuração ficam no arquivo .env.production. Uma estratégia de backup deve cobrir todos os três, pois perder qualquer um torna a recuperação completa impossível.

O banco de dados é o componente mais crítico. Sem ele, você não tem registros de quem se inscreveu, o que postou ou quem segue. Um dump PostgreSQL usando pg_dump cria um arquivo SQL de texto simples que pode ser restaurado em qualquer servidor PostgreSQL da mesma versão principal. Arquivos de mídia são menos críticos para a funcionalidade básica, mas os usuários esperam que seus avatares e imagens enviadas sobrevivam a uma restauração.

Arquivos de configuração contêm segredos que o Mastodon usa para criptografar sessões e se comunicar com serviços externos como armazenamento de objetos. Se você perder .env.production, precisará regenerar todos os segredos, o que invalida sessões de usuário existentes e chaves de federação. Backups diários de todos os três componentes são o padrão mínimo para uma instância Mastodon em produção.

Procedimento de Backup Diário para Instância Mastodon

O procedimento a seguir assume uma instalação padrão do Mastodon no Ubuntu ou Debian com PostgreSQL e systemd. Ajuste os caminhos se sua instância usar um diretório diferente ou configuração conteinerizada.

1. Pare os serviços Mastodon para evitar alterações de dados durante o backup
   Execute sudo systemctl stop mastodon-web mastodon-sidekiq mastodon-streaming. Isso garante que nenhum novo toot, seguidor ou upload de mídia ocorra enquanto o backup é executado.
2. Crie o dump do banco usando pg_dump
   Execute sudo -u postgres pg_dump -Fc mastodon_production > /backup/mastodon_db_$(date +%Y%m%d).dump. A flag -Fc cria um formato customizado compactado que é mais rápido de restaurar e menor que SQL simples.
3. Arquive os arquivos de configuração
   Execute sudo tar -czf /backup/mastodon_config_$(date +%Y%m%d).tar.gz /opt/mastodon/.env.production /opt/mastodon/nginx.conf. Inclua quaisquer arquivos personalizados de nginx ou systemd.
4. Faça backup dos arquivos de mídia
   Execute sudo tar -czf /backup/mastodon_media_$(date +%Y%m%d).tar.gz /opt/mastodon/public/system. Para instâncias grandes, considere usar rsync em vez de tar para economizar largura de banda em backups incrementais.
5. Reinicie os serviços Mastodon
   Execute sudo systemctl start mastodon-web mastodon-sidekiq mastodon-streaming. Verifique com sudo systemctl status mastodon-web se todos os serviços estão ativos.
6. Copie os backups para um local externo
   Use rclone copy /backup remote:backup-bucket/mastodon/ ou rsync -avz /backup/ user@backup-server:/backup/mastodon/. O armazenamento externo protege contra falhas de hardware do servidor ou interrupções no data center.

Erros Comuns de Backup e Como Evitá-los

Fazer backup do banco enquanto os serviços estão em execução

Um dump de banco ao vivo pode capturar uma transação parcialmente confirmada. Isso cria um backup que restaura corretamente, mas contém dados inconsistentes, como um toot que referencia uma conta inexistente. Sempre pare os serviços Mastodon antes do dump, ou use pg_dump --lock-wait-timeout=10 para impor um tempo de espera em locks.

Esquecer de fazer backup do arquivo .env.production

Sem a chave secreta base, o Mastodon não consegue descriptografar as sessões dos usuários. Os usuários precisam fazer login novamente e as chaves de federação são invalidadas. Armazene o arquivo .env.production em um arquivo de backup separado do banco para que você possa restaurá-lo sem restaurar todo o sistema de arquivos.

Não testar a restauração do backup

Um backup que nunca foi restaurado é um backup em que você não pode confiar. Configure um ambiente de teste em um servidor separado ou máquina virtual. Restaure o banco, a configuração e os arquivos de mídia e verifique se a instância inicia e as contas de usuário aparecem corretamente. Execute este teste mensalmente.

Dump do Banco vs Backup do Sistema de Arquivos: O que Cada Um Cobre

Item	pg_dump (Banco)	Backup do Sistema de Arquivos (tar/rsync)
Contas e perfis	Sim	Não
Status e respostas	Sim	Não
Seguidores e solicitações de seguimento	Sim	Não
Arquivos de mídia (avatares, cabeçalhos, anexos)	Não	Sim
Segredos de configuração	Não	Sim
Configuração do Nginx ou proxy reverso	Não	Sim

A tabela mostra que nenhum método sozinho é suficiente. Uma estratégia de backup completa usa ambos: pg_dump para o banco e backup do sistema de arquivos para mídia e configuração.

Agora você conhece os três componentes que exigem backup diário: o banco PostgreSQL, o diretório de mídia e o arquivo de configuração .env.production. Automatize esse processo com um cron job que executa as etapas acima a cada 24 horas. Em seguida, configure um teste de restauração mensal em um servidor de staging para confirmar que seus backups são válidos. Use rclone com criptografia para armazenar backups em um provedor de nuvem separado para máxima segurança.