À quelle fréquence le plan de reprise après sinistre d'un site Web doit-il être testé?
Nous faisons tous des sauvegardes en espérant ne jamais les utiliser, mais bien sûr, nous y arriverons un jour.
Je me demandais si un guide de bonnes pratiques avait été écrit sur la fréquence à laquelle un plan de reprise après sinistre devait être testé.
En ce moment, je fais des courses sèches de temps en temps quand je me sens particulièrement paranoïaque, mais il n'y a pas de programme et rien n'est automatisé.
Comme pour presque tout dans le monde, vous devez faire des compromis avant de décider quelle est la bonne approche.
La première chose à faire est d’évaluer votre entreprise et votre infrastructure pour élaborer un plan de gestion des risques (la reprise après sinistre et le plan de continuité des activités sont des éléments de celui-ci). Des questions comme:
- "Quelle est la perte d'argent si le site Web dure 10 minutes? Pendant 1 heure? 12 heures?"
- "Quelle est la perte de réputation?"
- "Quels sont les principaux impacts autres financiers et de réputation?"
- "Combien de données puis-je récupérer? Existe-t-il des redondances pour la base de données? Pour le serveur?"
- "Est-ce que la gestion de la configuration et la gestion des versions m'aident? Comment vont-ils?"
En dehors de cela, vous devez planifier la reprise après sinistre à certains niveaux. S'il s'agit d'un crash du serveur Web, d'une invasion de crackers, d'une inondation/d'un tremblement de terre, d'une défaillance de l'épine dorsale nationale, d'une mise hors tension ...
Comme vous pouvez le constater, certains risques peuvent simplement être atténués, certains exigeront beaucoup de travail et d’autres vous ne pouvez pas agir directement.
Après toutes les évaluations, vous pouvez déterminer quels tests vous feriez et à quelle fréquence. Chaque fois qu'un point change, vous devez le tester activement, par exemple, si vous achetez un nouveau serveur, vous devez tester la mise hors tension, un crash ... Lorsque tout est à peu près pareil mais que les données sur la base de données, un test de sauvegarde bimensuel ou mensuel est assez (si la gestion des risques le permet). Les grands corps simulent généralement cela une fois par trimestre, ainsi que tout le reste.
Juste un point ... vous devriez travailler sur l'automatisation de ce qu'il est possible d'automatiser. Si votre plan de gestion des risques laisse présager une perte massive, il est logique d'accélérer autant que possible l'automatisation afin de minimiser cet impact.
Je vais devoir aller avec "ça dépend" de celui-ci, mais plus sur cela plus tard. Je pense (et c'est une question assez subjective) que le choix de votre test importe plus que la fréquence à laquelle vous le testez. Comme Catcall l'a dit, vous devrez peut-être configurer un serveur complètement nouveau (évidemment pas si vous utilisez un hébergement partagé, ou en général si vous n'exécutez pas votre propre serveur). Vous devez donc vous assurer que tout peut être rapporté assez rapidement. Évidemment, cela ne vous aide pas si vous pouvez restaurer chaque page que vous hébergez à partir d'une sauvegarde en quelques minutes si tout le serveur ne s'exécute pas/ne dispose pas des mods dont vous avez besoin pour le site/ne dispose pas de la base de données requise/etc. Vous pouvez donc restaurer tout ce qui a été partagé avec le monde, mais il vous manque un plugin étrange ou vous devez inclure toutes les pages nécessaires et il ne vous reste plus qu'à déterminer ce qui manque, comment l'installer et comment y aller.
Après avoir testé la restauration de l'environnement de travail actuel et la restauration des données à partir de la sauvegarde, je ne pense vraiment pas que vous deviez le tester trop souvent. Je voudrais simplement m'assurer de le tester une fois pour toutes les modifications du système (nouvelle version des serveurs en cours d'exécution, nouveau matériel, nouveau système d'exploitation, nouvelle version de la base de données, etc.).
En ce qui concerne le "ça dépend" ... Quel genre de site web utilisez-vous? Évidemment, il n’est pas logique d’investir des centaines d’heures dans le test de la solution de sauvegarde si vous hébergez un petit site Web pouvant accueillir 100 visiteurs par mois. Si un temps d'indisponibilité de 12 heures réduit considérablement vos bénéfices, vous devriez probablement tester au moins une fois par mois.
Votre plan de reprise après sinistre doit être testé suffisamment souvent pour qu'il fonctionne correctement 100% du temps, si vous rencontrez un sinistre auquel il est supposé faire face. Cela signifie que lorsque vous êtes réveillé au milieu de la nuit, sans caféine, vous êtes crié au cours de tout le processus, etc.
Mon plan est supposé faire face à une intrusion et à un vol du serveur, mais on ne s'attend pas à ce que je le fasse en moins de deux heures au milieu de la nuit. J'ai le temps d'acheter un nouveau serveur localement, de recharger le système d'exploitation, d'installer un lecteur de bande de rechange et de restaurer à partir d'une bande.
Je lance rarement une restauration complète. Mais je teste ma capacité de restauration à partir d'une bande, y compris celle de restaurer des fichiers très volumineux, plusieurs fois par semaine. En fait, je restaure des fichiers et compare les sommes de contrôle md5.
Le site Web principal dont je m'occupe (juste une petite partie de mon travail) n'a pas besoin d'être restauré à partir d'une bande, mais le serveur sur lequel il est installé le fait. Le site Web est construit à partir d'un référentiel Subversion, et je peux le reconstruire à partir des sources environ 20 minutes après la mise en service du serveur.