sepehr/office_translator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Robustness: Implement multi-destination backups (LOCAL, NAS, SCP) and backup/restore of NPM configurations

Browse Source
This commit is contained in:
sepehr
2026-06-07 09:50:51 +02:00
parent c7299228cd
commit 80b49ee354
2 changed files with 230 additions and 173 deletions
Download Patch File Download Diff File Expand all files Collapse all files

158
DISASTER_RECOVERY.md
View File

@@ -1,106 +1,102 @@
# Guide de Reprise d'Activité (Disaster Recovery Playbook)
> Procédure pas-à-pas en cas de crash total du serveur principal (`192.168.1.151`)
# Playbook de Sauvegarde Complète & Reprise d'Activité (Disaster Recovery)
> Gestion des pannes matérielles, sauvegarde de Nginx Proxy Manager (NPM) et transfert distant (sans NAS).
---
## 🎯 Objectif
Ce document décrit comment restaurer l'intégralité de la plateforme SaaS **Wordly.art** (Base de données active, configurations secrètes `.env` et services Docker) sur un **nouveau serveur** de secours si le serveur principal tombe en panne complète.
Ce document explique comment automatiser la sauvegarde et restaurer l'intégralité de la plateforme SaaS **Wordly.art** (Base de données, fichier de configuration `.env` contenant vos secrets, et configurations de routage SSL/Proxy de **Nginx Proxy Manager**) sur un nouveau serveur en cas de crash du serveur principal.
---
## 📁 Fonctionnement de la sauvegarde DR (Disaster Recovery)
## ⚙️ 1. Variables de configuration dans le `.env`
Le script de reprise d'activité [disaster-recovery.sh](file:///d:/dev1405/office_translator/scripts/disaster-recovery.sh) génère une archive compressée contenant l'intégralité du système à restaurer :
1. **La base de données active** (PostgreSQL ou SQLite).
2. **Le fichier de configuration de production** `.env` (contenant vos clés API Stripe, OpenAI, DeepL, etc.).
3. **Le fichier `docker-compose.yml`** et ses variantes.
4. **Le dossier `docker/`** contenant toutes les configurations Prometheus, Grafana, Nginx, etc.
Pour activer les options de reprise d'activité, ajoutez ces variables dans votre fichier `.env` de production :
Toutes ces archives sont stockées sur votre **NAS** à l'abri des pannes matérielles du serveur local : `/mnt/nas-backups/wordly/dr/`.
```ini
# ============== Configuration Disaster Recovery (DR) ==============
# Choix de la destination : LOCAL, NAS, ou SCP
BACKUP_DEST_TYPE=LOCAL
# Chemin local ou point de montage (ex: /mnt/nas-backups/wordly)
BACKUP_DEST_PATH=/var/backups/wordly
# Configuration SSH/SCP (requis uniquement si BACKUP_DEST_TYPE=SCP)
SCP_HOST=192.168.1.200
SCP_USER=backup_user
SCP_KEY_PATH=/root/.ssh/id_rsa
SCP_PORT=22
SCP_DEST_PATH=/var/backups/wordly_saas
# Configurations des dossiers de Nginx Proxy Manager (NPM)
# Laissez vide si NPM tourne sur une autre machine et n'est pas géré ici.
NPM_DATA_DIR=/opt/npm/data
NPM_LETSENCRYPT_DIR=/opt/npm/letsencrypt
```
---
## 🛠️ Étape 1 : Automatisation de la sauvegarde complète (A faire aujourd'hui)
## 🛠️ 2. Comment configurer la sauvegarde à distance (Mode SCP)
Pour que la sauvegarde Disaster Recovery s'exécute automatiquement chaque nuit à 03h30 :
Si vous n'avez pas de NAS, le mode **SCP** permet d'envoyer chaque nuit l'archive complète vers une autre machine ou ordinateur de votre réseau local (ex: `192.168.1.200`).
1. Connectez-vous en SSH sur votre serveur principal (`192.168.1.151`).
2. Ouvrez le planificateur de tâches (cron) :
```bash
crontab -e
```
3. Ajoutez la ligne suivante tout à la fin du fichier :
```cron
30 3 * * * /opt/wordly/scripts/disaster-recovery.sh --backup >> /var/log/wordly-dr-backup.log 2>&1
```
4. Sauvegardez et quittez. Désormais, une archive complète de restauration sera créée et envoyée sur votre NAS chaque nuit, avec une rétention automatique de **14 jours**.
### Étape A : Générer une clé SSH sur le serveur principal
Sur le serveur applicatif (`192.168.1.151`), si vous n'avez pas de clé SSH :
```bash
sudo ssh-keygen -t rsa -b 4096 -N "" -f /root/.ssh/id_rsa
```
### Étape B : Autoriser la connexion sur la machine de backup
Copiez la clé publique sur votre machine de sauvegarde (`192.168.1.200`) :
```bash
sudo ssh-copy-id -i /root/.ssh/id_rsa.pub backup_user@192.168.1.200
```
*Vérification* : Exécutez `sudo ssh -i /root/.ssh/id_rsa backup_user@192.168.1.200` depuis le serveur principal. Vous devez vous connecter **sans saisir de mot de passe**.
---
## 🚨 Étape 2 : Procédure de restauration (En cas de crash du serveur)
## 📅 3. Automatisation quotidienne
Si le serveur `192.168.1.151` est indisponible et que vous devez remonter le SaaS sur une nouvelle machine (ex : **`192.168.1.152`**), suivez ces étapes :
Ajoutez le script à votre crontab pour qu'il s'exécute automatiquement chaque nuit à 03h30 :
```bash
sudo crontab -e
```
Ajoutez cette ligne tout à la fin :
```cron
30 3 * * * /opt/wordly/scripts/disaster-recovery.sh --backup >> /var/log/wordly-dr-backup.log 2>&1
```
### 2.1 Préparation de la nouvelle machine
1. Installez Docker et Docker Compose sur le nouveau serveur :
---
## 🚨 4. Procédure de restauration sur un nouveau serveur (Failover)
Si le serveur principal crashe complètement et que vous devez remonter l'infrastructure sur un serveur de secours (ex: `192.168.1.152`) :
### Étape 4.1 : Récupérer l'archive de sauvegarde
Récupérez le dernier fichier `wordly_dr_TIMESTAMP.tar.gz` depuis votre stockage de backup (NAS, machine de backup distante via SCP, ou clé USB).
### Étape 4.2 : Installer Docker sur le nouveau serveur
```bash
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER && newgrp docker
```
### Étape 4.3 : Lancer la restauration automatique
1. Créez le dossier de destination et placez-vous dedans :
```bash
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER && newgrp docker
```
2. Créez le dossier du projet et clonez le repository (ou copiez les fichiers depuis le NAS) :
```bash
git clone -b production-deployment https://gitea.parsanet.org/sepehr/office_translator.git /opt/wordly
sudo mkdir -p /opt/wordly
cd /opt/wordly
```
2. Lancez le script de restauration à partir de l'archive (le script va extraire le `.env`, copier le `docker-compose.yml`, restaurer les configurations et certificats SSL de NPM, démarrer Docker et réinjecter les données de la base de données) :
```bash
# Remplacez par le nom ou le chemin exact de votre archive
bash /chemin/vers/votre/archive/scripts/disaster-recovery.sh --restore /chemin/vers/votre/archive/wordly_dr_20260607_033000.tar.gz
```
3. Validez l'action en saisissant `RESTORE-ALL` lorsque le script vous le demande.
### 2.2 Monter le NAS sur le nouveau serveur
Pour que le nouveau serveur accède aux sauvegardes stockées sur votre NAS :
1. Installez l'utilitaire de montage :
```bash
sudo apt install cifs-utils -y
sudo mkdir -p /mnt/nas-backups/wordly
```
2. Créez le fichier de credentials :
```bash
sudo tee /etc/nas-credentials <<EOF
username=wordly-backup
password=MOT_DE_PASSE_NAS
domain=WORKGROUP
EOF
sudo chmod 600 /etc/nas-credentials
```
3. Montez le NAS temporairement pour la restauration (ou via `/etc/fstab` pour le rendre persistant) :
```bash
sudo mount -t cifs -o credentials=/etc/nas-credentials,uid=$(id -u),gid=$(id -g),vers=3.0 //IP_DU_NAS/wordly-backups /mnt/nas-backups/wordly
```
### Étape 4.4 : Redirection du trafic réseau
Puisque le serveur a changé d'adresse IP (de `192.168.1.151` à `192.168.1.152`) :
### 2.3 Exécuter la restauration
1. Listez les archives DR disponibles sur le NAS pour choisir la plus récente :
```bash
ls -lh /mnt/nas-backups/wordly/dr/
```
2. Lancez la restauration complète (le script va extraire le `.env`, copier le `docker-compose.yml`, lancer les services Docker, attendre que la base de données soit prête et y injecter vos données) :
```bash
# Remplacez par le nom de l'archive voulue
bash scripts/disaster-recovery.sh --restore /mnt/nas-backups/wordly/dr/wordly_dr_20260607_033000.tar.gz
```
3. Le script vous demandera de confirmer en tapant `RESTORE-ALL`. Tapez-le et appuyez sur Entrée.
4. Une fois terminé, vérifiez que l'application tourne bien :
```bash
docker compose ps
curl http://localhost:8000/health
```
#### Cas A : Si NPM tournait sur le serveur qui a crashé
Le script a restauré NPM sur la nouvelle machine. Vous devez simplement aller sur le routeur de votre box internet et modifier la redirection des ports **80** et **443** (Port Forwarding) pour qu'ils pointent vers la nouvelle IP `192.168.1.152` au lieu de `192.168.1.151`.
### 2.4 Mettre à jour Nginx Proxy Manager (NPM)
Votre service Nginx Proxy Manager (NPM) s'occupe de rediriger les requêtes de `wordly.art` vers l'IP interne du serveur.
1. Connectez-vous à l'interface d'administration de votre NPM (**http://IP_NPM:81**).
2. Allez dans **Proxy Hosts**.
3. Pour les entrées de domaines concernées :
- `wordly.art`
- `www.wordly.art`
- `monitoring.wordly.art`
4. Cliquez sur **Edit** (les trois points à droite).
5. Dans le champ **Forward Hostname / IP**, remplacez l'ancienne adresse IP (`192.168.1.151`) par la nouvelle IP de votre serveur de secours (**`192.168.1.152`**).
6. Cliquez sur **Save**.
**C'est terminé !** Vos utilisateurs peuvent à nouveau accéder à `https://wordly.art` et le système de paiement Stripe continuera à envoyer les webhooks vers la nouvelle machine automatiquement, sans aucune autre configuration requise.
#### Cas B : Si NPM tourne sur une machine externe dédiée
Connectez-vous à l'interface web de votre NPM (http://IP_NPM:81), modifiez les Proxy Hosts de `wordly.art` et changez le champ **Forward Hostname/IP** pour remplacer `192.168.1.151` par la nouvelle IP `192.168.1.152`.