Backup et restauration site web : procédure complète PME Afrique (2026)

Le backup est l'un des sujets les plus négligés en e-commerce africain : Bluehost / OVH proposent des backups, mais souvent obsolètes (J-7), avec des restaurations qui prennent 24-72h. Pour un e-commerce qui fait 500K FCFA/jour, c'est inacceptable. Voici la procédure backup propre 2026.

TL;DR

- Règle 3-2-1 : 3 copies, 2 supports différents, 1 hors-site.

- Backup quotidien automatique + mensuel longue durée.

- Test restoration mensuel (sans test = pas de backup).

- Coût : 5-30 €/mois pour une PME.

La règle 3-2-1

3 copies de vos données :

• Original (production)
• Copie locale (autre serveur ou disque)
• Copie distante (cloud différent ou pays différent)

2 supports différents (cloud + disque local, ou DO Spaces + Hetzner Storage Box).

1 copie hors-site géographiquement (au cas où data center principal a un sinistre).

Composants à backuper

Étape 1 — backup Postgres quotidien

`bash

#!/bin/bash

# /opt/scripts/backup-postgres.sh

DATE=$(date +%Y%m%d_%H%M%S)

BACKUP_DIR=/opt/backups/postgres

mkdir -p $BACKUP_DIR

# Dump compressed

docker exec postgres_container pg_dump -U postgres -F c -d mydb > "$BACKUP_DIR/db_$DATE.dump"

# Encryption (sensitive)

gpg --encrypt --recipient backup@kolonell.com "$BACKUP_DIR/db_$DATE.dump"

rm "$BACKUP_DIR/db_$DATE.dump"

# Upload to DO Spaces

s3cmd put "$BACKUP_DIR/db_$DATE.dump.gpg" "s3://kolonell-backups/postgres/$DATE.dump.gpg"

# Cleanup local > 7 days

find $BACKUP_DIR -name "*.dump.gpg" -mtime +7 -delete

`

Cron quotidien :

• 0 3 * * * /opt/scripts/backup-postgres.sh

Étape 2 — backup uploads utilisateur

Si Cloudflare R2 / S3 :

• Versioning + lifecycle (intégré, gratuit)
• Cross-region replication (quelques cents/mois)

Si stockage local :

`bash

# rsync vers DO Spaces

rsync -avz /opt/uploads/ s3://kolonell-backups/uploads/$(date +%Y%m%d)/

`

Étape 3 — backup mensuel longue durée

Quotidien = 30 jours rétention.

Mensuel = 12 mois rétention.

`bash

# Premier du mois, copier le backup vers archive long terme

0 4 1 * * cp /opt/backups/postgres/db_$(date +%Y%m01)_*.dump.gpg /opt/backups-monthly/

0 4 1 * * s3cmd put /opt/backups-monthly/*.dump.gpg s3://kolonell-archive/$(date +%Y)/

`

DO Spaces archive : tier "Standard-Infrequent Access" coûte 30 % moins cher.

Étape 4 — backup configuration

Envfiles, secrets, configurations sensibles :

`bash

# Encrypted backup

tar czf - /opt/configs | gpg --encrypt --recipient backup@kolonell.com > config_$(date +%Y%m%d).tar.gz.gpg

# Upload

s3cmd put config_$(date +%Y%m%d).tar.gz.gpg s3://kolonell-backups/configs/

`

JAMAIS dans Git public. JAMAIS en clair sur cloud.

Étape 5 — procédure de restauration

Scenario 1 — corruption DB partielle

`bash

# 1. Stop l'application

docker stop my_app

# 2. Récupérer le backup

s3cmd get s3://kolonell-backups/postgres/20260514_030000.dump.gpg ./

gpg --decrypt 20260514_030000.dump.gpg > restore.dump

# 3. Restore

docker exec -i postgres_container pg_restore -U postgres -d mydb_new < restore.dump

# 4. Switch DB

# (renommer mydb_new en mydb après vérification)

# 5. Restart application

docker start my_app

`

Time-to-recovery (TTR) cible : < 30 min.

Scenario 2 — perte totale serveur

`bash

# 1. Provisionner nouveau serveur (Hetzner CX31 - 30 sec)

# 2. Installer Docker + Caddy + scripts (~10 min)

# 3. Récupérer backup DB + config + uploads

# 4. Restore DB (5-15 min selon taille)

# 5. Pull Docker images depuis registry

# 6. Démarrer services

# 7. Update DNS si IP change

`

TTR cible : < 2h pour restaurer une production complète.

Scenario 3 — ransomware / code malveillant

`bash

# 1. Arrêter immédiatement l'application

# 2. Provisionner serveur isolé (clean room)

# 3. Restaurer backup PRÉ-incident (J-2 si bug détecté J-0)

# 4. Reset tous les secrets (mots de passe, API keys)

# 5. Forensic sur serveur infecté avant nettoyage

# 6. Re-déployer code source vérifié depuis Git

# 7. Restaurer DB depuis backup propre

# 8. Reset 2FA tous les admins

`

Étape 6 — TEST mensuel (le plus important)

Sans test, vous ne savez pas si vos backups marchent. Procédure mensuelle :

`bash

# Sur serveur de staging :

• Wipe staging
• Pull backup le plus récent
• Restore complet
• Test smoke : login, page produit, commande test
• Documenter résultat dans runbook

`

90 % des backups qu'on retrouve cassés en production sont des backups jamais testés.

Coût mensuel typique

Outils recommandés

Pour PME : restic ou pg_dump + cron suffit.

Cas réel — incident résolu

Boutique mode Dakar, été 2025 :

• Vendredi 18h : SQL injection détectée → tables vidées
• Samedi 9h : restauration DB depuis backup J-1
• Samedi 11h : forensic + identification faille
• Samedi 15h : patch + redéploiement
• Samedi 16h : back online

Pertes : 1 journée samedi vendredi soir (~600K FCFA CA), mais data préservée. Sans backup propre : perte totale + réputation détruite.

FAQ

Q : Backup chez Vercel / hébergeur suffisant ?

R : Non — backup hébergeur = backup au même endroit que la prod. Vol/corruption hébergeur = perte. Toujours backup hors-site.

Q : Combien de temps garder un backup ?

R : 30 jours quotidien + 12 mois mensuel + 5 ans annuel pour conformité fiscale (factures stockées DB).

Q : Backup chiffré obligatoire ?

R : Oui pour conformité RGPD/CDP. GPG ou age. Clé privée hors du serveur backup.

Conclusion

Le backup n'est pas un bonus — c'est une assurance vitale. 15-30 €/mois bien investis pour une protection complète. Procédure 3-2-1 + test mensuel + documentation runbook = standard 2026 de toute PME e-commerce africaine sérieuse. Le moment idéal pour mettre ça en place : avant le premier incident.