Customer HubDisaster Recovery
Ce guide décrit le concept de sauvegarde et de sécurisation 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 MinIO).
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.
Remarque : La configuration de l’automatisation des sauvegardes, la surveillance ainsi que la garantie de l’exécution des sauvegardes relèvent de la responsabilité du client.
Vue d’ensemble du système
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, de sauvegardes et de données persistantes.
Important : Toutes les applications peuvent également être exploitées ensemble sur une seule machine. L’utilisation du stockage S3 est optionnelle, mais si elle est utilisée, le fonctionnement du serveur Relution est impossible sans le contenu du bucket S3.
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
Composants et stratégies de sauvegarde
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.yml(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é
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
Processus de sauvegarde
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 |
Procédures de restauration
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 de base de données)
- Exécution de l’import des données (par ex. via
psqloumysql) - Test fonctionnel de l’application 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é et documentation
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 sécurisation 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.