Backup & Recuperação

O Chinaski mantém o conteúdo seguro com três camadas de backup cooperadoras, cada uma com um trabalho diferente , de modo que nenhuma falha isolada leve seu site embora. Esta página orienta você pelas camadas e aponta as páginas detalhadas.

Juntas elas cobrem o stack padrão de resiliência: snapshots locais frequentes para recuperação rápida após erros, arquivos completos no app para recuperação completa de ponto no tempo e cópias off-site, e , em plataformas de banco de dados hospedadas , uma cópia em nuvem off-site que sobrevive à perda total da máquina.

As três camadas

• O backup diário de sistema , um timer systemd executa o backup.sh uma vez por dia (padrão 03:17, deliberadamente fora do pico). Ele tira um snapshot do SQLite à prova contra WAL, faz uma checagem de integridade antes de mantê-lo, comprime com gzip, e o armazena em /var/backups/chinaski<N>/ com uma retenção padrão de 14 dias (configurável). O diretório de mídia é espelhado separadamente por rsync, porque os arquivos de mídia são imutáveis após o upload e um espelho é seguro de manter incrementalmente.
• Backups no app (Admin → Backups) , arquivos .tar.gz completos contendo o banco de dados e a mídia e os temas e os templates de site. Criados manualmente, em um agendamento diário ou semanal, e (opcionalmente) enviados automaticamente para um bucket DigitalOcean Spaces para armazenamento off-site. Cada arquivo criado é verificado por padrão antes de contar.
• Fluxos de restauração , o lado da restauração vive junto com os backups: enviar um arquivo (com uma prévia dry-run e um passo de confirmação), restaurar de um arquivo guardado no Spaces, ou restaurar à mão do snapshot diário do sistema durante a recuperação de desastres.

O que há em um backup

Os snapshots de nível de sistema capturam o banco de dados (todo o conteúdo, usuários, configurações, logs) mais um espelho de mídia. Os arquivos no app capturam o banco de dados mais mídia mais temas mais templates do site , tudo de que o site é feito, em um único arquivo que você pode mover para outro host. As páginas daily-and-Spaces+restore percorrem o conteúdo exato de cada camada.

Os caminhos que esta seção cobre

• Agendamento & Retenção , onde vivem os agendamentos automáticos (cron/timers do sistema e as configurações de agendamento no app), os knobs de retenção tanto para snapshots de banco de dados quanto para arquivos locais no app, e como a poda se comporta.
• Backup manual , arquivos de ponto no tempo: o que há no arquivo, criar, baixar, apagar; a cautela de que os fluxos manuais fazem parte do mesmo pipeline de retenção/verificação.
• Restaurar , a superfície de restauração no app: prévias dry-run, portão de versão de schema, restauração atômica do banco de dados, troca de mídia em estágios; o que “restore refused” significa.
• Recuperação de Desastres , o runbook completo de host: reconstruir o Chinaski em outro lugar a partir do que você já está guardando.

Postura de segurança que vale conhecer de início

• A verificação está ligada por padrão. Cada arquivo no app é extraído e validado após a criação; uma verificação com falha impede que um arquivo ruim seja armazenado.
• Sensível por design , os arquivos contêm hashes de senha e segredos criptografados. O diretório de backup é apertado para o modo 0700 a cada execução de backup de sistema, os arquivos são escritos no modo 0600, e os controles de restauração são apenas de admin, com cada restauração auditada.
• Proteja as credenciais, não apenas os dados , restaurar um banco de dados em uma instância cujo CHINASKI_SECRET difere perde o acesso às configurações criptografadas (senhas SMTP, segredos de webhook). O arquivo de env (CHINASKI_SECRET, LISTEN_URL) é um artefato separado que você deve copiar durante qualquer migração completa de host; ele não está dentro dos backups.
• Tudo é auditado , criação, restauração, exclusão, poda de retenção, todos gravam entradas de auditoria com o ator e o nome do arquivo.