📍 Article principal : Hetzner Object Storage 2026

Introduction

Une plateforme SaaS comptable d’Abidjan a découvert un mardi matin que sa base PostgreSQL était corrompue suite à une panne disque sur son VPS principal. Heureusement, l’équipe avait configuré six mois plus tôt un système de sauvegardes nocturnes vers Hetzner Object Storage avec rclone et chiffrement GPG. La restauration a pris 90 minutes : téléchargement du dump le plus récent, déchiffrement, restauration PostgreSQL, vérification des données, remise en service. Aucune donnée perdue, aucun client impacté. Sans cette discipline de sauvegarde, la perte aurait représenté plusieurs jours de travail comptable et probablement des poursuites de clients institutionnels. Ce tutoriel décrit la stratégie 3-2-1 appliquée à Hetzner Object Storage : trois copies, deux supports différents, un hors-site. La configuration tient en quelques scripts shell éprouvés sur des dizaines de projets clients ouest-africains.

Prérequis

VPS Hetzner ou autre serveur Linux à sauvegarder
Bucket Hetzner Object Storage configuré avec credentials
rclone installé (curl https://rclone.org/install.sh | sudo bash)
GPG installé pour chiffrement (apt install gnupg)
Niveau : intermédiaire — Temps : 1 h 30

Étape 1 — Stratégie 3-2-1

La règle 3-2-1 est le standard professionnel des sauvegardes depuis 30 ans. Trois copies des données : la version production active, plus deux sauvegardes distinctes. Deux supports différents : par exemple le disque local du serveur et un stockage objet distant. Un hors-site : au moins une copie dans un datacenter physiquement différent du serveur principal. Cette discipline élimine la classe entière des incidents catastrophiques (crash disque, suppression accidentelle, attaque ransomware, panne datacenter, sinistre incendie).

Pour un SaaS ouest-africain typique, l’application concrète est triple. Premièrement, un snapshot Hetzner Cloud quotidien du VPS (gratuit, conserve 7 jours) — protège contre les erreurs récentes. Deuxièmement, un dump nocturne PostgreSQL chiffré copié vers Hetzner Object Storage Falkenstein — protège contre le crash disque et offre rétention longue. Troisièmement, une copie hebdomadaire vers Backblaze B2 ou OVH Object Storage Roubaix — protège contre une panne majeure Hetzner ou compromission du compte. Coût total typique : 3 à 5 euros par mois, ce qui est dérisoire face au coût d’une perte de données.

Étape 2 — Configurer rclone pour Hetzner

rclone est un outil polyvalent qui parle nativement S3, Backblaze B2, Google Drive, et trente autres protocoles de stockage cloud. La configuration tient dans un seul fichier qui décrit chaque destinataire (appelé « remote »). Pour Hetzner, on configure un remote de type S3 avec endpoint et credentials spécifiques.

# ~/.config/rclone/rclone.conf
[hetzner]
type = s3
provider = Other
endpoint = https://fsn1.your-objectstorage.com
region = fsn1
access_key_id = VOTRE_ACCESS_KEY
secret_access_key = VOTRE_SECRET_KEY
acl = private

[backblaze]
type = b2
account = VOTRE_ACCOUNT_ID
key = VOTRE_APPLICATION_KEY

Tester immédiatement : rclone ls hetzner:itskills-backups liste le contenu du bucket (vide initialement). Si une erreur 403 apparaît, vérifier les credentials. Si une erreur DNS apparaît, vérifier l’endpoint. Une fois la connexion validée, rclone est opérationnel pour toutes les opérations standards : copy, sync, mount, etc.

Étape 3 — Sauvegarder PostgreSQL avec chiffrement

Le pattern recommandé combine pg_dump pour l’export de la base, gzip pour la compression, GPG pour le chiffrement, et rclone pour le transfert. Cette chaîne en pipe minimise l’utilisation du disque local : aucun fichier intermédiaire en clair n’est créé.

#!/usr/bin/env bash
# /usr/local/bin/backup-postgres.sh
set -euo pipefail

DATE=$(date +%Y%m%d-%H%M)
DB_NAME="app_production"
PASSPHRASE_FILE="/root/.backup-passphrase"

pg_dump -Fc -d ${DB_NAME} \
  | gzip \
  | gpg --batch --passphrase-file ${PASSPHRASE_FILE} --symmetric --cipher-algo AES256 \
  | rclone rcat hetzner:itskills-backups/postgres/${DB_NAME}-${DATE}.dump.gz.gpg

# Conserver 30 jours, supprimer les plus anciens
rclone delete --min-age 30d hetzner:itskills-backups/postgres/

echo "Backup terminé : ${DB_NAME}-${DATE}"

La passphrase est stockée dans un fichier protégé en lecture root uniquement (chmod 600). Cette discipline évite que la passphrase apparaisse dans l’historique shell ou dans les logs du processus. Pour la rotation périodique de la passphrase, on génère une nouvelle valeur tous les 6-12 mois et on conserve les anciennes en archive sécurisée pour pouvoir restaurer les sauvegardes anciennes si nécessaire.

Étape 4 — Automatisation cron

Le script s’exécute automatiquement chaque nuit via crontab. Pour un SaaS B2B servant des utilisateurs ouest-africains, planifier le backup à 3 heures du matin GMT (4h heure locale Sénégal/CI, 5h heure locale Niger) minimise l’impact sur les utilisateurs actifs et profite de la bande passante moins sollicitée.

# crontab -e (en tant que root)
0 3 * * * /usr/local/bin/backup-postgres.sh >> /var/log/backup-postgres.log 2>&1
30 3 * * 0 /usr/local/bin/backup-fichiers.sh >> /var/log/backup-fichiers.log 2>&1

La première ligne lance le backup PostgreSQL nocturne. La deuxième lance un backup hebdomadaire des fichiers (uploads utilisateurs, configurations) tous les dimanches à 3h30. Les logs sont concaténés dans des fichiers dédiés que l’on consulte en cas de problème ou que l’on intègre à un système de monitoring centralisé.

Étape 5 — Alternative : restic pour incrémentiel

rclone simple effectue des sauvegardes complètes à chaque exécution. Pour des volumes importants où le coût stockage devient sensible, restic est une alternative qui fait du backup incrémentiel avec déduplication. Seules les portions de données qui ont changé sont stockées, ce qui peut diviser par dix le coût stockage pour des sauvegardes fréquentes de gros volumes.

# Initialiser le repo restic chiffré sur Hetzner
RESTIC_PASSWORD_FILE=/root/.restic-pass restic init \
  --repo "s3:https://fsn1.your-objectstorage.com/itskills-backups/restic-volumes"

# Backup quotidien des fichiers
restic --repo "s3:..." backup /var/uploads --tag uploads-$(date +%Y%m%d)

# Politique de rétention : 7 derniers jours, 4 dernières semaines, 12 derniers mois
restic --repo "s3:..." forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Pour les sauvegardes de bases PostgreSQL volumineuses (au-delà de 50 Go), restic apporte un gain mesurable. Pour les bases plus modestes, rclone simple suffit et reste plus compréhensible pour un nouveau venu dans l’équipe. Le choix dépend du volume et de la fréquence : volume faible et fréquence basse égale rclone simple, volume élevé et fréquence haute égale restic.

Étape 6 — Tester la restauration

Une sauvegarde non testée est une sauvegarde illusoire. La discipline professionnelle impose un test de restauration trimestriel sur un environnement isolé. La procédure : provisionner un nouveau VPS Hetzner temporaire, télécharger la dernière sauvegarde, déchiffrer, restaurer PostgreSQL, lancer l’application, valider que les données critiques sont intactes.

# Sur un VPS de test
rclone copy hetzner:itskills-backups/postgres/app_production-20260427-0300.dump.gz.gpg /tmp/
gpg --batch --passphrase-file /root/.backup-passphrase --decrypt /tmp/app_production-20260427-0300.dump.gz.gpg | gunzip > /tmp/dump.sql
pg_restore -d app_test /tmp/dump.sql
psql app_test -c "SELECT count(*) FROM commandes WHERE statut='validee';"

Ce test révèle les problèmes silencieux : passphrase oubliée, dump corrompu, dépendances non installées sur l’environnement de restauration, schéma incompatible avec la version PostgreSQL. Détecter ces problèmes en routine trimestrielle est infiniment moins coûteux que les découvrir en plein incident à 3 heures du matin un samedi.

Erreurs fréquentes

Erreur	Cause	Solution
Backup s’exécute mais bucket vide	Erreur silencieuse dans le pipe	Ajouter `set -o pipefail` dans le script
« NoSuchBucket » malgré bucket existant	Region ou endpoint incorrect	Vérifier `fsn1` ou `nbg1` exact
Backup volumineux qui timeout	Pas de mode multipart	rclone gère automatiquement, vérifier connectivité
Passphrase perdue	Pas de coffre fort de mots de passe	1Password / Bitwarden organisationnel
Restauration échoue avec erreur de version	PostgreSQL prod plus récent que test	Aligner les versions ou utiliser pg_dumpall générique
Coûts stockage qui explosent	Pas de cleanup des anciens backups	rclone delete –min-age dans le script

Adaptation au contexte ouest-africain

Trois aspects pratiques. Premièrement, la connectivité variable des datacenters africains envers Hetzner Europe peut faire varier la durée des backups. Pour un dump de 5 Go, on observe typiquement 3 à 8 minutes selon le moment de la journée. Planifier les backups en heure creuse (3h-5h GMT) profite de la bande passante moins sollicitée. Deuxièmement, pour les SaaS qui traitent des données sensibles soumises à exigences réglementaires (santé, finance), le chiffrement GPG des dumps avant transfert est non-négociable. Documenter cette pratique dans le dossier de conformité présente un argument solide aux auditeurs. Troisièmement, la double destination (Hetzner primaire + Backblaze B2 secondaire) protège contre les pannes majeures et contre les compromissions de compte. Pour quelques euros de plus par mois, la résilience devient comparable à celle des grandes entreprises.

Pour les structures qui démarrent et se demandent quand investir dans une stratégie de backup professionnelle : la réponse est dès le premier client payant. Avant cela, perdre les données de quelques utilisateurs de test est gérable. Après, c’est un risque commercial existentiel qui justifie largement les 3-5 euros mensuels d’investissement.

Tutoriels frères

Pour aller plus loin

FAQ

Combien de temps conserver les backups ?
Selon les exigences réglementaires : 7 ans pour les données comptables (loi UEMOA), 5 ans pour les données fiscales, 3 ans pour les logs d’audit. Pour les données opérationnelles non régulées, 90 jours suffisent généralement.

Faut-il chiffrer absolument tous les backups ?
Oui dès qu’ils contiennent des données utilisateurs. Hetzner sécurise déjà au niveau infrastructure, mais le chiffrement applicatif protège même contre une compromission complète d’Hetzner.

Quelle alternative à rclone si on n’aime pas la CLI ?
Duplicacy ou Borgbackup pour les workflows similaires avec interfaces différentes. Pour une UI graphique, Veeam ou Bareos peuvent gérer Hetzner via leurs plugins S3.

Comment monitorer les backups en cas d’échec ?
Healthchecks.io ou Cronitor envoient une alerte si le cron ne ping pas l’endpoint dans le délai prévu. Configuration en 5 minutes, plan gratuit suffisant pour 20 jobs.

Patterns avancés et orchestration

Pour les SaaS qui ont plusieurs services à sauvegarder (PostgreSQL, MongoDB, Redis, fichiers utilisateurs, configurations), un script orchestrateur centralisé devient utile. Ce script appelle séquentiellement les sous-scripts spécialisés, agrège les statuts, et envoie un rapport unique. La discipline est de séparer chaque sauvegarde en sous-script dédié pour faciliter le débogage individuel et la maintenance évolutive. Ajouter ou retirer une source de données revient à éditer un sous-script sans toucher au reste de l’orchestration.

Pour les déploiements multi-tenant où chaque client a sa propre base de données, on automatise la liste des tenants depuis la base de configuration : un script lit les tenants actifs, lance le backup pour chacun, applique la rétention par tenant. Cette approche tient parfaitement avec rclone et bash sans avoir besoin d’orchestrateurs lourds. Pour les structures qui dépassent une cinquantaine de tenants, considérer Restic Rest Server ou un outil dédié comme BorgBackup avec attic deduplication peut apporter des gains opérationnels supplémentaires.

Plan de continuité d’activité

Au-delà des sauvegardes techniques, un plan de continuité d’activité formalisé documente la procédure de restauration : qui appelle qui en cas d’incident, quels sont les RTO et RPO acceptables (Recovery Time Objective et Recovery Point Objective), où sont stockées les passphrases d’urgence, comment communiquer aux clients pendant l’incident. Ce document de quelques pages sauve souvent les heures de panique du jour J. Pour les SaaS ouest-africains qui visent une certification ou des partenariats avec des clients institutionnels, ce plan est généralement demandé en preuve de maturité opérationnelle.

Un test trimestriel d’exercice de continuité, où l’équipe simule un incident et exécute le plan dans un environnement de test, valide que la documentation est encore à jour et que tous les membres savent quoi faire. Cette discipline, héritée des grandes entreprises, devient progressivement standard chez les startups sérieuses. L’investissement temps (une demi-journée par trimestre) se rentabilise dès le premier vrai incident où la procédure documentée évite le chaos et restaure le service rapidement.

Coût total détaillé d’une stratégie 3-2-1

Pour situer les coûts concrets, voici la facture mensuelle typique d’une stratégie 3-2-1 complète pour un SaaS ouest-africain de taille moyenne avec 100 Go de données critiques. Snapshot Hetzner Cloud quotidien : gratuit, inclus dans le plan VPS. Backup quotidien chiffré vers Hetzner Object Storage avec rétention 30 jours : environ 30 Go stockés en moyenne, soit 0,18 euros par mois. Copie hebdomadaire vers Backblaze B2 avec rétention 12 mois : environ 100 Go cumulés à 6 dollars par To, soit 0,60 dollars par mois. Total : moins d’un euro par mois pour une protection sérieuse contre tous les scénarios d’incident courants. Pour 1 To de données critiques, multiplier par dix, soit environ 7-10 euros mensuels — toujours largement inférieur au coût d’une perte de données.

Cette frugalité change la décision : il n’y a plus aucune raison économique de ne pas implémenter une stratégie 3-2-1 complète, même pour les freelances ou très petites structures. L’argument du coût ne tient pas. Le seul investissement reste le temps initial (3-5 heures pour configurer, tester, documenter) et la discipline trimestrielle de validation. Pour les structures qui hésitent encore, le déclencheur typique est le premier client perdu suite à un incident — leçon apprise à coût élevé qui aurait pu être évitée pour quelques euros mensuels.

Sauvegardes automatisées avec rclone vers Hetzner Storage : tutoriel 2026