sepehr
fa19f33ab0
Some checks failed
Deploy to Production / Build and Deploy (push) Has been cancelled
110 lines
4.7 KiB
Markdown
110 lines
4.7 KiB
Markdown
# Procédure de Restauration — Wordly.art
|
|
|
|
Ce document décrit comment restaurer rapidement et facilement l'application Wordly.art à partir des sauvegardes stockées sur le NAS (`192.168.1.146`), soit en cas de corruption de données sur le serveur principal, soit en cas de sinistre total nécessitant le basculement sur le serveur de secours.
|
|
|
|
---
|
|
|
|
## 📋 Table des matières
|
|
1. [Restauration sur le serveur principal (192.168.1.151)](#1-restauration-sur-le-serveur-principal-1921681151)
|
|
2. [Restauration d'urgence sur le serveur de secours (192.168.1.98)](#2-restauration-durgence-sur-le-serveur-de-secours-192168198)
|
|
3. [Vérifications post-restauration](#3-vérifications-post-restauration)
|
|
|
|
---
|
|
|
|
## 1. Restauration sur le serveur principal (192.168.1.151)
|
|
|
|
> 💡 **Cas d'usage :** Corruption de la base de données, erreur humaine (ex: suppression accidentelle), ou besoin de revenir à un état antérieur sur le serveur de production actif.
|
|
|
|
### Étape 1.1 : Trouver le fichier de sauvegarde à restaurer
|
|
Connectez-vous en SSH sur le serveur principal (`192.168.1.151`) et listez les archives disponibles sur le NAS :
|
|
```bash
|
|
cd /opt/wordly
|
|
bash scripts/backup-to-nas.sh --list
|
|
```
|
|
*Notez le nom de l'archive que vous souhaitez restaurer (ex: `wordly_dr_20260607_120000.tar.gz`).*
|
|
|
|
### Étape 1.2 : Exécuter la restauration
|
|
Lancez la commande suivante en remplaçant `NOM_ARCHIVE.tar.gz` par le nom du fichier choisi :
|
|
```bash
|
|
sudo bash scripts/disaster-recovery.sh --restore /volume1/backups/wordly/snapshots/NOM_ARCHIVE.tar.gz
|
|
```
|
|
|
|
### Étape 1.3 : Confirmer
|
|
Le script vous demandera une confirmation de sécurité. Saisissez textuellement :
|
|
```text
|
|
RESTORE-ALL
|
|
```
|
|
Le script arrête automatiquement les conteneurs, restaure la configuration, recrée la base de données PostgreSQL, réinjecte les données, puis relance l'application.
|
|
|
|
---
|
|
|
|
## 2. Restauration d'urgence sur le serveur de secours (192.168.1.98)
|
|
|
|
> ⚠️ **Cas d'usage :** Le serveur principal (`192.168.1.151`) est hors service (panne matérielle, panne réseau majeure, etc.). Vous devez reconstruire l'application sur le serveur `.98` et y rediriger le trafic utilisateur.
|
|
|
|
### Étape 2.1 : Se connecter au serveur de secours
|
|
Connectez-vous en root sur le serveur de secours :
|
|
```bash
|
|
ssh root@192.168.1.98
|
|
```
|
|
|
|
### Étape 2.2 : Récupérer les outils et les sauvegardes depuis le NAS
|
|
Grâce à la clé SSH configurée, téléchargez les scripts de restauration et les archives depuis le NAS :
|
|
```bash
|
|
# 1. Créer le répertoire pour les scripts
|
|
mkdir -p /opt/wordly/scripts
|
|
|
|
# 2. Télécharger les scripts depuis le NAS
|
|
rsync -az -e "ssh -i /root/.ssh/wordly_nas_key" wordly-backup@192.168.1.146:/volume1/backups/wordly/scripts/ /opt/wordly/scripts/
|
|
|
|
# 3. Télécharger les fichiers de sauvegarde dans le dossier /tmp/
|
|
rsync -az -e "ssh -i /root/.ssh/wordly_nas_key" wordly-backup@192.168.1.146:/volume1/backups/wordly/snapshots/ /tmp/
|
|
```
|
|
|
|
### Étape 2.3 : Choisir la sauvegarde et lancer la restauration
|
|
Listez les fichiers téléchargés dans `/tmp` pour identifier la dernière sauvegarde :
|
|
```bash
|
|
ls -lht /tmp/wordly_dr_*.tar.gz
|
|
```
|
|
|
|
Exécutez la restauration complète en remplaçant `NOM_ARCHIVE.tar.gz` :
|
|
```bash
|
|
bash /opt/wordly/scripts/disaster-recovery.sh --restore /tmp/NOM_ARCHIVE.tar.gz
|
|
```
|
|
|
|
### Étape 2.4 : Confirmer
|
|
Saisissez la confirmation de sécurité :
|
|
```text
|
|
RESTORE-ALL
|
|
```
|
|
|
|
### ⚙️ Automatisation effectuée par le script :
|
|
Le script effectue automatiquement les opérations suivantes :
|
|
1. Extraction de l'environnement (`.env`), du `docker-compose.yml` et des configurations Docker.
|
|
2. Démarrage des conteneurs applicatifs et de la base de données.
|
|
3. Restauration de la base de données PostgreSQL.
|
|
4. Redémarrage et vérification de la santé de l'application (HTTP Health Check).
|
|
5. **Appel de l'API de Nginx Proxy Manager (`192.168.1.184`) pour rediriger automatiquement le domaine `wordly.art` vers l'IP du serveur de secours (`192.168.1.98`)**.
|
|
6. Envoi d'une alerte de succès sur votre Telegram.
|
|
|
|
---
|
|
|
|
## 3. Vérifications post-restauration
|
|
|
|
Si le script se termine avec succès, l'application est en ligne. Vous pouvez valider manuellement avec les commandes suivantes :
|
|
|
|
* **Vérifier l'état des conteneurs :**
|
|
```bash
|
|
docker compose ps
|
|
```
|
|
* **Tester l'accès HTTP en local :**
|
|
```bash
|
|
curl http://localhost:8001/health
|
|
```
|
|
* **En cas d'erreur de redirection automatique de NPM (Dernier recours) :**
|
|
Si la redirection automatique échoue, connectez-vous sur l'interface d'administration NPM :
|
|
* URL : `http://192.168.1.184:81`
|
|
* Allez dans **Proxy Hosts** -> `wordly.art` -> **Edit**
|
|
* Modifiez le champ **Forward Hostname/IP** en y mettant l'IP du serveur actif (soit `.151`, soit `.98`).
|
|
* Cliquez sur **Save** (la modification est instantanée).
|