# 🔄 Backup & Rollback - Guide Complet FailDaily

## 🎯 Vue d'ensemble

Ce guide couvre :
- ✅ Backups MySQL automatiques quotidiens
- ✅ Restauration rapide d'un backup
- ✅ Rollback version Docker (images GitHub)
- ✅ Procédures d'urgence

---

## 📦 Scripts disponibles

| Script | Description | Usage |
|--------|-------------|-------|
| `backup-mysql.sh` | Backup MySQL compressé | `./backup-mysql.sh [rétention_jours]` |
| `restore-mysql.sh` | Restaure un backup | `./restore-mysql.sh <fichier.sql.gz>` |
| `rollback-version.sh` | Rollback version Docker | `./rollback-version.sh <version>` |
| `setup-cron-backups.sh` | Configure cron automatique | `./setup-cron-backups.sh` |

---

## 🚀 Installation (sur OVH)

### Étape 1 : Configuration initiale

```bash
# SSH sur serveur OVH
ssh ubuntu@141.94.42.172

# Aller dans le projet
cd ~/FailDaily

# Rendre les scripts exécutables
chmod +x scripts/*.sh

# Lancer la configuration automatique
./scripts/setup-cron-backups.sh
```

### Étape 2 : Vérifier la configuration

```bash
# Vérifier le cron
crontab -l

# Devrait afficher :
# 0 3 * * * /home/taaazzz/FailDaily/scripts/backup-mysql.sh 7 >> ...

# Tester un backup manuel
./scripts/backup-mysql.sh 7

# Vérifier le backup créé
ls -lh ~/FailDaily/backups/mysql/
```

---

## 💾 Backups MySQL

### Backup manuel

```bash
# Backup avec rétention 7 jours (défaut)
./scripts/backup-mysql.sh

# Backup avec rétention 30 jours
./scripts/backup-mysql.sh 30
```

**Ce qui est sauvegardé :**
- ✅ Toutes les bases de données (`faildaily`, `faildaily_logs`)
- ✅ Procédures stockées et triggers
- ✅ Événements MySQL
- ✅ Structure + données

**Localisation :**
```
~/FailDaily/backups/mysql/
  ├── faildaily_backup_20251129_030000.sql.gz (1.2 MB)
  ├── faildaily_backup_20251128_030000.sql.gz (1.1 MB)
  └── backup.log
```

### Backup automatique (cron)

**Fréquence :** Tous les jours à 3h du matin  
**Rétention :** 7 jours par défaut

**Modifier la fréquence :**
```bash
crontab -e

# Exemples :
# Toutes les 6h : 0 */6 * * * /home/taaazzz/FailDaily/scripts/backup-mysql.sh 7
# Tous les dimanches 2h : 0 2 * * 0 /home/taaazzz/FailDaily/scripts/backup-mysql.sh 30
```

**Logs cron :**
```bash
tail -f ~/FailDaily/backups/cron.log
```

---

## 🔄 Restauration MySQL

### Scénario 1 : Restaurer le backup d'hier

```bash
# Lister les backups disponibles
ls -lht ~/FailDaily/backups/mysql/

# Restaurer le dernier backup
LAST_BACKUP=$(ls -t ~/FailDaily/backups/mysql/faildaily_backup_*.sql.gz | head -n1)
./scripts/restore-mysql.sh "$LAST_BACKUP"

# Confirmer avec 'yes'
```

### Scénario 2 : Restaurer un backup spécifique

```bash
# Restaurer le backup du 28 novembre
./scripts/restore-mysql.sh ~/FailDaily/backups/mysql/faildaily_backup_20251128_030000.sql.gz
```

**⚠️ IMPORTANT :**
- La restauration **écrase toutes les données actuelles**
- Le backend redémarre automatiquement après restauration
- Les utilisateurs seront déconnectés (tokens JWT invalides)

---

## 🔀 Rollback Version Docker

### Pourquoi versionner ?

**Problème avec `latest` :**
```bash
# Déploiement v1.0 avec bug critique
docker build -t faildaily-backend:latest
docker stack deploy ...
# 💥 Bug détecté ! Comment revenir à v0.9 ?
```

**Solution avec versions GitHub :**
```bash
# Déploiement v1.0
docker build -t ghcr.io/taaazzz-prog/faildaily-backend:v1.0
docker push ghcr.io/taaazzz-prog/faildaily-backend:v1.0
docker stack deploy ...

# Bug détecté → Rollback en 30 secondes !
./scripts/rollback-version.sh v0.9-beta
```

### Rollback rapide

```bash
# Voir les versions disponibles sur GitHub
# https://github.com/Taaazzz-prog?tab=packages

# Rollback vers v0.9-beta
./scripts/rollback-version.sh v0.9-beta

# Le script :
# 1. Modifie docker-compose.swarm.yml
# 2. Redéploie la stack
# 3. Attend 30s
# 4. Teste le endpoint /health
# 5. Affiche les logs si erreur
```

### Rollback manuel (comprendre ce qui se passe)

```bash
# 1. Éditer le fichier compose
nano ~/FailDaily/docker/docker-compose.swarm.yml

# 2. Changer les versions :
#    image: ghcr.io/taaazzz-prog/faildaily-backend:v1.0
# → image: ghcr.io/taaazzz-prog/faildaily-backend:v0.9-beta

# 3. Redéployer
docker stack deploy -c docker/docker-compose.swarm.yml faildaily

# 4. Vérifier
docker stack ps faildaily
curl http://localhost:3000/health
```

---

## 🚨 Procédures d'urgence

### Bug critique en production

**Symptôme :** L'application ne répond plus, erreurs 500, base corrompue

**Plan d'action (dans l'ordre) :**

```bash
# 1. Rollback version Docker (rapide - 30s)
./scripts/rollback-version.sh v0.9-beta

# 2. Si le problème persiste, restaurer DB
LAST_BACKUP=$(ls -t ~/FailDaily/backups/mysql/faildaily_backup_*.sql.gz | head -n1)
./scripts/restore-mysql.sh "$LAST_BACKUP"

# 3. Vérifier les services
docker stack ps faildaily
docker service logs faildaily_backend --tail 100

# 4. Tester
curl -I https://faildaily.com/api/health
```

### Perte de données (suppression accidentelle)

```bash
# 1. STOP IMMÉDIATEMENT l'application (éviter écrasement)
docker service scale faildaily_backend=0

# 2. Restaurer le dernier backup
LAST_BACKUP=$(ls -t ~/FailDaily/backups/mysql/faildaily_backup_*.sql.gz | head -n1)
./scripts/restore-mysql.sh "$LAST_BACKUP"

# 3. Relancer l'application
docker service scale faildaily_backend=2
```

### Serveur MySQL corrompu

```bash
# 1. Supprimer le service MySQL
docker service rm faildaily_mysql

# 2. Supprimer le volume
docker volume rm faildaily_mysql-data

# 3. Redéployer la stack (MySQL vierge)
docker stack deploy -c docker/docker-compose.swarm.yml faildaily

# 4. Attendre MySQL démarré (30s)
sleep 30

# 5. Restaurer le backup
LAST_BACKUP=$(ls -t ~/FailDaily/backups/mysql/faildaily_backup_*.sql.gz | head -n1)
./scripts/restore-mysql.sh "$LAST_BACKUP"
```

---

## 📊 Monitoring

### Espace disque backups

```bash
# Taille totale backups
du -sh ~/FailDaily/backups/mysql/

# Nombre de backups
ls ~/FailDaily/backups/mysql/faildaily_backup_*.sql.gz | wc -l

# Backups > 100 MB
find ~/FailDaily/backups/mysql/ -name "*.sql.gz" -size +100M
```

### Logs et alertes

```bash
# Derniers backups
tail -20 ~/FailDaily/backups/mysql/backup.log

# Erreurs cron
grep -i error ~/FailDaily/backups/cron.log

# Derniers rollbacks
tail -20 ~/FailDaily/backups/rollback.log
```

---

## 🎯 Stratégie de versioning

### Convention de nommage

```
v<majeur>.<mineur>-<tag>

Exemples :
  v0.9-beta      → Version beta avant v1.0
  v1.0-stable    → Première version production stable
  v1.1-hotfix    → Correctif urgent v1.0
  v2.0-rc1       → Release candidate 2.0
```

### Cycle de vie version

```bash
# 1. Développement local
git checkout -b feature/nouvelle-fonctionnalite
# ... développement ...

# 2. Build et tag version
docker build -t ghcr.io/taaazzz-prog/faildaily-backend:v1.1-beta backend-api/
docker build -t ghcr.io/taaazzz-prog/faildaily-frontend:v1.1-beta frontend/

# 3. Push vers GitHub Container Registry
docker push ghcr.io/taaazzz-prog/faildaily-backend:v1.1-beta
docker push ghcr.io/taaazzz-prog/faildaily-frontend:v1.1-beta

# 4. Modifier docker-compose.swarm.yml
sed -i 's/:v1.0-stable/:v1.1-beta/' docker/docker-compose.swarm.yml

# 5. Déployer
docker stack deploy -c docker/docker-compose.swarm.yml faildaily

# 6. Si OK, tagger 'stable'
docker tag ghcr.io/taaazzz-prog/faildaily-backend:v1.1-beta \
           ghcr.io/taaazzz-prog/faildaily-backend:v1.1-stable
docker push ghcr.io/taaazzz-prog/faildaily-backend:v1.1-stable
```

### Tags recommandés à conserver

| Tag | Usage | Rétention |
|-----|-------|-----------|
| `v*-stable` | Production | Permanent |
| `v*-beta` | Pre-prod | 3 mois |
| `v*-hotfix` | Correctifs | 6 mois |
| `latest` | ❌ Éviter | - |

---

## 📋 Checklist maintenance mensuelle

- [ ] Vérifier espace disque backups (`df -h`)
- [ ] Tester restauration backup (`restore-mysql.sh`)
- [ ] Tester rollback version (`rollback-version.sh`)
- [ ] Vérifier logs cron (`tail cron.log`)
- [ ] Supprimer vieux backups manuels si besoin
- [ ] Documenter versions déployées en production

---

## 🔧 Configuration avancée

### Backup vers stockage distant (OVH Object Storage)

```bash
# Installer rclone
curl https://rclone.org/install.sh | sudo bash

# Configurer OVH
rclone config

# Modifier backup-mysql.sh pour sync automatique
# Ajouter à la fin :
rclone sync ~/FailDaily/backups/mysql/ ovh:faildaily-backups/mysql/
```

### Alertes email en cas d'échec

```bash
# Installer mailutils
sudo apt install mailutils

# Modifier backup-mysql.sh
# Ajouter en cas d'erreur :
if [ $? -ne 0 ]; then
  echo "Backup failed" | mail -s "FailDaily Backup Error" admin@faildaily.com
fi
```

---

## ❓ FAQ

**Q : Puis-je faire un backup pendant que l'app tourne ?**  
R : Oui, le script utilise `--single-transaction` pour un backup cohérent sans verrouiller les tables.

**Q : Combien de temps prend un backup ?**  
R : ~5-10 secondes pour une DB de 2 MB. Compression incluse.

**Q : Les backups sont-ils chiffrés ?**  
R : Non par défaut. Pour chiffrer, ajouter : `gpg -c backup.sql.gz`

**Q : Puis-je restaurer sur un autre serveur ?**  
R : Oui, copier le fichier `.sql.gz` et utiliser `restore-mysql.sh`

**Q : Que se passe-t-il si un rollback échoue ?**  
R : Le script affiche les logs et retourne un code erreur. Les anciennes versions restent actives.

---

*Guide maintenu par : Équipe FailDaily*  
*Dernière mise à jour : 29 novembre 2025*
