Backup e Restauração de Shards em Nós Cosmos: Tutorial Prático

Em operações de blockchain, proteger o estado de um nó Cosmos é essencial para reduzir downtime, evitar perda de dados e garantir que validadores possam voltar a operar com segurança. Este tutorial apresenta um fluxo prático de backup e restauração de shards em nós Cosmos, com foco em arquivos de banco de dados, consistência de snapshot e verificação de integridade.

O que significa shard no contexto Cosmos

No ecossistema Cosmos, o termo shard é frequentemente usado para descrever partes dos arquivos de banco de dados que compõem o estado do nó. Dependendo da configuração, o diretório de dados pode conter bancos como application.db, blockstore.db, state.db, tx_index.db e evidence.db, além de arquivos de consenso e chaves. Copiar esses arquivos com o serviço em execução pode gerar um backup inconsistente; por isso, a abordagem mais segura é parar o nó ou usar snapshot de filesystem.

Pré-requisitos

• Acesso SSH ao servidor com permissões administrativas.
• Espaço em disco suficiente para o arquivo compactado e para o backup temporário.
• Versão do binário Cosmos compatível com os dados que serão restaurados.
• Ferramentas como tar, zstd, sha256sum e, opcionalmente, rsync, rclone ou cliente S3.
• Janela de manutenção definida, especialmente para validadores.

1. Planejamento e janela de manutenção

Antes de iniciar, confirme o diretório home do nó. Neste exemplo, usaremos /home/cosmos/.gaia, mas o caminho pode variar conforme a rede e o binário utilizado. Também é recomendável registrar a altura atual do bloco e a versão do software para comparação após a restauração.

export NODE_HOME=/home/cosmos/.gaia
export BACKUP_DIR=/backup/cosmos
sudo mkdir -p $BACKUP_DIR

2. Parar o serviço com segurança

Pare o serviço do nó e aguarde o encerramento completo dos processos. O nome do serviço pode ser cosmovisor, gaiad ou outro definido pela sua operação.

sudo systemctl stop cosmovisor

Verifique se não há processos remanescentes:

pgrep -af gaiad

Atenção: em validadores, nunca mantenha duas instâncias com a mesma chave de validador em execução. Isso pode causar double-sign e penalidades graves.

3. Criar um backup consistente

Com o serviço parado, compacte o diretório data e, se necessário, o diretório config. O diretório data contém os bancos e o estado operacional; o diretório config contém configurações e chaves sensíveis.

sudo tar --numeric-owner -C $NODE_HOME -I 'zstd -T0 -19' -cf $BACKUP_DIR/gaia-data-$(date +%F-%H%M).tar.zst data config

Se preferir usar gzip, substitua o comando por:

sudo tar --numeric-owner -C $NODE_HOME -czf $BACKUP_DIR/gaia-data-$(date +%F-%H%M).tar.gz data config

Para grandes volumes de dados, considere fazer snapshot de filesystem com LVM, ZFS ou Btrfs. Isso permite criar uma cópia consistente sem manter o nó parado por muito tempo.

4. Verificar a integridade do backup

Liste o conteúdo do arquivo e gere um checksum para validação futura:

ls -lh $BACKUP_DIR
tar -tf $BACKUP_DIR/gaia-data-AAAA-MM-DD-HHMM.tar.zst | head
sha256sum $BACKUP_DIR/gaia-data-AAAA-MM-DD-HHMM.tar.zst | sudo tee $BACKUP_DIR/gaia-data-AAAA-MM-DD-HHMM.sha256

Guarde o checksum em local separado. Ele será usado para confirmar que o arquivo não foi corrompido durante a cópia ou o armazenamento.

5. Copiar para um local seguro

Armazene o backup fora do servidor principal. Use rsync, rclone ou um bucket S3 com criptografia. Sempre que possível, crie uma cópia adicional em outra região ou provedor.

rsync -avP $BACKUP_DIR/ usuario@servidor-backup:/backups/cosmos/

Para dados sensíveis, criptografe o arquivo com gpg ou age antes de enviá-lo para a nuvem.

6. Restaurar um nó Cosmos

Pare o serviço, mova o diretório atual para um local temporário e extraia o backup. Mantenha permissões e proprietário corretos.

sudo systemctl stop cosmovisor
sudo mv $NODE_HOME/data $NODE_HOME/data.old
sudo mv $NODE_HOME/config $NODE_HOME/config.old
sudo mkdir -p $NODE_HOME
sudo tar --numeric-owner -C $NODE_HOME -I 'zstd -d -T0' -xf $BACKUP_DIR/gaia-data-AAAA-MM-DD-HHMM.tar.zst
sudo chown -R cosmos:cosmos $NODE_HOME

Se a restauração for feita na mesma máquina, preserve as chaves originais e o estado mais recente do validador. Ao migrar para outro servidor, copie priv_validator_key.json apenas se for uma migração planejada e com o nó antigo permanentemente desligado. O arquivo priv_validator_state.json deve refletir o estado mais recente para evitar assinatura dupla.

7. Validar a sincronização

Inicie o serviço e acompanhe os logs:

sudo systemctl start cosmovisor
sudo journalctl -u cosmovisor -f

Verifique a altura e o status do nó:

curl -s localhost:26657/status

Confirme se o nó está sincronizando, se os peers estão conectados e se não há erros de banco de dados ou de consenso.

8. Limpeza e retenção

Após validar a restauração, remova diretórios temporários antigos e aplique uma política de retenção. Mantenha pelo menos um backup recente, um backup semanal e um backup antes de upgrades críticos.

sudo rm -rf $NODE_HOME/data.old $NODE_HOME/config.old

Solução de problemas

• Falha de checksum: refaça o download ou a cópia do backup.
• Erro de permissões: ajuste o proprietário com chown -R cosmos:cosmos.
• Versão incompatível: use a mesma versão do binário ou siga o procedimento de migração recomendado pela rede.
• Banco inconsistente: restaure novamente a partir de um backup criado com o serviço parado ou use snapshot de filesystem.
• Double-sign: nunca execute dois nós com a mesma chave de validador; mantenha o estado do validador atualizado.

Boas práticas

• Automatize o backup com scripts e monitore o sucesso da tarefa.
• Teste a restauração periodicamente em ambiente separado.
• Criptografe backups que contenham chaves privadas.
• Armazene cópias offsite e com versionamento.
• Faça backup antes de atualizações de software e mudanças de configuração.

Conclusão

Um backup consistente de shards e bancos de dados é uma camada essencial de proteção para qualquer operador de nó Cosmos. Ao parar o serviço, compactar os dados corretamente, verificar checksums e testar a restauração, sua equipe reduz riscos de perda de estado, downtime prolongado e penalidades em validadores. O processo deve ser documentado, automatizado e revisado regularmente.