Recuperação de Desastres

Se um host morre, uma restauração dá errado, ou você precisa mover o Chinaski a uma nova máquina, este é o runbook. Três camadas de backup existem , backups de timer de nível de sistema, backups de arquivo no app com uma restauração de um clique, e uma restauração de envie-seu-próprio-arquivo , e saber qual alcançar é a maior parte do trabalho.

O que você deve ter antes de o desastre chegar

O backup diário de sistema (backup.sh sob systemd): um snapshot do banco de dados à prova de WAL, gzip, em /var/backups/chinaski<N>/ (verificado por integridade antes de ser mantido, modo 0600, guardado 14 dias por padrão) mais um espelho rsync do diretório de mídia.
Backups no app (Admin → Backups): arquivos chinaski_backup_<timestamp>.tar.gz completos contendo o banco de dados, mídia, temas e templates de site , criados manualmente, automaticamente num agendamento diário ou semanal que você define na aba Backups, e opcionalmente enviados a um bucket DigitalOcean Spaces.
O arquivo de env do host antigo (/etc/chinaski<N>/env com CHINASKI_SECRET, LISTEN_URL) , veja o aviso de “mesmo segredo” abaixo. Faça backup dele agora; não está no banco de dados e não está no tar.gz.

Restaurar no lugar (o caso comum)

De Admin → Backups, faça upload de um chinaski_backup_*.tar.gz:

Os uploads de restauração são limitados a 50 MiB.
Use dry run primeiro: ele coloca o arquivo em estágio e prévia o que vai mudar, então um clique de confirmação executa a restauração real.
A restauração valida o arquivo (um manifest de backup deve corresponder), então o aplica numa ordem segura: o banco de dados é restaurado atomicamente primeiro, então o diretório de mídia é trocado (com rollback se a troca falha), então temas e templates de site são restaurados , falhas ali são reportadas como avisos, não abortos totais.
Se o backup foi feito por uma versão de schema diferente da aplicação em execução, a restauração se recusa em vez de correr risco de corrupção; atualize a aplicação (ou a versão que fez o backup) em vez disso.
Opções para restaurar: upload do seu navegador, ou restaurar diretamente de um backup guardado no Spaces se o Spaces estiver configurado. Restaurações automáticas por API também estão disponíveis (mesmas regras) para scripts.
O que a restauração toca é visível no audit log; restaurações com falha deixam o site inalterado.

Reconstruindo um host perdido

Instale um Chinaski fresco no novo host com o instalador padrão (mesmo padrão de nome de instância). Isso cria o usuário de serviço, um banco de dados vazio e um novo arquivo de env.
Restaure o arquivo de env, não misture segredos. Copie o antigo /etc/chinaski<N>/env por cima do gerado antes de iniciar , ou espere que as configurações criptografadas (senha SMTP, segredos criptografados pela API) armazenadas num banco de dados restaurado fiquem indestrutíveis. A chave de criptografia dos segredos armazenados é derivada do CHINASKI_SECRET; restaurar um banco de dados sob um segredo diferente rende silenciosamente valores vazios em vez de um erro, então conserte o segredo do env primeiro e salve as configurações de novo depois, se não puder a mesma coisa.
Restaure os dados a partir dos backups que você guardou, o mais fácil via a restauração no app acima (envie o tar.gz).
Reconstrua o site estático (página do builder via “Rebuild” no dashboard de Settings) e ponha o site ao ar com as configurações de reverse proxy/TLS dos exemplos de deploy , então verifique que /health responde e o conteúdo renderiza.

Recuperando apenas com os backups de sistema

Se o caminho do tar.gz não estiver disponível, o snapshot diário do DB em /var/backups mais o espelho de mídia bastam:

Descomprima com gzip chinaski-<timestamp>.db.gz de volta ao caminho do banco de dados.
Sincronize o espelho de mídia de volta ao diretório de mídia da instância.
Anote a estreita janela de consistência documentada no próprio script de backup: o snapshot do DB é tomado antes do espelho de mídia, de modo que um arquivo de mídia apagado segundos antes do backup pode existir no DB mas não na árvore de mídia. O passo de reconciliação documentado é apagar linhas de media cujo arquivo esteja ausente do diretório de mídia restaurado (uma passada por nome de arquivo sobre a tabela de mídia), que os comentários do script de backup soletram.
Após restaurar: dispare um rebuild, verifique o /health, e tire um backup no app fresco para reestabelecer sua rede de segurança normal.

Guardrails que vale conhecer

As restaurações validam o manifest do backup e recusam de imediato divergências de versão de schema (“Restore aborted to prevent data corruption”) , de modo que um backup de uma versão bem mais antiga precisa ser restaurado na versão da aplicação correspondente.
A verificação de backup executa em cada arquivo criado por padrão (há uma configuração backup-verify; vem ligada a menos que explicitamente desligada).
Como os backups contêm hashes de senha e segredos de sessão, trate o diretório de backup e qualquer tar.gz baixado como sensível: o diretório de backup de sistema é forçado ao modo 0700 a cada execução, e os snapshots são armazenados no modo 0600.
Um backup de Spaces agendado executa apenas quando o Spaces está plenamente configurado (endpoint, bucket, access key, secret key) e apenas quando o modo air-gap está desligado.
A hora do último backup automático é visível na aba Backups, junto com a lista de backups locais , confira de relance após qualquer mudança no servidor.