Toute sauvegarde fonctionne jusqu'au jour où elle est nécessaire. L'instantané se trouve sur la plateforme qui vient de tomber. L'archive nocturne échoue silencieusement depuis qu'un disque s'est rempli en mars. L'export de la base de données était en réalité une copie de fichier prise en pleine écriture, et elle ne restaure rien. Les sauvegardes sont la seule partie d'un serveur qu'on ne peut pas juger en la regardant — seulement en la restaurant. Voici comment en construire une qui survit à une panne matérielle, à vos propres erreurs et à quelqu'un d'autre détenant vos identifiants, sans donner une copie lisible de la machine à celui qui la stocke.
Quatre choses détruisent un serveur, et chacune exige quelque chose de différent
Concevez la sauvegarde autour de la panne, pas autour de l'outil. Quatre scénarios couvrent l'essentiel des pertes réelles, et chacun exige quelque chose de différent de la copie que vous conservez. Une configuration qui gère l'un d'eux semble parfaitement adéquate jusqu'à ce qu'elle rencontre l'autre.
Panne matérielle ou panne d'hôte
Le disque, le nœud ou le datacenter lâche. Toute copie détenue ailleurs vous sauve. C'est la seule panne qu'un instantané sur la même plateforme gère de façon fiable, ce qui explique précisément pourquoi tant de gens croient que les instantanés suffisent.
Vos propres erreurs
Un mauvais indicateur, un script de migration pointé sur la production, un nettoyage qui a supprimé plus que prévu. Les dégâts se répliquent instantanément vers tout ce qui synchronise, donc ce qui vous sauve, c'est l'historique — une version d'avant l'erreur, pas une copie actuelle d'après elle.
Compromission et rançongiciel
Un attaquant disposant du root a exactement la portée qu'a votre tâche de sauvegarde : les mêmes identifiants, la même destination, le même planning. Si le serveur peut supprimer ses propres sauvegardes, elles seront supprimées. La survie dépend du fait que la copie soit en ajout seul, ou totalement hors de portée.
Perdre le compte, pas le serveur
Un impayé, un compte suspendu, un retrait forcé dans la mauvaise juridiction. Le matériel va bien, vous ne pouvez simplement plus l'atteindre. Seule une copie chez un autre fournisseur, avec un autre mode de paiement, aide ici.
Notez contre lequel des quatre vous vous défendez réellement avant de choisir quoi que ce soit. Une copie nocturne dans un second répertoire sur le même disque en couvre exactement un — le moins probable — tout en ayant complètement l'air d'une sauvegarde. La plupart des configurations qui échouent en production échouent parce que personne n'a jamais nommé le scénario.
Les instantanés ne sont pas des sauvegardes
Les mots sont utilisés de façon interchangeable, alors qu'ils décrivent des objets différents avec des domaines de défaillance différents. Savoir lequel vous avez détermine si vous avez quoi que ce soit.
Utilisez les instantanés pour ce à quoi ils excellent réellement : un retour en arrière de cinq secondes avant de toucher au noyau, au bootloader ou au schéma d'une base de données. Prenez-en un, faites l'opération risquée, supprimez-le une fois que ça fonctionne. Ce qu'il ne faut jamais faire, c'est laisser "il y a un instantané" devenir la raison pour laquelle il n'y a pas de sauvegarde — un instantané partage le sort de la plateforme qui l'héberge, et un compte suspendu emporte les deux à la fois.
3-2-1, et les deux chiffres que tout le monde oublie
La vieille règle survit parce qu'elle décrit une indépendance plutôt qu'un système de classement : trois copies des données, sur deux types de stockage différents, dont une ailleurs. Deux ajouts couvrent des pannes qui étaient rares quand la règle a été écrite et qui sont devenues courantes aujourd'hui.
- Trois copies. Les données en production plus deux sauvegardes. Deux copies signifie que vous êtes à une restauration ratée de vous retrouver à zéro.
- Deux supports, ou deux fournisseurs. Sur une infrastructure louée, "support" veut en réalité dire indépendance administrative — une seconde copie sous le même compte, sur la même plateforme, payée depuis le même solde, n'est qu'une copie avec des étapes en plus.
- Une hors site. Bâtiment différent, réseau différent, juridiction différente si cela compte pour vous. /locations en est la version pratique : choisissez une région qui tombe en panne indépendamment de celle que vous protégez.
- Une immuable ou hors ligne. Une copie que le serveur lui-même ne peut pas supprimer, parce que quiconque possède le serveur possède aussi ses identifiants.
- Zéro restauration non vérifiée. Une sauvegarde que vous n'avez jamais restaurée est une hypothèse. Le chiffre qui compte, c'est le nombre de restaurations que vous avez effectuées, pas le nombre de tâches ayant annoncé un succès.
Sauvegardez les données, reconstruisez le reste
Le réflexe, c'est de tout imager. C'est coûteux, lent à restaurer, et ça préserve fidèlement le binaire compromis, l'état cassé des paquets et la dérive de configuration dont vous ne vous souvenez même plus être l'auteur. Un serveur contient trois types de contenu, et un seul d'entre eux a sa place dans la sauvegarde.
- Incluez /etc, /home, /root, /srv, la racine de votre site web, le répertoire d'état de votre application, les volumes de conteneurs nommés, et un répertoire d'exports de base de données récents.
- Incluez la recette de déploiement elle-même — fichiers compose, scripts Ansible ou shell, les notes que vous avez écrites à deux heures du matin. Gardez-la aussi sous contrôle de version, mais placez-en une copie dans la sauvegarde pour que la restauration ne dépende jamais de l'accessibilité d'un second service.
- Excluez /proc, /sys, /dev, /run et les répertoires temporaires. Ce sont des interfaces noyau et de l'espace de travail ; les copier fait perdre du temps ou bloque carrément la tâche.
- Excluez les caches de paquets, les répertoires de build, les arborescences de dépendances et les virtualenvs — tout ce qu'une étape de build régénère. Sur un serveur d'application classique, cela représente la majeure partie du disque.
- Excluez les fichiers de base de données en production si vous exportez correctement la base par ailleurs. Sauvegarder les deux fait que c'est la copie la plus grosse et la plus inutile que quelqu'un restaure à trois heures du matin.
- N'excluez pas les fichiers cachés. La moitié de ce qui compte sur une machine Linux commence par un point.
Les bases de données ne survivent pas à une copie de fichier
C'est la cause la plus fréquente d'échec d'une restauration. Une base de données en fonctionnement garde une partie de son état en mémoire et écrit dans le désordre ; copier ses fichiers pendant qu'elle tourne capture un état déchiré, à moitié écrit, qui peut restaurer, peut restaurer silencieusement corrompu, ou peut ne pas restaurer du tout. Faites un export propre, puis sauvegardez cet export.
- PostgreSQL : pg_dump par base de données, ou pg_dumpall pour tout le cluster, rôles compris. Là où perdre une journée est inacceptable, ajoutez l'archivage WAL pour pouvoir restaurer à un instant précis plutôt qu'à la nuit dernière.
- MySQL ou MariaDB : mysqldump avec --single-transaction donne un instantané cohérent sur InnoDB sans bloquer les écritures. Ce n'est pas le cas sur MyISAM — une raison de plus de ne pas faire tourner MyISAM. Pour de gros volumes, un outil physique comme mariabackup restaure bien plus vite que de rejouer un export.
- SQLite : ne copiez jamais le fichier. Utilisez la commande .backup ou VACUUM INTO, qui posent le verrou correctement. Copier une base dont le journal d'écriture anticipée est actif, c'est un pari que vous finirez tôt ou tard par perdre.
- Redis : déclenchez une sauvegarde en arrière-plan et sauvegardez le fichier instantané qui en résulte, ou activez le mode ajout seul (append-only) et sauvegardez le journal. Copier un instantané en pleine écriture vous donne un fichier tronqué qui se charge comme un jeu de données vide.
- Conteneurs : le volume, c'est la donnée. Arrêtez la stack le temps que dure une copie, ou lancez l'outil d'export à l'intérieur du conteneur — mais ne faites pas un tar du volume d'une base de données en fonctionnement en l'appelant sauvegarde.
- Tout ce qui repose sur un processus persistant — index de recherche, files d'attente de messages, démons de registre — possède sa propre commande d'export cohérent. Trouvez-la maintenant, pas pendant l'incident.
Les instantanés au niveau du système de fichiers résolvent le problème depuis l'autre bout : LVM, ZFS et btrfs figent une vue cohérente du volume en quelques millisecondes, et vous sauvegardez cette vue figée pendant que la base continue de servir. C'est la bonne réponse pour les jeux de données où un export prend des heures. Ce n'est pas une raison pour sauter l'export d'une base de 200 MB, où l'export est plus simple, portable d'une version de moteur à l'autre, et lisible par un humain quand quelque chose a mal tourné.
Choisir un outil
Quatre outils couvrent presque tous les cas. La propriété la plus importante, c'est l'endroit où a lieu le chiffrement. Si les données ne sont chiffrées qu'en transit, puis au repos par le fournisseur de stockage, ce dernier peut les lire — et la sauvegarde est tranquillement devenue le point le plus faible d'un système que vous avez durci partout ailleurs.
Quel que soit votre choix, la phrase de passe ou la clé doit exister ailleurs que sur le serveur sauvegardé. C'est le piège qui attrape les gens prudents : la clé du dépôt stockée dans /root, fidèlement sauvegardée à l'intérieur du dépôt qu'elle déverrouille. Imprimez-la, ou conservez-la dans un gestionnaire de mots de passe que vous pouvez ouvrir depuis une machine encore en vie. Un dépôt que vous ne pouvez pas déchiffrer est indiscernable de l'absence totale de sauvegarde.
Où la seconde copie doit vivre
La destination est autant une juridiction et une relation de facturation que de l'espace disque. Quatre options, classées approximativement selon leur indépendance vis-à-vis du serveur que vous protégez.
Un second serveur dans une autre région
La réponse la plus directe : une instance bon marché dans un autre pays, accessible en SSH, qui ne fait tourner rien d'autre que sshd et un dépôt. Une offre /vps de 1 GB héberge les sauvegardes de toute une petite flotte, et le compte peut être verrouillé sur une seule commande forcée pour qu'une clé volée n'ouvre aucun shell.
Disque de classe stockage
Une fois que le jeu de données atteint des centaines de gigaoctets, la capacité HDD sur une liaison illimitée coûte bien moins cher par téraoctet que le NVMe, et les écritures de sauvegarde n'ont aucun besoin de la latence du NVMe. /storage est conçu pour ça : du disque protégé par RAID en classe téraoctet, un accès root complet, aucune inspection de contenu.
Stockage objet compatible S3
Pratique, facturé au gigaoctet, et souvent avec un support d'object-lock qui donne une véritable immuabilité. Lisez la tarification de la sortie de données avant de vous y fier — récupérer un téraoctet en urgence est un mauvais moment pour découvrir ce que coûte la récupération.
Du matériel que vous possédez
Un disque externe ou une machine à la maison, récupérée en pull plutôt que poussée en push. Plus lent et manuel, et la seule copie de cette liste qu'aucun fournisseur, aucune décision de justice, aucun litige de facturation ne peut toucher. Ça vaut le coup de la garder pour les données que vous ne pouvez vraiment pas recréer, même si elle a une semaine de retard.
Faites correspondre les propriétés de confidentialité de la sauvegarde à celles du serveur. Chiffrer un disque avec LUKS puis expédier chaque nuit des sauvegardes en clair vers un bucket enregistré à votre carte annule tout l'exercice : les données sont désormais lisibles, et classées à votre nom. Si le serveur valait la peine d'être payé anonymement, la copie aussi — chiffrez côté client, et achetez la destination de la même manière que vous avez acheté l'origine.
Le construire, étape par étape
- 1
Décidez d'abord des deux chiffres
Combien de données vous pouvez vous permettre de perdre — l'écart entre deux passages — et combien de temps vous pouvez vous permettre d'être hors service. Tout le reste découle de ces deux réponses. Des sauvegardes horaires d'un site statique, c'est du théâtre ; des sauvegardes nocturnes d'une base de commandes sont une décision à prendre délibérément, pas à hériter d'un tutoriel.
- 2
Créez la destination
Une seconde instance dans une autre région, avec sa propre clé SSH et un utilisateur non privilégié dédié dont le répertoire personnel est le dépôt. Rien d'autre ne tourne là-dessus. Restreignez la clé à une commande forcée pour qu'un identifiant volé ne puisse qu'ajouter des sauvegardes, jamais ouvrir un shell.
- 3
Générez la clé et stockez-la ailleurs
Une longue phrase de passe aléatoire, notée quelque part qui survit à la perte du serveur. Initialisez le dépôt, puis prouvez que vous pouvez lister son contenu depuis une troisième machine en n'utilisant que ce que vous avez noté. Si vous n'y arrivez pas, corrigez cela avant d'écrire la moindre sauvegarde.
- 4
Exportez d'abord les bases de données
Un petit script qui écrit des exports cohérents dans un répertoire intermédiaire et qui sort avec un code non nul si l'un d'eux échoue — à exécuter avant la sauvegarde de fichiers, pas en parallèle. Une tâche qui continue après l'échec d'un export, c'est comme ça qu'on se retrouve avec trente jours de fichiers de zéro octet.
- 5
Sauvegardez les chemins qui comptent
Pointez l'outil vers la liste d'inclusion, appliquez les exclusions, et vérifiez la cohérence du premier passage. Si un dépôt neuf pour un serveur de 40 GB arrive à 300 MB, quelque chose est silencieusement sauté ; s'il arrive à 38 GB, vos exclusions ne fonctionnent pas.
- 6
Planifiez-la et rendez l'échec bruyant
Un timer systemd avec un délai aléatoire, ou cron si c'est l'habitude. Faites ensuite en sorte que la tâche fasse un rapport : un signal de vie vers un monitoring en cas de succès, et une alerte quand ce signal cesse d'arriver. L'échec silencieux est le mode de défaillance normal des sauvegardes, parce que rien ne casse visiblement quand elles s'arrêtent — jusqu'au jour où tout casse.
- 7
Définissez une rétention et purgez réellement
Horaire pendant un jour, quotidien pendant une quinzaine, hebdomadaire pendant deux mois, mensuel pendant un an. Lancez ensuite la purge et vérifiez que le dépôt cesse de grossir. Une rétention configurée mais jamais exécutée finit par remplir la destination et emporter les sauvegardes avec elle.
- 8
Restaurez quelque chose aujourd'hui
Pas une tâche de test — un vrai fichier, vers un répertoire jetable, ouvert et vérifié. Mettez ensuite une date au calendrier pour la machine entière. La première restauration complète fait toujours remonter quelque chose : un chemin manquant, une permission, un certificat, un utilisateur de base de données qui n'a jamais existé que sur l'ancienne machine.
Envoyez la sauvegarde depuis le serveur vers l'extérieur, et vous avez accepté que quiconque y dispose du root puisse détruire toutes les copies. Faites l'inverse — l'hôte de sauvegarde se connecte, récupère les données, puis se déconnecte — et un serveur compromis ne peut atteindre le dépôt en aucune façon, puisqu'il ne détient aucun identifiant pour y accéder. Le mode pull demande plus de travail à mettre en place, et c'est la plus grande amélioration que la plupart des configurations puissent adopter.
La rétention, et pourquoi plus long coûte moins cher qu'il n'y paraît
La rétention est généralement fixée en fonction de ce qui tient sur le disque, puis oubliée. Elle mérite une réflexion délibérée, parce qu'elle détermine quelles erreurs restent récupérables. Une fenêtre de sept jours rattrape un fichier supprimé mardi. Elle ne rattrape pas une corruption démarrée six semaines plus tôt et découverte quand un rapport est sorti faux, ni un intrus resté tranquillement sur la machine pendant un mois avant d'agir.
La déduplication rend tout cela bien moins coûteux que ce que le tableau suggère : le second passage sur un serveur resté globalement inchangé ne stocke que ce qui a changé, si bien qu'une année de points de restauration mensuels sur une machine de 40 GB coûte typiquement quelques gigaoctets plutôt qu'un demi-téraoctet. Fixez la politique en fonction de ce dont vous avez besoin pour vous rétablir, puis vérifiez la facture. Vous constaterez généralement que vous pouvez vous permettre la version généreuse.
L'immuabilité : la partie qui arrête les rançongiciels
Tout ce qui précède suppose que l'adversaire est l'entropie. Si l'adversaire est une personne disposant du root, une tâche de sauvegarde ordinaire est un mode d'emploi — les identifiants sont sur la machine, la destination est dans la config, et le dépôt est effacé avant même que le chiffrement ne commence. Quatre mécanismes brisent cette chaîne, et chacun d'eux à lui seul change l'issue.
- Dépôts en ajout seul. Le mode ajout seul (append-only) côté serveur de Borg, ou le serveur REST de restic en mode append-only, acceptent les nouvelles données et refusent les suppressions. Le serveur peut écrire ; seul vous, depuis ailleurs, pouvez purger.
- Sauvegardes en pull. L'hôte de sauvegarde initie la connexion et détient les seuls identifiants. Le serveur de production n'a aucune clé, aucune adresse de destination, et aucune route vers le dépôt.
- Object lock. Un stockage compatible S3 avec une période de rétention imposée au niveau du bucket, où la suppression est refusée par la couche de stockage elle-même, quoi que les identifiants permettent par ailleurs.
- Des identifiants séparés par machine. Une seule machine compromise ne devrait pas exposer l'historique de toutes les autres. Des clés distinctes, des chemins distincts, des restrictions distinctes.
- Une copie réellement hors ligne. Un disque débranché est immunisé contre toute attaque distante jamais écrite. Démodé, et imbattu.
L'exercice de restauration
Une restauration est une procédure, et une procédure que personne n'a jamais exécutée est une fiction. Faites cet exercice une fois maintenant, puis une fois tous les six mois, et notez ce que vous apprenez — les notes finissent par valoir aussi cher que les données.
- 1
Déployez une instance vierge
Même version de système d'exploitation, rien d'autre installé. Un VPS de courte durée suffit, et tout l'exercice coûte moins cher qu'un repas.
- 2
Restaurez en n'utilisant que ce que vous avez noté
L'adresse du dépôt, la phrase de passe, les commandes. Si vous avez besoin de quelque chose qui n'existe que sur le serveur que vous faites semblant d'avoir perdu, vous venez de trouver la faille — un jour où la trouver ne coûte rien.
- 3
Remettez les données en place avant l'application
Chargez l'export de base de données, remettez les fichiers là où ils doivent être, puis corrigez la propriété et les permissions. La propriété est la surprise habituelle : les identifiants numériques d'utilisateur de l'ancienne machine s'alignent rarement sur la nouvelle.
- 4
Démarrez le service et utilisez-le pour de vrai
Pas une commande de statut — connectez-vous, chargez une page, lancez une requête, envoyez un message. Un service qui démarre n'est pas la même chose qu'un service qui fonctionne.
- 5
Chronométrez, et notez le chiffre
Combien de temps tout cela a-t-il pris ? C'est votre véritable temps de reprise, et il est presque toujours plusieurs fois supérieur à l'estimation. Gardez les notes à côté de la phrase de passe, et mettez à jour les deux à chaque changement de la stack.
Ce que ça coûte, honnêtement
La sauvegarde est l'assurance la moins chère de toute l'infrastructure, et c'est celle qu'on saute le plus régulièrement pour des raisons de prix. Quelques chiffres concrets pour un petit serveur, en supposant que les données se compressent et se dédupliquent comme des données ordinaires.
Comparez n'importe lequel de ces montants au coût de l'incident qu'il évite. Nommer le chiffre, c'est tout l'intérêt — l'argument contre les sauvegardes ne porte jamais vraiment sur l'argent une fois que l'argent a été chiffré noir sur blanc.
La place de l'hébergeur
Un plan de sauvegarde a les deux mêmes dépendances que le serveur qu'il protège : un endroit indépendant où placer la copie, et un moyen de le payer qui ne crée pas une nouvelle trace de qui vous êtes. Les deux comptent encore plus ici qu'à l'origine, parce que la sauvegarde est une copie complète de tout ce que l'origine protégeait.
Chaque offre /vps et /storage ici se déploie depuis un solde crypto prépayé sans KYC, à travers quinze régions listées sur /locations — la seconde copie peut donc se trouver sous une juridiction différente de la première, sans second contrôle d'identité nulle part dans la chaîne. Des instantanés immédiats sont inclus sur chaque instance pour le retour en arrière de cinq secondes, la bande passante illimitée fait que ni le premier envoi ni la restauration d'urgence ne sont des événements facturés au volume, et /storage ajoute du disque protégé par RAID en classe téraoctet à partir de $8.99/mo, sans inspection de contenu. /pay-with couvre les monnaies acceptées, /offshore-hosting détaille ce que la juridiction change réellement, et /guides propose les articles complémentaires sur le chiffrement de disque et sur ce qu'un hébergeur peut voir, ou non, d'une machine.
La checklist
- Nommez la panne contre laquelle vous vous défendez avant de choisir un outil.
- Traitez les instantanés comme un bouton d'annulation, jamais comme la sauvegarde.
- Sauvegardez les données et la configuration ; reconstruisez le système d'exploitation depuis un script.
- Exportez chaque base de données avec sa propre commande d'export cohérent, et sauvegardez cet export.
- Chiffrez côté client, avant que quoi que ce soit ne quitte la machine.
- Conservez la phrase de passe du dépôt quelque part qui survit à la perte du serveur.
- Placez au moins une copie chez un fournisseur, dans une région et avec un mode de paiement différents.
- Rendez une copie en ajout seul, en pull ou hors ligne, pour qu'un accès root compromis ne puisse pas l'effacer.
- Alertez sur l'absence d'un passage réussi — les échecs sont silencieux, et le silence est le symptôme.
- Restaurez un fichier aujourd'hui, et la machine entière deux fois par an. Chronométrez-le et notez-le.
Les instantanés du fournisseur suffisent-ils à eux seuls ?
Non, et c'est la lacune la plus courante dans des configurations par ailleurs soignées. Un instantané vit sur la même plateforme que le volume qu'il copie, donc il ne survit pas à une panne au niveau de la plateforme, une suspension de compte ou un impayé — trois des scénarios où vous en avez le plus besoin. Il ne garde généralement aussi qu'un historique court, donc il ne récupérera pas un fichier supprimé le mois dernier ni une corruption apparue six semaines plus tôt. Les instantanés sont excellents comme retour en arrière de cinq secondes avant un changement risqué : gardez-les, utilisez-les au quotidien, et gardez une vraie sauvegarde ailleurs.
restic ou Borg — lequel choisir ?
restic si la destination est du stockage objet ou un simple compte SSH, parce qu'il n'a besoin de rien d'installé à l'autre bout et parle S3 nativement. Borg si la destination est une machine Linux que vous contrôlez et que vous voulez son mode serveur en ajout seul et une compression légèrement plus poussée. Les deux dédupliquent, les deux chiffrent et authentifient côté client, les deux sont matures et largement déployés, et l'un comme l'autre est un choix défendable. La mauvaise réponse, c'est de passer un mois à les comparer pendant que le serveur n'a aucune sauvegarde du tout — choisissez-en un cet après-midi, et changez d'avis plus tard si ça compte vraiment un jour.
À quelle fréquence sauvegarder un VPS ?
L'intervalle est simplement la quantité maximale de travail que vous êtes prêt à refaire. Pour un site statique, une fréquence hebdomadaire est honnête. Pour tout ce dans quoi des utilisateurs écrivent, le rythme nocturne est le plancher, et le rythme horaire devient bon marché une fois que la déduplication fait le travail — le second passage de la journée ne stocke généralement que quelques mégaoctets. Pesez la valeur d'une journée de données face au coût de stocker vingt-quatre points de restauration plutôt qu'un seul, et la réponse est en général évidente.
Faut-il sauvegarder le disque entier ou seulement mes données ?
Les données et la configuration, dans presque tous les cas. Une image disque complète restaure la machine exactement comme elle était, y compris la compromission dont vous êtes en train de vous remettre et l'état des paquets que vous ne comprenez plus, et elle est plus lente à créer comme à restaurer. Une sauvegarde au niveau fichier de /etc, des données de votre application et de vos exports de base de données, associée à un script qui reconstruit le système d'exploitation, restaure plus vite et plus proprement. Imagez le disque quand vous avez besoin d'une préservation forensique bit à bit, ou quand la machine est une boîte noire construite par quelqu'un d'autre.
Mon fournisseur dit que les disques sont chiffrés — ma sauvegarde est-elle chiffrée ?
Pas dans un sens qui vous aide. Le chiffrement côté fournisseur protège contre un disque qu'on sort physiquement d'une baie ; le fournisseur détient la clé, donc les données restent lisibles par lui, et par quiconque peut le contraindre. Le chiffrement côté client — restic, Borg, la couche crypt de rclone, ou une archive chiffrée — signifie que ce qui arrive à destination n'a aucun sens sans une phrase de passe qui n'a jamais quitté votre machine. Pour une infrastructure où la confidentialité est critique, cette distinction est tout l'enjeu, parce que la sauvegarde est une copie complète de tout ce que le serveur protégeait.
Comment empêcher un rançongiciel de chiffrer aussi mes sauvegardes ?
Partez du principe que tout ce que le serveur peut atteindre, un attaquant disposant du root peut le détruire — les identifiants, la destination et le planning sont tous sur la machine. Cassez cette portée d'une de ces trois façons : un dépôt en ajout seul qui accepte les écritures mais refuse les suppressions, un modèle en pull où l'hôte de sauvegarde se connecte vers l'intérieur et où le serveur ne détient aucun identifiant, ou un stockage objet avec un verrou imposé par la couche de stockage elle-même. Ajoutez ensuite une rétention longue, pour qu'une compromission lente et discrète ne sorte pas simplement de la fenêtre avant que quiconque ne la remarque, et gardez une copie hors ligne, hors de portée de toute attaque distante.
