Un VPS vous donne le contrôle total du serveur, ce qui veut dire que les sauvegardes sont aussi votre affaire. Voici ce qu'il faut sauvegarder, la règle 3-2-1 sur un VPS, comment automatiser la planification, et pourquoi un test de restauration est la seule vraie preuve.
Une sauvegarde de VPS est une copie des données de votre serveur stockée à un endroit que le serveur lui-même ne peut pas atteindre, de sorte que lorsque le serveur tombe en panne, est supprimé par erreur ou chiffré par un rançongiciel, vous pouvez ramener les mêmes données sur une machine neuve. En hébergement mutualisé, c'est le fournisseur qui prend ces copies pour vous ; sur un VPS, vous contrôlez toute la pile, donc la responsabilité des sauvegardes, et de la reprise qui suit, vous incombe. Le standard pratique est la règle 3-2-1 — trois copies des données, sur deux types de stockage différents, avec une copie hors site — et la seule preuve que tout cela fonctionne est une restauration que vous avez réellement exécutée.
En hébergement mutualisé, le fournisseur fait des instantanés de toute la machine et vous ouvrez un ticket quand quelque chose casse. Le VPS supprime ce plafond : c'est vous qui choisissez le système d'exploitation, la base de données, le pare-feu et le calendrier des mises à jour, et c'est précisément l'intérêt d'en avoir un — mais cela veut aussi dire que personne ne prend de copie pour vous. Le fournisseur protège toujours le matériel, et un bon fournisseur survit à un disque défaillant sans que vous le remarquiez, mais cela ne couvre que la couche physique. Cela ne couvre pas l'opérateur qui installe une mise à jour et casse la base de données, le script qui écrase le mauvais répertoire, l'attaquant qui chiffre tout et exige une rançon, ni le compte fournisseur compromis par lequel un projet entier disparaît. Ces quatre scénarios ont un point commun : ils sont invisibles pour le datacenter, et ils finissent tous de la même façon tant qu'aucune copie n'existe ailleurs.
La règle, c'est trois copies des données, sur deux supports différents, dont une hors site, et elle survit parce qu'elle est simple et qu'elle couvre chaque point de défaillance unique. Sur un VPS, elle se traduit directement par l'infrastructure que vous avez déjà. La première copie, c'est le serveur en production lui-même. La deuxième est une copie sur un stockage différent dans le même projet — un instantané de volume détaché, un dump de base de données écrit dans un bucket de stockage objet, ou un service de sauvegarde chez le même fournisseur mais sur des disques séparés. La troisième est la copie hors site, et "hors site" doit signifier un domaine de défaillance entièrement différent : un autre fournisseur, un autre datacenter, ou un compte de stockage objet dans une région séparée. Deux supports comptent parce qu'un réseau de stockage entier peut tomber ; un site séparé compte parce qu'un compte ou un fournisseur entier peut tomber. Deux nombres décident de la forme de toute l'installation : votre objectif de point de récupération, la quantité de données que vous pouvez vous permettre de perdre, mesurée en temps, et votre objectif de délai de récupération, le temps pendant lequel l'entreprise peut survivre sans le service. Répondez d'abord à ces deux questions et chaque décision de sauvegarde ensuite se prend toute seule.
Tout sur un serveur ne mérite pas une copie, et tout traiter de la même façon est ce qui fait exploser les budgets de sauvegarde. Les bases de données viennent en premier, parce qu'elles contiennent le travail : faites un dump logique chaque nuit avec pg_dump ou mysqldump — un seul fichier compressé qui se restaure n'importe où — et pour les bases plus volumineuses ajoutez une récupération continue à un instant donné, afin qu'un mauvais import puisse être annulé à l'heure près plutôt que jusqu'à minuit la veille. Le code de l'application n'a pas besoin de sauvegarde, parce que le dépôt est la sauvegarde ; déployer depuis git signifie que reconstruire l'application est une seule commande. Ce qui a besoin d'être copié, c'est tout ce que le dépôt ne peut pas recréer : les fichiers téléversés et les médias des utilisateurs, les fichiers d'environnement qui contiennent les secrets et les clés tierces, la configuration de nginx et des services, les tâches cron et le script de sauvegarde lui-même. Les certificats et les enregistrements DNS figurent aussi sur la liste, car un domaine dont les enregistrements sont perdus peut prendre des jours à reconstruire. Gardez les secrets chiffrés au repos où qu'ils soient stockés — une sauvegarde d'un fichier .env dans un bucket public est une fuite de données qui attend d'être découverte.
Une sauvegarde qui dépend de la mémoire d'une personne sera oubliée le jour même où elle compte. Automatisez-la et rendez l'automatisation honnête : lancez la tâche depuis cron ou systemd selon un calendrier fixe, que chaque étape écrive dans un journal, et surtout que le script se termine par un code de sortie non nul quand une étape échoue, puis envoyez ce code là où un humain le lit — un e-mail, un canal de discussion, un système de supervision. Une tâche de sauvegarde qui a produit silencieusement un fichier vide pendant six mois est le résumé classique d'un incident, et le code de sortie est la garde peu coûteuse contre cela. Ajoutez des contrôles d'intégrité : vérifiez que le dump n'est pas vide, contrôlez la somme de contrôle de l'archive, et confirmez que la copie hors site est réellement arrivée en lisant le contenu du bucket plutôt qu'en faisant confiance à la commande d'envoi. Fixez ensuite la rétention délibérément au lieu de tout garder éternellement — un cycle grand-père de copies quotidiennes pendant une semaine, hebdomadaires pendant un mois, et mensuelles pendant un an couvre tous les besoins réalistes pour une fraction du coût de stockage, et cela force les anciennes données à disparaître plutôt qu'à s'accumuler jusqu'à ce que le budget double silencieusement.
Une sauvegarde n'est qu'une théorie tant qu'elle n'a pas été restaurée. Une fois par trimestre, prenez une copie récente, provisionnez un serveur jetable de même taille, et restaurez toute la pile à partir de rien : l'application, la configuration, la base de données, les fichiers téléversés. Chronométrez l'exercice, car une sauvegarde qui met neuf heures à se restaurer n'est pas la même proposition qu'une qui en met vingt minutes, et l'écart ne se voit que lorsqu'on le mesure. Comparez ensuite des enregistrements réels avec les données restaurées — un total, un nombre de lignes, une transaction récente — car une restauration qui aboutit sans la semaine dernière n'est pas un succès. Une fois l'exercice terminé, écrivez ce qui s'est passé dans un runbook qui vit hors du serveur : les commandes dans l'ordre, la source des identifiants, les enregistrements DNS à basculer, et qui fait quoi. Un runbook stocké sur la machine qu'il doit sauver est inutile pile au moment où il sert, et un ingénieur calme avec un runbook testé récupère en une heure ce qu'un ingénieur affolé redécouvre en une journée.
Des sauvegardes quotidiennes automatisées sont le minimum pour un site professionnel, avec des dumps de base de données plus fréquents si les données changent en permanence — toutes les quelques heures, ou une récupération continue à un instant donné si perdre toute une matinée de transactions ferait mal. Le bon intervalle est fixé par votre objectif de point de récupération : la réponse à « combien de nouveau travail pouvons-nous nous permettre de perdre ? » mesurée en heures, pas par une règle générale.
Les sauvegardes du fournisseur sont une première couche utile, et sur une bonne plateforme elles sont fiables, mais ce n'est pas un plan de reprise après sinistre. Elles vivent généralement dans le même compte et le même domaine de défaillance que le serveur, c'est souvent un coût supplémentaire qui disparaît quand les budgets se resserrent, et si le compte du fournisseur est compromis, le serveur et ses sauvegardes disparaissent ensemble. Gardez la sauvegarde du fournisseur, et ajoutez une copie que vous contrôlez en dehors de ce compte — c'est la copie hors site que la règle 3-2-1 existe pour imposer.
En les restaurant. Une tâche de sauvegarde qui signale un succès prouve seulement que le script s'est exécuté et qu'un fichier a été écrit ; cela ne dit rien sur le fait que le fichier est complet, intact ou restaurable. Le seul test fiable est un exercice de restauration dans un environnement jetable — provisionnez un serveur neuf, reconstruisez la pile depuis la sauvegarde, et comparez des données réelles avec l'original. Faites-le au moins une fois par trimestre, et chronométrez-le, car une restauration qui fonctionne mais prend toute une journée change vos plans de reprise.
Des serveurs VPS déployés avec une histoire de récupération qui fonctionne — sauvegardes quotidiennes de base de données, copies hors site et restaurations testées dans le service géré.
La moitié prévention de ce guide — clés SSH, pare-feu, mises à jour automatiques et TLS, pour que moins d'incidents atteignent la sauvegarde.
L'emplacement de votre serveur décide de sa latence et de son domaine de défaillance — la même question à se poser avant de placer une copie hors site.
EGYmass gère l'hébergement, la sécurité et la maintenance continue - pour que vous puissiez vous concentrer sur votre produit.
Consultation gratuite