Vous avez enfin trouvé l'endroit où vous vous sentez chez vous. Un petit forum, un salon vocal où l'on se retrouve le soir, un tableau collaboratif qui part dans tous les sens. Nodyx, c'est cette plateforme communautaire que vous avez pris le temps d'installer, de configurer, d'aimer. Ce n'est pas juste un serveur Discord parmi d'autres. C'est votre espace, avec vos règles, votre liberté, et la sécurité de savoir qu'il vous appartient vraiment ("The network is the people").
Mais avouons‑le : il y a une petite voix qui vous trotte dans la tête. Et si le disque dur lâchait ? Et si je faisais une mauvaise manip ? Et si… je perdais tout ? Jusqu'à aujourd'hui, cette question restait sans réponse.
Avec la v2.4.0, cette angoisse disparaît. Non, la machine à remonter le temps n'existe toujours pas. Mais à partir de maintenant, à un clic près, vous avez l'équivalent : la sauvegarde intégrale de votre instance, prête à être restaurée à n'importe quel moment.
👋 Fini le "et si…", place à "et voilà"
Désormais, dans votre interface d'administration, un nouvel onglet fait son apparition : Sauvegardes. Vous cliquez, et en quelques secondes, Nodyx empaquette tout : les messages du forum, les salons vocaux, chaque trait du tableau blanc, les profils, les images. Absolument tout. Le résultat ? Un fichier .tar.gz que vous pouvez télécharger et ranger précieusement (sur un autre disque, un NAS, un cloud chiffré, à vous de voir).
L'interface vous donne même un indicateur d'espace de stockage utilisé par vos sauvegardes, pour que vous gardiez toujours un œil sur la place disponible.
Et la restauration ? Tout aussi simple : vous sélectionnez votre sauvegarde, cliquez sur Restaurer, et Nodyx vous offre un aperçu des changements (nombre de fils de discussion, de messages, d'utilisateurs…). Une petite vérification visuelle rassurante avant de passer à l'action.
🔧 Et ce n'est pas tout : le mode maintenance, le dry‑run, et "The Yannick Story"
Mais je vous vois venir, vous les experts : "Oui, mais en vrai, c'est solide ?" Alors je vous réponds par deux anecdotes.
La fonction dry‑run : avant de lancer une vraie restauration, vous pouvez cliquer sur Vérifier. Nodyx va alors analyser l'archive, contrôler son empreinte SHA‑256, s'assurer qu'elle n'est pas corrompue et que son format est compatible. Le tout sans toucher à votre base de données ni à vos fichiers. L'affichage est clair : ✅ "restaurable" ou ❌ avec le message d'erreur exact. Une sécurité supplémentaire bienvenue.
The Yannick Story : pendant le tout premier test de restauration en production, un nouveau membre, Yannick, s'est inscrit pile entre la sauvegarde (21:00) et la restauration (21:17). Sa fiche utilisateur a été écrasée par la restauration. Au passage, ça a révélé un bug de design subtil : le système incluait dans ses propres archives la table qui sert à tracker les sauvegardes, ce qui faisait disparaître le filet de sécurité au moment où on en avait justement besoin. Le compte de Yannick a été récupéré en 60 secondes via la sauvegarde pré‑restauration. Trois commits ont suivi dans l'heure pour corriger ça définitivement, et Yannick est désormais immortalisé dans le repo en tant que contributeur involontaire.
Aujourd'hui, certaines tables critiques (comme la table des sauvegardes elle‑même) sont exclues des archives. Une restauration ne peut donc plus jamais effacer son propre filet de sécurité. Et avant chaque restauration, une sauvegarde automatique "pré‑restauration" est créée, intouchable pendant 24 heures, votre bouée de secours absolue.
Ajoutez à cela un verrou Redis qui empêche deux sauvegardes de s'exécuter en même temps, un journal d'audit qui trace chaque action (avec l'adresse IP et l'agent utilisateur, pratique en cas d'incident), et vous obtenez un système mûrement réfléchi, bien au‑delà du simple "bouton de backup".
Oh, et j'allais oublier : j'en ai profité pour ajouter un mode maintenance qui s'enclenche automatiquement pendant chaque sauvegarde et chaque restauration. Pendant ces quelques minutes, un bandeau ambré apparaît en haut de chaque page : les visiteurs continuent à lire, mais les nouvelles inscriptions, posts et uploads attendent gentiment la fin de l'opération. Plus jamais de Yannick écrasé par accident, et plus jamais de quoi que ce soit perdu en plein milieu d'un restore.
Bref, la v2.4.0, c'est l'autonomie. Plus besoin de tâtonner avec pg_dump ou tar dans le terminal. Plus besoin de stresser à l'idée d'une fausse manip. Vous avez le contrôle, et vous pouvez désormais expérimenter, modifier, casser et reconstruire votre communauté en toute sérénité.
Nodyx devient ainsi un peu plus souverain. Parce qu'une communauté qui a peur de perdre ses données n'est jamais tout à fait libre.
Installez la mise à jour, faites votre première sauvegarde, et dormez sur vos deux oreilles.
🧠 Détails techniques : comment ça marche sous le capot
Pour celles et ceux qui aiment savoir ce qui se trame en coulisses, voici l'essentiel du fonctionnement technique de cette nouvelle fonctionnalité.
🛠️ Architecture et composants
La sauvegarde repose sur une nouvelle migration SQL (077_backups.sql) qui crée trois tables dédiées :
backups: archive les métadonnées de chaque sauvegarde (date, taille, empreinte, etc.)backup_settings: table "singleton" qui centralise la configuration (emplacement du répertoire de stockage, etc.)backup_audit_log: journal d'audit détaillé de toutes les actions
Ces tables sont spécialement exclues des archives de sauvegarde, avec schema_migrations, pour éviter qu'une restauration ne vienne accidentellement effacer son propre historique.
💾 Processus de création d'une sauvegarde
Lorsque vous cliquez sur Créer une sauvegarde, le service backupService.ts :
Utilise
pg_dump --format=custom --compress=9pour extraire la base de données PostgreSQL. Le format custom embarque déjà sa propre compression.Empaquette le dump avec les fichiers utilisateurs (uploads) et le manifest dans une archive
tar -czf.Calcule l'empreinte SHA‑256 de l'archive résultante.
Enregistre la sauvegarde dans la table
backupset ajoute une entrée dans la table d'audit.
Un verrou Redis (backup:lock, option NX avec expiration de 3600 secondes) garantit qu'une seule opération de sauvegarde peut s'exécuter à la fois, et empêche également qu'une restauration ne tente de s'exécuter pendant une sauvegarde en cours.
🔄 Processus de restauration
La restauration est conçue pour être atomique :
pg_restore --single-transaction --clean --if-exists: si la restauration échoue à mi‑chemin, la transaction est annulée et la base revient à son état antérieur.Avant toute restauration, une sauvegarde automatique "pré‑restauration" est créée, marquée
protected=TRUEet avecexpires_at = NOW() + 24h. Cette sauvegarde ne peut pas être supprimée manuellement pendant cette fenêtre.
🖥️ Interface administrateur
Côté frontal, une nouvelle page /admin/backups offre :
Un indicateur de stockage pour connaître l'espace total utilisé.
Un tableau listant toutes les sauvegardes, avec pour chacune les actions disponibles.
Une modale de restauration avec :
Aperçu des changements (nombre de fils, messages, utilisateurs, uploads)
Confirmation par saisie d'un slug, avec un compte à rebours de 5 secondes côté client, et la même vérification côté serveur
Affichage pas à pas des étapes de la restauration, pour lever tout mystère
La fonction Vérifier (dry‑run) est particulièrement intéressante : elle analyse l'archive pour valider l'empreinte SHA‑256, vérifier la compatibilité du format et l'intégrité de la structure tar, sans rien modifier ni dans la base ni dans le système de fichiers. Une opération auditée avec le flag metadata.dry_run = true.
🔒 Sécurité et audit
11 endpoints administrateur sont exposés sous /api/v1/admin/backups pour toutes les actions possibles (liste, création, téléchargement, suppression, restauration, vérification, etc.), avec une protection contre les attaques de type path traversal via l'utilisation de path.basename() sur le chemin de téléchargement.
Un journal d'audit complet est disponible dans l'interface /admin/backups/audit, affichant avec des "chips" chaque action effectuée (création, restauration, etc.), son succès ou échec, l'adresse IP de l'utilisateur et son agent. Cette fonction a été pensée pour l'analyse forensique post‑compromission : par exemple, le téléchargement d'une sauvegarde par un attaquant est un événement d'exfiltration à ne pas manquer.
📦 Pour les auto‑hébergeurs
Quelques points pratiques : le répertoire de stockage des sauvegardes est nodyx-core/backups/. Ce dossier doit être accessible en écriture par l'utilisateur nodyx. Sur les instances existantes, créez‑le manuellement une fois pour toutes :
sudo install -d -o nodyx -g nodyx -m 0700 /var/www/nexus/nodyx-core/backups
Ce qui vient plus tard (Phase 2 / 3) : les sauvegardes automatiques planifiées, la rotation, le glisser‑déposer pour importer une archive externe, le chiffrement AES‑256‑GCM, et la détection des bind‑mounts Docker. Mais le socle est solide et prêt à l'emploi.
🔗 Pour aller plus loin
Release notes GitHub : https://github.com/Pokled/nodyx/releases/tag/v2.4.0
Changelog complet (avec le récit pas à pas de The Yannick Story) : https://github.com/Pokled/nodyx/blob/main/CHANGELOG.md
Spec technique : https://github.com/Pokled/nodyx/blob/main/docs/specs/014-backup-system/SPEC.MD
🙏 Soutenez Nodyx
Si cette fonctionnalité vous plaît et que vous souhaitez encourager le projet, n'hésitez pas à mettre une étoile ⭐ sur GitHub : cela aide d'autres personnes à découvrir Nodyx. Vous pouvez aussi soutenir via Ko‑fi pour permettre au projet de continuer à évoluer.
Alors, prêt à passer à la v2.4.0 ? Votre communauté n'attend que vous.