Une stratégie de sauvegarde ne se teste jamais la nuit où le serveur meurt. Elle se teste des semaines plus tôt, dans trois décisions silencieuses que personne ne note nulle part : où va la copie, qui a le droit de la supprimer, et si quelqu’un a déjà vraiment relu une sauvegarde restaurée.
Un hébergement qui n’a jamais demandé votre identité offre quelque chose en échange, et c’est le bon endroit pour le dire honnêtement. Il n’y a pas de gestionnaire de compte à appeler, pas de ticket qui ressuscite un volume effacé, et notre politique de rétention est sans détour sur la raison : les données du serveur sont détruites dans les 24 heures suivant la résiliation, les disques sont effacés cryptographiquement plutôt que formatés, et aucune sauvegarde n’est conservée. C’est la même caractéristique qui rend la plateforme intéressante, vue sous un autre angle. Tout ce que vous voudriez récupérer après une mauvaise nuit doit déjà se trouver ailleurs, et c’est vous qui l’y placez.
Ce qui détruit vraiment les serveurs
Presque personne ne perd un serveur de la façon qu’il imagine. La panne matérielle catastrophique est réelle mais rare, et c’est le seul cas contre lequel un hébergeur compétent est déjà protégé. Les pertes qui arrivent vraiment sont plus banales, et chacune met en échec un type de copie différent — c’est pourquoi « j’ai une sauvegarde » n’est pas une réponse tant que vous ne dites pas laquelle de ces situations elle permet de survivre.
| Ce qui casse | Comment ça arrive en général | Ce qui vous sauve |
|---|---|---|
| Votre propre main | Un rm -rf avec une variable shell vide, une migration pointée vers la production, un déploiement qui supprime la mauvaise table | Toute copie hors serveur datant d’avant l’erreur — ce qui veut dire que la rétention doit remonter plus loin que le temps qu’il vous faut pour vous en apercevoir |
| Corruption silencieuse | Un NVMe en train de mourir, une écriture tronquée pendant un redémarrage, une base de données qui écrit des lignes corrompues depuis une semaine | Des copies versionnées assez profondes pour atteindre un point sain connu. Une simple copie miroir reproduit fidèlement les dégâts |
| Compromission | Une clé volée, une application non patchée, une dépendance empoisonnée — puis, délibérément, vos sauvegardes | Une copie que la machine compromise n’avait aucun moyen de supprimer. Rien d’autre ne compte ici |
| Un incident fournisseur ou pays | Perte matérielle, action judiciaire au datacentre, un compte ou un jeton que vous ne pouvez plus atteindre | Une copie qui n’est ni chez ce fournisseur ni sous cette juridiction |
| Perte de la clé | Une phrase de passe oubliée, un fichier de clé effacé avec le serveur qu’il protégeait, un en-tête LUKS que personne n’a exporté | Rien. C’est la seule ligne sans colonne de récupération, et c’est plus fréquent qu’une panne matérielle |
Lisez ce tableau comme une liste de contrôle plutôt que comme une liste de craintes. Une copie nocturne vers un second disque dans la même machine répond à la ligne un et à rien d’autre. Un snapshot dans le même panneau répond aux lignes un et deux. Seule une copie conservée quelque part que le serveur ne peut pas atteindre, sous une clé que vous détenez encore, répond aux cinq.
Un snapshot n’est pas une sauvegarde, et votre hébergeur non plus
Les snapshots excellent dans leur rôle : ils annulent une mise à jour ratée, en quelques secondes, sans aucun transfert. Ce qu’ils ne peuvent pas faire, c’est survivre à ce qui a emporté le serveur, parce qu’ils partagent avec lui tous les mêmes domaines de panne — le même fournisseur, le même compte, le même moyen de paiement, le même pays, souvent le même cluster de stockage. Un snapshot vous protège contre vous-même. Une sauvegarde vous protège contre tout le reste.
Cette distinction compte davantage ici que chez un hébergeur classique, parce que les filets de sécurité habituels ont été retirés délibérément. Personne ne se connecte aux serveurs des clients, donc personne ne remarque que votre tâche de sauvegarde échoue depuis mars. Aucune identité n’est rattachée au compte, donc il n’existe aucun recours humain du type « prouvez qui vous êtes et nous restaurerons ». Et la résiliation est réellement définitive : un solde expiré est un événement de perte de données, pas un événement de facturation.
La clause des 24 heures résume tout l’argument. Sur cette plateforme, les données d’un serveur résilié sont détruites en moins d’une journée, et les disques sont effacés cryptographiquement plutôt que formatés. Il n’y a pas d’annulation de suppression, pas de palier de stockage froid discret, pas d’issue de support qui se termine par « nous avons retrouvé une copie plus ancienne » — parce qu’en conserver une reviendrait à garder vos données après que vous nous avez demandé de ne pas le faire. Le filet de sécurité et la confidentialité sont le même compromis, fait une seule fois.
3-2-1, réécrite pour ceux qui n’ont jamais montré leur pièce d’identité
La règle classique dit trois copies, sur deux types de support, dont une hors site. Elle a été écrite pour une époque de bande magnétique et de disque dur, et la clause sur les supports a discrètement cessé de vouloir dire quoi que ce soit : votre disque de production est du NVMe, le disque de votre cible de sauvegarde est du NVMe, et appeler ça « deux supports » est une histoire que vous vous racontez. La clause qui mérite d’être gardée est celle sur la distance, et pour une infrastructure offshore, la distance ne se mesure pas en kilomètres.
Réécrivez-la comme trois copies, deux fournisseurs, deux juridictions. Les pannes qui emportent les deux copies à la fois sont presque jamais physiques — c’est un compte dont vous avez perdu l’accès, un fournisseur qui a eu une mauvaise semaine, ou un instrument juridique qui frappe un pays sans avoir de prise sur un autre. Deux serveurs dans la même baie sont une copie avec des étapes en plus ; deux serveurs sous le même régime juridique ne font guère mieux. Notre guide des juridictions explique comment choisir une seconde juridiction qui ne reproduit pas simplement l’exposition de la première.
En pratique, c’est bon marché. Une cible de sauvegarde n’a pas besoin de cœurs, et à peine besoin de réseau — elle a besoin de disque et d’une adresse. Le plus petit forfait VPS dans un autre de nos sept emplacements est une cible restic ou Borg tout à fait compétente, et pour des archives se comptant en téraoctets, une machine dédiée avec de vrais disques coûte moins cher par téraoctet que n’importe quel stockage objet. Là où les données sont vraiment volumineuses et rarement lues, l’économie favorise largement le bare metal.
Une chose que les gens font bien en production et mal sur la cible de sauvegarde : la payer de la même façon. Un second serveur acheté avec une carte à votre propre nom rattache discrètement l’identité que vous avez pris soin de retirer du premier, et il détient désormais une copie complète de tout ce qu’il contient. Si la machine de production est payée en Monero, la machine de sauvegarde mérite le même traitement.
La troisième copie est celle que la plupart des gens sautent, et c’est la seule qui soit immunisée contre toutes les pannes distantes à la fois : un disque que vous tenez physiquement, mis à jour de temps en temps, gardé hors ligne. Une fois par mois suffit pour la plupart des gens. Cela coûte l’attention d’un café, et c’est la copie qui survit aux scénarios que les deux autres partagent.
Push, pull, et l’erreur qui laisse une mauvaise nuit dévorer les deux copies
Voici l’arrangement que presque tout le monde construit en premier. Une tâche sur le serveur de production tourne chaque nuit, détient une clé ou un jeton pour la cible de sauvegarde, se connecte, et pousse les données. Ça marche, c’est simple, et ça a une propriété qui ne devient visible que le pire jour de la vie du serveur : qui contrôle la machine de production contrôle aussi les sauvegardes.
Ce n’est pas une hypothèse d’école. Supprimer ou chiffrer les sauvegardes de la victime avant de s’annoncer est une pratique courante chez quiconque fait cela commercialement — les identifiants traînent dans une tâche cron ou un fichier d’environnement, et les trouver prend environ une minute. Une copie que votre attaquant peut supprimer n’est pas une seconde copie. C’est un miroir de la première, avec un délai.
Il existe deux corrections propres, qui se combinent bien avec le durcissement de base que vous devriez déjà avoir fait.
- Cibles en append-only. Les deux outils majeurs prennent en charge un mode où un client peut ajouter des données mais ne peut pas les supprimer. Borg le fait en épinglant la clé SSH sur la cible à
borg serve --append-only; restic le fait avec un serveur REST lancé avec--append-only. Le serveur de production écrit chaque nuit et est structurellement incapable de détruire l’historique. L’élagage des anciens snapshots se fait alors sur la cible, dans une session que la machine de production ne peut pas ouvrir. - Pull plutôt que push. Inversez le sens de la connexion : l’hôte de sauvegarde se connecte à la production, lit, et stocke. La production ne détient aucun identifiant pour la cible, il n’y a donc rien à voler. Restreignez la clé utilisée côté production avec
restrictet uncommand=forcé, pour qu’une clé de sauvegarde volée ne puisse pas devenir un shell.
Le pull est le modèle le plus robuste et demande un peu plus de travail à faire tourner ; l’append-only est quasi gratuit si vous utilisez déjà Borg ou restic. L’un comme l’autre transforme « l’attaquant a supprimé mes sauvegardes » d’un résultat en une simple tentative. Si vous ne devez retenir qu’une chose de ce guide, retenez cette section.
Chiffrer à la source, puis décider qui détient la clé
Les deux outils sérieux chiffrent sur la machine sauvegardée, avant que quoi que ce soit ne traverse le réseau. La cible stocke des blocs qu’elle ne peut pas interpréter — c’est précisément ce qui rend la copie chez un autre fournisseur sûre. Votre second hôte n’a pas besoin d’être digne de confiance, ni même amical ; il doit être joignable et avoir du disque. Cette seule propriété transforme « un serveur dans un pays que je ne connais pas » d’un risque en infrastructure.
C’est un mécanisme différent du chiffrement du disque propre du serveur, et les deux répondent à des questions différentes — notre guide sur le chiffrement intégral du disque sur un VPS détaille ce que le chiffrement de disque protège et ne protège pas pendant que la machine tourne. Le chiffrement des sauvegardes est le plus simple et le plus utile des deux, parce que le modèle de menace est honnête : les données sont au repos, sur un matériel que vous ne contrôlez pas, et la clé n’y va jamais.
Ce qui déplace tout le risque vers la garde de la clé. La phrase de passe est désormais un point unique de perte totale, et c’est un point unique pire qu’on ne l’imagine, parce que la perdre est silencieux — rien ne casse, les sauvegardes continuent de tourner, et vous vous en apercevez au moment exact où vous en aviez besoin. Trois habitudes règlent le problème :
- Ne gardez la phrase de passe sur le serveur que sous forme d’un fichier lisible par root seul, référencé avec
--password-file, pour qu’elle n’apparaisse jamais dans une liste de processus ou un historique de shell. - Gardez une copie lisible par un humain hors de toutes les machines concernées. Du papier dans un tiroir bat véritablement un gestionnaire de mots de passe qui se synchronise vers un compte que vous risquez aussi de perdre.
- Ajoutez une seconde clé au dépôt —
restic key add, ou une clé Borg exportée — pour qu’une phrase de passe oubliée soit une gêne plutôt que la fin de l’archive.
La règle sous-jacente à ces trois habitudes : si la seule copie de la clé se trouve sur la machine que la sauvegarde existe pour remplacer, vous n’avez pas de sauvegarde. Vous avez un tas de blocs chiffrés et une histoire à leur sujet.
Choisir un outil, en un tableau
Le choix de l’outil compte moins que le sens de la connexion et l’état de votre clé, c’est pourquoi il vient en sixième position plutôt qu’en premier. Cela dit, les différences sont réelles, et choisir la mauvaise forme pour le travail crée du travail plus tard.
| Outil | Chiffre avant de partir | Déduplique | Cible append-only | Où il s’utilise |
|---|---|---|---|---|
| restic | Oui, tout le dépôt | Oui | Oui, via son serveur REST | Le choix par défaut. Parle SFTP, le stockage objet et son propre serveur, donc la cible peut être presque n’importe quoi |
| BorgBackup | Oui, tout le dépôt | Oui, le meilleur du groupe | Oui, nativement via SSH | Une seule cible Linux atteinte via SSH. Imbattable quand les données sont volumineuses et répétitives |
| rsync avec rotations | Non — la cible voit tout | Partielle, via des hardlinks | Non | Miroir vers une machine que vous contrôlez entièrement, quand des restaurations partielles instantanées comptent plus que la confidentialité |
| rclone | Seulement avec rclone crypt | Non | Dépend du fournisseur de stockage | Déplacer une archive qui existe déjà vers du stockage objet, ou entre fournisseurs |
| Réplication ZFS | Seulement avec un dataset chiffré | Oui, au niveau bloc | Via les permissions de snapshot | Répliquer entre deux machines ZFS. Très rapide, très rigide aux deux extrémités |
| tar avec age ou GPG | Oui, si vous chiffrez l’archive | Non | Non applicable | Archives petites, occasionnelles, conservées indéfiniment, où la simplicité l’emporte sur l’efficacité |
Pour un serveur unique, restic vers un second VPS est le chemin le plus court vers quelque chose de correct. Pour un seedbox, une archive de médias ou tout ce qui comporte de nombreux gros fichiers similaires, la déduplication de Borg fait la différence entre un disque plein et un disque confortable — le guide seedbox détaille le volet stockage de cette charge de travail.
Tout ce qui tourne n’est pas un fichier
La sauvegarde corrompue la plus courante au monde est une simple copie de fichier d’une base de données en fonctionnement. Elle se termine sans erreur, elle pèse le bon poids, et elle se restaure dans une table que le moteur refuse d’ouvrir. La base de données était en train d’écrire quand la copie est passée ; ce que vous avez sauvegardé est la photo d’une page en train de se tourner.
Trois façons de s’en sortir, par ordre croissant d’effort. La dumper : mysqldump --single-transaction donne un dump InnoDB cohérent sans bloquer les processus d’écriture, et pg_dump fait de même pour PostgreSQL. La snapshotter : geler le système de fichiers ou prendre un snapshot LVM ou ZFS, copier depuis le snapshot, le libérer — c’est ainsi que l’on gère des jeux de données trop volumineux pour être dumpés chaque nuit. Ou l’arrêter : pour un petit service, deux minutes d’indisponibilité à 4 h du matin est une stratégie de cohérence tout à fait respectable, et c’est la seule sans cas particulier.
La même logique s’applique au-delà des bases de données. La couche accessible en écriture d’un conteneur est jetable, mais pas ses volumes, ni le fichier docker compose et l’environnement qui vont avec — une sauvegarde qui restaure les données mais pas la définition vous laisse reconstruire la pile de mémoire. Les files de messages, Redis avec la persistance activée, et une file d’attente de courrier écrite par un MTA méritent tous le même traitement : mettre en pause, snapshotter, ou dumper, mais jamais copier tel quel en espérant.
Quoi sauvegarder, et ce que tout le monde oublie
La plupart des gens sauvegardent la charge utile évidente — la base de données et le répertoire de l’application — et reconstruisent le reste à la main sous pression. C’est dans la reconstruction que partent les heures. Une sauvegarde qui vous ramène à un système fonctionnel, plutôt qu’à un tas de données correctes, inclut la couche ennuyeuse :
/etcen entier, plus les unités et timers systemd que vous avez écrits, et toute crontab qui vit en dehors.- Les certificats TLS et leurs clés privées, ou au minimum la clé de compte ACME, pour que les certificats se renouvellent au lieu de repartir de zéro.
- Les règles de pare-feu et la liste des paquets, qui ensemble reconstruisent la forme de la machine plus vite qu’aucun souvenir qu’on en aurait.
- Les secrets applicatifs et les fichiers d’environnement — ceux délibérément exclus de votre dépôt de code, et donc présents nulle part ailleurs.
- Les enregistrements DNS exportés en texte, y compris les entrées de reverse-DNS et de PTR, qui vivent chez le fournisseur et non sur le serveur.
Certaines clés ne sont pas des données — ce sont des identités. La clé privée d’un service onion Tor est l’adresse : la perdre, et le site ne peut pas revenir sous le même nom .onion, quoi que vous ayez restauré par ailleurs. Une clé de serveur WireGuard signifie réémettre chaque configuration client que vous avez jamais distribuée. La clé DKIM d’un serveur mail signifie un nouveau sélecteur et un nouveau départ pour la délivrabilité. La seed et l’état des canaux d’un nœud Lightning peuvent signifier des fonds, pas juste des fichiers — le guide d’hébergement de nœud est explicite à ce sujet. Copiez-les séparément, gardez-les hors ligne, et traitez-les comme plus précieuses que les données qu’elles protègent.
Une restauration que vous n’avez pas testée est une rumeur
Le logiciel de sauvegarde fait son propre rapport, et il rend compte honnêtement de la mauvaise chose. « Snapshot terminé » signifie que des données ont été écrites dans un dépôt. Cela ne dit rien sur le fait de savoir si le dépôt peut être lu sur une machine qui n’est pas celle-ci, par une personne qui ne se souvient plus de ce qu’elle a configuré onze mois plus tôt.
Commencez par les contrôles d’intégrité bon marché — restic check --read-data-subset=5% ou borg check --verify-data à intervalles réguliers — et comprenez qu’ils vérifient l’archive, pas votre capacité à l’utiliser. Le vrai exercice est différent et prend un après-midi, une fois. Commandez un serveur neuf à l’heure dans un emplacement que vous n’utilisez pas par ailleurs. Restaurez dessus avec rien d’autre que l’adresse du dépôt, la phrase de passe, et vos propres notes. Remettez le service en marche. Chronométrez le tout. Puis détruisez la machine. Coût total : quelques dollars, et c’est le seul exercice qui produit un chiffre digne de confiance.
Ce qu’il révèle de façon fiable, ce n’est jamais les données. C’est le paquet manquant que personne n’a noté, la configuration qui vivait en dehors des chemins sauvegardés, la phrase de passe qui n’a jamais existé que dans l’historique shell du serveur que vous essayez de remplacer, et la version de l’outil qui sait lire le format de votre dépôt. Chacun de ces points est trivial à corriger à l’avance et pénible à découvrir pendant une panne.
Notez les deux chiffres que donne l’exercice : combien de temps a pris une restauration, et combien de travail le calendrier peut perdre. Voilà la politique de sauvegarde. Tout ce qui précède n’est qu’un détail d’implémentation à leur service.
L’automatiser pour que ça continue
Faites tourner la tâche depuis un timer systemd plutôt que cron. Vous obtenez des journaux à un seul endroit, un vrai relevé de la dernière exécution, et un calendrier qui survit aux redémarrages — rien de tout cela que cron vous donne sans travail supplémentaire. Gardez la phrase de passe hors du fichier unit lui-même, que n’importe qui ayant un accès shell peut lire directement via systemctl cat.
Réglez ensuite le mode de défaillance qui piège vraiment les gens, qui n’est pas une erreur mais un silence. Une sauvegarde arrêtée depuis six semaines ressemble exactement à une sauvegarde parfaitement réussie, parce que les deux ne produisent aucune sortie. Alertez sur l’absence, pas sur l’échec. Faites en sorte que la tâche envoie un ping à un moniteur en cas de succès et laissez le moniteur se plaindre quand le ping n’arrive pas — et placez ce moniteur n’importe où sauf sur le serveur qu’il surveille, puisqu’une machine hors service ne peut pas signaler qu’elle est hors service.
Définissez la rétention délibérément plutôt que par défaut. Quelque chose comme --keep-daily 7 --keep-weekly 4 --keep-monthly 6 couvre les erreurs que vous remarquez ce soir et la corruption que vous remarquez au printemps, sans grossir indéfiniment. Faites l’élagage côté cible si vous êtes passé en append-only, ce qui est tout l’intérêt d’être passé en append-only. Le volume de transfert est rarement la contrainte sur notre réseau — la bande passante est illimitée sur chaque forfait — planifiez donc pour la cohérence plutôt que pour un quota, et vérifiez le timing par rapport à vos propres heures creuses. Les habitudes plus larges autour de tout cela sont couvertes dans le guide OpSec serveur.
La version courte
Si vous ne retenez rien d’autre de cette page, faites ces six choses, à peu près dans cet ordre :
- Placez une copie chez un second fournisseur, dans une seconde juridiction, payée de manière aussi privée que la première.
- Rendez cette copie append-only, ou récupérez-la depuis la cible en pull, pour qu’un serveur compromis ne puisse pas la détruire.
- Laissez l’outil chiffrer à la source, et gardez la clé hors des deux machines concernées.
- Dumpez les bases de données et arrêtez ou snapshotez tout ce qui tourne ; ne copiez jamais un état vivant tel quel.
- Sauvegardez les clés d’identité séparément — onion, WireGuard, DKIM, seeds de nœud — car celles-ci ne peuvent pas être régénérées.
- Restaurez une fois sur un serveur jetable, chronométrez, et notez ce qui manquait.
Rien de tout cela n’est exotique, et rien ne prend un week-end. C’est un après-midi de mise en place et un exercice, contre une catégorie de perte qui met fin à des projets. Sur une plateforme qui ne garde délibérément rien sur vous, la copie que vous avez faite vous-même est la seule qui existe — c’est le coût de l’arrangement, et il est équitable. Lancez un second serveur dans une juridiction qui n’est pas la première, et donnez à la sauvegarde de ce soir un endroit où atterrir.