Sauvegardes chiffrées hors site : la règle 3-2-1 sur votre propre VPS offshore

Un snapshot n'est pas une sauvegarde

Le snapshot de votre panneau est un outil réellement utile, et vous devriez en prendre un avant chaque changement risqué. Ce n'est pas non plus une sauvegarde, et la différence n'est pas de la pédanterie — c'est la liste complète des situations auxquelles vous essayez de survivre. Un snapshot vit sur le même hôte, dans le même compte, derrière les mêmes identifiants que la machine qu'il protège. Il répond parfaitement à une seule question : comment est-ce que j'annule les vingt dernières minutes ? Il ne répond à aucune des autres. Si le compte disparaît, le snapshot disparaît avec lui. Si la région devient inaccessible, le retour en arrière l'est aussi. Si un intrus atteint le panneau, il atteint aussi les snapshots. Et si les données étaient déjà corrompues au moment où le snapshot a été pris, vous avez préservé la corruption avec une fidélité admirable.

La même logique s'applique aux deux choses que l'on confond le plus souvent avec des sauvegardes. Le RAID n'est pas une sauvegarde : il protège contre la mort d'un disque, et il réplique rm -rf vers le miroir à pleine vitesse. La réplication n'est pas une sauvegarde pour la même raison — elle est conçue pour rendre la seconde copie identique à la première aussi vite que possible, y compris quand la première copie vient d'être détruite. Sur un hébergeur no-KYC, le volet « compte » de cette liste est plus tranchant qu'ailleurs : l'inscription se résume à un pseudonyme, un mot de passe et huit codes de récupération, sans e-mail ni document nulle part dans la boucle, de sorte qu'il n'existe aucun support vers lequel vous tourner si vous les perdez. C'est le produit qui fonctionne comme prévu. Cela signifie aussi que la copie qui compte réellement est celle qui n'est pas accessible depuis les identifiants que vous pourriez perdre.

3-2-1, réécrite pour un serveur que personne ne peut identifier

La vieille règle tient toujours : trois copies de tout ce à quoi vous tenez, sur deux systèmes différents, dont une hors site. L'extension moderne que l'on écrit 3-2-1-1-0 ajoute les deux clauses qui comptent le plus en 2026 — une copie immuable ou hors ligne, et zéro erreur lors de la vérification. Rapportée à un seul serveur, cela donne : la copie un, ce sont les données en production ; la copie deux, c'est le snapshot côté hébergeur ou l'option de sauvegardes chiffrées quotidiennes, qui gère l'erreur ordinaire de deux heures du matin sans le moindre effort de votre part ; la copie trois, c'est un dépôt chiffré sur une seconde machine, dans une région différente, que la première machine n'a aucune autorité pour supprimer. Seule la troisième copie survit à la perte du compte de la première machine, et seule la troisième copie est vraiment la vôtre, au sens où personne d'autre ne peut être contraint de la produire.

Soyez précis sur ce que signifie « hors site ». Une autre baie dans le même bâtiment n'est hors site dans aucun sens qui compte réellement, et une autre région sous la même loi n'en fait que la moitié du chemin — un seul instrument juridique qui atteint une machine ne devrait pas automatiquement atteindre les deux. Avec 6 régions au choix, c'est une décision que vous prenez une fois, au moment du déploiement, et que vous ne revisitez jamais. Il vaut mieux le dire franchement, cependant : deux serveurs ici restent deux serveurs chez un seul hébergeur, ce qui constitue un risque corrélé, aussi bonne que soit l'isolation. Si votre modèle de menace inclut réellement notre disparition à nous, la troisième copie doit se trouver ailleurs, entièrement ailleurs — une machine chez vous, la baie d'un ami, un autre hébergeur sur un autre continent. Tout ce qui est décrit dans ce guide fonctionne à l'identique quel que soit l'endroit où vit la destination ; la seule chose qui change, c'est l'adresse dans une variable d'environnement.

Chiffrez avant que les données ne quittent la machine

La destination doit être un endroit qui stocke des octets qu'il ne peut pas lire. Ce n'est pas une politique que vous acceptez de la part d'un hébergeur, c'est une propriété que vous construisez vous-même : les données sont découpées en chunks, compressées, chiffrées et authentifiées sur la source, et ce qui traverse le réseau est déjà opaque. Les modes repokey et keyfile de Borg chiffrent chaque chunk avec de l'AES-256 en mode compteur et l'authentifient, et les variantes -blake2 remplacent HMAC-SHA256 par BLAKE2b, ce qui est mesurablement plus rapide sur les CPU 64 bits modernes. Le contenu des fichiers, les noms de fichiers et le manifeste d'archive qui les répertorie sont tous chiffrés ; la destination ne détient que des fichiers de segments numérotés et un index qu'elle ne peut pas interpréter. restic vous offre la même architecture avec une plomberie différente. Dans les deux cas, le bon modèle mental est que vous louez de l'espace disque, pas de la confiance.

Deux mises en garde honnêtes. D'abord, ce qui fuit malgré tout : quiconque détient le disque de destination peut voir combien de données arrivent et à quel moment elles arrivent. La taille du dépôt et le rythme des écritures sont visibles même quand le contenu ne l'est pas, ce qui est sans importance pour la plupart des gens et ne l'est pas pour quelques-uns. Ensuite, le chiffrement au repos sur la destination — LUKS sur la machine de sauvegarde — protège contre le disque qui quitte le bâtiment, pas contre l'hôte en cours d'exécution, donc il complète le chiffrement côté client plutôt qu'il ne le remplace. Et puis vient la partie qui ruine les gens : avec repokey, le matériel de clé vit à l'intérieur du dépôt, enveloppé par votre phrase de passe, donc perdre le dépôt fait perdre la clé aussi ; avec keyfile, elle ne vit que sur la source, donc perdre la source fait perdre chaque archive que vous avez jamais créée. Aucun des deux n'est sûr tant que vous n'avez pas exporté la clé et déposé cet export quelque part qui n'est ni l'une ni l'autre des deux machines. Faites-le à l'étape trois, pas « plus tard ».

Borg, restic, rclone : choisissez-en un, et sachez pourquoi

Deux outils constituent de bonnes réponses ici, et le choix dépend réellement de la destination. Borg fait de la déduplication au niveau des chunks, de la compression et du chiffrement authentifié, et — c'est la raison pour laquelle il sert d'exemple détaillé ci-dessous — il embarque un vrai mode append-only côté serveur, obtenu gratuitement via du SSH classique, sans démon à faire tourner ni port supplémentaire à ouvrir. Il faut que borg soit installé aux deux extrémités, et il parle son propre protocole. restic offre les mêmes garanties tout en étant agnostique du backend : SFTP, stockage objet compatible S3, Backblaze B2, ou son propre rest-server. Rien n'a besoin d'être installé sur une simple cible SFTP, ce qui est pratique, mais l'append-only dépend alors de rest-server --append-only ou d'une politique de bucket plutôt que d'une restriction SSH. Règle générale : Borg quand la destination est un serveur que vous contrôlez, restic quand c'est du stockage objet ou quand vous voulez un seul outil pour plusieurs backends.

Ce qu'il ne faut pas utiliser, parce que c'est la façon la plus courante dont tout cela tourne mal. rclone est un outil de synchronisation. Son remote crypt vous donne bien un chiffrement côté client, mais une synchronisation propage les suppressions — le fichier que vous avez perdu à 03h00 est fidèlement retiré de la destination à 03h15, ce qui est exactement l'échec auquel vous essayiez de survivre. Il est excellent pour pousser un dépôt Borg ou restic déjà constitué vers un troisième emplacement ; ce n'est pas une sauvegarde. La même objection s'applique à un simple rsync --delete en cron, qui n'est jamais qu'un miroir déguisé en sauvegarde. tar | gpg vers un chemin distant est une vraie sauvegarde, mais sans déduplication, sans logique de rétention, et avec une restauration qui oblige à remonter toute une chaîne d'incréments pour récupérer un seul fichier. Utilisez les outils conçus pour cela ; ils sont packagés dans toutes les distributions mentionnées dans ce guide.

Append-only, ou comment l'intrus supprime aussi vos sauvegardes

Voici le scénario qui sépare un véritable système de sauvegarde d'un simple script de sauvegarde. Quelqu'un obtient les droits root sur votre machine de production — par l'application, une dépendance, une clé qui a fuité, peu importe comment. La première chose que fait un ransomware compétent, et la première chose que fait un humain compétent, c'est chercher les sauvegardes, parce qu'une victime dont les sauvegardes fonctionnent ne paie pas et ne panique pas. Votre tâche nocturne tourne sans surveillance, donc ses identifiants se trouvent nécessairement sur cette même machine. Si la tâche peut supprimer des archives, l'intrus peut supprimer des archives, et vous ne vous en apercevez qu'au moment précis où vous en avez besoin. Ce n'est pas un mode de défaillance hypothétique ; c'est le mode normal.

Le correctif est minuscule, et c'est la ligne la plus importante de ce guide. Sur la destination, épinglez la clé automatisée à une seule commande dans authorized_keys : command="borg serve --append-only --restrict-to-path /srv/borg",restrict. Cette clé ne peut désormais faire qu'une seule chose — ajouter des données à un dépôt sous un seul chemin. Elle ne peut pas obtenir de shell, ne peut pas rediriger un port, ne peut pas lister votre système de fichiers, et ne peut supprimer aucune archive. Le mot-clé restrict (OpenSSH 7.2 et ultérieur) coupe l'allocation de pty et tous les types de redirection en un seul mot, si bien que la restriction ne se dégrade pas au fil de l'ajout de nouvelles options. Voici maintenant la mise en garde honnête que la plupart des tutoriels passent sous silence : tant que l'append-only est en vigueur, borg prune et borg compact semblent réussir sans réellement rien libérer — la suppression est enregistrée dans une transaction que la prochaine session append-only annule. La rétention a donc besoin d'une seconde clé, non restreinte, que vous utilisez à la main depuis votre ordinateur portable et que vous ne stockez jamais sur la source. Deux clés, deux tâches : celle de la nuit ne peut qu'écrire ; celle de maintenance peut supprimer, et elle vit quelque part que la machine compromise ne peut pas atteindre. Gardez cette clé sous la main pour un autre usage : une tâche interrompue en plein milieu laisse un verrou périmé, et borg break-lock est une écriture.

Où la seconde copie doit vivre

Les sauvegardes sont la seule charge de travail où la latence n'a pas d'importance, donc ignorez le réflexe habituel qui consiste à rapprocher la machine de vos utilisateurs, et choisissez plutôt en fonction du droit et de l'indépendance. Un pays différent de celui de la production est le strict minimum ; une famille juridique différente, c'est mieux. Chacune de nos régions répond à une question différente — la Roumanie est le porte-étendard, où les notifications DMCA ne sont tout simplement pas traitées ; la Suisse se trouve hors de l'UE, derrière des lois de protection des données particulièrement strictes ; l'Islande dispose du cadre IMMI ; le Panama n'a aucune loi de rétention des données obligatoire et aucune voie rapide pour les demandes étrangères ; la Malaisie place une copie entièrement hors de portée des Five Eyes ; et les Pays-Bas sont la plaque tournante du peering. Quelle localisation offshore choisir ? détaille correctement ces compromis ; pour une cible de sauvegarde, la réponse est généralement « là où la production n'est pas ». La bande passante est illimitée sur chaque plan, donc le premier envoi complet est limité par la vitesse à laquelle la source peut lire son propre disque, pas par un forfait de transfert qu'il faudrait rationner.

Le dimensionnement est moins spectaculaire qu'on ne l'imagine. La déduplication combinée à zstd fait que le dépôt représente typiquement une fraction de la source, et après la première exécution, seuls les chunks modifiés traversent le réseau — un serveur chargé de 40 Go avec un taux de changement normal se stabilise autour de quelques centaines de mégaoctets par nuit, si bien qu'une année d'archives quotidiennes coûte bien moins de disque qu'une année de tarballs quotidiens. Le plus petit plan de la gamme constitue une cible parfaitement adaptée ; ne montez en gamme que si vous conservez un historique profond de quelque chose de vraiment volumineux, et consultez les caractéristiques exactes sur la page des plans plutôt que de faire confiance à un chiffre inscrit dans un guide, où il finirait par devenir obsolète. Une seule règle concernant la machine elle-même : ne lui donnez rien d'autre à faire. Pas de serveur web, pas de base de données, aucun service public à part SSH sur une clé. Une cible de sauvegarde qui héberge aussi un projet annexe est une cible de sauvegarde avec la surface d'attaque du projet annexe en plus, et elle mérite le traitement complet de la première heure avant de recevoir la moindre archive.

Une sauvegarde que vous n'avez jamais restaurée n'est qu'une rumeur

Les systèmes de sauvegarde échouent rarement bruyamment. Ils échouent parce qu'un motif d'exclusion a discrètement avalé le répertoire de données, ou parce qu'une base de données a été copiée fichier par fichier pendant que des écritures étaient en cours et que le dump se restaure en une table charcutée, ou parce que la minuterie échoue depuis six semaines derrière une mise à niveau de distribution et que personne ne lit le spool de mails. Le seul test qui détecte tout cela, c'est une restauration. Faites-le selon un calendrier régulier : choisissez une archive au hasard, extrayez-la dans un répertoire temporaire, comparez une poignée de fichiers avec la production, démarrez la base de données à partir du dump et exécutez une requête, et notez combien de temps l'ensemble a pris. Ce chiffre est votre véritable temps de récupération — pas celui que vous aviez supposé — et c'est le seul chiffre qui vaille la peine de vous le citer à vous-même à trois heures du matin. Au moins une fois, faites l'exercice depuis une machine vierge, parce que c'est le scénario réel : un VPS tout neuf, une phrase de passe tirée de votre gestionnaire de mots de passe, une clé exportée depuis l'endroit où vous l'avez rangée, et rien d'autre.

La surveillance mérite le même scepticisme que celui que vous avez appliqué au reste de la pile. Le conseil standard consiste à utiliser un dead man's switch tiers que votre tâche contacte en cas de succès, ce qui révèle discrètement à un service extérieur vos noms d'hôtes, votre calendrier et les moments où votre infrastructure est défaillante — une drôle de chose à greffer sur une machine que vous avez délibérément achetée sans laisser d'identité nulle part. Vous n'en avez pas besoin. La fraîcheur peut être vérifiée depuis la destination sans la clé du tout : le fichier de segment le plus récent du dépôt porte un horodatage, donc un cron de cinq lignes sur la machine de sauvegarde qui hurle quand rien n'est arrivé depuis vingt-cinq heures ne coûte rien et ne révèle rien. L'intégrité dispose elle aussi d'une vérification qui ne nécessite pas la clé — borg check --repository-only tourne localement sur la destination et valide la structure des segments sans jamais voir vos données. Lancez de temps en temps la passe approfondie --verify-data depuis la source avec la clé de maintenance, là où est sa place.

Ce que ça coûte, et sa place dans la pile

L'équation économique ne fait aucun débat. Un second VPS à partir de $8.00/mois, financé sur le même solde prépayé avec des recharges à partir de $30.00, en ligne en environ 15 min, face au coût de la perte de tout ce qui se trouve sur la première machine. Faites-le tourner aux côtés des sauvegardes côté hébergeur plutôt qu'à leur place : l'option de sauvegardes chiffrées quotidiennes gère le cas du mauvais répertoire supprimé par erreur, sans aucun travail de votre part et sans avoir à y penser à trois heures du matin, tandis que ce que vous avez construit ici est la copie qui reste vôtre quand c'est le compte, la région ou l'hébergeur lui-même qui a disparu. Elles couvrent des défaillances différentes, et aucune ne remplace l'autre — c'est tout l'intérêt de compter jusqu'à trois.

Il vaut la peine de terminer en resituant les sauvegardes par rapport à tout le reste, car ce sont quatre contrôles qui échouent indépendamment les uns des autres. Ce que l'hébergeur sait de vous est le premier, et ici c'est proche de rien — un pseudonyme et un solde crypto, le sujet de payer son hébergement anonymement. Quelle loi s'applique est le second, décidé par l'endroit où se trouve le matériel plutôt que par l'endroit où vous vous trouvez. Ce que la machine permet est le troisième, c'est-à-dire la première heure après déploiement, et cela n'appartient qu'à vous de le configurer. Et ce qui survit à la machine est le quatrième — le seul qui soit une promesse que vous faites à votre futur vous-même, et le seul dont personne ne vous rappellera l'existence avant le jour où il sera trop tard pour commencer. Une heure ce soir, et un exercice de restauration inscrit au calendrier. C'est tout ce qu'il y a à faire.

Étape par étape

1. 01

   Déployez la cible de sauvegarde et ne lui donnez rien d'autre à faire

   Déployez un second VPS dans une région qui n'est pas celle où vit la production, et traitez-le comme un appareil à vocation unique. Appliquez-lui la checklist standard de la première heure — SSH par clé uniquement, pare-feu default-deny sur les deux familles d'IP, mises à jour de sécurité automatiques — puis n'ouvrez rien d'autre. Le seul port entrant sur cette machine est SSH.

   ssh root@198.51.100.7
   apt update && apt full-upgrade -y
   hostnamectl set-hostname vault-01
   apt install -y borgbackup ufw unattended-upgrades
   ufw default deny incoming && ufw default allow outgoing
   ufw limit 22/tcp && ufw enable

2. 02

   Créez un compte borg restreint avec deux clés

   Générez deux paires de clés sur la source : une pour la tâche nocturne (sans phrase de passe — elle doit tourner sans surveillance) et une pour la maintenance, que vous gardez uniquement sur votre ordinateur portable. Sur la cible, créez un utilisateur borg non privilégié et épinglez chaque clé à une commande forcée. La clé de la tâche reçoit --append-only ; celle de maintenance non. C'est ce seul fichier qui empêche un intrus présent sur la source d'effacer votre historique.

   # on the source
   ssh-keygen -t ed25519 -N "" -f /root/.ssh/borg_job -C "job@edge-01"
   # on your laptop
   ssh-keygen -t ed25519 -f ~/.ssh/borg_maint -C "maint@laptop"
   
   # on the target
   adduser --disabled-password --gecos "" borg
   install -d -m 700 -o borg -g borg /home/borg/.ssh /srv/borg
   cat > /home/borg/.ssh/authorized_keys <<'EOF'
   command="borg serve --append-only --restrict-to-path /srv/borg",restrict ssh-ed25519 AAAA...job@edge-01
   command="borg serve --restrict-to-path /srv/borg",restrict ssh-ed25519 AAAA...maint@laptop
   EOF
   chown borg:borg /home/borg/.ssh/authorized_keys
   chmod 600 /home/borg/.ssh/authorized_keys

3. 03

   Initialisez le dépôt, puis sortez la clé des deux machines

   Initialisez avec la clé de maintenance, depuis votre ordinateur portable — créer un dépôt n'est pas un append. Un dépôt par machine source garde la rétention triviale et le rayon des dégâts restreint. Exportez ensuite la clé deux fois, dans deux formats, et déplacez les deux exports quelque part qui n'est ni la source ni la cible : un gestionnaire de mots de passe, une clé USB chiffrée, une feuille de papier dans un tiroir. Un dépôt dont la clé n'existe qu'à l'intérieur de lui-même, c'est jouer à pile ou face.

   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i ~/.ssh/borg_maint'
   borg init --encryption=repokey-blake2
   
   borg key export :: /tmp/edge-01.borgkey
   borg key export --paper :: /tmp/edge-01.paper
   # move both off this machine, then shred the copies
   shred -u /tmp/edge-01.borgkey /tmp/edge-01.paper

4. 04

   Figez l'état de l'application avant de lire le disque

   Copier fichier par fichier le répertoire d'une base de données en cours d'exécution produit quelque chose qui ressemble à une base de données et qui se restaure comme une scène de crime. Faites d'abord un dump, sauvegardez ce dump, et excluez le répertoire de données brut. La même logique s'applique à tout ce dont vous ne contrôlez pas le format sur disque : dumpez-le, ou arrêtez-le le temps que dure le snapshot.

   install -d -m 700 /var/backups/dumps
   mariadb-dump --single-transaction --quick --all-databases \
     > /var/backups/dumps/mariadb.sql
   # PostgreSQL:
   # sudo -u postgres pg_dumpall > /var/backups/dumps/pg.sql
   chmod 600 /var/backups/dumps/*.sql

5. 05

   Écrivez la tâche de sauvegarde et placez-la sur une minuterie

   Gardez le script ennuyeux et laissez-le échouer bruyamment. La phrase de passe provient d'un fichier en mode 600 via BORG_PASSCOMMAND, donc elle n'apparaît jamais dans la liste des processus. Nommez les archives avec le nom d'hôte et un horodatage ISO pour qu'elles se trient correctement. Remarquez ce qui n'est pas dans ce script : ni prune, ni delete — la clé de la tâche ne pourrait de toute façon pas les exécuter. Une minuterie avec Persistent=true rattrape le coup après un redémarrage, et un délai randomisé empêche toutes vos machines d'envoyer leurs données à la même seconde.

   cat > /usr/local/sbin/borg-backup.sh <<'EOF'
   #!/bin/bash
   set -euo pipefail
   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i /root/.ssh/borg_job -o BatchMode=yes'
   export BORG_PASSCOMMAND='cat /root/.config/borg/passphrase'
   borg create --stats --compression zstd,6 --one-file-system \
     --exclude-caches --exclude '/var/cache/*' \
     --exclude '/var/lib/mysql' --exclude '/home/*/.cache' \
     ::'{hostname}-{now:%Y-%m-%dT%H:%M}' \
     /etc /root /home /srv /var/www /var/backups/dumps
   EOF
   chmod 700 /usr/local/sbin/borg-backup.sh
   
   cat > /etc/systemd/system/borg-backup.service <<'EOF'
   [Unit]
   Description=Off-site Borg backup
   [Service]
   Type=oneshot
   Nice=10
   IOSchedulingClass=idle
   ExecStart=/usr/local/sbin/borg-backup.sh
   EOF
   
   cat > /etc/systemd/system/borg-backup.timer <<'EOF'
   [Unit]
   Description=Nightly off-site Borg backup
   [Timer]
   OnCalendar=*-*-* 03:17:00
   RandomizedDelaySec=900
   Persistent=true
   [Install]
   WantedBy=timers.target
   EOF
   systemctl daemon-reload
   systemctl enable --now borg-backup.timer

6. 06

   Purgez avec la clé de maintenance, compactez sur la cible

   La rétention ne peut pas tourner depuis la source, parce que la clé de la source est append-only et que ses suppressions seraient annulées silencieusement. Faites-la plutôt tourner depuis votre ordinateur portable, à la cadence qui vous convient — une fois par mois est amplement suffisant. prune décide quelles archives conserver ; compact est ce qui libère réellement l'espace disque. Faites d'abord un --dry-run et lisez la liste avant de le laisser supprimer quoi que ce soit.

   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i ~/.ssh/borg_maint'
   
   borg prune --dry-run --list \
     --keep-daily 7 --keep-weekly 4 --keep-monthly 6
   borg prune --list --stats \
     --keep-daily 7 --keep-weekly 4 --keep-monthly 6
   borg compact --progress

7. 07

   Effectuez l'exercice de restauration, puis rédigez le runbook

   Restaurez avant d'en avoir besoin. Extrayez une archive réelle dans un répertoire temporaire, comparez quelques fichiers avec les originaux, et chargez le dump de la base de données dans un schéma jetable. Ajoutez ensuite les deux contrôles qui tournent sans votre attention : une alarme de fraîcheur sans clé sur la cible, et une passe d'intégrité périodique. Notez enfin les trois faits dont vous aurez besoin dans votre pire jour — où vit la clé exportée, où vit la phrase de passe, et les commandes exactes ci-dessous.

   borg list ::
   mkdir -p /var/tmp/drill && cd /var/tmp/drill
   borg extract --list ::edge-01-2026-08-31T03:17 etc/nginx
   diff -r etc/nginx /etc/nginx && echo 'restore OK'
   
   # on the target, no key needed:
   borg check --repository-only /srv/borg/edge-01
   find /srv/borg/edge-01/data -type f -mmin -1500 | head -1   # empty = stale