Guides d'achat

Planifier la sauvegarde et la restauration d'un VPS

Transformez les sauvegardes du fournisseur en un plan de restauration réellement testé, avec des prix et des cas d'échec réalistes.

Dernière vérification24 oct. 2026 · 1033 mots

L'interface est traduite. Les faits fournisseurs et le texte des évaluations sont actuellement en anglais ; la page reste non indexée jusqu'à une traduction de qualité.

Ce guide est entièrement traduit. La version anglaise reste la référence pour les faits et prix des fournisseurs ; la traduction est en attente de relecture éditoriale, cette page reste donc pour l'instant hors index.

Une sauvegarde, c'est une restauration que vous avez effectuée

Une case à cocher « sauvegarde » chez un fournisseur n'est pas un plan de restauration. La bonne question est ce qui se passe une fois la machine disparue : combien de temps il faut pour obtenir un remplacement fonctionnel, ce qui est exactement restauré et quelles données vous perdez entre-temps. Un instantané d'une base de données en cours d'exécution est souvent incohérent ; une sauvegarde conservée uniquement chez le même fournisseur disparaît avec un problème de facturation ; et une sauvegarde que vous n'avez jamais restaurée est une hypothèse, pas une capacité.

Ce guide distingue les trois couches qui comptent : les données que vous ne pouvez pas reconstruire (enregistrements métier, fichiers envoyés par les utilisateurs, clés), la configuration que vous pouvez reconstruire depuis le contrôle de version, et les fonctionnalités du fournisseur que vous payez. Chaque couche exige un délai de restauration et un test différents.

Ce que les fournisseurs de ce catalogue proposent réellement

DigitalOcean documente des sauvegardes hebdomadaires à 20 pour cent du prix du Droplet et des sauvegardes quotidiennes à 30 pour cent, désactivées par défaut. Linode publie des prix fixes mensuels pour le module de sauvegarde selon la taille de l'offre, ce qui rend le coût à long terme plus facile à calculer qu'un pourcentage. Hostinger inclut des sauvegardes hebdomadaires avec ses offres KVM sans frais supplémentaires, tandis que BuyVM vend des sauvegardes nocturnes à 10 pour cent du prix de base avec un minimum mensuel de 0.50 dollar et inclut cinq instantanés gratuits. OVHcloud inclut une sauvegarde quotidienne de 24 heures avec ses offres VPS et vend une sauvegarde premium de 7 jours ainsi que des instantanés comme options distinctes. Hostens propose un module de sauvegarde pour 1 dollar par mois sur ses offres Linux. Contabo vend Auto Backup comme module payant avec une rétention incrémentielle de 10 jours.

Ces différences comptent plus que le prix affiché. Une fenêtre de rétention de 24 heures signifie qu'une suppression accidentelle découverte deux jours plus tard est irrécupérable depuis la sauvegarde du fournisseur ; une planification hebdomadaire signifie jusqu'à sept jours de perte. La tarification en pourcentage évolue avec l'offre, si bien qu'une offre bon marché aujourd'hui devient une ligne de sauvegarde plus chère après une montée en gamme.

Concevez le chemin de restauration avant de choisir le module

Notez l'objectif de point de restauration (combien de données vous pouvez perdre) et l'objectif de délai de restauration (combien de temps le service peut être indisponible). Pour un site vitrine reconstruit depuis un dépôt, un instantané hebdomadaire et une reconstruction en 30 minutes peuvent suffire. Pour une petite boutique, les données de commande ne peuvent généralement pas être recréées : un export quotidien de la base stocké hors du fournisseur et une procédure de restauration testée constituent le minimum. Pour une médiathèque, le volume de stockage compte plus que le système d'exploitation, et restaurer des centaines de gigaoctets prend des heures, quelle que soit la fonction de sauvegarde du fournisseur.

Vérifiez ensuite que la fonction du fournisseur peut atteindre ces objectifs. Si la seule sauvegarde est un instantané chez le même fournisseur avec une rétention de 24 heures, elle ne peut pas satisfaire une exigence de rétention de 30 jours ni de protection contre la perte du compte. Ajoutez une copie indépendante : un bucket de stockage objet, un hôte externe ou une archive chiffrée que vous téléchargez selon un calendrier. Le coût de cette copie fait partie du plan, ce n'est pas un extra facultatif.

Des exercices de restauration réalisables ce mois-ci

Commencez par une restauration au niveau fichier : supprimez un fichier de test connu sur une copie de préproduction et restaurez-le depuis la sauvegarde. Restaurez ensuite un export de base de données dans une base distincte et exécutez une requête qui prouve le nombre de lignes et les enregistrements les plus récents. Enfin, reconstruisez l'instance entière à partir de l'image du fournisseur et de la sauvegarde, rattachez les données et mesurez le temps. Chaque exercice doit produire une note datée : ce qui a été restauré, combien de temps cela a pris et ce qui a échoué.

Gardez la cible de l'exercice séparée de la production. Restaurer par-dessus un serveur en production pour « tester » la sauvegarde, c'est ainsi que de petites erreurs deviennent des pannes. Une seconde petite instance ou un schéma isolé suffit pour les vérifications de données, et sert aussi à confirmer que les clés, la configuration d'environnement et les tâches planifiées sont couvertes par le plan.

Chiffrement, rétention et accès

Les instantanés du fournisseur sont généralement chiffrés au repos par le fournisseur, mais cela protège le support de stockage, pas votre compte. Si un attaquant contrôle le compte, les instantanés sont accessibles. Pour les archives que vous téléchargez, chiffrez-les vous-même et conservez la clé ailleurs que sur le serveur sauvegardé. Notez qui peut lire l'emplacement de sauvegarde et retirez l'accès aux personnes qui n'en ont plus besoin.

La rétention doit être réfléchie : des copies quotidiennes pendant une semaine, des copies hebdomadaires pendant un mois et une copie mensuelle conservée plus longtemps pour les données que vous ne pouvez pas reconstruire. Une rétention plus longue n'est pas automatiquement meilleure si personne ne vérifie que les anciennes copies se restaurent encore. Un ensemble plus petit et testé vaut mieux qu'une grande archive non testée.

Cas d'échec courants

La base de données est sauvegardée pendant qu'elle écrit, produisant un export corrompu : utilisez un mécanisme d'export cohérent ou un instantané de système de fichiers pris avec la base au repos. La sauvegarde ne vit que chez le même fournisseur et le compte est suspendu : conservez une copie hors fournisseur. La restauration exige la même version du système d'exploitation et l'image du fournisseur a évolué : documentez l'image de base et figez-la lorsque c'est possible. La sauvegarde inclut les données mais pas la configuration : stockez les fichiers d'environnement et les notes d'infrastructure séparément, sans secrets dans le dépôt.

Aucun de ces échecs n'exige une configuration exotique pour être évité. Ils exigent d'écrire le chemin de restauration et de le tester avant l'incident. Si le fournisseur ne publie ni prix ni durée de rétention des sauvegardes, c'est une inconnue à vérifier, pas un vide à combler par une supposition.

Écrivez le plan au même endroit que le runbook que vous ouvrirez réellement pendant une panne : quel instantané ou export utiliser, où se trouvent les identifiants, qui approuve une restauration et comment vous confirmerez que le service restauré est sain avant de rétablir le trafic. Un plan d'une page qui nomme la fonction du fournisseur, la copie indépendante, la commande de restauration et la requête de vérification vaut mieux qu'un long document de politique que personne ne lit. Révisez-le après chaque exercice, car les lacunes que vous trouvez se situent généralement dans les étapes que vous supposiez évidentes.

Checklist de vérification

  • Notez la perte de données et l'indisponibilité maximales acceptables.
  • Confirmez la planification, la rétention et le prix des sauvegardes du fournisseur.
  • Conservez au moins une copie en dehors du compte du fournisseur.
  • Chiffrez les archives téléchargées et stockez les clés séparément.
  • Restaurez un fichier, une base de données et une instance entière à titre d'exercice.
  • Enregistrez la date, la durée et les échecs de l'exercice.
  • Traitez les conditions de sauvegarde non publiées comme inconnues jusqu'à vérification.

Sources