Planification et rétention des backups

Chinaski préserve votre contenu avec des backups sur deux axes : votre app ou votre serveur peuvent les planifier automatiquement, et l'un comme l'autre peut élaguer les anciens pour garder l'usage disque borné. Cette page explique les réglages de planification, ce qui s'exécute quand, et comment fonctionne la rétention.

Planifier les backups dans l'app

Sous Settings → Backups, vous pouvez activer les backups automatiques avec deux réglages :

Fréquence de backup : Off (défaut), Daily ou Weekly.
Heure de backup : l'heure locale d'exécution, 02:00 par défaut.

Quand c'est activé, l'app vérifie chaque minute et démarre un backup dès que l'horloge atteint l'heure configurée : une fois par jour pour un agenda Daily, ou au plus une fois tous les sept jours pour Weekly. Si plusieurs workers du serveur tournent, la coordination est gérée en interne : exactement un seul se déclenche, et les timestamps stockés dans les réglages empêchent une seconde exécution dans la même fenêtre.

Une exécution planifiée fait toute la pipeline seule :

Crée l'archive (snapshot de base de données plus fichiers applicatifs), la même procédure de snapshot sûre que les backups manuels ; les échecs sont consignés comme exécutions en échec dans l'historique des backups et dans le journal d'audit, et la fenêtre de temps sautée peut réessayer plus tard.
Vérifie l'archive : chaque backup est testé (contrôle de restauration) avant d'être placé dans le dossier des backups, sauf si vous désactivez la vérification. Chaque exécution consigne si la vérification a réussi, échoué ou été sautée.
Publie l'archive dans le dossier local backups et, si vous avez configuré le stockage cloud (une cible « Spaces » compatible S3 avec clés définies dans Settings → Backups), l'y pousse. En mode airgap rien ne quitte l'hôte. Si la clé de stockage cloud stockée ne peut pas être lue, la poussée distante est sautée plutôt que tentée à moitié configurée.

Rétention (combien de backups conserver)

Deux réglages dans Settings → Backups bornent le nombre de backups qui s'accumulent localement : tous deux à 0 par défaut, signifiant illimité (la rétention est opt-in) :

Garder les N derniers backups locaux : supprimer les archives les plus anciennes dès qu'il y en a plus de N.
Garder les backups locaux N jours : supprimer les archives plus vieilles que ce nombre de jours.

Détails à connaître :

Les deux règles se combinent généreusement, pas strictement : un fichier n'est supprimé que s'il est à la fois au-delà du dernier N et plus vieux que la limite en jours (« garder la règle la plus généreuse »).
La page de liste des backups prévisualise l'effet : vous pouvez voir combien de backups la politique courante supprimerait avant même qu'elle ne s'exécute.
Chaque suppression automatique est consignée dans le journal d'audit avec la politique qui l'a déclenchée.
Les balayages de rétention s'exécutent aussi une fois au démarrage de l'app, au cas où des backups se seraient accumulés pendant l'arrêt du serveur.
Le nommage des archives est horodaté (chinaski_backup_YYYYMMDD_HHMMSS.tar.gz), donc rien n'est écrasé silencieusement.

Le backup planifié côté serveur (niveau OS)

Il existe un second système de planification indépendant, livré pour les déploiements systemd :

Un timer quotidien (chinaski-backup@) se déclenche à 03:17 heure locale (minute choisie pour étaler la charge si plusieurs instances partagent un hôte), avec un petit délai aléatoire, et il rattrape si l'hôte était éteint au moment prévu.
Le script de backup prend un snapshot consistant de la base de données (sûr pendant que le CMS tourne), le compresse en gzip, vérifie le fichier et le stocke sous /var/backups/chinaski<instance>. Les fichiers media sont mirrorés à côté. Les snapshots de plus de 14 jours sont supprimés ; changez cela avec CHINASKI_BACKUP_RETENTION_DAYS dans le fichier env de l'instance (les chemins de backup et de media peuvent aussi être redéfinis).
Snapshot et media sont lisibles par le propriétaire seul (répertoire 0700).
Avant de faire confiance au timer, exécutez un backup manuel et confirmez que les deux parties se terminent.

Ne pas confondre les deux

Le scheduler applicatif et le timer OS font des travaux similaires avec des périmètres différents (archive complète vs snapshot base de données + media ; rétention gérée par l'app vs le défaut de 14 jours). Exécuter les deux est acceptable et conservateur. Quel que soit celui sur lequel vous comptez, surveillez l'historique de l'onglet Backups : chaque tentative planifiée consigne son issue (succès, échec, et de quel type de backup manual/scheduled/API/push il s'agissait), y compris les résultats de vérification pour chaque exécution.