[Accueil](https://servhidden.com/fr) / [Guides Hébergement Privé](https://servhidden.com/fr/guides) / Sauvegarde VPS chiffrée et hors site : la stratégie qui restaure vraiment Exploitation # Des sauvegardes VPS qui restaurent vraiment L’hébergement no-KYC retire le filet de sécurité en même temps que la paperasse : aucune sauvegarde conservée, données détruites dans les 24 heures suivant la résiliation, et aucun support qui se termine par une copie récupérée. Voici le plan concret : quoi copier, où le mettre, comment empêcher un attaquant de le supprimer, et comment prouver que ça restaure. [Lire le guide](#guide-body) [FAQ](#guide-faq) ## Sur cette page - [Guide](#guide-body) - [FAQ](#guide-faq) - [Guides connexes](#guide-related) - [Pages recommandées](#guide-cta) Sans KYC Crypto uniquement Aucun journal DMCA ignoré Accès root complet SSD NVMe 21 min de lecture Mis à jour Aug 2026 Sur cette page [01Ce qui détruit vraiment les serveurs](#ce-qui-détruit-vraiment-les-serveurs) [02Un snapshot n’est pas une sauvegarde, et votre hébergeur non plus](#un-snapshot-nest-pas-une-sauvegarde-et-votre-hébergeur-non-p) [033-2-1, réécrite pour ceux qui n’ont jamais montré leur pièce d’identité](#3-2-1-réécrite-pour-ceux-qui-nont-jamais-montré-leur-pièce-d) [04Push, pull, et l’erreur qui laisse une mauvaise nuit dévorer les deux copies](#push-pull-et-lerreur-qui-laisse-une-mauvaise-nuit-dévorer-le) [05Chiffrer à la source, puis décider qui détient la clé](#chiffrer-à-la-source-puis-décider-qui-détient-la-clé) [06Choisir un outil, en un tableau](#choisir-un-outil-en-un-tableau) [07Tout ce qui tourne n’est pas un fichier](#tout-ce-qui-tourne-nest-pas-un-fichier) [08Quoi sauvegarder, et ce que tout le monde oublie](#quoi-sauvegarder-et-ce-que-tout-le-monde-oublie) [09Une restauration que vous n’avez pas testée est une rumeur](#une-restauration-que-vous-navez-pas-testée-est-une-rumeur) [10L’automatiser pour que ça continue](#lautomatiser-pour-que-ça-continue) [11La version courte](#la-version-courte) [FAQQuestions fréquentes](#guide-faq) [→Pages recommandées](#guide-cta) 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](https://servhidden.com/fr/privacy) 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. Une cible de sauvegarde a besoin de disque et d’une adresse, pas de cœurs. La machine la moins chère dans une autre juridiction est une cible tout à fait compétente — et la seule copie qui survit à un incident chez le premier fournisseur. ## 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](https://servhidden.com/fr/guides/choosing-an-offshore-jurisdiction) 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](https://servhidden.com/fr/vps) dans un autre de nos [sept emplacements](https://servhidden.com/fr/locations) est une cible restic ou Borg tout à fait compétente, et pour des archives se comptant en téraoctets, une [machine dédiée](https://servhidden.com/fr/dedicated) 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](https://servhidden.com/fr/guides/how-to-pay-for-hosting-with-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](https://servhidden.com/fr/guides/first-hour-vps-hardening-checklist) 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 restrict et un command= 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](https://servhidden.com/fr/guides/full-disk-encryption-on-a-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](https://servhidden.com/fr/guides/seedbox-setup-guide) 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 : - /etc en 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](https://servhidden.com/fr/guides/how-to-host-a-tor-hidden-service), 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é](https://servhidden.com/fr/guides/offshore-mail-server-setup). 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](https://servhidden.com/fr/guides/crypto-node-hosting-guide) 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](https://servhidden.com/fr/guides/server-opsec-staying-anonymous). ## 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](https://servhidden.com/fr/vps) dans une juridiction qui n’est pas la première, et donnez à la sauvegarde de ce soir un endroit où atterrir. FAQ ## Sauvegarde VPS — questions fréquentes ### 01 ServHidden sauvegarde-t-il mon VPS ? Non, et c’est délibéré, pas un oubli. Notre politique de rétention indique qu’aucune sauvegarde n’est conservée, que les données du serveur sont détruites dans les 24 heures suivant la résiliation, et que les disques sont effacés cryptographiquement plutôt que formatés. Garder une copie de vos données après que vous nous avez demandé de les supprimer contredirait la raison d’être de la plateforme. Tout ce que vous voulez faire survivre au serveur doit être copié par vous-même, idéalement vers un second fournisseur dans une seconde juridiction. ### 02 Un snapshot est-il la même chose qu’une sauvegarde ? Non. Un snapshot partage tous les domaines de panne avec le serveur dont il provient — le même fournisseur, le même compte, le même pays, souvent le même stockage. Il est excellent pour annuler une mise à jour ratée et inutile face à la perte du compte, du fournisseur ou de la machine. Considérez les snapshots comme un bouton annuler et les sauvegardes comme une assurance ; ils résolvent des problèmes différents et vous voulez les deux. ### 03 restic ou BorgBackup, lequel choisir ? restic si la cible pourrait être du stockage objet, du SFTP ou quelque chose que vous n’avez pas encore choisi, car il parle le plus de back-ends. BorgBackup si la cible est une seule machine Linux atteinte via SSH et que les données sont volumineuses et répétitives, car sa déduplication est la meilleure du lot. Les deux chiffrent à la source avant que quoi que ce soit ne quitte la machine, et les deux prennent en charge une cible append-only, ce qui compte bien plus que le choix entre eux. ### 04 Comment empêcher un attaquant de supprimer mes sauvegardes ? Retirez la capacité plutôt que le motif. Soit vous rendez la cible append-only, pour que les identifiants du serveur de production puissent ajouter des données mais jamais les supprimer, soit vous inversez la connexion pour que l’hôte de sauvegarde vienne chercher les données en pull et que le serveur de production ne détienne aucun identifiant du tout. Supprimer les sauvegardes avant de s’annoncer est une pratique courante chez quiconque fait cela commercialement, et une copie que votre attaquant peut supprimer n’est pas une seconde copie. ### 05 Où faut-il héberger la seconde copie ? Chez un fournisseur différent, dans une juridiction différente, et payée de façon aussi privée que votre serveur de production. Les événements qui emportent les deux copies à la fois sont rarement physiques — c’est un compte perdu, un fournisseur qui traverse une mauvaise semaine, ou un instrument juridique qui touche un pays et pas un autre. Deux serveurs dans la même baie sont une copie avec des étapes en plus. Comme les outils chiffrent à la source, le second hôte n’a pas besoin d’être un hôte de confiance. ### 06 À quelle fréquence faut-il sauvegarder son VPS ? Partez de la quantité de travail que vous êtes prêt à refaire. Un blog peut perdre une journée sans que personne ne le remarque ; une boutique ne peut pas perdre une heure de commandes. Une fréquence nocturne est le bon réglage par défaut pour la plupart des configurations à serveur unique, avec des dumps de base de données plus fréquents si les écritures ont de la valeur. Ce qui compte plus que la fréquence, c’est la profondeur de rétention : la corruption est souvent remarquée des semaines plus tard, donc gardez assez d’historique pour atteindre un point antérieur à son apparition. ### 07 Une sauvegarde chiffrée est-elle sûre sur un serveur que je ne contrôle pas ? Pour le contenu, oui — restic et Borg chiffrent avant que les données ne quittent la source, donc la cible stocke des blocs qu’elle ne peut pas lire, et la clé ne voyage jamais. Ce que la cible apprend, ce sont des métadonnées : à peu près combien de données vous détenez, comment elles évoluent, et quand vos tâches tournent. C’est généralement acceptable. Si ça ne l’est pas, variez le calendrier et gardez le dépôt sur une machine dont la propriété n’est pas liée à celle de la production. ### 08 Que se passe-t-il si je perds la phrase de passe de la sauvegarde ? L’archive est perdue, définitivement, sans aucun recours possible. C’est la perte totale la plus fréquente de tout ce sujet, et le seul échec sans chemin de récupération. Gardez la phrase de passe quelque part en dehors de toutes les machines concernées, préférez le papier à un compte que vous pourriez aussi perdre, et ajoutez une seconde clé au dépôt pour qu’un mot de passe oublié soit une gêne plutôt que la fin de l’archive. Guides connexes ## Continuer la lecture [### Comment choisir une juridiction d'hébergement offshore en 2026 Achat Un cadre de décision pratique pour choisir une juridiction offshore : loi sur la rétention de données, exposition aux MLAT, position face au DMCA, rapidité des tribunaux et application réelle — pays par pays. FAQ de 6 questions](https://servhidden.com/fr/guides/choosing-an-offshore-jurisdiction) [### VPS vs Serveur Dédié pour les Charges de Travail Sensibles à la Confidentialité Achat Quand un VPS suffit, quand la colocation est une responsabilité, et quand le bare metal est la seule réponse honnête. Isolation matérielle, risque hyperviseur, et coût vs modèle de menace. FAQ de 6 questions](https://servhidden.com/fr/guides/vps-vs-dedicated-for-privacy) [### VPN Auto-Hébergé sur un VPS Sans-KYC : WireGuard vs OpenVPN Exploitation Pourquoi un VPN auto-hébergé surpasse les fournisseurs commerciaux, et comment WireGuard et OpenVPN se comparent vraiment sur la confidentialité, les performances et le risque opérationnel en 2026. FAQ de 6 questions](https://servhidden.com/fr/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 pour l'inférence IA (et où se situe le RTX 5090) Achat Guide d'achat : quel GPU NVIDIA pour des charges LLM auto-hébergées, image, vidéo, voix et finetuning en 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, débit, $/token, quand chacun gagne. FAQ de 6 questions](https://servhidden.com/fr/guides/rtx-4090-vs-h100-for-ai-inference) [### RDP Windows offshore pour le trading Forex MT4 / MT5 / cTrader Exploitation Guide complet : pourquoi un RDP Windows pour le trading Forex, comment choisir une juridiction offshore à faible latence, configuration MT4 / MT5 / cTrader / Expert Advisor, latence vers les serveurs de courtiers, et la voie de paiement sans KYC. FAQ de 6 questions](https://servhidden.com/fr/guides/offshore-windows-rdp-for-forex-trading) [### L’hébergement DMCA-ignoré expliqué : ce que cela signifie vraiment en 2026 Achat Ce que l’hébergement « DMCA ignoré » vous apporte réellement, quelles juridictions le soutiennent vraiment, les charges de travail qui en ont besoin, et les pièges en matière de droits d’auteur que le terme ne couvre pas. FAQ de 6 questions](https://servhidden.com/fr/guides/dmca-ignored-hosting-explained) [### Enregistrement de domaine anonyme avec crypto : confidentialité WHOIS en 2026 Confidentialité Un guide pratique 2026 pour enregistrer des domaines sans révéler votre identité : régimes WHOIS par extension, choix du bureau d’enregistrement, options de paiement en crypto, et les erreurs opérationnelles qui vous trahissent quand même. FAQ de 6 questions](https://servhidden.com/fr/guides/anonymous-domain-registration-with-crypto) [### Paiements Crypto pour l'Hébergement : Monero vs Bitcoin vs USDT Confidentialité Comment le choix de la monnaie affecte ce que votre hébergeur apprend sur vous. Confidentialité, frais, finalité et exposition à l'analyse de chaîne pour XMR, BTC et USDT — avec une recommandation claire. FAQ de 6 questions](https://servhidden.com/fr/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### L’hébergement offshore est-il vraiment anonyme ? Une réponse honnête Confidentialité L’hébergement offshore sans KYC supprime l’identité qu’un hébergeur classique collecte — mais « anonyme » dépend du paiement, de la journalisation du fournisseur et de votre propre opsec. Voici ce qui est réellement traçable. FAQ de 6 questions](https://servhidden.com/fr/guides/is-offshore-hosting-truly-anonymous) [### La première heure de durcissement d’un VPS : une checklist Exploitation Une checklist concrète et ordonnée pour sécuriser un nouveau VPS en moins d’une heure : clés SSH, pare-feu, fail2ban, mises à jour automatiques, et la réduction de surface d’attaque qui stoppe la plupart des attaques opportunistes. FAQ de 6 questions](https://servhidden.com/fr/guides/first-hour-vps-hardening-checklist) [### Qu'est-ce que l'hébergement sans KYC ? Définition, légalité et fonctionnement Confidentialité L'hébergement sans KYC vous permet de louer un serveur sans aucune vérification d'identité — ni nom, ni e-mail, ni pièce d'identité. Voici exactement ce que cela signifie, comment ça fonctionne techniquement, si c'est légal, et comment choisir un vrai prestataire. FAQ de 6 questions](https://servhidden.com/fr/guides/what-is-no-kyc-hosting) [### L'hébergement offshore est-il légal ? La réponse honnête en 2026 Achat L'hébergement offshore est légal — pour vous comme pour le prestataire. Voici ce que le terme signifie vraiment, où se situe réellement la limite légale, les idées reçues à abandonner et comment l'utiliser de façon responsable. FAQ de 6 questions](https://servhidden.com/fr/guides/is-offshore-hosting-legal) [### Comment payer son hébergement avec Monero (XMR) — Guide étape par étape Confidentialité Un guide étape par étape pour payer un VPS ou un serveur dédié avec Monero (XMR) : pourquoi XMR est l'option la plus privée, comment l'obtenir, et comment fonctionne le paiement — de la facture à un serveur opérationnel en quelques minutes. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-pay-for-hosting-with-monero) [### Comment héberger un site web anonymement — Guide pratique 2026 Confidentialité Un guide pratique et structuré par couches pour héberger un site web sans identité attachée : le compte, le paiement, le domaine, la juridiction, votre connexion et le contenu — chaque couche expliquée. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-host-a-website-anonymously) [### Comment configurer un VPN WireGuard sur un VPS — Guide étape par étape Exploitation Créez votre propre VPN privé sur un VPS avec WireGuard : pourquoi un VPN auto-hébergé surpasse un service commercial, la configuration complète de l'installation à la connexion d'un client, et comment le renforcer. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### Comment héberger soi-même un LLM sur un serveur GPU — Guide 2026 Exploitation Faites tourner votre propre grand modèle de langage sur un serveur GPU loué : pourquoi l'auto-hébergement surpasse une API tierce, quel GPU et quel modèle choisir, la mise en place avec Ollama ou vLLM, et ce que ça coûte. FAQ de 6 questions](https://servhidden.com/fr/guides/self-host-an-llm-on-a-gpu-server) [### Hébergement bulletproof vs hébergement offshore — Quelle est la différence ? Achat Hébergement bulletproof et hébergement offshore sont constamment confondus — et pourtant ce n'est pas la même chose. Voici la vraie différence, pourquoi elle compte, et lequel des deux vous recherchez réellement. FAQ de 6 questions](https://servhidden.com/fr/guides/bulletproof-vs-offshore-hosting) [### Comment acheter un VPS avec Bitcoin — Guide étape par étape (2026) Achat Un guide accessible pour acheter un VPS avec Bitcoin : obtenir des BTC, choisir un plan, régler la facture et ce que vous obtenez — un serveur opérationnel sans carte bancaire et sans nom associé. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-buy-a-vps-with-bitcoin) [### Meilleurs pays pour un hébergement ignorant le DMCA en 2026 Achat Où héberger vos serveurs hors de portée des suppressions à l'américaine : les juridictions qui fonctionnent vraiment, ce que « ignorer le DMCA » signifie concrètement, et comment choisir. FAQ de 6 questions](https://servhidden.com/fr/guides/best-countries-for-dmca-ignored-hosting) [### Comment héberger un service caché Tor (site .onion) — Guide 2026 Exploitation Configurez un service onion Tor sur un VPS : ce qu'est un service caché, pourquoi c'est la forme d'hébergement anonyme la plus robuste, la mise en place complète et comment préserver réellement son anonymat. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-host-a-tor-hidden-service) [### Configuration d'un serveur mail offshore — Hébergez votre messagerie privée en 2026 Exploitation Gérez votre propre serveur de messagerie privé sur un VPS offshore : pourquoi auto-héberger vos emails, ce dont vous avez besoin, la mise en place concrète avec une solution tout-en-un, et comment assurer la délivrabilité. FAQ de 6 questions](https://servhidden.com/fr/guides/offshore-mail-server-setup) [### Guide d'hébergement de nœud crypto — Faire tourner un nœud blockchain sur un VPS Exploitation Comment héberger un nœud blockchain sur un serveur : pourquoi faire tourner son propre nœud, dimensionner le serveur pour Bitcoin, Ethereum, Monero et d'autres chaînes, la mise en place, et comment conserver sa confidentialité. FAQ de 6 questions](https://servhidden.com/fr/guides/crypto-node-hosting-guide) [### Hébergement GPU pour Stable Diffusion — Faites tourner votre propre serveur d'images Exploitation Faites tourner Stable Diffusion sur votre propre serveur GPU : pourquoi héberger soi-même la génération d'images, quel GPU choisir, la mise en place avec une interface web, et ce que cela coûte par rapport à un service hébergé. FAQ de 6 questions](https://servhidden.com/fr/guides/gpu-hosting-for-stable-diffusion) [### OpSec serveur — Rester anonyme quand on gère un serveur Confidentialité Sécurité opérationnelle pour toute personne gérant un serveur anonyme : les erreurs qui permettent de désanonymiser, les habitudes qui les préviennent, et comment maintenir une identité vraiment séparée. FAQ de 6 questions](https://servhidden.com/fr/guides/server-opsec-staying-anonymous) [### Guide de configuration d'une seedbox — Créez votre propre seedbox privée en 2026 Exploitation Comment créer sa propre seedbox sur un serveur : ce qu'est une seedbox, comment la dimensionner, installer un client torrent avec interface web, et la maintenir privée et sécurisée. FAQ de 6 questions](https://servhidden.com/fr/guides/seedbox-setup-guide) [### Comment contourner la censure DPI avec votre propre VPS (guide 2026) Confidentialité Votre VPN a cessé de fonctionner ? Comment contourner la censure DPI avec votre propre VPS : ce que l'inspection approfondie des paquets détecte réellement, lequel des cinq protocoles de 2026 bat quel type de blocage, et un guide complet de déploiement VLESS+REALITY. FAQ de 6 questions](https://servhidden.com/fr/guides/bypass-dpi-censorship-with-your-own-vps) [### Chiffrement intégral du disque sur un VPS : configuration LUKS Exploitation Comment chiffrer un VPS avec LUKS : volumes de données chiffrés, chiffrement intégral de la racine avec déverrouillage SSH, les réglages qui comptent sur un petit serveur, et ce que le chiffrement empêche vraiment. FAQ de 8 questions](https://servhidden.com/fr/guides/full-disk-encryption-on-a-vps) [### Masquer l'IP d'origine : CDN, reverse proxy et fuites Confidentialité Faut-il un CDN devant un serveur offshore : ce qu'il masque, le service abus hérité, les six fuites d'IP d'origine possibles, et comment auditer la vôtre. FAQ de 8 questions](https://servhidden.com/fr/guides/hiding-your-origin-server-ip) [### Auto-héberger Matrix : fédération, métadonnées et limites du chiffrement E2EE Exploitation Ce qu'un serveur Matrix auto-hébergé change : Synapse ou Conduit, le server_name qu'on ne change jamais, les médias qui saturent le disque, ce que révèle la fédération. FAQ de 8 questions](https://servhidden.com/fr/guides/self-host-a-matrix-server) [### Migrer un site vers un hébergeur offshore sans interruption Exploitation L’ordre qui rend une migration d’hébergeur ennuyeuse : baisser le TTL DNS plusieurs jours à l’avance, faire tourner les deux serveurs en parallèle, geler les écritures pendant des minutes plutôt que des heures — et nettoyer la trace laissée par le DNS passif, les journaux Certificate Transparency et le WHOIS. FAQ de 8 questions](https://servhidden.com/fr/guides/migrate-website-to-offshore-hosting) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Exploitation Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. FAQ de 8 questions](https://servhidden.com/fr/guides/self-host-a-crypto-payment-gateway) ## Donnez à la sauvegarde de ce soir un endroit où atterrir Sept juridictions, bande passante illimitée sur chaque forfait, et des serveurs à partir de $7.50/mo qui font d’excellentes cibles restic ou Borg. Pas de KYC, pas d’email, crypto uniquement — pour la cible de sauvegarde autant que pour la production. [Voir les offres VPS](https://servhidden.com/fr/vps) [Serveurs Dédiés](https://servhidden.com/fr/dedicated) [Toutes les localisations](https://servhidden.com/fr/locations) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "VPS et serveurs dédiés offshore dans 7 juridictions privacy-friendly. Sans KYC, sans logs, crypto uniquement. La vie privée par architecture.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Sauvegarde VPS chiffrée et hors site : la stratégie qui restaure vraiment", "description": "Votre hébergeur ne conserve aucune sauvegarde. Ce qui détruit un serveur, restic contre Borg, les clés qu’on oublie, et comment tester une restauration.", "image": "https://servhidden.com/assets/img/guides/vps-backup-strategy.webp?v=1787218773", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-20T00:00:00+00:00", "dateModified": "2026-08-20T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/vps-backup-strategy", "inLanguage": "fr", "keywords": "sauvegarde VPS, sauvegarde VPS chiffrée, sauvegarde hors site, restic vs BorgBackup, règle 3-2-1 sauvegarde, sauvegarde append-only, sauvegarder un serveur no-KYC, tester une restauration VPS", "articleSection": "Exploitation", "wordCount": 4122 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "ServHidden sauvegarde-t-il mon VPS ?", "acceptedAnswer": { "@type": "Answer", "text": "Non, et c’est délibéré, pas un oubli. Notre politique de rétention indique qu’aucune sauvegarde n’est conservée, que les données du serveur sont détruites dans les 24 heures suivant la résiliation, et que les disques sont effacés cryptographiquement plutôt que formatés. Garder une copie de vos données après que vous nous avez demandé de les supprimer contredirait la raison d’être de la plateforme. Tout ce que vous voulez faire survivre au serveur doit être copié par vous-même, idéalement vers un second fournisseur dans une seconde juridiction." } }, { "@type": "Question", "name": "Un snapshot est-il la même chose qu’une sauvegarde ?", "acceptedAnswer": { "@type": "Answer", "text": "Non. Un snapshot partage tous les domaines de panne avec le serveur dont il provient — le même fournisseur, le même compte, le même pays, souvent le même stockage. Il est excellent pour annuler une mise à jour ratée et inutile face à la perte du compte, du fournisseur ou de la machine. Considérez les snapshots comme un bouton annuler et les sauvegardes comme une assurance ; ils résolvent des problèmes différents et vous voulez les deux." } }, { "@type": "Question", "name": "restic ou BorgBackup, lequel choisir ?", "acceptedAnswer": { "@type": "Answer", "text": "restic si la cible pourrait être du stockage objet, du SFTP ou quelque chose que vous n’avez pas encore choisi, car il parle le plus de back-ends. BorgBackup si la cible est une seule machine Linux atteinte via SSH et que les données sont volumineuses et répétitives, car sa déduplication est la meilleure du lot. Les deux chiffrent à la source avant que quoi que ce soit ne quitte la machine, et les deux prennent en charge une cible append-only, ce qui compte bien plus que le choix entre eux." } }, { "@type": "Question", "name": "Comment empêcher un attaquant de supprimer mes sauvegardes ?", "acceptedAnswer": { "@type": "Answer", "text": "Retirez la capacité plutôt que le motif. Soit vous rendez la cible append-only, pour que les identifiants du serveur de production puissent ajouter des données mais jamais les supprimer, soit vous inversez la connexion pour que l’hôte de sauvegarde vienne chercher les données en pull et que le serveur de production ne détienne aucun identifiant du tout. Supprimer les sauvegardes avant de s’annoncer est une pratique courante chez quiconque fait cela commercialement, et une copie que votre attaquant peut supprimer n’est pas une seconde copie." } }, { "@type": "Question", "name": "Où faut-il héberger la seconde copie ?", "acceptedAnswer": { "@type": "Answer", "text": "Chez un fournisseur différent, dans une juridiction différente, et payée de façon aussi privée que votre serveur de production. Les événements qui emportent les deux copies à la fois sont rarement physiques — c’est un compte perdu, un fournisseur qui traverse une mauvaise semaine, ou un instrument juridique qui touche un pays et pas un autre. Deux serveurs dans la même baie sont une copie avec des étapes en plus. Comme les outils chiffrent à la source, le second hôte n’a pas besoin d’être un hôte de confiance." } }, { "@type": "Question", "name": "À quelle fréquence faut-il sauvegarder son VPS ?", "acceptedAnswer": { "@type": "Answer", "text": "Partez de la quantité de travail que vous êtes prêt à refaire. Un blog peut perdre une journée sans que personne ne le remarque ; une boutique ne peut pas perdre une heure de commandes. Une fréquence nocturne est le bon réglage par défaut pour la plupart des configurations à serveur unique, avec des dumps de base de données plus fréquents si les écritures ont de la valeur. Ce qui compte plus que la fréquence, c’est la profondeur de rétention : la corruption est souvent remarquée des semaines plus tard, donc gardez assez d’historique pour atteindre un point antérieur à son apparition." } }, { "@type": "Question", "name": "Une sauvegarde chiffrée est-elle sûre sur un serveur que je ne contrôle pas ?", "acceptedAnswer": { "@type": "Answer", "text": "Pour le contenu, oui — restic et Borg chiffrent avant que les données ne quittent la source, donc la cible stocke des blocs qu’elle ne peut pas lire, et la clé ne voyage jamais. Ce que la cible apprend, ce sont des métadonnées : à peu près combien de données vous détenez, comment elles évoluent, et quand vos tâches tournent. C’est généralement acceptable. Si ça ne l’est pas, variez le calendrier et gardez le dépôt sur une machine dont la propriété n’est pas liée à celle de la production." } }, { "@type": "Question", "name": "Que se passe-t-il si je perds la phrase de passe de la sauvegarde ?", "acceptedAnswer": { "@type": "Answer", "text": "L’archive est perdue, définitivement, sans aucun recours possible. C’est la perte totale la plus fréquente de tout ce sujet, et le seul échec sans chemin de récupération. Gardez la phrase de passe quelque part en dehors de toutes les machines concernées, préférez le papier à un compte que vous pourriez aussi perdre, et ajoutez une seconde clé au dépôt pour qu’un mot de passe oublié soit une gêne plutôt que la fin de l’archive." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Accueil", "item": "https://servhidden.com/fr/" }, { "@type": "ListItem", "position": 2, "name": "Guides Hébergement Privé", "item": "https://servhidden.com/fr/guides" }, { "@type": "ListItem", "position": 3, "name": "Sauvegarde VPS chiffrée et hors site : la stratégie qui restaure vraiment", "item": "https://servhidden.com/fr/guides/vps-backup-strategy" } ] } ```