Reprise après sinistre

Si un hôte meurt, qu'un restore tourne mal, ou que vous devez déplacer Chinaski vers une nouvelle machine, voici le runbook. Trois couches de backup existent : les backups du timer au niveau système, les backups d'archives in-app avec restore en un clic, et un restore d'archive-téléversée-par-vous ; et savoir laquelle saisir constitue l'essentiel du travail.

Ce que vous devriez avoir avant que le désastre frappe

Le backup système quotidien (backup.sh sous systemd) : un snapshot de la base de données compatible WAL compressé en gzip dans /var/backups/chinaski<N>/ (contrôlé d'intégrité avant d'être conservé, mode 0600, gardé 14 jours par défaut) plus un miroir rsync du répertoire media.
Les backups in-app (Admin → Backups) : des archives chinaski_backup_<timestamp>.tar.gz complètes contenant la base de données, le media, les thèmes et les templates de site, créées manuellement, automatiquement sur un agenda quotidien ou hebdomadaire que vous définissez dans l'onglet Backups, et éventuellement poussées vers un bucket DigitalOcean Spaces.
Le fichier env de l'ancien hôte (/etc/chinaski<N>/env avec CHINASKI_SECRET, LISTEN_URL), voir l'avertissement « même secret » ci-dessous. Sauvegardez-le maintenant ; il n'est ni dans la base de données ni dans le tar.gz.

Restaurer sur place (le cas courant)

Depuis Admin → Backups, téléversez un chinaski_backup_*.tar.gz :

Les restores téléversés sont plafonnés à 50 Mio.
Utilisez d'abord le dry run : il stage l'archive et prévisualise ce qui va changer, puis un clic de confirmation effectue le vrai restore.
Le restore valide l'archive (un manifest de backup doit correspondre), puis l'applique dans un ordre sûr : la base de données est restaurée atomiquement d'abord, puis le répertoire media est échangé (avec rollback si l'échange échoue), puis les thèmes et les templates de site sont restaurés ; les échecs y sont rapportés comme avertissements, pas comme avortements totaux.
Si le backup a été créé par une version de schéma différente de l'app en cours, le restore refuse plutôt que de risquer la corruption ; mettez à jour l'app (ou la version qui a créé le backup) à la place.
Options de restauration : téléverser depuis votre navigateur, ou restaurer directement depuis un backup stocké sur Spaces si Spaces est configuré. Des restores automatiques par API sont aussi disponibles (mêmes règles) pour le scripting.
Ce que le restore touche est visible dans le journal d'audit ; les restores en échec laissent le site inchangé.

Reconstruire un hôte perdu

Installez un Chinaski neuf sur le nouvel hôte avec l'installateur standard (même motif de nom d'instance). Cela crée l'utilisateur de service, une base de données vide et un nouveau fichier env.
Restaurez le fichier env, ne mélangez pas les secrets. Copiez l'ancien /etc/chinaski<N>/env par-dessus celui généré avant de démarrer ; sinon attendez-vous à ce que les réglages chiffrés (mot de passe SMTP, secrets chiffrés API) stockés dans la base de données restaurée soient indéchiffrables. La clé de chiffrement des secrets stockés est dérivée de CHINASKI_SECRET ; restaurer une base de données sous un autre secret produit silencieusement des valeurs vides plutôt qu'une erreur, donc corrigez d'abord le secret env puis re-sauvegardez les réglages ensuite si vous ne le pouvez pas.
Restaurez les données depuis les backups que vous avez conservés, le plus simplement via le restore in-app ci-dessus (téléversez le tar.gz).
Rebuild le site statique (page du builder via « Rebuild » du dashboard Settings) et mettez le site en ligne avec la configuration reverse proxy/TLS des exemples de deploy, puis vérifiez que /health répond et que le contenu se rend.

Récupérer avec seulement les backups système

Si la voie du tar.gz n'est pas disponible, le snapshot DB quotidien de /var/backups plus le miroir media suffisent :

Décompressez en gzip chinaski-<timestamp>.db.gz vers le chemin de la base de données.
Resynchronisez le miroir media dans le répertoire media de l'instance.
Notez l'étroite fenêtre de consistance documentée dans le script de backup lui-même : le snapshot DB est pris avant le miroir media, si bien qu'un fichier media supprimé quelques secondes avant le backup peut exister dans la DB mais pas dans l'arborescence media. L'étape de réconciliation documentée consiste à supprimer les lignes media dont le fichier est absent du répertoire media restauré (une passe par nom de fichier sur la table media), ce que les commentaires du script de backup détaillent.
Après le restore : déclenchez un rebuild, vérifiez /health, et prenez un backup in-app frais pour rétablir votre filet de sécurité habituel.

Garde-fous à connaître

Les restores valident le manifest du backup et refusent catégoriquement les écarts de version de schéma (« Restore aborted to prevent data corruption ») ; un backup d'une version beaucoup plus ancienne doit donc être restauré dans la version d'app correspondante.
La vérification des backups s'exécute sur chaque archive créée par défaut (il y a un réglage backup-verify ; il est actif sauf désactivation explicite).
Comme les backups contiennent des hash de mots de passe et des secrets de session, traitez le répertoire de backup et tout tar.gz téléchargé comme sensibles : le répertoire de backup système est forcé en mode 0700 à chaque exécution, et les snapshots sont stockés en mode 0600.
Un backup Spaces planifié ne s'exécute que quand Spaces est entièrement configuré (endpoint, bucket, access key, secret key) et seulement quand le mode air-gap est désactivé.
L'heure du dernier backup automatique est visible sur l'onglet Backups, avec la liste des backups locaux ; vérifiez après tout changement de serveur.