📚 À lire en complément : notre guide pilier self-hosting pour PME africaines 2026 qui couvre le choix du VPS, Coolify, la sécurité serveur, le monitoring Grafana/Loki et les coûts réels en F CFA.

Une base de données sans backup, c’est une base qui n’existe pas encore — c’est ce que tout sysadmin apprend après son premier crash, généralement au pire moment possible (vendredi soir, jour de paie, lancement de produit). Coolify intègre nativement les sauvegardes vers une destination S3-compatible (Backblaze B2, Wasabi, AWS S3, MinIO auto-hébergé). Voici comment configurer une stratégie de backup robuste qui résiste à un crash serveur, à une suppression accidentelle, à un ransomware, et même à un incendie de datacenter.

Cet article s’inscrit dans notre série Coolify. Si vous démarrez, lisez d’abord le guide d’installation Coolify et le guide PostgreSQL Coolify. Ce tutoriel suppose que vous avez au moins une base de données provisionnée dans Coolify.

Pourquoi la stratégie 3-2-1

La règle de l’industrie est connue depuis des décennies : 3 copies des données, sur 2 supports différents, dont 1 hors site. Avec Coolify, ça se traduit par : la base vivante sur le VPS (1), un dump quotidien sur le même VPS (2 — sur le même disque mais en fichier séparé), et un dump répliqué chez un fournisseur S3 distant (3, hors site géographiquement).

Pourquoi tant de précautions ? Parce que les modes de panne sont multiples : panne disque (corruption, défaillance physique), erreur humaine (DROP TABLE en prod), bug applicatif (mass delete), attaque (ransomware qui chiffre tout), incident hébergeur (datacenter en feu, faillite). Une seule copie ne couvre aucun de ces scénarios. Trois copies bien placées les couvrent tous.

Pour les PME ouest-africaines, je recommande comme destination distante : Backblaze B2 (~6 $ par To/mois, le plus économique du marché), Wasabi (équivalent), ou MinIO sur un second VPS Hetzner différent géographiquement (Helsinki + Falkenstein, par exemple, ou Frankfurt + Helsinki). Pour les budgets ultra-serrés, un VPS partagé entre plusieurs freelances qui hébergent un MinIO mutualisé fonctionne aussi.

Configurer la destination S3 dans Coolify

Dans Coolify, Servers → votre serveur → S3 Storages → « + New ». Renseignez :

Endpoint : s3.eu-central-003.backblazeb2.com (Backblaze EU Central) ou autre selon votre fournisseur. Pour AWS S3 c’est s3.eu-west-1.amazonaws.com ou similaire selon la région. Pour MinIO auto-hébergé, c’est l’URL de votre instance.
Bucket : le nom du bucket créé dans la console du fournisseur (par exemple coolify-backups-prod).
Region : eu-central-003 ou équivalent. Sur certains fournisseurs comme Backblaze, la région est dans l’endpoint.
Access Key + Secret Key : générés dans la console du fournisseur. Pour Backblaze, c’est Application Keys avec accès limité au bucket de backup. Pour AWS, créez un IAM user avec une policy s3:PutObject + s3:ListBucket sur ce bucket uniquement.
Use Path Style : à activer pour MinIO et certains fournisseurs ; désactivé pour Backblaze et AWS.

Coolify teste la connexion en faisant un PUT et un DELETE sur un fichier témoin. Si OK, vous pouvez utiliser ce stockage S3 pour toutes les bases de données du serveur.

Activer les backups sur PostgreSQL

Sur votre instance PostgreSQL Coolify, onglet Backups → Add Backup. Configurez :

Schedule (cron) : 0 3 * * *      # tous les jours à 03h00 UTC
Retention (jours) : 30
Save locally : Yes               # garder une copie sur le VPS
Save to S3 : Yes                 # répliquer vers S3
S3 Storage : [votre destination configurée plus haut]

Coolify utilise pg_dump en format custom (-Fc), ce qui est rapide à restaurer et compressé. Le fichier est nommé db_backup_YYYYMMDDHHMMSS.dump. Sur une base de 1 Go, le backup prend généralement 30 secondes à 2 minutes selon la charge du serveur.

Ajustez la fréquence selon votre RPO (perte de données acceptable) :

Quotidien (3h00) — RPO 24h, pour la plupart des projets PME
Toutes les 6 heures — RPO 6h, pour applications critiques avec données métier importantes
Toutes les heures — RPO 1h, pour applications financières ou e-commerce à fort volume
Continu (WAL archiving) — RPO < 1 minute, hors scope Coolify standard, demande PgBackRest ou Barman

Tester la restauration

Un backup non testé est un backup mort. C’est la règle d’or souvent ignorée. Une fois par mois minimum, simulez une restauration sur un environnement de staging et chronométrez le temps complet. Procédure :

# 1. Télécharger le dump depuis S3
aws s3 cp s3://coolify-backups-prod/postgres/db_backup_20260315_030000.dump ./

# 2. Créer une instance Postgres staging dans Coolify (1 clic)
#    Notez le nom du conteneur, par exemple postgres-staging-abc123

# 3. Copier le dump dans le conteneur
docker cp db_backup_20260315_030000.dump postgres-staging-abc123:/tmp/

# 4. Restaurer dans le conteneur
docker exec -i postgres-staging-abc123 \
  pg_restore -U postgres -d postgres --clean --if-exists \
  /tmp/db_backup_20260315_030000.dump

# 5. Vérifier
docker exec postgres-staging-abc123 \
  psql -U postgres -c "SELECT count(*) FROM users;"

Vérifiez : nombre de tables, nombre de lignes sur les tables critiques, intégrité d’une donnée connue (compte admin, transaction connue). Documentez le RTO (temps de restauration) et le RPO (perte de données acceptable) qui en découlent. Pour une PME, un RTO de 1 heure et un RPO de 24 heures sont des valeurs raisonnables.

MinIO auto-hébergé : alternative souveraine

Si vous voulez garder vos backups en Afrique pour des raisons de souveraineté (données sensibles, RGPD africain, certaines réglementations sectorielles), montez un MinIO sur un second VPS via Coolify lui-même. Coolify a MinIO dans sa marketplace : un clic, une instance opérationnelle.

Configurez ensuite votre Coolify principal pour pointer ses backups sur ce MinIO. Coût supplémentaire : 4-8 € de VPS chez Hetzner ou un hébergeur sénégalais comme Maktoob ou DigitalRise pour de la donnée locale. Pour une vraie redondance, ne mettez pas le MinIO sur le même hébergeur ni dans le même datacenter que votre application.

Sauvegarder aussi les fichiers applicatifs

Les bases de données ne sont qu’une partie du système. Si votre application stocke des fichiers utilisateur (uploads, photos de profil, documents PDF) sur le VPS, sauvegardez-les aussi. Deux approches :

Restic : un outil de backup incrémental qui chiffre côté client et écrit sur S3-compatible. Configurez un cron Linux qui lance restic backup /path/to/uploads chaque nuit. Très efficace en bande passante grâce à la déduplication.
Stocker directement sur S3 dès le départ : votre application écrit les uploads sur Backblaze B2 via SDK plutôt que sur le disque local. Ainsi le VPS reste stateless et les fichiers sont déjà répliqués.

Adaptation Afrique de l’Ouest

Backblaze B2 est accessible depuis tous les pays CEDEAO sans problème, paiement par carte Visa/Mastercard internationale (Wave Visa virtuelle fonctionne aussi). Si votre carte est limitée pour les paiements internationaux, Wasabi accepte aussi PayPal. Pour vraiment payer en FCFA, l’option MinIO auto-hébergé chez un opérateur sénégalais reste la plus pragmatique — facturation en CFA, support local, et données qui restent en Afrique.

Côté bande passante : vos backups partent du VPS européen vers le S3, ce qui ne consomme pas votre bande passante africaine. Le téléchargement pour restauration se fait depuis le VPS européen, donc rapide aussi. Vous payez uniquement pour le stockage S3 et les transferts sortants vers internet (négligeable pour un usage backup).

Sauvegarde immuable et anti-ransomware

Pour vous protéger contre un ransomware qui aurait compromis votre VPS et tenterait de supprimer aussi les backups, utilisez les fonctions d’Object Lock sur S3. Backblaze B2 et AWS S3 supportent ça : un fichier écrit avec Object Lock ne peut pas être supprimé pendant N jours, même par un attaquant ayant les credentials.

Configurez Object Lock à 30 jours sur votre bucket de backup, et générez deux jeux de credentials S3 : un pour Coolify (write-only, pas de delete), un autre pour vous personnellement (admin) gardé hors-ligne. Ainsi un attaquant qui compromet Coolify ne peut pas effacer les backups.

Erreurs fréquentes

Erreur	Cause	Solution
Backup échoue silencieusement	Credentials S3 expirées	Régénérer Application Key, retester
Disque local plein	Retention locale trop longue	Réduire Save locally à 7 jours, ajouter cron de cleanup
Lent vers S3	Bande passante VPS limitée ou région S3 lointaine	Choisir région S3 proche du VPS, augmenter compression
pg_restore échoue	Version Postgres différente	Restaurer dans la même version majeure (16 → 16)
Restauration partielle	Constraints violations sur données existantes	–clean –if-exists ou drop database avant
Coût S3 élevé	Trop de versions ou retention infinie	Configurer cycle de vie : 30j standard puis cold storage

Pour aller plus loin

Guide complet Coolify self-hosted
PostgreSQL managé avec Coolify
Déployer Next.js sur Coolify
Documentation Backblaze B2 : backblaze.com/docs/cloud-storage
Documentation MinIO : min.io/docs
Documentation Restic : restic.net

Backups automatiques Coolify vers S3 et MinIO : guide complet 2026