Snapshots et backups sont les deux assurances vie d’un VPS en production. Hetzner Cloud propose les deux nativement, à des prix très accessibles. Mais ils ne couvrent pas les mêmes scénarios — un snapshot disque ne remplace pas un backup applicatif. Voici la stratégie complète pour protéger votre VPS Hetzner contre tous les modes de panne courants en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer).

Cet article complète notre guide Hetzner Cloud Afrique.

Snapshot vs backup : la différence critique

Snapshot : image complète du disque à un instant T. Permet de restaurer le VPS exactement comme il était. Ne capture PAS la cohérence d’une base de données en cours d’écriture (potentiel de corruption au restore si la DB n’est pas figée).
Backup applicatif : dump structuré (pg_dump, mysqldump) ou réplication des fichiers, avec garantie de cohérence. Restauration sélective possible (juste une table, juste les données utilisateur).

Les deux sont complémentaires. Le snapshot vous sauve d’une fausse manip de configuration ou d’un crash kernel. Le backup vous sauve d’un DROP TABLE, d’un ransomware, ou d’une migration ratée.

Snapshots Hetzner : tarifs et usage

Tarif : 0,012 € par Go-mois en 2026 (variable, vérifier sur Hetzner)
Pour un VPS CX23 (40 Go disque, mais snapshot ne pèse que la donnée utile, ~10-25 Go) : ~0,30 €/mois pour garder un snapshot
Pas de limite de nombre de snapshots, vous pouvez en garder 10 si vous voulez
Usage type : avant chaque opération risquée (mise à jour majeure, migration de schéma DB, déploiement non testé)

Comment créer un snapshot

# Via la console web :
# Servers → votre VPS → Snapshots → Take snapshot
# Description : "avant migration auth-v2 2026-04-30"

# Via CLI (hcloud)
brew install hcloud  # ou télécharger binaire
hcloud context create production
# Coller votre token API Hetzner

hcloud server create-image \
  --type snapshot \
  --description "Pre-deploy auth-v2" \
  votre-vps-name

Le snapshot prend 1-5 minutes selon la taille du disque utilisée. Le VPS continue de tourner pendant le snapshot (pas d’interruption).

Backups automatiques Hetzner Cloud

Hetzner propose une option « Backup » sur les VPS Cloud, séparée des snapshots manuels :

Tarif : 20 % du coût mensuel du VPS. Pour CX23 à 4,51 €, c’est ~0,90 €/mois.
Rotation : 7 jours glissants, automatique chaque nuit
Activation : via Console → Server → Backups → Enable. Effet immédiat, pas de redémarrage.
Restauration : choisir un backup et restaurer en place ou comme nouveau VPS

Recommandation : activer Backup automatique sur tous les VPS production. C’est le filet le plus simple à 1 € par mois.

Stratégie 3-2-1 complète

Pour une PME ouest-africaine sérieuse, la stratégie complète mêle plusieurs niveaux :

Backup Hetzner activé : 7 jours rotation, niveau zero-effort
Snapshot avant chaque déploiement majeur : créé manuellement, gardé 30 jours, supprimé après validation
Backup applicatif quotidien : pg_dump, mysqldump, etc. envoyé sur S3 (Backblaze B2) — voir notre guide backups S3
Backup hors site mensuel : copie chez un autre fournisseur (Wasabi, MinIO chez un confrère) pour résister à un incident Hetzner total

Coût total typique pour un projet PME : 0,90 € (Backup auto) + 1 € (snapshots) + 0,06 € (B2 10 Go) = environ 2 €/mois pour une protection sérieuse.

Tester la restauration

Un backup non testé n’existe pas. Une fois par mois minimum :

Restaurer un snapshot ou backup Hetzner sur un VPS de test (pas de production !)
Vérifier que les services démarrent correctement
Vérifier l’intégrité de la base de données (count tables, queries connues)
Documenter le RTO réel (temps de restauration) et le RPO (perte de données)
Détruire le VPS test pour ne pas être facturé

Automatisation snapshots avant déploiement

#!/usr/bin/env bash
# scripts/pre-deploy.sh

set -e

SERVER_NAME="web-prod-01"
DESC="pre-deploy-$(date +%Y%m%d-%H%M%S)"

echo "Création snapshot $DESC..."
SNAPSHOT_ID=$(hcloud server create-image \
  --type snapshot \
  --description "$DESC" \
  "$SERVER_NAME" -o noheader -o columns=ID)

echo "Snapshot créé : $SNAPSHOT_ID"
echo "$SNAPSHOT_ID" >> /var/log/deploy-snapshots.log

# Continuer le déploiement
ssh deploy@$SERVER_NAME "cd /opt/app && git pull && systemctl restart myapp"

# Si succès, on garde le snapshot 7 jours pour rollback rapide
# Si échec, on restaure manuellement le snapshot créé

Adaptation Afrique de l’Ouest

Activez systématiquement Backup Hetzner sur tous les VPS prod — la dépense de 1 €/mois est dérisoire vs le coût d’une restauration manuelle
Pour la fenêtre de backup, Hetzner choisit automatiquement une heure de faible charge. En Afrique, ça tombe souvent en milieu de nuit UTC — vérifiez les horaires.
Utilisez Backblaze B2 (~6 $/To/mois) comme stockage hors-site, accessible depuis tous pays CEDEAO
Documentez votre runbook de restauration en français pour que tout collaborateur puisse l’exécuter en cas d’absence

Erreurs fréquentes

Erreur	Cause	Solution
Snapshot prend des heures	VPS très grand ou I/O saturée	Faire pendant heure creuse, taille volume limitée
Restoration corrompt la DB	Snapshot pendant écriture intensive	Stopper la DB, snapshot, redémarrer DB ; ou utiliser dump logique
Backup auto désactivé silencieusement	Compte impayé ou suspendu	Surveillance facturation, alertes
Pas de backup app malgré snapshot	Confiance excessive en snapshot	Toujours un dump applicatif en complément

Pour explorer plus loin

Etape 1 : comprendre snapshot vs backup chez Hetzner

Hetzner distingue deux mecanismes : les snapshots (manuels ou via API, factures 0,0119 EUR/Go/mois soit ~7,8 FCFA/Go/mois) et les backups automatiques (option a +20 % du prix du serveur, gardent 7 jours rolling). Confondre les deux coute cher : un developpeur a Lagos qui croit avoir des backups peut decouvrir trop tard qu’il n’a que des snapshots ponctuels et obsoletes.

# Voir les snapshots existants
hcloud image list --type snapshot
# Voir si les backups automatiques sont actives
hcloud server describe SERVER_ID -o json | jq '.backup_window'

Si backup_window est null, les backups automatiques ne sont pas actifs. Pour un serveur de production, activez les deux : snapshots avant chaque deploiement majeur (rollback rapide en moins de 2 minutes), et backups automatiques pour la couverture quotidienne sans intervention.

Etape 2 : activer les backups automatiques

Sur la console cloud.hetzner.com, allez sur le serveur > Backups > Enable. Le cout est exactement 20 % du prix du serveur, peu importe la taille du disque. Sur un CX22 a 4,15 EUR/mois (~2722 FCFA), les backups coutent 0,83 EUR/mois (~545 FCFA). Hetzner conserve 7 backups quotidiens en rotation.

# Activer en CLI
hcloud server enable-backup SERVER_ID
# Verifier
hcloud server describe SERVER_ID | grep -i backup

Le premier backup s’execute dans la fenetre de 2 heures suivant l’activation, sans downtime visible (Hetzner utilise Ceph snapshots cote storage). Les jours suivants, le backup tourne dans une fenetre de 4 heures que vous pouvez parametrer (UTC). Choisissez 02h-06h UTC pour un trafic ouest-africain (faible activite cote Dakar/Abidjan).

Etape 3 : creer un snapshot manuel avant chaque deploiement

Avant toute mise a jour majeure (upgrade Postgres, changement de version Node, migration de schema), creez un snapshot. Si la mise a jour echoue, vous restaurez en moins de 2 minutes au lieu de passer 4 heures a debugger en pleine nuit avec un client mecontent.

hcloud server create-image SERVER_ID --type snapshot \
  --description "pre-deploy-$(date +%Y%m%d-%H%M)"
# Lister apres
hcloud image list --type snapshot

Le snapshot prend 2 a 8 minutes selon la taille du disque (1 minute par 10 Go environ). Le serveur reste online pendant la creation. Une fois fini, le snapshot apparait dans la liste avec un nom horodate. Conservez 5 snapshots maximum par serveur pour limiter les couts (au-dela, supprimez les plus anciens).

Etape 4 : restaurer un backup en cas d’incident

Si votre serveur est compromis ou si une migration a corrompu la DB, restaurez depuis le dernier backup. La restauration ne se fait pas « en place » : elle cree une nouvelle image que vous deployez sur le meme serveur ou sur un nouveau. Le serveur d’origine doit etre arrete avant restauration.

# 1. Trouver l'ID du backup a restaurer
hcloud image list --type backup --selector "server=SERVER_ID"
# 2. Arreter le serveur (downtime de la restauration)
hcloud server poweroff SERVER_ID
# 3. Restaurer le backup
hcloud server rebuild SERVER_ID --image BACKUP_ID
# 4. Demarrer
hcloud server poweron SERVER_ID

Comptez 5 a 15 minutes de downtime selon la taille du disque. Pour minimiser l’impact business, faites pointer un Load Balancer Hetzner (4,90 EUR/mois soit ~3214 FCFA) sur 2 serveurs en redondance : un peut etre restaure pendant que l’autre sert le trafic. C’est la base de toute architecture production qui ne meurt pas la nuit du 31 decembre.

Etape 5 : automatiser des snapshots externes vers S3 Object Storage

Les snapshots Hetzner restent dans la meme region datacenter. Si la region nbg1 (Nuremberg) tombe (incident reseau, incendie, panne electrique), vous perdez tout. Pour une protection geographique, dumpez vos donnees applicatives vers Hetzner Object Storage dans une autre region (fsn1 Falkenstein ou hel1 Helsinki).

#!/bin/bash
# /opt/dump-to-s3.sh
DATE=$(date +%Y%m%d-%H%M)
# Dump applicatif (exemple Postgres)
docker exec pg pg_dump -U postgres mydb | zstd > /tmp/db-$DATE.sql.zst
# Push vers Object Storage region differente
aws s3 cp /tmp/db-$DATE.sql.zst \
  s3://disaster-recovery/db/ \
  --endpoint-url https://hel1.your-objectstorage.com
rm /tmp/db-$DATE.sql.zst

Cron quotidien a 03h30 UTC. Hetzner Object Storage coute 5,99 EUR/TB/mois (~3928 FCFA/TB). Pour 50 GB de dumps compresses, vous payez moins de 0,30 EUR/mois (~197 FCFA). C’est la premiere chose a faire avant de passer en production avec de vrais clients : sans DR cross-region, vous etes a 1 incident d’une faillite.

Etape 6 : tester la restauration une fois par mois

Une sauvegarde non testee n’est pas une sauvegarde. Programmez le 1er de chaque mois un test de restauration sur un serveur jetable (Hetzner CPX11 a 4,49 EUR/mois soit ~2945 FCFA), restauration depuis le dernier backup, verification que l’app demarre, puis suppression du serveur.

# Script test mensuel
hcloud server create --name dr-test --type cpx11 \
  --image BACKUP_ID --location fsn1
sleep 120
hcloud server ssh dr-test "systemctl status myapp"
# Si OK, supprimer le serveur de test
hcloud server delete dr-test

Le cout d’un test mensuel est de 0,15 EUR (~98 FCFA) prorata. Compare au cout d’une perte de donnees reelle (jours de downtime, perte de confiance client, eventuels remboursements), c’est l’investissement le plus rentable de votre infra. Documentez chaque test dans un Notion partage avec l’equipe.

Etape 7 : utiliser les snapshots pour cloner un environnement de staging

Au-dela du DR, les snapshots servent a cloner la prod vers un environnement de staging realiste. Particulierement utile pour tester une migration de schema lourde : creez un snapshot de prod, deployez un nouveau serveur a partir de ce snapshot, faites tourner la migration, verifiez que ca marche en moins de 2 heures.

hcloud server create --name staging-from-prod \
  --type cx22 --image SNAPSHOT_ID --location nbg1
# Le serveur staging a une copie exacte de la prod
# IP differente, DB identique, configs identiques

Sur un site marchand a Abidjan qui prevoit de migrer Postgres 15 vers Postgres 17, le clonage staging permet de mesurer la duree exacte de la migration (souvent 3 a 8 heures sur 100 Go de donnees) et de planifier la fenetre de maintenance reelle. Sans staging, vous decouvrez les bugs en production a 02h00 du matin.

Etape 8 : surveiller les alertes de backup echoue

Hetzner envoie un email a l’adresse du compte si un backup automatique echoue. Mais beaucoup d’admins ne lisent pas ces emails. Pour une vraie surveillance, scriptez un check API quotidien qui verifie que le dernier backup date de moins de 30 heures, et envoyez une alerte Telegram ou Slack si non.

#!/bin/bash
LAST_BACKUP=$(hcloud image list --type backup --selector "server=SERVER_ID" \
  -o json | jq -r '.[0].created')
HOURS_AGO=$(( ($(date +%s) - $(date -d "$LAST_BACKUP" +%s)) / 3600 ))
if [ "$HOURS_AGO" -gt 30 ]; then
  curl -X POST "https://api.telegram.org/botTOKEN/sendMessage" \
    -d "chat_id=CHAT_ID&text=ALERT: backup SERVER_ID a $HOURS_AGO heures"
fi

Cron quotidien a 12h00 UTC (apres la fenetre de backup nocturne). En cas d’alerte, connectez-vous au panel Hetzner et verifiez l’etat. Cause typique : disque sature au-dela de 80 % (les snapshots ont besoin d’espace libre). Liberez 10 Go en supprimant des logs ou des images Docker inutilisees, et le backup suivant repart normalement.

Pour completer votre stack infra, consultez notre rubrique DevOps & infra avec les guides Docker et CI/CD, et le hub cloud pour comparer Hetzner aux alternatives africaines.