Sauvegarde serveur : automatiser et tester la restauration

La plupart des sauvegardes de serveur fonctionnent parfaitement jusqu’au jour où elles servent. Deux défauts expliquent presque tous les échecs, et aucun ne se voit dans un tableau de bord vert : la sauvegarde est joignable avec les mêmes identifiants que le serveur qu’elle protège, et personne n’a jamais tenté de restaurer. Voici comment construire un dispositif qui résiste à ces deux cas.

La règle 3-2-1, et ce qu’on lui a ajouté

La règle classique reste le socle : trois copies des données, sur deux supports différents, dont une hors du site principal. Elle protège de la panne matérielle et du sinistre physique, et elle a été conçue pour cela.

Elle ne protège pas d’un rançongiciel, parce qu’un attaquant qui obtient vos accès chiffre aussi les copies qu’il peut atteindre. D’où deux ajouts devenus la norme :

• Une copie hors ligne ou immuable, c’est-à-dire qu’aucun identifiant en circulation ne permet de l’effacer ou de la modifier avant l’expiration d’un délai fixé.
• Zéro erreur à la vérification, ce qui suppose un contrôle automatique de l’intégrité des archives, et pas seulement un message « sauvegarde terminée ».

Le sens du transfert change tout

C’est le point de conception le plus important, et celui que presque personne ne pose. Une sauvegarde peut se faire dans deux sens, et ils n’offrent pas du tout la même protection.

	Le serveur envoie (push)	Le dépôt vient chercher (pull)
Qui détient les identifiants	Le serveur de production	Le serveur de sauvegarde
Serveur compromis	L’attaquant atteint les sauvegardes	Il n’a aucun accès au dépôt
Facilité de mise en place	Immédiate	Demande une machine dédiée

Autrement dit, si votre serveur web possède les identifiants du stockage de sauvegarde, celui qui prend le contrôle du serveur les possède aussi. Inverser le sens supprime ce chemin : le dépôt se connecte au serveur pour lire, jamais l’inverse, et rien sur la machine exposée ne permet d’atteindre les archives.

Quand le mode d’envoi est imposé, exigez au minimum un dépôt en ajout seul, où la clé utilisée peut écrire de nouvelles données mais ni supprimer ni réécrire les anciennes. Les outils de sauvegarde chiffrée courants proposent ce mode, et il est la meilleure protection disponible sans machine supplémentaire.

Sauvegarder une base de données sans la bloquer

Copier les fichiers d’une base pendant qu’elle écrit produit une archive incohérente, qui se restaure sans erreur et contient des données corrompues. C’est le piège le plus insidieux, car rien ne le signale.

mysqldump --single-transaction --quick --routines base > base.sql
pg_dump --format=custom base > base.dump

L’option importante est la première : elle réalise la copie dans une transaction unique, ce qui donne une image cohérente à un instant donné sans bloquer les écritures pendant l’opération. Sans elle, vous choisissez entre un site figé pendant la sauvegarde et une archive douteuse.

Sauvegardez la base et les fichiers dans la même fenêtre, et notez l’heure des deux. Une base de lundi restaurée avec des fichiers de mardi produit des références cassées difficiles à démêler.

Quoi garder, et combien de temps

Une rétention trop courte est aussi dangereuse qu’une absence de sauvegarde. Une corruption ou une intrusion peut passer inaperçue plusieurs semaines : si vous ne conservez que sept jours, vous ne disposez plus que de copies déjà atteintes.

Rythme	Conservation	Ce que cela couvre
Quotidien	7 à 14 jours	L’erreur humaine, détectée vite
Hebdomadaire	4 à 8 semaines	Une dégradation passée inaperçue
Mensuel	6 à 12 mois	Une compromission ancienne, une obligation légale

Cette pyramide occupe beaucoup moins d’espace qu’il n’y paraît, car les outils de sauvegarde modernes ne stockent qu’une fois les blocs identiques. Conserver douze mensuelles coûte rarement plus qu’une poignée de quotidiennes supplémentaires.

Tester la restauration, la seule preuve qui compte

Une sauvegarde jamais restaurée est une hypothèse, pas une protection. Le test doit se faire sur une autre machine que celle d’origine, sans quoi vous ne testez rien : vous vérifiez seulement que le fichier existe.

1. Restaurez sur une machine vierge, à partir des seules archives et de la documentation. Si vous avez besoin d’un mot de passe qui n’est que dans votre tête, la procédure est incomplète.
2. Chronométrez. La durée mesurée est votre vrai délai de reprise, et elle est presque toujours plus longue que prévu.
3. Vérifiez le contenu, pas seulement le démarrage : quelques enregistrements récents, un fichier déposé la veille, une page qui s’affiche.
4. Notez ce qui a manqué et complétez la procédure. Un fichier de configuration oublié se découvre à ce moment-là, jamais avant.

Un test par trimestre suffit sur une infrastructure stable. C’est peu, et c’est ce qui sépare une sauvegarde d’une illusion de sauvegarde.

Être prévenu quand ça échoue, pas quand ça réussit

Une sauvegarde automatisée qui s’arrête de fonctionner ne produit aucun bruit. Elle cesse simplement d’écrire, et personne ne s’en aperçoit pendant des mois.

Un message quotidien de réussite est le pire des dispositifs : au bout de trois semaines, plus personne ne le lit, et son absence passe inaperçue. Deux réglages valent mieux.

• Alerter sur l’échec, et uniquement sur l’échec, avec le message d’erreur réel et non un code.
• Surveiller l’absence de résultat. C’est le point clé : une tâche qui ne s’exécute plus du tout n’émet aucune erreur. Il faut donc un contrôle extérieur qui s’inquiète quand la sauvegarde attendue n’est pas arrivée à l’heure prévue.

Contrôlez aussi la taille de chaque archive. Une sauvegarde subitement dix fois plus légère que la veille signale un répertoire disparu ou une base vidée, et c’est souvent le seul signal avant un incident grave.

Ce qu’il ne faut pas oublier de sauvegarder

• Les fichiers de configuration du serveur, serveur web, planificateur de tâches, règles de pare-feu. Sans eux, la restauration produit un site qui fonctionne autrement.
• Les certificats et les clés. Les remplacer est possible, mais pas dans l’urgence, comme le rappelle notre article sur la sécurité d’un serveur.
• Les tâches planifiées, souvent invisibles et pourtant indispensables au fonctionnement quotidien.
• La liste des paquets installés, qui permet de reconstruire un environnement identique sans chercher.
• La documentation elle-même, qui ne doit pas être stockée uniquement sur le serveur qu’elle sert à restaurer.

Ce dernier point est celui qui coince le plus souvent : la procédure de restauration se trouve sur l’intranet, et l’intranet est sur le serveur en panne.

La réserve : un instantané n’est pas une sauvegarde

Les instantanés proposés par les hébergeurs sont extrêmement pratiques et souvent pris pour une sauvegarde. Ils n’en sont pas.

Un instantané réside chez le même fournisseur, souvent sur la même infrastructure, et il disparaît généralement avec la machine. Il protège d’une mise à jour ratée, très bien et très vite. Il ne protège ni d’un incident chez l’hébergeur, ni d’une suppression de compte, ni d’un accès compromis à la console d’administration. C’est le même raisonnement que celui exposé dans notre article sur le choix entre sur site et cloud, et dans notre comparaison entre mutualisé, VPS et dédié.

Gardez donc les deux : l’instantané pour revenir en arrière en cinq minutes, la sauvegarde externalisée pour survivre à ce qui touche le fournisseur lui-même.

Questions fréquentes sur la sauvegarde d'un serveur

Comment protéger ses sauvegardes d'un rançongiciel ?

En faisant en sorte que le serveur de production ne détienne aucun identifiant permettant d’effacer les archives. Soit le dépôt vient chercher les données, soit la clé utilisée est en mode ajout seul, capable d’écrire mais pas de supprimer.

Comment sauvegarder une base de données sans couper le site ?

Avec une copie réalisée dans une transaction unique, via l’option --single-transaction pour MySQL ou MariaDB. Elle produit une image cohérente à un instant donné sans bloquer les écritures pendant l’opération.

Combien de temps faut-il conserver les sauvegardes ?

Une pyramide est préférable à une durée unique : 7 à 14 jours de quotidiennes, 4 à 8 semaines d’hebdomadaires et 6 à 12 mois de mensuelles. Une corruption peut passer inaperçue plusieurs semaines.

Un instantané de machine virtuelle suffit-il ?

Non. Il réside chez le même fournisseur, souvent sur la même infrastructure, et disparaît généralement avec la machine. Il protège d’une mise à jour ratée, pas d’un incident chez l’hébergeur ni d’un accès compromis à la console.

À quelle fréquence tester une restauration ?

Une fois par trimestre suffit sur une infrastructure stable, à condition de restaurer sur une machine vierge à partir des seules archives et de la documentation, et de chronométrer l’opération.