Customer HubReprise après sinistre
Ce guide décrit le concept de sauvegarde et de restauration d’un serveur Relution qui utilise une base de données (PostgreSQL ou MariaDB) et intègre éventuellement un système de stockage compatible S3 exploité on-premises (par exemple SeaweedFS, voir Stockage objet pour Relution →).
L’objectif est de garantir l’intégrité des données, de minimiser les temps d’arrêt (RTO) et d’assurer une restaurabilité fiable en cas d’urgence.
Composants à sauvegarder
L’infrastructure Relution se compose généralement des composants suivants, qui doivent être sauvegardés :
- Serveur d’application : héberge l’application et les services Relution.
- Base de données (on-premises) : MariaDB ou PostgreSQL.
- Stockage S3 (on-premises) : système de stockage objet (optionnel) pour le dépôt de fichiers (par ex. paquets d’applications et ressources téléversées). Sans S3, Relution enregistre ces contenus dans la base de données ; la sauvegarde de la base de données couvre alors aussi tous les fichiers.
Objectifs de sauvegarde
- Minimisation de la perte de données (RPO – Recovery Point Objective)
- Restauration rapide des services (RTO – Recovery Time Objective)
- Protection contre les pannes matérielles, les erreurs logicielles et les erreurs humaines
- Protection contre la manipulation de données ainsi que contre les ransomwares
1. Sauvegarde de la base de données
| Stratégie | Détails |
|---|---|
| Fréquence | Dumps complets quotidiens (par ex. via mariadb-dump ou pg_dump) |
| Incrémentiel | Sauvegardes incrémentielles horaires (selon les besoins) |
| Gestion | Rotation automatisée et règles de conservation |
| Sécurité | Chiffrement des fichiers de sauvegarde (AES256 ou GPG) selon les besoins |
| Cohérence | Pendant la sauvegarde, le service Relution devrait être temporairement arrêté afin d’éviter les incohérences ! |
2. Sauvegarde du stockage S3 (optionnel)
| Stratégie | Détails |
|---|---|
| Méthode | Réplication vers une seconde cible S3 ou synchronisation régulière (s3cmd sync, rclone sync) |
| Périmètre | Sauvegarde des buckets critiques à des intervalles définis |
| Cohérence | Pendant la sauvegarde, le service Relution devrait être temporairement arrêté afin d’éviter les incohérences ! |
3. Sauvegarde de la configuration du serveur
Tous les fichiers de configuration pertinents doivent être sauvegardés :
/opt/relution(répertoire du serveur Relution)compose.yaml, oudocker-compose.ymlpour les installations plus anciennes (ou scripts de démarrage comparables)application.yml(configuration Relution)- Le cas échéant, le fichier de configuration NginX
- Le certificat SSL et la clé
- Les clés des données chiffrées, si elles sont configurées (voir la remarque suivante)
relution.database.crypto.keks) ou si une clé SSE-C ou un fichier de clé (keyFile, voir Chiffrement côté serveur (SSE-C) →) est configuré pour le stockage objet, la sauvegarde de la base de données ou du bucket ne peut pas être restaurée sans ces clés. Les clés ne se trouvent souvent pas dans application.yml, mais dans des variables d’environnement, un fichier .env ou un coffre de secrets. Elles sont conservées séparément des sauvegardes de données. Après un changement de KEK, l’ancienne clé est conservée tant que des sauvegardes plus anciennes de la base de données existent. Sans KEK externe, Relution génère lui-même la clé et l’enregistre dans la base de données ; dans ce cas, la sauvegarde de la base de données suffit.Emplacements de stockage des sauvegardes
Le respect du principe de sauvegarde 3-2-1 est recommandé :
- 3 copies des données
- 2 systèmes/supports différents
- 1 copie externe/hors site
Planification
| Intervalle | Sauvegarde |
|---|---|
| Quotidien | Sauvegarde complète de la base de données |
| Horaire | Sauvegarde incrémentielle de la base (selon les besoins) |
| Quotidien | Synchronisation S3 des buckets critiques |
| Hebdomadaire | Sauvegarde complète de la configuration du serveur |
Autres aspects
| Domaine | Détails |
|---|---|
| Automatisation | Cronjobs ou timers systemd ; journalisation de tous les processus ; notifications en cas d’erreur |
| Chiffrement | Chiffrement de toutes les sauvegardes ; TLS/HTTPS/SSH pour le transport |
| Contrôle d’intégrité | Restauration test mensuelle |
1. Restauration de la base de données
- Sélection du fichier de sauvegarde correct
- Préparation du système cible (arrêt du service Relution ; le service de base de données doit rester actif ; création d’une base de données vide si nécessaire)
- Exécution de l’import des données (par ex. via
psqloumysql) - Test fonctionnel de l’application Relution
La restauration utilise la même version de Relution que celle installée au moment de la sauvegarde. Les mises à jour de la base de données ne s’exécutent que vers l’avant ; une mise à jour vers une version plus récente s’effectue ensuite normalement (voir Mise à jour →). Une KEK externe configurée doit de nouveau être disponible au démarrage de Relution.
2. Restauration du stockage S3
- Sélection des objets/buckets
- Restauration via
rclone,s3cmdou API - Contrôle d’intégrité (vérifier que les fichiers sont présents dans Relution)
3. Restauration complète du système
- Restauration des configurations (à partir des sauvegardes de configuration du serveur)
- Redémarrage de tous les services
- Test fonctionnel de l’ensemble de l’application
Surveillance et alerte
- Surveillance de tous les processus de sauvegarde (par ex. avec des outils tels que Grafana + Prometheus)
- Alertes en cas de :
- Erreurs lors de la sauvegarde
- Espace de stockage faible
- Erreurs d’intégrité
- Échecs de la restauration test
Sécurité
- Restrictions d’accès (principe du moindre privilège)
- Stockage sécurisé des clés et des identifiants
- Mises à jour régulières des logiciels utilisés
Documentation
- Documentation de toutes les modifications de processus (configuration, plannings)
- Responsabilités claires pour la sauvegarde et la restauration
- Conservation des journaux pendant au moins 90 jours
Conclusion
Ce concept de sauvegarde garantit que la base de données et le système de stockage S3 on-premises sont tous deux protégés de manière fiable et peuvent être rapidement restaurés en cas d’urgence. Grâce à l’automatisation et à des contrôles réguliers, la sécurité opérationnelle est assurée à long terme.