Sauvegarde et Récupération

Chinaski exécute trois couches de backup coopératives, chacune avec un rôle différent, si bien qu'aucune défaillance unique n'emmène votre site avec elle. Cette page vous oriente dans les couches et relie les pages détaillées.

Ensemble, elles couvrent la pile de résilience standard : des snapshots locaux fréquents pour une récupération rapide après des erreurs, des archives complètes in-app pour une recovery complète à un instant donné et des copies off-site, et, sur les tiers de base de données hébergés, une copie cloud off-site qui survit à la perte totale de la machine.

Les trois couches

• Le backup système quotidien: un timer systemd exécute backup.sh une fois par jour (03:17 par défaut, délibérément en heures creuses). Il prend un snapshot SQLite compatible WAL, le contrôle d'intégrité avant de le conserver, le compresse en gzip et le stocke dans /var/backups/chinaski<N>/ avec une rétention par défaut de 14 jours (configurable). Le répertoire media est mirroré séparément par rsync, car les fichiers media sont immuables après upload et un miroir peut se maintenir de façon incrémentale en toute sécurité.
• Les backups in-app (Admin → Backups) : des archives .tar.gz complètes contenant la base de données et le media et les thèmes et les templates de site. Créées manuellement, sur un agenda quotidien ou hebdomadaire, et (en option) poussées automatiquement vers un bucket DigitalOcean Spaces pour un stockage off-site. Chaque archive créée est vérifiée par défaut avant de compter.
• Les flux de restore: le côté restore vit avec les backups : téléverser une archive (avec un preview de dry-run et une étape de confirmation), restaurer depuis une archive stockée sur Spaces, ou restaurer à la main depuis le snapshot quotidien du système pendant la disaster recovery.

Ce qu'il y a dans un backup

Les snapshots au niveau système capturent la base de données (tout le contenu, les utilisateurs, les réglages, les logs) plus un miroir media. Les archives in-app capturent la base de données plus le media plus les thèmes plus les templates de site : tout ce dont le site est fait, dans un seul fichier que vous pouvez transporter vers un autre hôte. Les pages Daily/Spaces+restore détaillent le contenu exact de chaque couche.

Les chemins couverts par cette section

• Planification et rétention des backups: où vivent les planifications automatiques (cron/timers système et réglages de planification in-app), les molettes de rétention pour les snapshots de base de données comme pour les archives in-app locales, et le comportement de l'élagage.
• Backup manuel: les archives à un instant donné : contenu du fichier, création, téléchargement, suppression ; la mise en garde que les flux manuels font partie de la même pipeline de rétention/vérification.
• Restaurer: la surface de restore in-app : previews de dry-run, contrôle de version de schéma, restore de base de données atomique, remplacement de media par étapes ; ce que signifie « restore refused ».
• Reprise après sinistre: le runbook complet de reconstruction d'hôte : reconstruire Chinaski ailleurs à partir de ce que vous conservez déjà.

Posture de sécurité à connaître d'emblée

• La vérification est activée par défaut. Chaque archive in-app est extraite et validée après sa création ; une vérification en échec empêche une archive défectueuse d'être stockée.
• Sensible par conception: les archives contiennent des hash de mots de passe et des secrets chiffrés. Le répertoire de backup est resserré en mode 0700 à chaque exécution du backup système, les archives sont écrites en mode 0600, et les contrôles de restore sont réservés aux admins avec chaque restore audité.
• Protégez les credentials, pas seulement les données: restaurer une base de données dans une instance dont le CHINASKI_SECRET diffère fait perdre l'accès aux réglages chiffrés (mots de passe SMTP, secrets de webhook). Le fichier env (CHINASKI_SECRET, LISTEN_URL) est un artefact distinct que vous devriez copier lors de toute migration complète d'hôte ; il n'est pas dans les backups.
• Tout est audité: création, restore, suppression, élagage de rétention écrivent tous des entrées d'audit avec l'acteur et le nom du fichier.