Checklist de sauvegarde de serveur pour une récupération fiable

Publié le 25 septembre 2026

Une sauvegarde qui n’a jamais été restaurée n’est pas une protection. C’est un fichier plein d’espoir qui se trouve quelque part ailleurs. Cette checklist de sauvegarde de serveur vous aide à élaborer un plan de récupération pour les éléments qui permettent réellement à votre entreprise de fonctionner : sites web, bases de données, e-mails, fichiers utilisateur, paramètres du serveur et accès nécessaires pour les restaurer.

L’objectif n’est pas de créer l’archive la plus volumineuse possible. Il s’agit de récupérer la bonne version du bon service dans un délai que vos clients peuvent tolérer. Un petit site vitrine et une boutique en ligne très fréquentée n’ont pas besoin de la même planification, de la même conception du stockage ni du même objectif de récupération. Une bonne planification des sauvegardes commence par là.

Commencez par la récupération, pas par le stockage

Avant de choisir une destination de sauvegarde ou de définir une planification, déterminez ce que coûterait une défaillance. Posez-vous deux questions pratiques : quelle quantité de données récentes pouvez-vous vous permettre de perdre et combien de temps le service peut-il rester indisponible ?

La première réponse correspond à votre objectif de point de récupération, souvent appelé RPO. Si votre boutique reçoit des commandes toute la journée, une sauvegarde quotidienne de la base de données peut entraîner la perte d’une journée entière de transactions. Le second correspond à votre objectif de délai de récupération, ou RTO. Si la restauration d’un serveur prend six heures alors que votre temps d’arrêt acceptable est d’une heure, la sauvegarde est peut-être complète, mais le plan ne l’est pas.

Notez ces objectifs pour chaque service important. Les sites web, les bases de données, les e-mails et les fichiers d’application présentent souvent des taux de modification différents. Cela évite l’erreur courante qui consiste à considérer une seule image nocturne du serveur comme la solution à tous les problèmes de récupération.

Checklist de sauvegarde de serveur : que protéger

Une sauvegarde utile couvre davantage que les fichiers visibles du site web. Les échecs de restauration surviennent généralement parce qu’une dépendance négligée a été oubliée : un mot de passe de base de données, un certificat SSL, un compte e-mail ou une configuration de service personnalisée.

Utilisez cette checklist pour définir l’ensemble à sauvegarder avant toute automatisation :

• Fichiers et téléversements du site web : incluez les racines de documents, le code de l’application, les bibliothèques multimédias et les fichiers stockés en dehors du répertoire web habituel.
• Bases de données : sauvegardez chaque base de données et vérifiez que les tables, routines, déclencheurs et autorisations utilisateur nécessaires sont inclus.
• Données e-mail : protégez les boîtes aux lettres, alias, règles de transfert, paramètres antispam et identifiants de compte si les e-mails sont hébergés sur le serveur.
• Configuration du serveur et des services : enregistrez les hôtes virtuels du serveur web, les paramètres PHP, les règles du pare-feu, les tâches planifiées, les zones DNS et les fichiers de configuration d’application pertinents.
• Certificats et clés SSL : un certificat de remplacement peut être émis, mais disposer des éléments de clé d’origine et de la configuration du renouvellement permet de gagner du temps lors d’une récupération stressante.
• Comptes utilisateur et informations d’accès : documentez les accès administrateur, les clés SSH, les utilisateurs du panneau de contrôle et la procédure de récupération des identifiants.
• Journaux et enregistrements métier : conservez les journaux nécessaires au dépannage ou à la conformité, mais définissez des périodes de conservation réalistes afin qu’ils ne consomment pas inutilement l’espace de sauvegarde.

Dans un environnement d’hébergement géré, les sauvegardes au niveau du compte peuvent suffire pour les restaurations courantes de sites web. Pour un serveur doté de services personnalisés, de plusieurs applications ou d’une configuration inhabituelle, ajoutez également des sauvegardes au niveau du système. Tout dépend de ce que vous devez reconstruire et de la rapidité avec laquelle vous devez le remettre en service.

Utilisez plusieurs copies

Conserver les sauvegardes sur le même serveur ne protège contre une suppression accidentelle que si la sauvegarde est isolée de cette suppression. Cela ne vous protège pas contre une défaillance du disque, un rançongiciel, un compte administrateur compromis ou une défaillance du centre de données.

Une règle pratique est l’approche 3-2-1 : conservez au moins trois copies des données, sur deux types de stockage différents, dont une copie stockée hors site. Pour de nombreuses équipes, cela signifie des données de production sur le serveur, une sauvegarde sur un stockage distinct et une autre copie chiffrée dans un emplacement différent.

La copie hors site est particulièrement importante lorsque le serveur principal rencontre un problème grave. Dans la mesure du possible, le stockage des sauvegardes doit également utiliser des identifiants distincts de ceux du serveur de production. Si un seul mot de passe volé permet de supprimer à la fois le site web et toutes les sauvegardes, le plan de récupération présente une faiblesse évidente.

Envisagez l’immuabilité ou la protection contre la suppression pour les sauvegardes critiques. Ces fonctionnalités limitent la rapidité avec laquelle les sauvegardes peuvent être modifiées ou supprimées, ce qui peut être précieux lors d’un incident de rançongiciel. Elles introduisent également un compromis : les erreurs peuvent être plus difficiles à corriger. Définissez donc qui peut modifier les paramètres de conservation et de suppression.

Définissez des planifications adaptées aux taux de modification

Un site web statique peut se contenter de sauvegardes quotidiennes. Un site WordPress fréquemment modifié, recevant des contributions de clients ou ayant une activité de commerce électronique, nécessite une protection plus fréquente de la base de données et des contenus téléversés.

Une approche courante consiste à effectuer des sauvegardes complètes quotidiennes, à conserver plusieurs points de récupération hebdomadaires et à garder les copies mensuelles pendant une période plus longue. Les bases de données peuvent nécessiter des sauvegardes plus fréquentes que les fichiers. Si votre application prend en charge les journaux de transactions ou la récupération à un instant donné, utilisez-les lorsque la valeur des données récentes justifie la configuration et le coût de stockage supplémentaires.

Ne confondez pas la fréquence des sauvegardes avec une conservation illimitée. Conserver chaque version indéfiniment devient coûteux et complique la recherche de la version dont vous avez besoin. Définissez une politique de conservation fondée sur les besoins opérationnels, les engagements envers les clients et les éventuelles exigences légales. Réexaminez-la ensuite à mesure que l’entreprise évolue.

Chiffrez les sauvegardes et limitez les accès

Les sauvegardes contiennent souvent tout ce qu’un attaquant convoite : données client, mots de passe stockés dans des fichiers de configuration, clés privées et secrets d’application. Chiffrez les données de sauvegarde en transit et au repos. Protégez les clés de chiffrement et documentez les personnes qui peuvent y accéder en cas d’urgence.

L’accès doit suivre le même principe que l’administration du serveur : seules les personnes et les systèmes qui en ont besoin doivent y avoir accès. Utilisez des identifiants de sauvegarde distincts, l’authentification multifacteur lorsqu’elle est disponible et la journalisation des activités pour les modifications administratives.

Un autre détail opérationnel est souvent oublié : veillez à ce que l’accès nécessaire à la récupération ne dépende pas du serveur que vous essayez de restaurer. Stockez les coordonnées d’urgence, les informations de récupération des comptes, les procédures liées aux clés de chiffrement et un runbook de restauration succinct dans un emplacement sécurisé situé en dehors du serveur.

Testez une restauration avant d’en avoir besoin

Les tâches de sauvegarde peuvent signaler une réussite tout en produisant des archives incomplètes, des exports de bases de données corrompus ou des sauvegardes qui ne correspondent plus à la configuration actuelle de l’application. Un test de restauration transforme la confiance en preuve.

Au moins une fois par trimestre, restaurez un site web et une base de données représentatifs dans un environnement de test isolé. Vérifiez que le site se charge, que les utilisateurs peuvent se connecter, que les données récentes sont présentes, que les tâches planifiées fonctionnent et que les e-mails ou autres services connectés se comportent comme prévu. Notez la durée du processus et comparez-la à votre RTO.

Testez plus souvent après des changements majeurs, comme une migration de serveur, la mise à niveau d’un moteur de base de données, la modification du logiciel de sauvegarde ou l’ajout d’une nouvelle application. Un test de cinq minutes après une modification est bien plus simple que la découverte d’une dépendance manquante pendant une interruption de service.

FASTPANEL peut améliorer la visibilité de la gestion courante des serveurs en regroupant les sites web, les bases de données et les comptes au même endroit, mais la responsabilité reste la même : confirmez que l’étendue de vos sauvegardes et votre processus de restauration correspondent à votre environnement réel.

Surveillez le processus de sauvegarde

Une planification de sauvegardes sans alertes n’est qu’un rappel de calendrier, pas un système opérationnel. Configurez des notifications pour les tâches échouées, les planifications manquées, la faible capacité de stockage, les erreurs d’authentification et les tailles de sauvegarde inhabituellement réduites. Une sauvegarde qui diminue soudainement peut indiquer qu’une base de données, un répertoire ou un compte a été ignoré.

Examinez régulièrement les rapports de sauvegarde. Recherchez les tâches lentes, l’augmentation de l’utilisation du stockage, les avertissements répétés et les variations de la quantité de données protégées. Si plusieurs personnes gèrent le serveur, attribuez clairement les responsabilités. Quelqu’un doit savoir quand la dernière sauvegarde réussie a été exécutée, où elle est stockée et comment commencer une restauration.

Documentez les étapes dans un langage clair. Lors d’un incident, personne ne gagne à disposer d’une procédure de récupération rédigée comme une énigme. Indiquez l’ordre des opérations, les délais de restauration prévus, les considérations liées au DNS, les contrôles de vérification et le moment où demander de l’aide.

Une récupération sereine se prépare avant l’interruption de service. Définissez l’étendue, séparez les copies, protégez les accès et entraînez-vous à effectuer la restauration. Vos sauvegardes cessent alors d’être une tâche d’arrière-plan et deviennent ce qu’elles devraient être : un moyen fiable de revenir à la normale.