Une sauvegarde réussie ne prouve pas à elle seule qu’une application peut être remise en service. Il peut manquer une clé, une dépendance externe, les fichiers associés à la base de données ou une procédure précisant dans quel ordre les récupérer. Les tests de reprise après sinistre pour les applications PHP permettent de vérifier l’ensemble du processus avant qu’une perte ou une corruption de données n’oblige à l’exécuter sous pression.
L’objectif n’est pas de garantir qu’il n’y aura jamais d’interruption, mais d’obtenir des éléments concrets sur ce qui peut être récupéré, le temps nécessaire et les obstacles qui restent à surmonter. Pour que l’exercice soit utile, il faut en définir le périmètre, isoler l’environnement, valider à la fois l’infrastructure et le comportement de l’application, et désigner des responsables pour les améliorations nécessaires.
Vérifier une sauvegarde ne signifie pas rétablir le service
Une vérification de sauvegarde peut confirmer qu’un fichier existe, que sa taille semble raisonnable ou qu’un outil peut le lire. C’est un contrôle utile, mais différent de la restauration des composants nécessaires et de la démonstration que l’application fonctionne avec ceux-ci.
La reprise complète peut inclure une base de données, des fichiers téléversés par les utilisateurs, du code et de la configuration, ainsi que des services comme des files de travaux, du stockage d’objets, un cache ou des tâches planifiées. Elle peut aussi dépendre du DNS, de certificats, d’autorisations, d’extensions PHP et de services externes. Si l’un de ces éléments manque ou ne correspond pas aux autres, la sauvegarde peut être valide sans que le service soit pour autant rétabli.
Il est utile de définir ce que signifie « rétabli » pour chaque application. Cela peut vouloir dire que le processus PHP démarre, que les utilisateurs autorisés peuvent se connecter et effectuer un parcours critique, ou que les travaux en arrière-plan sont de nouveau traités. Une page d’accueil visible ne suffit pas comme seul critère.
Définir le périmètre et les critères de réussite avant de commencer
Documentez le scénario à tester : par exemple, la perte d’une base de données, la corruption de fichiers ou l’indisponibilité d’un environnement complet. Il n’est pas nécessaire de simuler tous les incidents au cours d’une seule séance. Délimiter le scénario permet d’identifier les composants à restaurer et ce qui est explicitement exclu de l’exercice.
Convenez de critères vérifiables avec les équipes métier, techniques et opérationnelles. Voici quelques questions pratiques :
- Quelles fonctionnalités doivent être de nouveau disponibles et lesquelles peuvent attendre ?
- Jusqu’à quel moment les données peuvent-elles être récupérées, et quelle perte de modifications serait tolérable ?
- Combien de temps le service peut-il être interrompu avant que l’impact ne devienne inacceptable ?
- Quelles dépendances font partie de la reprise et lesquelles seront représentées par des substituts sûrs ?
- Qui autorise l’exécution, valide le résultat et communique les problèmes ?
Les objectifs de point de reprise (RPO) et de délai de reprise (RTO) peuvent servir à exprimer les tolérances en matière de perte de données et d’interruption. Ils doivent être définis en fonction des besoins et des capacités de chaque service ; il n’existe pas de valeur universelle. Le test permet de comparer les délais et l’état des données observés à ces objectifs, sans transformer un résultat ponctuel en garantie pour l’avenir.
Préparer un environnement isolé et sécurisé
Effectuez la restauration dans un environnement distinct de la production, en prenant des mesures pour empêcher que l’exercice ne modifie des données réelles ou n’envoie des messages aux clients. Isolez les réseaux dans la mesure du possible et bloquez ou remplacez les intégrations susceptibles d’effectuer des paiements, d’envoyer des courriels, de publier des événements ou de modifier des systèmes externes. Informez les participants qu’il s’agit d’un test.
Les données restaurées peuvent contenir des informations sensibles. Appliquez les politiques pertinentes en matière d’accès, de conservation et de protection des données ; limitez le nombre de personnes pouvant accéder à l’environnement et la durée de cet accès. Évitez de réutiliser les identifiants de production. Gérez les secrets de test de manière contrôlée et vérifiez que les fichiers restaurés ne les exposent pas dans les journaux, les dépôts ou les répertoires accessibles au public.
Consignez les conditions initiales : date et point de sauvegarde, versions du code et de la configuration nécessaires, ressources disponibles et différences entre l’environnement de test et la production. Une version différente de PHP, des extensions manquantes ou des autorisations différentes peuvent influer sur le résultat. Ces écarts doivent être consignés, et non confondus avec la réussite ou l’échec de la sauvegarde.
Rétablir tous les composants nécessaires
Suivez la procédure documentée, même si vous connaissez une méthode plus rapide. Le but est précisément de vérifier si les instructions suffisent pour qu’une autre personne puisse rétablir le service. Notez l’ordre et la durée de chaque étape, les commandes manuelles, les décisions prises et toute intervention imprévue.
Une séquence possible, à adapter à chaque architecture, consiste à restaurer l’infrastructure et la configuration, à récupérer la base de données et les fichiers, à déployer la version de code compatible, puis à connecter les dépendances nécessaires. En PHP, vérifiez, le cas échéant, la configuration du serveur web et de PHP-FPM, les extensions requises, les variables d’environnement, les autorisations d’écriture et les tâches planifiées. Vérifiez également les files d’attente, le stockage d’objets et les processus de travail si l’application en dépend.
N’exécutez pas automatiquement des migrations ou des processus de reconstruction des données sans en connaître les effets sur une copie restaurée. Vérifiez que les identifiants se rapportent exclusivement aux services de test et que les tâches cron ne produisent pas d’effets externes. Si la reprise nécessite une intervention manuelle, consignez-la dans la durée effective de la reprise et comme piste d’amélioration possible.
Valider l’intégrité et le comportement, pas seulement le démarrage
Les vérifications doivent couvrir les données et les parcours fonctionnels. Commencez par les contrôles techniques : connectivité à la base de données, état des processus, espace disponible, journaux d’erreurs et réponse des services internes. Vérifiez ensuite la cohérence entre les fichiers stockés et leurs références, ainsi que la cohérence des relations ou contraintes importantes de la base de données.
Choisissez des requêtes et des parcours représentatifs, adaptés à l’utilisation réelle de l’application. Par exemple, vérifiez qu’il est possible de retrouver une entité connue, de se connecter avec un compte de test et d’effectuer une opération sans effets externes. Si des fichiers ont été téléversés, vérifiez qu’ils peuvent être récupérés et associés à leurs enregistrements. S’il existe des files d’attente, vérifiez que les travaux en attente se comportent comme prévu et ne sont pas traités deux fois par erreur.
Conservez suffisamment de preuves pour pouvoir répéter l’évaluation : résultats des requêtes, étapes effectuées, erreurs observées et heures de début et de fin. Noter simplement « fonctionne » ne suffit pas. Définissez à l’avance les vérifications qui permettent de réussir l’exercice et celles qui sont bloquantes. Une application qui répond, mais affiche des données incomplètes ou ne traite pas les opérations critiques, ne doit pas être considérée comme rétablie si les critères sont plus exigeants.
Mesurer, corriger et recommencer à une fréquence adaptée
Mesurez le temps écoulé entre le début convenu et le respect des critères de reprise, et pas seulement le temps nécessaire à la restauration d’une base de données. Pour faciliter l’analyse, distinguez le temps d’attente, les tâches automatisées, les étapes manuelles et la validation. Comparez le résultat aux objectifs convenus et relevez les hypothèses qui ne se sont pas vérifiées, comme des autorisations indisponibles ou une documentation obsolète.
Le rapport doit préciser le périmètre, le point restauré, le résultat de chaque vérification, les délais observés, les incidents, les décisions et les responsables des mesures correctives. Donnez la priorité aux mesures qui réduisent les blocages : automatiser les étapes répétitives, mettre à jour les instructions, corriger les autorisations, réexaminer les dépendances ou améliorer la stratégie de sauvegarde. Fixez des dates de suivi et répétez la partie concernée pour vérifier si la correction a résolu le problème.
La cadence dépend des risques, des évolutions de l’architecture et des capacités opérationnelles. Il est possible de combiner une restauration partielle fréquente — par exemple, d’une base de données ou de fichiers — avec des exercices de reprise complète et des scénarios différents. Il peut aussi être opportun de répéter le test après des changements importants du système de sauvegarde, de l’infrastructure ou des dépendances. Un test réussi fournit des éléments concrets pour un scénario et des conditions précis : il ne garantit pas le résultat de tous les incidents à venir.
