Stratégie 3-2-1, snapshots, dumps DB chiffrés, monitoring uptime, post-mortem structuré, RTO/RPO.
Règle classique du backup :
| Scénario | Protection |
|---|---|
| Suppression accidentelle | Copie 2 (ou 3) sur autre support |
| Corruption disque | Copie sur autre support (pas le même disque) |
| Ransomware qui chiffre tout en ligne | Copie offsite déconnectée du réseau |
| Incendie / vol bureau | Copie offsite (cloud distant) |
| Account cloud compromis | Copie sur support local |
| Métrique | Définition | Question |
|---|---|---|
| RTO (Recovery Time Objective) | Temps maximum acceptable pour récupérer le service après incident | "Combien de temps puis-je rester offline ?" |
| RPO (Recovery Point Objective) | Perte de données maximum acceptable | "Combien de temps de travail puis-je perdre ?" |
| Service | RTO | RPO | Implication |
|---|---|---|---|
| Site vitrine | 24h | 1 semaine | Backup hebdo OK, restauration manuelle OK |
| n8n workflows | 4h | 1 jour | Snapshot quotidien + procédure de restauration documentée |
| Odoo prod | 2h | 1h | Backup DB toutes les heures + restauration scriptée |
| Plateforme e-commerce (revenue) | 15 min | 5 min | Réplication temps réel, basculement automatique |
Plus le RTO/RPO est court, plus c'est cher. Le bon RTO/RPO est celui qui balance le coût de l'outage vs le coût de la solution.
Pattern type pour backup d'une base Postgres vers stockage objet distant, chiffré côté client.
#!/bin/bash
# /usr/local/bin/backup-postgres.sh
# À planifier dans cron : 0 2 * * * /usr/local/bin/backup-postgres.sh
set -euo pipefail
# Configuration
DB_NAME="odoo_prod"
BACKUP_DIR="/var/backups/postgres"
S3_BUCKET="s3://ezway-backups/postgres"
GPG_RECIPIENT="backups@ezway-technology.com"
DATE=$(date +%Y-%m-%d_%H-%M)
TMPFILE="${BACKUP_DIR}/${DB_NAME}_${DATE}.sql.gz.gpg"
mkdir -p "$BACKUP_DIR"
# 1. Dump + compression + chiffrement en pipeline (pas de fichier intermédiaire en clair)
pg_dump "$DB_NAME" \
| gzip -9 \
| gpg --encrypt --trust-model always --recipient "$GPG_RECIPIENT" \
> "$TMPFILE"
# 2. Upload S3 (Backblaze B2 utilise la même API)
aws s3 cp "$TMPFILE" "${S3_BUCKET}/${DB_NAME}_${DATE}.sql.gz.gpg" \
--endpoint-url https://s3.eu-west-1.amazonaws.com
# 3. Nettoyer local (garder 3 jours)
find "$BACKUP_DIR" -name "*.sql.gz.gpg" -mtime +3 -delete
# 4. Vérification (taille non nulle, exit code OK)
if [ ! -s "$TMPFILE" ]; then
echo "ERREUR: backup vide" | mail -s "Backup KO $(hostname)" alerts@ezway-technology.com
exit 1
fi
echo "Backup OK : $TMPFILE"Si vous chiffrez côté serveur du cloud (SSE-S3), le fournisseur a vos données en clair en transit + un instant en mémoire. Préférez le chiffrement côté client (GPG) — le fournisseur ne voit que des bytes opaques.
Conséquence : conservez précieusement la clé GPG ailleurs (USB chiffrée, coffre physique). Sinon vos backups sont des bytes inutiles.
Un backup non testé n'existe pas. Beaucoup d'organisations découvrent au moment fatidique que :
# 1. Provisionner un VPS de test (5€ prorata)
# 2. Télécharger le backup le plus récent
aws s3 cp s3://ezway-backups/postgres/odoo_prod_LATEST.sql.gz.gpg .
# 3. Déchiffrer + décompresser
gpg --decrypt odoo_prod_LATEST.sql.gz.gpg | gunzip > odoo_prod_restore.sql
# 4. Restaurer dans une base vierge
createdb odoo_restore_test
psql odoo_restore_test < odoo_prod_restore.sql
# 5. Vérifier
psql odoo_restore_test -c "SELECT COUNT(*) FROM res_partner;"
# Doit retourner un chiffre cohérent avec la prod
# 6. Lancer l'app sur la DB de test, vérifier que ça boot
# 7. Destruction du VPS de testDocumentez chaque test dans un fichier backup-tests.md versionné en git — preuve d'audit + détection des dégradations.
Uptime Kuma est l'outil open-source de référence pour monitorer ses services. Auto-hébergeable, UI propre, alertes via tous les canaux (email, Slack, Telegram, Discord, webhook).
# Via Docker
docker run -d --restart=always \
-p 3001:3001 \
-v uptime-kuma:/app/data \
--name uptime-kuma \
louislam/uptime-kuma:1
# Ouvrir http://<votre-vps>:3001 et créer le compte adminUptime Kuma génère une status page publique (`/status/...`) — utile pour la transparence avec vos utilisateurs/clients. Pattern : status.votre-domaine.com.
Quand un incident se produit (piratage, fuite de données, ransomware, downtime majeur), le réflexe est crucial. Voici le runbook à imprimer (oui, sur papier, accessible même si tout est down).
Document structuré, blameless (pas de culpabilisation individuelle) :
# Post-mortem — Incident YYYY-MM-DD — [Titre court]
## Résumé
[2-3 lignes : quoi, quand, impact]
## Timeline
| Heure | Action | Qui |
|---|---|---|
| 14:23 | Alerte Uptime Kuma : site down | Auto |
| 14:25 | Investigation démarrée | François |
| 14:40 | Identification : WP piraté via plugin obsolète | François |
| 14:45 | Site mis offline | François |
| 15:30 | Restauration backup propre démarrée | Webmaster |
...
## Cause racine (5 whys)
- Pourquoi le site a été piraté ? → Plugin WP obsolète
- Pourquoi le plugin était obsolète ? → Pas de mise à jour auto
- Pourquoi pas de MAJ auto ? → Crainte de breaking changes
- Pourquoi pas de staging ? → Pas prioritisé budget
- Pourquoi pas prioritisé ? → Risque pas évalué
## Impact
- Site offline 4h
- 2 clients ont contacté pour s'inquiéter
- Aucune donnée personnelle exfiltrée (vérifié logs)
## Ce qui a bien marché
- Détection auto via Uptime Kuma (5 min)
- Backup propre disponible (J-1)
- Communication client claire
## Ce qui a mal marché
- 30 min perdues à chercher l'origine (logs pas centralisés)
- Procédure de restauration pas documentée → improvisation
## Actions correctives
| Action | Owner | Deadline |
|---|---|---|
| Activer MAJ auto WP + plugins | François | 2026-05-25 |
| Mettre en place staging WP | Webmaster | 2026-06-15 |
| Documenter procédure restauration | François | 2026-05-30 |
| Centraliser logs (Loki) | François | 2026-07-01 |Cas vécu sur un site WP de l'écosystème Ezway (cf. mémoire). Leçons apprises :
wp_usermeta) + désactiver via mu-pluginUn incident bien post-mortem-é coûte 2-3 jours mais vous économise les 5 suivants. C'est de loin le meilleur formateur en sécurité opérationnelle.