Comment sauvegarder un VPS vers un stockage offshore chiffré

Presque personne ne met en place des sauvegardes le jour où il déploie un serveur. Cela arrive après coup — après qu'un disque se remplit pendant une mise à niveau, après une suppression dans le mauvais répertoire, après qu'une migration laisse une base de données qui démarre proprement mais répond de travers, après une intrusion. L'écart entre faire tourner une machine qui compte et détenir une copie qui lui survit est la fenêtre la plus dangereuse de l'auto-hébergement, et la plupart des gens y vivent pendant des mois sans le remarquer, parce que rien ne va mal pendant longtemps, puis tout se déclenche d'un coup. La refermer n'est ni difficile ni coûteux. Ce qui donne cette impression de difficulté, c'est que le mot « sauvegarde » sert à désigner quatre choses différentes, dont une seule sera encore là le jour où tout part de travers.

Les quatre choses qui ne sont pas des sauvegardes

Chacune de ces choses est authentiquement utile et mérite d'exister. Aucune n'est une sauvegarde, et croire le contraire est la raison la plus courante pour laquelle les gens perdent des données qu'ils croyaient en sécurité. La distinction n'est pas pédante — chacune de ces solutions échoue précisément dans la situation où une sauvegarde est le plus nécessaire.

• Le RAID, c'est de la disponibilité, pas une sauvegarde. Une grappe survit à un disque mort sans passer hors ligne, c'est pourquoi nos serveurs de stockage tournent en RAID-6 et tolèrent deux pannes à la fois. Elle ne survit pas à un répertoire supprimé, une mise à niveau ratée, une arborescence chiffrée par quelqu'un d'autre ou une table supprimée — chacun de ces événements est fidèlement écrit sur tous les disques au même instant.
• Les instantanés, c'est un « annuler », pas une sauvegarde. Ils vivent sur le même stockage que les données, ils sont généralement visibles par root sur la même machine, et tout ce qui détruit le volume ou l'hôte emporte les instantanés avec lui. Rapides pour revenir en arrière, inutiles quand la machine a disparu.
• La synchronisation, c'est de la réplication, pas une sauvegarde. Un outil de synchronisation existe pour que le côté distant corresponde au côté local, si bien qu'une suppression ou une corruption se propage à la copie aussi vite que le réseau le permet. Nextcloud, Dropbox et la synchronisation rclone se comportent tous ainsi par conception.
• L'historique des versions et la corbeille, c'est du confort, pas une sauvegarde. Ce sont des fonctionnalités de l'application, conservées dans la base de données de l'application, avec une fenêtre de rétention comptée en jours. Quand c'est l'application elle-même qui casse, son propre historique disparaît avec elle.
• Une copie sur le même serveur n'est pas hors site. Si la panne touche la machine, le compte chez l'hébergeur, l'hyperviseur, ou qu'il y a une saisie, chaque fichier présent sur cette machine se trouve dans le même domaine de défaillance, quel que soit le répertoire où il se trouve.

Une sauvegarde est une copie séparée dans l'espace, séparée dans le temps et séparée dans le contrôle. Séparée dans l'espace pour qu'un incendie ou une saisie ne prenne pas les deux à la fois. Séparée dans le temps pour pouvoir revenir à avant les dégâts plutôt qu'à une copie fidèle de ces dégâts. Séparée dans le contrôle pour que des identifiants volés sur la machine en production ne puissent pas l'atteindre. Tout ce à quoi il manque l'un de ces trois éléments est une fonctionnalité de confort déguisée en sauvegarde.

La règle du 3-2-1, et la version qui survit à 2026

La vieille règle veut trois copies des données, sur deux types de stockage différents, dont une hors site. Elle a bien vieilli parce qu'il s'agit en réalité d'une règle sur les pannes non corrélées plutôt que sur les bandes magnétiques. Deux ajouts ont depuis gagné leur place, et tous deux existent à cause de choses qui n'arrivaient pas couramment à l'époque où la règle a été écrite.

• Trois copies. Les données en production, plus deux autres. Deux copies signifient qu'une seule panne vous sépare d'un point unique de défaillance, et les points uniques de défaillance ont une fâcheuse tendance à lâcher pendant que vous comptiez encore réparer le premier.
• Deux types de stockage. Un matériel différent, un logiciel différent, idéalement un hébergeur différent. Deux volumes sur le même hôte partagent un hyperviseur, un panneau de contrôle et un compte — ce qui signifie qu'ils partagent aussi toutes les façons de perdre ce compte.
• Une copie hors site. Physiquement ailleurs, sur une infrastructure qui ne tombe pas en même temps que la vôtre. C'est la copie qui compte en cas d'incendie, de vol, de saisie ou de compte fermé sans préavis.
• Une copie immuable ou hors ligne. Un ransomware comme un accès root compromis cherchent d'abord les sauvegardes, et une destination sur laquelle votre serveur peut écrire est une destination qu'il peut effacer. Des identifiants en ajout seul ou une architecture en tirage (pull) transforment cela d'une catastrophe en simple contrariété.
• Zéro restauration non vérifiée. Une sauvegarde que vous n'avez jamais restaurée n'est qu'une hypothèse. C'est l'ajout que les gens sautent le plus souvent et regrettent le plus amèrement, parce qu'une tâche de sauvegarde qui rapporte un succès depuis deux ans peut très bien avoir écrit des archives inutilisables pendant deux ans.

Quoi sauvegarder : l'état, pas la machine entière

Le réflexe est d'imager le serveur entier. C'est généralement la mauvaise approche : les sauvegardes d'image sont volumineuses, lentes, malcommodes à restaurer sélectivement, et l'essentiel de ce qu'elles contiennent est un système d'exploitation standard que vous pouvez réinstaller en une minute. Ce que vous ne pouvez pas régénérer, c'est l'état — les choses qui n'existent que parce que vous les avez faites.

• Les bases de données, exportées (dump) plutôt que copiées. Un fichier de base de données copié pendant que le moteur écrit est un fichier déchiré, qui peut se restaurer, peut se restaurer de travers, et ne vous dira pas lequel des deux. Utilisez l'outil d'export propre au moteur, ou arrêtez le service, ou prenez un instantané du système de fichiers et exportez à partir de celui-ci.
• Les répertoires de données de l'application. Fichiers envoyés, médias, ressources générées — l'arborescence de fichiers vers laquelle pointe une base de données. Elle doit être capturée au même instant que sa base de données, sinon vous restaurez un index qui décrit des fichiers absents.
• La configuration et tout ce que vous avez modifié à la main. Configuration du serveur web et du reverse proxy, unités systemd, entrées cron, règles de pare-feu, les vingt petits correctifs faits à deux heures du matin dont vous ne vous souviendrez plus.
• Les secrets et les clés, traités séparément et avec plus de soin. Certificats TLS et leurs clés privées, clés d'hôte SSH, jetons d'API, et surtout fichiers de portefeuille et phrases de récupération. Ils méritent leur propre copie chiffrée, qui ne se trouve pas uniquement sur une machine louée.
• Les définitions de conteneurs et les volumes. Les fichiers compose et les fichiers d'environnement, plus les volumes nommés — la partie que les gens oublient, parce que les conteneurs eux-mêmes se recréent trivialement, contrairement à leurs volumes.
• La liste de ce qui est installé, pas l'installation elle-même. Un court inventaire des paquets, des versions et de ce qui tourne où se restaure plus vite et en moins d'espace qu'une image de tout le système de fichiers racine.

La ligne de partage est simple : si vous pouvez le régénérer depuis un script ou un gestionnaire de paquets en dix minutes, ne le sauvegardez pas — notez seulement comment. S'il n'existe que parce que vous ou un utilisateur avez fait quelque chose, il lui faut une copie. Ce principe s'applique aussi bien à un petit site qu'à une instance BTCPay, où le portefeuille et la base de données sont tout et le reste est réinstallable, ou à un serveur Nextcloud, où l'arborescence de fichiers et sa base de données doivent être capturées ensemble, sans quoi ni l'une ni l'autre ne vaut grand-chose.

Dimensionner la destination, et ce qu'elle coûte réellement

Les gens surestiment cela très largement, généralement en calculant le prix de la première copie complète puis en multipliant par le nombre de jours de rétention visé. Un outil de sauvegarde moderne ne fonctionne pas ainsi. Il découpe les données en blocs, stocke chaque bloc unique une seule fois, et compresse ce qui se compresse — si bien que le deuxième instantané d'un serveur resté globalement inchangé ne coûte presque rien, et que trente instantanés quotidiens sont très loin de coûter trente fois le premier.

• Budgétisez à peu près la taille de votre état en production, plus trente à cinquante pour cent pour l'historique, pour une politique de rétention classique sur un serveur qui évolue à un rythme normal.
• La rétention fait grimper le volume bien plus que la fréquence. Des instantanés horaires conservés deux jours coûtent moins cher que des instantanés quotidiens conservés trois ans. Décidez jusqu'où vous remonteriez réellement un jour, puis élaguez automatiquement à cette limite.
• Des données déjà compressées ne se compressent pas une seconde fois. Vidéos, photos, archives et blobs chiffrés atterrissent près de leur taille d'origine, si bien qu'un serveur riche en médias a besoin d'une vraie capacité plutôt que de réglages astucieux.
• Les bases de données dédupliquent mal d'un export à l'autre, parce qu'un export compressé d'une base légèrement différente est un flux d'octets entièrement différent. Exportez sans compression et laissez l'outil de sauvegarde gérer la compression, et votre coût de stockage chute nettement.
• Le premier envoi est la seule partie lente. Ensuite, une exécution nocturne ne déplace que le delta, qui se compte en mégaoctets sur la plupart des serveurs. Le transfert est illimité ici, donc cette première passe est une question de patience, pas de budget.

En pratique, c'est l'assurance la moins chère de toute votre infrastructure. Un serveur de stockage démarre à $7.99/mo pour 1 TB en RAID-6, ce qui dépasse largement l'état qu'occupera une poignée d'instances VPS, et le STO-2 à $12.99/mo double cela. Les bibliothèques de médias et les longues rétentions sont les cas où la capacité compte vraiment : le STO-4 à $22.99/mo vous donne 4 TB, le STO-8 à $39.99/mo vous en donne 8. La destination parle rsync, SFTP et une API compatible S3, si bien que tout outil de sauvegarde courant s'y connecte sans plugin, et les volumes sont chiffrés au repos en AES-256, avec prise en charge de vos propres clés — même si, comme l'argumente la section suivante, il vaut mieux chiffrer avant que les données ne quittent la source de toute façon.

Choisir un outil, et à quoi chacun sert vraiment

Inutile de s'arracher les cheveux ici. Trois outils couvrent l'essentiel des cas, ils sont tous gratuits, et la différence entre eux compte bien moins que la différence entre en avoir un et n'en avoir aucun. Choisissez selon la forme de votre problème plutôt que selon des benchmarks.

• restic — la recommandation par défaut pour la plupart des serveurs. Chiffré côté client, dédupliquant, un seul binaire statique sans démon, et il écrit nativement vers SFTP, des points de terminaison compatibles S3 et de simples répertoires. Son mode ajout seul est le chemin le plus simple vers une destination qu'un serveur compromis ne peut pas effacer.
• BorgBackup — excellente déduplication et compression, très efficace sur des liaisons lentes, mature et éprouvé. Il veut son propre agent disponible côté destination pour les dépôts distants, une contrainte mineure en échange d'un espace de stockage nettement plus réduit.
• rclone — le bon outil quand la tâche consiste vraiment à déplacer des données entre espaces de stockage objet, ou quand vous voulez un miroir plutôt qu'un historique versionné. Associez-le à sa couche crypt si vous l'utilisez directement, et gardez à l'esprit qu'une simple synchronisation propage aussi les suppressions.
• Les outils d'export natifs, toujours, pour les bases de données. mysqldump, pg_dump et leurs équivalents produisent une copie logique cohérente que le moteur peut relire à coup sûr. Exportez vers un fichier, puis laissez restic ou Borg récupérer ce fichier — n'essayez pas de remplacer l'export par une copie astucieuse au niveau fichier.
• Les instantanés de l'hébergeur, uniquement comme couche locale rapide. Prenez-en avant une mise à niveau risquée pour pouvoir revenir en arrière rapidement, mais ne les comptez jamais parmi vos trois copies.

Étape par étape : une sauvegarde chiffrée fonctionnelle en une seule session

1. 01Déployez la destination et verrouillez-laUn serveur de stockage dans une région différente de celle des serveurs qu'il protège. SSH par clé uniquement, son propre utilisateur, et aucune réutilisation d'identifiants provenant des machines qui y écriront.
2. 02Décidez la liste de l'état à protéger avant de toucher un outilNotez chaque chemin et chaque base de données qui doit survivre. Dix minutes avec un fichier texte maintenant évitent la restauration où vous découvrez le seul répertoire que personne n'avait listé.
3. 03Initialisez un dépôt chiffréGénérez un mot de passe de dépôt robuste, initialisez le dépôt via SFTP ou S3, et stockez ce mot de passe ailleurs que sur le serveur sauvegardé. Un dépôt dont la clé n'existe que sur la machine morte n'est pas récupérable.
4. 04Exportez les bases de données d'abord, puis archivezUn script enveloppant qui exporte chaque base de données vers un répertoire de préparation, puis lance une seule passe de sauvegarde sur les exports et l'arborescence de fichiers. C'est cet ordre qui rend la base de données et ses fichiers cohérents entre eux.
5. 05Lancez la première sauvegarde et attendez qu'elle se termineLa première passe est la longue. Lancez-la dans un multiplexeur de terminal pour qu'une connexion coupée ne la tue pas, et notez sa durée — vous connaissez désormais aussi votre fenêtre de restauration.
6. 06Définissez la rétention et élaguez automatiquementQuelque chose comme sept instantanés quotidiens, quatre hebdomadaires et six mensuels convient à la plupart des serveurs. Configurez l'élagage dans la même tâche, sinon le dépôt grossit jusqu'au jour où il cesse de fonctionner.
7. 07Planifiez-la, puis rendez l'échec bruyantUn timer nocturne ou une entrée cron, plus une alerte quand la tâche ne rapporte pas de succès. Une tâche de sauvegarde silencieuse est indiscernable de l'absence de sauvegarde, pendant tous les mois qu'il faudra pour le remarquer.
8. 08Restaurez quelque chose aujourd'hui, depuis la sauvegarde, sur une autre machinePas un simple listing de l'archive — une restauration réelle d'un vrai fichier et d'une vraie base de données sur un serveur jetable. Tant que vous ne l'avez pas fait une fois, vous avez un script de sauvegarde, pas une sauvegarde.

Faire survivre la copie à ce qui a tué le serveur

C'est ce qui sépare une sauvegarde d'une simple contrariété pour un attaquant. Si le serveur détient des identifiants capables de supprimer les sauvegardes, alors un root compromis, un passage de ransomware ou un script malencontreux atteint les deux copies dans la même minute. La correction est structurelle, ce n'est pas une question de mots de passe plus solides.

• Utilisez des identifiants en ajout seul depuis la source. restic comme Borg prennent en charge un mode où la machine qui écrit peut créer de nouveaux instantanés mais ne peut ni supprimer ni élaguer les existants. L'élagage tourne alors depuis ailleurs, selon un calendrier, avec une clé séparée.
• Préférez une architecture en tirage (pull) dès que possible. Une destination qui va chercher elle-même les données à la source, plutôt qu'une source qui les pousse, signifie que la source ne détient jamais le moindre identifiant vers l'archive.
• Ne réutilisez jamais de clés SSH ou de mots de passe de dépôt d'un serveur à l'autre. Une machine compromise doit vous coûter les sauvegardes de cette seule machine, pas de tout votre parc.
• Gardez au moins une copie dans une juridiction différente et un domaine de défaillance différent. La diversité géographique n'est pas de la paranoïa — c'est la différence entre un incident matériel et une perte totale.
• Stockez la clé du dépôt entièrement en dehors de l'infrastructure. Un gestionnaire de mots de passe, un jeton matériel, du papier dans un coffre. N'importe où, sauf sur les machines que le dépôt protège.
• Surveillez les sauvegardes qui se mettent soudain à réussir suspicieusement vite. Une tâche qui prenait vingt minutes et n'en prend plus que quarante secondes sauvegarde généralement un répertoire vide ou démonté, et elle continuera à rapporter un succès en le faisant.

Le choix de la région est ici une vraie décision, pas un détail, parce que votre sauvegarde et votre serveur de production ne devraient pas pouvoir être saisis dans la même action. Si cela compte pour ce que vous faites tourner, choisir l'emplacement délibérément vaut quelques minutes, et placer la destination dans un régime juridique différent de celui de la source est précisément le but de l'exercice.

Restaurer : la partie que personne ne répète

Les restaurations échouent pour des raisons banales, et elles échouent au pire moment possible, parce que c'est le seul moment où la plupart des gens en tentent une. Chacun des échecs ci-dessous se découvre en quelques minutes pendant un exercice, et en plusieurs heures pendant une panne réelle.

• Le mot de passe du dépôt ne se trouvait que sur le serveur qui est mort, si bien que les archives sont intactes et définitivement illisibles.
• La base de données s'est restaurée mais l'arborescence de fichiers provenait d'une passe trois heures plus tard, si bien que l'application affiche des enregistrements dont les fichiers n'existent pas.
• La sauvegarde capturait un répertoire qui avait cessé d'être monté sans que personne ne le remarque, et elle a fidèlement archivé un dossier vide chaque nuit pendant un an.
• Personne ne connaissait l'ordre de restauration — base de données d'abord ou fichiers d'abord, service arrêté ou actif — et l'état à moitié restauré a dû être jeté pour tout recommencer.
• La restauration prend onze heures sur la liaison disponible, que personne n'avait mesurée, et le plan de reprise n'avait pas prévu un tel délai.
• La propriété et les permissions des fichiers reviennent fausses, si bien que tout est présent mais que l'application refuse de démarrer.
• Seul le tout dernier instantané avait jamais été testé, et la corruption dont on essaie de se remettre avait commencé six semaines plus tôt.

Un exercice deux fois par an règle tout cela. Déployez un VPS jetable, restaurez-y depuis le dépôt réel, démarrez le service, regardez les données, détruisez la machine. Cela coûte quelques dollars et une heure, et cela transforme tout le système de sauvegarde d'une croyance en un fait vérifié. Faites-le une fois avec le runbook ouvert, et corrigez le runbook partout où il vous a menti.

La couche confidentialité : une sauvegarde peut défaire votre anonymat

Ce point est spécifique à l'hébergement offshore, et on ne le traite correctement que si l'on y réfléchit avant le premier envoi plutôt qu'après. Une sauvegarde est une copie complète, indexée et durable de votre infrastructure, posée ailleurs, ce qui la rend exactement aussi sensible que l'original — et bien plus facile à oublier.

• Les noms de fichiers et la structure des répertoires sont des métadonnées, même quand le contenu est chiffré. Le chiffrement côté client de restic et Borg couvre aussi les noms ; un simple miroir rsync ne le fait pas, et un listing de répertoire suffit souvent à identifier ce qu'est un serveur et qui le fait tourner.
• Le compte de destination fait partie de l'histoire. Un coffre de sauvegarde loué avec une carte à votre nom légal rattache ce nom à tout ce que le coffre contient, quelle que soit la rigueur avec laquelle la machine source a été tenue propre.
• Le trafic de sauvegarde est une liaison persistante, planifiée et à fort volume entre deux adresses. C'est l'un des motifs les plus lisibles que produit un serveur, et il pointe vers la destination absolument chaque nuit.
• Les vieux instantanés survivent aux décisions qui les ont créés. Quelque chose que vous avez cessé de stocker il y a un an est toujours dans l'archive si la rétention ne l'a jamais élagué — une bonne propriété pour la récupération, une mauvaise pour l'exposition.
• Les journaux et l'historique du shell sont emportés avec tout le reste. L'archive contient fréquemment les adresses IP, les commandes et les identifiants auxquels vous aviez pourtant fait attention sur la machine en production.

Les correctifs sont ordinaires. Utilisez un outil qui chiffre les noms autant que le contenu. Louez la destination de la même façon que vous avez loué la source — chez un hébergeur qui n'a jamais demandé qui vous êtes, financée depuis un solde crypto, avec un rechargement en Monero si vous voulez refermer la trace du paiement aussi. Faites passer le transfert par un tunnel WireGuard si le motif lui-même vous dérange. Et appliquez à la machine de stockage le même durcissement des dix premières minutes que vous avez appliqué à la production, parce qu'une machine qui détient une copie de tout n'est pas une cible de moindre valeur que l'original — c'en est souvent une de plus grande valeur.

Les erreurs qui coûtent leurs données aux gens

• Faire confiance au RAID, aux instantanés ou à un dossier synchronisé en guise de sauvegarde, et découvrir dans quelle catégorie ils se trouvaient réellement le jour où ça comptait.
• Garder l'unique copie sur le même serveur, le même compte ou le même hébergeur que ce qu'elle est censée protéger.
• Copier un fichier de base de données en production au lieu de l'exporter, et restaurer une archive subtilement et silencieusement corrompue.
• Sauvegarder l'arborescence de fichiers et la base de données à des moments différents, si bien qu'aucune des deux ne correspond à l'autre lors de la restauration.
• Stocker le mot de passe du dépôt sur la machine même que ce dépôt protège.
• Donner à la source des droits de suppression complets sur la destination, si bien qu'une seule compromission emporte les archives avec elle.
• Ne jamais élaguer, jusqu'à ce que la destination se remplisse et que la tâche nocturne échoue silencieusement depuis des semaines.
• Sauvegarder des centaines de gigaoctets de données publiques de blockchain pendant que le fichier de portefeuille, lui, ne figure dans aucune archive.
• Configurer des alertes en cas d'échec mais jamais en cas d'absence, si bien qu'une tâche qui a complètement cessé de s'exécuter ne rapporte plus rien du tout.
• Ne tester que le tout dernier instantané, et découvrir pendant un incident réel que la corruption lui est antérieure.

Les sauvegardes sont la chose la moins intéressante que vous configurerez, et la seule dont l'absence est irrécupérable. Tout le reste sur un serveur se reconstruit avec un gestionnaire de paquets et un après-midi ; l'état, lui, ne se reconstruit pas. Consacrez-y une session : listez ce qui doit survivre, exportez les bases de données, envoyez une archive chiffrée vers un serveur de stockage dans un autre pays, élaguez selon un calendrier, alertez sur le silence, et restaurez quelque chose de réel avant de fermer le terminal. Puis laissez-le tranquille. La mesure d'un bon système de sauvegarde, c'est que vous en oubliez l'existence jusqu'au matin où il transforme une catastrophe en une heure légèrement agaçante.