🌘 Restaurer ListMonk depuis une archive Borg
🌘 Contexte
L’accès à la section Paramètres de ListMonk était impossible parce que la configuration SMTP était cassée. La cause principale est que le serveur était restauré sur un nouveau Yunohost avec une configuration périmée. Il y avait des erreurs dans le Javascript qui pointaient vers des incohérences dans la configuration retournée en JSON par l’API qui est alimentée par la base de données PostgreSQL. J’ai fini par effacer la base de données au complet en taponnant et j’ai du tout réinstaller. C’est ce que je te raconte ici. Une chance que j’avais une sauvegarde automatisée avec Borg de la base de données !
Comment restaurer ListMonk depuis une archive Borg
Extrais le dump SQL depuis l’archive Borg, recrée la base ListMonk, puis importe le fichier après avoir nettoyé les paramètres incompatibles.
🌘 Ce que Borg conserve pour ListMonk
Sur YunoHost avec Borg configuré vers rsync.net, chaque sauvegarde nocturne est une archive dédiée par application. Pour ListMonk, la sauvegarde SQL se résume à un seul fichier, donc c’est possible de restaurer seulement la base de données sans toucher aux fichiers de configuration ou à l’application elle-même.
apps/listmonk/backup/db.sql
Ce dump SQL contient listes, abonnés, campagnes et paramètres. Si ce fichier est présent, la restauration est possible.
🌘 La procédure
🌘 1. Lister les archives disponibles
/var/www/borg/wrapper/borg list --remote-path=borg14 \
de3385@de3385.rsync.net:/~/admin.jevalide.ca | grep listmonk | tail -1
Résultat attendu :
auto_listmonk-2026-05-16T03:01:35
🌘 2. Vérifier le contenu de l’archive ciblée
/var/www/borg/wrapper/borg list --remote-path=borg14 \
de3385@de3385.rsync.net:/~/admin.jevalide.ca::auto_listmonk-2026-05-16T03:01:35
Vérifie la présence de apps/listmonk/backup/db.sql avant d’aller plus loin.
🌘 3. Extraire vers un répertoire temporaire
Crée un répertoire temporaire pour l’extraction. Donne ensuite récursivement les permissions globales pour ne pas de faire chier avec ça plus tard.
mkdir -p /tmp/restore
cd /tmp/restore/
/var/www/borg/wrapper/borg extract --remote-path=borg14 \
de3385@de3385.rsync.net:/~/admin.jevalide.ca::auto_listmonk-2026-05-16T03:01:35
chmod -R 777 /tmp/restore/
L’extraction produit /tmp/restore/apps/listmonk/backup/db.sql.
🌘 4. Arrêter le service ListMonk
systemctl stop listmonk
🌘 5. Supprimer la base corrompue puis recréer une base vide
sudo -u postgres psql -d postgres -c "DROP DATABASE listmonk;"
sudo -u postgres psql -d postgres -c "CREATE DATABASE listmonk;"
Opération destructive. N’exécute ces commandes que si le dump SQL a été extrait et que tu confirmes son intégrité.
Au préalable, fais une sauvegarde de ListMonk avec l’utilitaire de YunoHost pour pouvoir revenir en arrière si jamais.
🌘 6. Importer le dump
sudo -u postgres psql -d listmonk -f /tmp/restore/apps/listmonk/backup/db.sql
🌘 7. Corriger les paramètres incompatibles entre versions
Le dump peut contenir des entrées settings rejetées par la version cible :
sudo -u postgres psql -d listmonk -c "
DELETE FROM settings
WHERE key IN ('smtp', 'privacy.domain_blocklist', 'privacy.domain_allowlist');
"
sudo -u postgres psql -d listmonk -c "
INSERT INTO settings (key, value)
VALUES ('smtp', '[]'::jsonb);
"
🌘 8. Redémarrer les services
systemctl start listmonk
🌘 Validation
- L’interface d’administration est accessible.
- Les listes d’abonnés sont présentes.
- Les campagnes planifiées sont restaurées.
La restauration ne marche que si la sauvegarde a été conçue pour ce cas et si les clés Borg sont accessibles.
🌘 Points de contrôle avant d’en avoir besoin
- Clés de chiffrement Borg stockées hors du serveur principal.
- Procédure testée hors production au moins une fois.
- Notifications de fin de sauvegarde actives.
- Paramètres critiques documentés indépendamment du serveur.
Je peux t’aider à sécuriser la restauration de ton instance Yunohost pour éviter cette situation.