Backup distant chiffré des conteneurs Incus vers S3 — Bunny ou Wasabi 2026

📍 Article principal du sujet : Incus 6 LTS — gérer conteneurs système et VMs Linux pour PME ouest-africaine

Sauvegarder un parc d’instances Incus localement sur le même VPS ne protège que des erreurs humaines — pas d’un incendie de datacenter, d’un compte compromis chez l’hébergeur, ou d’une suppression accidentelle de la machine. Pour une vraie stratégie de continuité, il faut externaliser les sauvegardes vers un stockage objet S3-compatible distant, idéalement chez un autre fournisseur que celui qui héberge la production. Ce tutoriel construit cette chaîne complète : snapshot ZFS, export Incus, push incrémentiel vers Bunny Storage ou Wasabi, rotation automatisée et procédure de restauration testée.

Le scénario type : un Hostinger Cloud VPS en production qui héberge dix à trente conteneurs Incus, et qui pousse chaque nuit ses sauvegardes vers un bucket Bunny Storage en Europe. Coût total : 5 USD/mois pour le bucket, 6 USD/mois pour le VPS — soit moins de 7 000 FCFA mensuels pour une infrastructure résiliente capable de redémarrer sur n’importe quel autre VPS en moins d’une heure.

Pourquoi Bunny Storage ou Wasabi plutôt qu’AWS S3

Le triplet de tarification S3 chez AWS combine stockage, requêtes, et egress (sortie des données). C’est le coût d’egress qui pique en cas de restauration : restaurer 100 Go de backups depuis AWS S3 coûte 9 USD à chaque tentative. Bunny Storage et Wasabi proposent des tarifs pay-per-storage sans coût de bande passante : 5 USD par téraoctet stocké par mois chez Bunny, 6 USD chez Wasabi, restaurations gratuites à volonté.

Pour une PME qui restaure rarement (idéalement jamais en exploitation, mais une fois par trimestre en test), AWS S3 reste défendable. Pour une PME qui veut tester ses backups régulièrement (recommandé) ou qui prévoit un scénario de migration multi-cloud, Bunny ou Wasabi changent radicalement l’économie. Je recommande Bunny pour la francophonie africaine : datacenter à Paris (latence courte vers Dakar), interface en français, support réactif, paiement carte sans surcharge.

Prérequis

• VPS Linux 64 bits avec Incus 6 LTS opérationnel — voir Installer Incus avec Zabbly
• Pool de stockage ZFS (la structure de cet article repose sur les snapshots ZFS instantanés)
• Un compte Bunny Storage, Wasabi ou MinIO auto-hébergé sur un autre VPS
• Niveau attendu : Linux confortable, notion de stockage objet
• Temps estimé : 60 minutes pour le pipeline complet, dont 20 minutes de tests de restauration

Étape 1 — Choisir et configurer le bucket cible

Sur Bunny.net, créer un compte, ajouter une zone Storage (région Europe pour minimiser la latence), récupérer le mot de passe Storage et le hostname. Sur Wasabi, créer un bucket dans la région eu-central-1, générer un access key + secret key dédiés à ce bucket avec permissions limitées (ListBucket, GetObject, PutObject, DeleteObject). Sur MinIO auto-hébergé, créer le bucket via mc mb.

Quel que soit le fournisseur, chiffrer côté client avant l’upload : aucun fournisseur ne doit avoir accès en clair à vos backups. On utilisera age (succsseur moderne de gpg) pour ce chiffrement.

# Sur l'hôte Incus
apt install -y rclone age
# Configurer rclone interactivement
rclone config
# Choisir : new, Bunny / S3 (selon fournisseur), entrer credentials, sauvegarder
# Vérifier
rclone lsd bunny:

L’outil rclone unifie l’accès à 50+ backends (Bunny, Wasabi, AWS S3, Backblaze B2, MinIO, etc.). Une fois configuré, la commande rclone copy remplace les aws s3 cp spécifiques.

Étape 2 — Générer une paire de clés age pour le chiffrement

age-keygen -o /etc/incus-backup/key.txt
chmod 600 /etc/incus-backup/key.txt
# Récupérer la clé publique pour le chiffrement
grep "public key:" /etc/incus-backup/key.txt
# public key: age1xyz...

La clé privée reste sur le VPS de production et sera nécessaire en cas de restauration. Sauvegarder la clé privée hors-ligne immédiatement : impression papier dans un coffre, copie sur clé USB chiffrée, ou stockage dans un gestionnaire de mots de passe d’entreprise (Bitwarden, 1Password). Si vous perdez cette clé, vos backups deviennent illisibles — un disque chiffré sans clé est aussi utile qu’un caillou.

Étape 3 — Script de backup unitaire

Le script principal backup-incus.sh traite une instance : snapshot, export, chiffrement, push, vérification.

cat <<'EOF' > /usr/local/bin/backup-incus.sh
#!/usr/bin/env bash
set -euo pipefail

INSTANCE=${1:?"Usage: backup-incus.sh "}
DATE=$(date +%Y%m%d-%H%M)
SNAP_NAME="auto-${DATE}"
WORK_DIR=/var/backups/incus
PUBKEY=$(grep 'public key:' /etc/incus-backup/key.txt | awk '{print $NF}')
REMOTE=bunny:backups-itskills/incus

mkdir -p ${WORK_DIR}

# 1. Snapshot ZFS instantané
incus snapshot create ${INSTANCE} ${SNAP_NAME}

# 2. Export tar.gz à partir du snapshot
ARCHIVE=${WORK_DIR}/${INSTANCE}-${DATE}.tar.gz
incus export ${INSTANCE} ${ARCHIVE} --snapshot=${SNAP_NAME}

# 3. Chiffrement age
ENCRYPTED=${ARCHIVE}.age
age -r ${PUBKEY} -o ${ENCRYPTED} ${ARCHIVE}
rm ${ARCHIVE}

# 4. Push vers stockage distant
rclone copy ${ENCRYPTED} ${REMOTE}/${INSTANCE}/

# 5. Vérification que le fichier distant existe
if rclone lsf ${REMOTE}/${INSTANCE}/${INSTANCE}-${DATE}.tar.gz.age > /dev/null; then
  echo "[OK] ${INSTANCE} backup pushed: ${DATE}"
  rm ${ENCRYPTED}
else
  echo "[ERR] ${INSTANCE} push failed"
  exit 1
fi

# 6. Rotation : garder 7 snapshots Incus locaux
incus snapshot list ${INSTANCE} --format csv | grep '^auto-' | head -n -7 | \
  cut -d',' -f1 | xargs -I{} incus snapshot delete ${INSTANCE} {}
EOF
chmod +x /usr/local/bin/backup-incus.sh

Six étapes claires : snapshot, export, chiffrement, push, vérif, rotation. La vérification post-push est cruciale — sans elle, un échec silencieux peut passer plusieurs nuits avant qu’on s’en aperçoive. Toujours valider que le fichier est bien arrivé avant de le considérer comme backupé.

Étape 4 — Cron quotidien sur tous les conteneurs

cat <<'EOF' > /etc/cron.d/incus-backup
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=admin@example.org

# Backup quotidien tous les conteneurs à 3h du matin
0 3 * * * root for i in $(incus list -c n --format csv); do /usr/local/bin/backup-incus.sh "$i" >> /var/log/incus-backup.log 2>&1; done
EOF

Cron lance le script séquentiellement sur chaque conteneur. Pour 30 instances avec snapshot ZFS instantané et export incrémentiel, l’ensemble prend 15 à 30 minutes selon la taille — totalement supportable la nuit. Pour des cas plus rapides, on peut paralléliser avec xargs -P 4.

Étape 5 — Rotation côté distant

Sans politique de rétention, le bucket grossit indéfiniment. Une politique typique : garder 7 sauvegardes quotidiennes, 4 hebdomadaires, 12 mensuelles. Bunny Storage et Wasabi ne proposent pas de lifecycle policy native simple, donc on gère côté client avec un script de purge mensuel.

cat <<'EOF' > /etc/cron.monthly/incus-backup-rotation
#!/usr/bin/env bash
REMOTE=bunny:backups-itskills/incus
# Garder les 7 derniers, supprimer les plus anciens (sauf 1er du mois pour archivage)
for inst in $(rclone lsf ${REMOTE}/ --dirs-only); do
  rclone lsf ${REMOTE}/${inst} --files-only | sort -r | tail -n +8 | \
    grep -v '\-01-' | xargs -I{} rclone delete ${REMOTE}/${inst}{}
done
EOF
chmod +x /etc/cron.monthly/incus-backup-rotation

Pour 30 conteneurs sur 12 mois, cette politique tient l’occupation autour de 100 Go totaux, soit moins de 1 USD/mois chez Bunny. Pour des fichiers volumineux (médiathèques, données scientifiques), on adapte les chiffres mais la logique reste la même.

Étape 6 — Restauration testée d’un conteneur

Un backup non testé est un backup imaginaire. Au moins une fois par trimestre, on simule une restauration complète sur un VPS séparé pour valider que la chaîne fonctionne réellement. Procédure :

# Sur un VPS de test (peut être un autre Hostinger 4 Go)
# 1. Installer Incus et configurer ZFS
# 2. Récupérer la clé privée age (depuis votre coffre offline)
mkdir -p /etc/incus-backup
cp /chemin/vers/votre-cle-privee.txt /etc/incus-backup/key.txt
chmod 600 /etc/incus-backup/key.txt

# 3. Récupérer le backup chiffré
rclone copy bunny:backups-itskills/incus/wp-clientA/wp-clientA-20260429-0300.tar.gz.age /tmp/

# 4. Déchiffrer
age -d -i /etc/incus-backup/key.txt -o /tmp/wp-clientA.tar.gz /tmp/wp-clientA-20260429-0300.tar.gz.age

# 5. Importer dans Incus
incus import /tmp/wp-clientA.tar.gz
incus start wp-clientA

# 6. Vérifier que le service tourne
incus exec wp-clientA -- systemctl status nginx

Le test complet prend 15 à 30 minutes selon la taille du conteneur et la bande passante depuis Bunny vers le VPS de test. Si la restauration échoue, c’est mieux de le découvrir un dimanche calme que pendant un incident en production.

Étape 7 — Métriques et alerting

Pour ne pas découvrir un mois plus tard que les backups n’ont pas tourné, on instrumente le script avec un push de métriques vers un système d’alerting. Healthchecks.io propose un service gratuit pour ce cas exact : on déclare un check, on appelle son URL à chaque succès, et on reçoit un mail si l’appel ne vient pas dans la fenêtre attendue.

# À la fin du script backup-incus.sh, ajouter :
curl -fsS --retry 3 https://hc-ping.com/ > /dev/null

Si une nuit le backup échoue silencieusement (disque plein, credentials Bunny expirés, réseau coupé), Healthchecks.io ne reçoit pas le ping et envoie un mail dans l’heure. Ce filet de sécurité simple évite des semaines de fausse confiance.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour une agence dakaroise qui héberge 30 sites WordPress dans des conteneurs Incus, le coût mensuel total avec backup distant tient en trois lignes : 13 USD VPS Hostinger 8 Go, 5 USD bucket Bunny 100 Go, 0 USD pour rclone et age (open source). Soit 18 USD/mois pour une infrastructure résiliente avec sauvegardes chiffrées hors-site. À comparer aux 200 USD/mois minimum d’une solution managed type Acronis Cyber Backup pour l’équivalent.

Côté bande passante, le push initial peut prendre du temps depuis Dakar (10-20 Mo/s effectifs vers Bunny Paris en heures creuses, 2-5 Mo/s en pic). Stratégie : la première sauvegarde pendant un weekend, puis seuls les exports incrémentiels suivent — typiquement 50 à 200 Mo par conteneur et par jour, soit moins de 5 minutes de transfert pour un parc complet.

Pour les cabinets juridiques ou médicaux tenus à un secret professionnel strict, le chiffrement age côté client est non-négociable. Aucun employé Bunny ou Wasabi ne peut accéder aux contenus, même s’ils le voulaient — ils n’ont que des fichiers .age opaques. C’est l’argument souveraineté des données qui se vend bien à ce type de clientèle.

Tutoriels frères

• Héberger 100 conteneurs Incus sur un seul VPS — pour comprendre la dimension capacité.
• Environnements de développement par équipe — autre cas avec backup quotidien important.
• Snapshots ZFS et incrémentiels — pour creuser le mécanisme côté pool.

Pour aller plus loin

• 🔝 Retour à l’article principal sur Incus
• Documentation officielle rclone
• age, chiffrement moderne
• Documentation Bunny Storage
• Pour pratiquer : Hostinger Cloud VPS

FAQ

Bunny ou Wasabi ?
Bunny pour la francophonie (datacenter Paris, interface FR). Wasabi pour les budgets plus serrés (5 USD/To vs 6 USD/To) ou un footprint plus large (multi-régions internationales).

Pourquoi age et pas gpg ?
age est plus simple, plus rapide, et n’a pas l’historique de bugs de gpg. Pour un usage automatisé serveur, age fait moins d’erreurs et résiste mieux au temps.

Faut-il chiffrer si Bunny le fait côté serveur ?
Oui. Le chiffrement côté client garantit qu’aucun employé du fournisseur, ni la NSA via mandat, ne peut accéder aux contenus. Le chiffrement serveur protège uniquement contre le vol physique de disque.

Quelle taille de bucket prévoir ?
Compter 50 Mo à 5 Go par conteneur selon la charge, puis multiplier par le nombre de jours conservés. Pour 30 conteneurs × 200 Mo × 30 jours = 180 Go, soit 1 USD/mois chez Bunny.

Restaurer un seul fichier dans un conteneur ?
Restaurer le tar.gz dans un conteneur temporaire, monter son rootfs, copier le fichier vers la destination, supprimer le temp. La doc Incus détaille la procédure pour les cas avancés.