Agendamento de Backup & Retenção

O Chinaski mantém o seu conteúdo seguro com backups em dois eixos: seu app ou seu servidor podem agendá-los automaticamente, e qualquer um pode podar os antigos para manter o uso de disco limitado. Esta página explica as configurações de agendamento, o que executa quando, e como a retenção funciona.

Agendando backups no app

Em Settings → Backups você pode habilitar backups automáticos com duas configurações:

Frequência de backup . Off (padrão), Diário, ou Semanal.
Horário de backup , a hora local em que executar, padrão 02:00.

Quando habilitado, o app checa a cada minuto e inicia um backup no instante em que o relógio atinge seu horário configurado , uma vez por dia para um agendamento Diário, ou no máximo uma vez a cada sete dias para o Semanal. Se vários workers do servidor estiverem executando, a coordenação é tratada internamente: exatamente um dispara, e timestamps armazenados nas configurações evitam uma segunda execução na mesma janela.

Uma execução agendada faz o pipeline inteiro sozinha:

Cria o arquivo (snapshot do banco de dados mais os arquivos da aplicação) , o mesmo procedimento seguro de snapshot que os backups manuais usam; falhas são registradas como execuções com falha no histórico de backups e no audit log, e a janela de tempo pulada pode tentar de novo depois.
Verifica o arquivo , cada backup é testado (checagem de restauração) antes de ser colocado na pasta de backups, a menos que você desligue a verificação. Cada execução registra se a verificação passou, falhou, ou foi pulada.
Publica o arquivo na pasta local de backups e, se você configurou armazenamento em nuvem (um alvo “Spaces” compatível com S3 com chaves definidas em Settings → Backups), o envia para lá. No modo airgap nada sai do host. Se a chave de armazenamento em nuvem armazenada não puder ser lida, o push remoto é pulado em vez de tentado meio-configurado.

Retenção (quantos backups manter)

Duas configurações em Settings → Backups delimitam quantos backups se acumulam localmente , ambas têm como padrão 0, significando ilimitado (a retenção é opt-in):

Manter os últimos N backups locais , apaga os arquivos mais antigos assim que existam mais que N.
Manter backups locais por N dias , apaga arquivos mais velhos que esse número de dias.

Detalhes que vale saber:

As duas regras se combinam generosamente, não estritamente: um arquivo só é apagado quando está tanto além dos últimos N quanto mais velho que o limite de dias (“manter o que for mais generoso”).
A página da lista de backups prévia o efeito: você pode ver quantos backups a política atual apagaria antes de ela um dia executar.
Cada exclusão automática é registrada no audit log com a política que a disparou.
Varreduras de retenção também executam uma vez quando o app inicia, caso os backups se tenham acumulado enquanto o servidor estava fora.
A nomenclatura dos arquivos é estampada com timestamp (chinaski_backup_YYYYMMDD_HHMMSS.tar.gz), então nada é sobrescrito silenciosamente.

O backup agendado do lado do servidor (nível de SO)

Há um segundo sistema de agendamento independente embarcado para deployments systemd:

Um timer diário (chinaski-backup@) dispara às 03:17 no horário local , minuto escolhido para espalhar a carga se múltiplas instâncias dividirem um host , com um pequeno atraso aleatório, e se recupera se o host estava desligado quando deveria ter executado.
O script de backup tira um snapshot consistente do banco de dados (seguro enquanto o CMS está ao vivo), comprime com gzip, verifica o arquivo, e o armazena sob /var/backups/chinaski<instance>. Os arquivos de mídia são espelhados ao lado. Snapshots mais velhos que 14 dias são apagados , mude isso com CHINASKI_BACKUP_RETENTION_DAYS no arquivo de env da instância (os caminhos de backup e mídia também podem ser sobrescritos).
Snapshot e mídia são legíveis apenas pelo dono (diretório 0700).
Antes de confiar no timer, execute um backup manual e confirme que ambas as partes completam.

Mantendo os dois separados

O scheduler da aplicação e o timer do SO fazem trabalhos similares com escopos diferentes (arquivo completo vs snapshot de banco + mídia; retenção gerenciada pelo app vs o padrão de 14 dias). Executar ambos é válido e conservador. Em qual você confiar: vigie o histórico da aba Backups , cada tentativa agendada registra seu desfecho (sucesso, falha, e que tipo de backup manual/agendado/API/push era), incluindo os resultados de verificação de cada execução.