Sauvegardes

Une commande fait une sauvegarde complète pendant que Ronne tourne : la base de données (quelle qu'elle soit), les éléments et plugins stockés et le fichier de réglages, dans une seule archive. Elle lit un moment cohérent de la base, donc chacun continue de travailler. Une mise à jour ne peut pas être annulée : une sauvegarde est aussi le chemin du retour.

L'archive est aussi sensible que le serveur : avec le fichier de réglages, elle contient AUTH_SECRET et le mot de passe de la base. Elle est écrite lisible par son seul propriétaire; chiffrez les copies qui quittent la machine.

• --keep 14 supprime les archives les plus anciennes du dossier au-delà de 14, après une sauvegarde réussie.
• --encrypt la scelle avec une phrase secrète (.tar.enc), demandée dans un terminal ou lue depuis --passphrase-file ou RONNE_BACKUP_PASSPHRASE. Une phrase secrète perdue ne peut pas être retrouvée.
• --verify ARCHIVE vérifie une archive sans la restaurer : chaque somme de contrôle, et le fichier de chaque version publiée.
• --no-settings laisse le fichier de réglages de côté; gardez-en une copie ailleurs.

De façon planifiée : Ronne n'a pas de planificateur à lui; celui du système lance la commande. Une fois par jour, en gardant deux semaines, c'est un bon début, par exemple dans la crontab de root :

15 3 * * * /usr/bin/rmk-server backup --keep 14 >> /var/log/rmk-server-backup.log 2>&1
15 3 * * * cd /opt/ronne-marketplace && docker compose exec -T web pnpm run backup --keep 14 >> /var/log/ronne-backup.log 2>&1   # Docker

Une sauvegarde contient des données personnelles : ce que la base de données contenait au moment où elle a été faite, adresses IP comprises. Ne gardez pas les sauvegardes plus longtemps que la rétention fixée par root (Confidentialité).

Gardez des copies hors de la machine : une sauvegarde sur le même disque ne survit pas au disque. L'archive est un fichier ordinaire : copiez-la avec rsync, rclone ou l'outil de votre cloud (avec Docker, sortez-la d'abord du volume avec docker compose cp web:/app/data/backups/. ./ronne-backups/). De temps en temps, restaurez-en une ailleurs et démarrez-la : c'est la seule façon de savoir qu'elle se restaure.

Le runbook de sauvegarde détaille le timer systemd, launchd et cron, les sauvegardes chiffrées planifiées, les certificats de Caddy et des temps mesurés.

La restauration ne se fait que dans une base de données et un stockage vides, Ronne arrêté. Elle vérifie d'abord toute l'archive et ne change rien si l'archive a été coupée ou modifiée, vient d'un Ronne plus récent, ou si la cible n'est pas vide. Puis elle restaure les lignes et les fichiers, applique les changements de base de données que la version installée a depuis, et écrit ou garde le fichier de réglages. Avec un service sous Linux (sous macOS, dans le dossier de données qu'affiche rmk-server service status) :

sudo rmk-server service stop
cd /var/lib/rmk-server
sudo mkdir -m 700 before-restore && sudo mv ronne.db* storage before-restore/
sudo rmk-server restore /var/lib/rmk-server/backups/ronne-backup-20261014-130541.tar
sudo rmk-server service start

• Docker : arrêtez web, mettez les données de côté dans le volume, puis docker compose run --rm --no-deps web pnpm run restore ARCHIVE et docker compose up -d. Avec PostgreSQL ou MySQL fournis, videz plutôt cette base.
• Sur une autre machine : installez Ronne de la même façon sans en lancer l'installation initiale, copiez l'archive et restaurez avec --with-settings : les réglages de la sauvegarde suivent, avec la base et le stockage de la nouvelle machine.
• Vers un autre type de base : une sauvegarde se restaure dans SQLite, PostgreSQL, MySQL ou MariaDB, quelle que soit son origine : c'est ainsi qu'on déplace une instance devenue trop grande pour SQLite. Créez une base vide et indiquez-la avec --database-url.

Connexions : avec --with-settings sur une machine sans fichier de réglages, ou avec le même fichier de réglages, chacun reste connecté. Restaurée sans les réglages de la sauvegarde, l'instance reçoit un nouvel AUTH_SECRET : chacun se reconnecte. Les jetons d'accès restent valides dans les deux cas, donc rmk et le serveur MCP continuent de fonctionner. Les secrets de la connexion à deux facteurs sont chiffrés avec l'AUTH_SECRET de la sauvegarde : quand l'instance restaurée tournera avec un autre secret, la restauration désactive la connexion à deux facteurs de tous ceux qui l'ont, et indique leur nombre (pour une sauvegarde sans réglages, elle en essaie un avec le secret que l'instance utilisera). Les secrets client des fournisseurs d'identité sont chiffrés de la même façon : restauré avec un autre AUTH_SECRET, le fournisseur affiche Failing jusqu'à ce que root saisisse de nouveau son secret client (Verrouillage et fournisseurs en panne). Chaque restauration est enregistrée dans le journal d'audit, par-dessus l'historique restauré. Un compte effacé après la sauvegarde revient avec elle, données personnelles comprises : effacez-le de nouveau.