Deux promesses reviennent en boucle autour du serveur dédié, et elles sont régulièrement confondues avec autre chose : la sauvegarde et la haute disponibilité. La première protège vos données contre leur disparition. La seconde protège votre service contre l'interruption. Un RAID ne fait ni l'une ni l'autre, et l'infogérance ne les inclut presque jamais par défaut.
Comprendre ce que chaque brique couvre réellement évite la mauvaise surprise classique : découvrir au moment de l'incident que ce qu'on croyait protégé ne l'était pas.
Le RAID n'est pas une sauvegarde
Le RAID réplique les données sur plusieurs disques d'une même machine. Si un disque tombe, le service continue et le disque se remplace sans perte : c'est de la tolérance de panne matérielle, et c'est précieux.
Mais le RAID réplique tout, fidèlement et immédiatement. Un fichier effacé par erreur est effacé sur tous les disques. Une base MySQL corrompue est corrompue partout. Un chiffrement malveillant se propage à l'identique. Le RAID ne connaît pas la notion de "version d'avant" : il n'a aucune mémoire du passé.
Autrement dit, le RAID protège du disque qui meurt. La sauvegarde protège de tout le reste, à commencer par vous.
Ce qui est inclus, et ce qui ne l'est pas
Sur la plupart des offres de serveurs dédiés, ce qui est fourni se limite au matériel, au réseau et à sa bande passante, à l'adresse IP, et selon les cas à une protection anti-DDoS. Le contenu de la machine, lui, vous appartient, au sens juridique comme au sens opérationnel.
L'infogérance, lorsqu'elle est proposée, couvre en général le maintien en condition du matériel et parfois du système. Elle ne construit pas votre stratégie de sauvegardes, et elle ne transforme pas une machine unique en architecture redondante. C'est une distinction que nous détaillons dans notre comparaison entre housing et serveur dédié managé.
La règle 3-2-1, et pourquoi elle tient toujours
La formulation classique demande trois copies des données, sur deux supports différents, dont une hors site. Elle date d'avant le cloud et n'a pas pris une ride, parce qu'elle répond à trois risques distincts.
- Trois copies couvrent l'erreur humaine : la copie de travail, plus deux filets.
- Deux supports couvrent la défaillance d'une technologie : un SSD NVMe et un stockage distant ne tombent pas pour les mêmes raisons.
- Une copie hors site couvre l'incident qui touche la machine entière, le baie ou le datacenter.
Le point le plus souvent raté est le troisième. Une sauvegarde déposée sur un second espace disque de la même machine ne survit ni à une compromission de cette machine, ni à un incident physique. C'est une commodité, pas une protection.
Le cas particulier des bases de données
Copier les fichiers d'une base MySQL pendant qu'elle écrit produit souvent une sauvegarde inutilisable : l'état capturé est incohérent, à cheval entre deux transactions. Le résultat a l'air d'une sauvegarde, occupe l'espace disque d'une sauvegarde, et ne se restaure pas.
La parade tient en un principe : passer par un export applicatif, qui demande au moteur de produire lui-même un instantané cohérent, plutôt que de copier les fichiers sous ses pieds. Et vérifier que l'export se termine sans erreur, plutôt que de supposer qu'il s'est bien passé parce qu'un fichier existe.
Haute disponibilité : ce que le terme recouvre vraiment
La haute disponibilité ne se mesure pas en qualité de matériel mais en capacité à continuer malgré la panne. Elle suppose au minimum deux machines, un mécanisme de bascule, et des données répliquées entre elles. Un seul serveur dédié, si puissant soit-il, ne peut pas être hautement disponible : il reste un point de défaillance unique.
C'est aussi vrai côté virtualisé. Une machine virtuelle ou un serveur cloud ne sont pas redondants par nature ; c'est l'architecture construite autour d'eux qui l'est. La virtualisation facilite simplement certaines opérations, comme déplacer une VM d'un hôte à l'autre. Le sujet est développé dans notre comparaison entre serveur dédié et VPS.
La bonne question n'est donc pas "suis-je en haute disponibilité ?" mais "combien de temps mon service peut-il rester indisponible, et combien de données puis-je me permettre de perdre ?". Les réponses à ces deux questions déterminent seules l'architecture dont vous avez besoin, et son coût.
Ce qui est sauvegardé, selon le type d'hébergement
Le partage des responsabilités change d'une formule à l'autre, et c'est souvent là que naît la confusion.
| Formule | Sauvegarde généralement fournie | Ce qui reste à votre charge |
|---|---|---|
| Hébergement mutualisé | Souvent une sauvegarde quotidienne gérée par l'hébergeur, avec une rétention courte. | Vérifier la rétention réelle et savoir comment déclencher une restauration. |
| VPS (serveur virtuel) | Parfois des instantanés de la machine virtuelle, en option la plupart du temps. | Le contenu applicatif et les bases MySQL, qu'un instantané ne capture pas toujours proprement. |
| Serveur dédié | En général rien : le serveur physique, son espace disque et son réseau, pas leur contenu. | La totalité de la stratégie, du choix de la destination au test de restauration. |
| Serveur cloud | Instantanés et images disponibles, généralement facturés au volume stocké. | La cohérence applicative, et une copie hors du même fournisseur. |
Un point revient dans les trois dernières lignes : un instantané de machine virtuelle capture un état disque, pas nécessairement un état applicatif cohérent. Pour une base de données, il ne remplace pas un export.
Où envoyer les sauvegardes
La destination compte autant que la fréquence. Un stockage distant accessible en FTP ou en SFTP, un espace objet chez un autre hébergeur, ou une machine que vous contrôlez ailleurs remplissent tous le critère "hors site". Le panneau de contrôle de la machine, Plesk par exemple, sait généralement pousser ses propres sauvegardes vers une de ces destinations.
Deux réflexes utiles : chiffrer la sauvegarde avant de l'envoyer, et conserver la clé ailleurs que sur le serveur sauvegardé. Une copie chiffrée dont la clé disparaît avec la machine ne vaut rien.
Ce que coûte vraiment la redondance
Passer d'une machine à une architecture tolérante à la panne implique plusieurs serveurs, donc de payer plusieurs fois le processeur, la RAM et le stockage, plus le travail de conception. Un cluster suppose en outre un mécanisme d'arbitrage pour décider quel nœud prend la main, et une réplication des données assez rapide pour que la bascule ne perde rien.
La virtualisation facilite certaines de ces opérations, en permettant par exemple la migration d'une machine virtuelle d'un hôte à l'autre. Des solutions comme VMware ou ses équivalents libres industrialisent ce mécanisme. Mais déplacer une VM n'est pas la même chose que survivre à la perte brutale de son hôte : la première est une opération planifiée, la seconde demande une vraie réplication.
C'est pourquoi la question du data center compte aussi : deux serveurs dans la même baie partagent l'alimentation et le réseau de cette baie. Notre guide sur le housing en datacenter détaille ce niveau de redondance.
La sauvegarde que personne n'a jamais restaurée
Une sauvegarde non testée est une hypothèse. Les motifs d'échec au moment critique sont d'une banalité décevante : sauvegarde interrompue depuis des semaines sans alerte, espace disque saturé, export de base vide, fichier de configuration absent de la copie, clé de chiffrement perdue avec la machine.
Le test n'a pas besoin d'être lourd. Restaurer périodiquement une sauvegarde sur une machine de test, ou même seulement en extraire quelques fichiers et vérifier qu'une base se recharge, suffit à écarter la quasi-totalité de ces cas. Ce qui compte est la régularité, pas la sophistication.
Checklist
- RAID considéré comme de la tolérance de panne, jamais comme une sauvegarde.
- Au moins une copie hors de la machine, idéalement hors du site.
- Bases MySQL sauvegardées par export applicatif, pas par copie de fichiers à chaud.
- Fréquence des sauvegardes alignée sur le volume de données que vous acceptez de perdre.
- Alerte en cas d'échec : une sauvegarde silencieusement arrêtée est le pire des cas.
- Restauration testée à intervalle régulier, pas seulement le jour de l'incident.
- Besoin de continuité de service évalué avant d'investir dans la redondance.
Ces réglages complètent ceux du premier jour sur un serveur dédié, qui traite l'accès SSH, le firewall et les services exposés. Pour l'environnement physique, notre guide sur le housing en datacenter explique ce que l'infrastructure d'accueil garantit. Nos serveurs dédiés et nos VPS Linux vous laissent libres de la stratégie de sauvegarde, c'est à ce niveau que se joue l'essentiel.