Au fur et à mesure qu’un déploiement ArcGIS Enterprise devient plus complexe, il est nécessaire de prendre en compte des considérations supplémentaires en vue de la récupération d’urgence. Ces considérations nécessitent des connaissances des différents systèmes formant l’architecture de déploiement. Comme dans bon nombre de scénarios techniques, il n’existe pas de solution universelle pour la sauvegarde des systèmes de base et dépendants dans un déploiement.
Le cadre suivant a pour objectif d’augmenter vos chances de réussir la restauration au cours d’un événement de récupération d’urgence. Les organisations peuvent adopter ces pratiques pour définir leurs procédures d’exploitation normalisées au sein de leur plan de continuité et de reprise des activités (PC/RA) en cas de sinistre dans le contexte de leur déploiement ArcGIS Enterprise.
Bonnes pratiques pour créer des sauvegardes
Passez en revue les bonnes pratiques suivantes permettant de créer des sauvegardes de votre organisation ArcGIS Enterprise et de toute source de données référencée.
Sauvegarder ArcGIS Enterprise
Une organisation ArcGIS Enterprise est constituée du site Portal for ArcGIS, de tous les sites ArcGIS Server fédérés et des données associées ainsi que des données incluses dans l’instance ArcGIS Data Store. Les composants peuvent être sauvegardés à l’aide de l’outil WebGISDR inclus ou d’outils tiers permettant d’effectuer des sauvegardes basées sur les machines et les images.
L’outil WebGISDR est un utilitaire de ligne de commande inclus avec Portal for ArcGIS qui permet de sauvegarder le contenu et les données de l’organisation, les informations du site ArcGIS Server fédéré et les données contenues dans les data stores relationnels et de cache tuilé. Cet outil est particulièrement utile pour préserver l’uniformité dans les composants d’un déploiement de base, ainsi que dans tous les sites fédérés supplémentaires, même s’il exige un déploiement fonctionnel pour effectuer la récupération.
Il est nécessaire de prendre en compte les éléments suivants en dehors du traitement de sauvegarde WebGIS :
- Sites ArcGIS Mission Server ou ArcGIS Notebook Server fédérés - Si vous possédez l’un de ces sites, créez des sauvegardes en suivant les instructions indiquées dans la documentation ArcGIS Mission Server et la documentation ArcGIS Notebook Server.
- Sauvegardes de Spatiotemporal Big Data Store et de graph stores - Si avez inscrit un Spatiotemporal Big Data Store ou un graph store (ou les deux) auprès de votre serveur d’hébergement, créez des sauvegardes pour chacun d’eux à l’aide de l’utilitaire backupdatastore de ArcGIS Data Store.
- Configuration du site ArcGIS GeoEvent Server - Gérez la sauvegarde de votre configuration ArcGIS GeoEvent Server à l’aide du fichier de configuration de sauvegarde.
Les object stores sont utilisés pour la mise en cache éphémère des réponses aux requêtes des couches d’entités dans la version 11.0, de sorte que les données n’ont pas besoin d’être persistantes dans le cadre d’un scénario de récupération.
La plupart des plateformes de virtualisation autorisent les instantanés sur des machines virtuelles en cours d’exécution répondant à des objectifs de délais de reprise attendus réduits. Bien qu’ils soient utiles, ils ne sont pas considérés comme des sauvegardes durables dans le cadre d’un plan PC/RA plus large.
Lorsque vous effectuez une sauvegarde avant ou durant une fenêtre de maintenance, l’objectif de délais de reprise attendus réduits assuré par les instantanés motive l’utilisation de ces outils lorsqu’ils sont disponibles. Lors d’une sauvegarde de tierce partie, les composants de niveau de données sous-jacents de Portal for ArcGIS et de ArcGIS Data Store ne bénéficient pas d’une intégration avec ces méthodes et impliquent donc un niveau de risque associé à la sauvegarde en direct d’une base de données en cours d’exécution. Pour minimiser ce risque, les instantanés et les sauvegardes basées sur les images doivent être réalisés après arrêt du service pour les composants ArcGIS Enterprise en cours d’exécution.
Dans le cas d’architectures utilisant un partage de fichier pour héberger le répertoire du contenu du portail partagé ou le magasin de configuration et ses répertoires racine pour les sites ArcGIS Server, il est important de tenir compte de la cohérence des sauvegardes de ces emplacements lors de l’utilisation d’outils de sauvegarde tiers tels que les instantanés de machines virtuelles ou les sauvegardes basées sur les images. Si, par exemple, un administrateur effectue une opération d’annulation suite à l’échec de la mise à niveau de Portal for ArcGIS en récupérant un instantané, il se peut que le répertoire du contenu ait été endommagé par le processus de mise à niveau et risque de ne plus être cohérent avec les informations renfermées dans la base de données de l’instance récupérée. Pour limiter ces effets en cas d’utilisation d’outils tiers, les sauvegardes doivent être réalisées pendant une interruption des services au cours de laquelle aucun contenu n’est publié ou mis à jour dans l’organisation. Cela inclut à la fois les composants ArcGIS Enterprise et les partages de fichiers associés éventuels.
L’instance ArcGIS Data Store peut être sauvegardée séparément des autres composants pour réduire la perte de données en cas de panne dans ce composant. L’exécution de sauvegardes planifiées de data stores relationnels et de cache tuilé peut intervenir en dehors de la planification pour l’utilitaire WebGISDR et les autres outils de sauvegarde.
Sauvegarder des sources de données référencées
ArcGIS Server peut proposer du contenu à partir de nombreuses sources dont les enterprise geodatabases, les partages de fichiers inscrits et les stockages sur le Cloud. Ces sources de données externes doivent être incluses dans le plan de récupération d’urgence en vue des déploiements. Il est recommandé de suivre les instructions du fournisseur pour effectuer des sauvegardes ou répliquer les données sur un autre emplacement.
Les enterprise geodatabases qui contiennent les données fournies par les services référencés doivent être sauvegardées conformément à la perte de données maximale admissible de chaque organisation à l’aide des outils mis à disposition par le fournisseur. Ces données étant référencées par les services ArcGIS Server, la cohérence des services publiés peut être désynchronisée par rapport aux tables de bases de données back-end si la récupération de la base de données est effectuée indépendamment des sites contenant les services publiés. Il est donc important d’aligner la planification des sauvegardes de tous les composants dans le déploiement ArcGIS Enterprise.
Les partages de fichiers réseau peuvent utiliser les outils de sauvegarde basées sur des images ou sur des systèmes de fichiers pour empaqueter les données et les transférer vers une solution de stockage durable existant en dehors du domaine d’échec du déploiement.
Les stockages Cloud doivent être sauvegardés ou répliqués sur une autre région pour bénéficier de capacités de récupération et de durabilité supplémentaires. Il est également possible de déployer les stores répliqués via l’archivage ou un stockage longue durée pour en réduire le coût global.
Fréquence de la sauvegarde
La fréquence de la sauvegarde dépend de plusieurs facteurs, le plus important étant la durée de l’opération de sauvegarde. Comme les processus de sauvegarde peuvent impacter l’utilisation des ressources système, les sauvegardes complètes sont généralement planifiées en dehors des heures de bureau normales. Pour des types de sauvegarde différents, la fréquence à laquelle le système est sauvegardé peut varier lors d’un déploiement ArcGIS Enterprise.
Ainsi, il est possible de sauvegarder une enterprise geodatabase de production de manière incrémentielle toutes les 15 minutes pour une faible perte de données maximale admissible. Les données les plus importantes doivent être conservées dans une instance de la base de données afin de réduire les pertes de données potentielles. Pour un déploiement de ArcGIS Enterprise impliquant de nombreux services référencés et du contenu statique, la fréquence à laquelle les sauvegardes sont réalisées peut être quotidienne ou hebdomadaire. En revanche, les déploiements effectuant une utilisation massive des services d’entités hébergés et des créations fréquentes d’applications et de cartes Web, doivent viser un délai plus court entre les sauvegardes.
Valider les sauvegardes
Il convient de superviser les sauvegardes pour s’assurer qu’elles aboutissent correctement et d’alerter les administrateurs en cas d’incident. Pour l’outil WebGISDR, le code de sortie de l’exécution du script peut être utilisé pour déterminer si une sauvegarde a été menée à bien. Un zéro indique une sauvegarde réussie, tout autre code signale un échec. Il est possible d’intégrer plusieurs outils d’alerte pour autoriser les notifications par e-mail ou SMS à l’équipe responsable de l’intégrité de la sauvegarde. De nombreux outils de sauvegarde indépendants assurent la même fonction et peuvent être intégrés avec d’autres services pour émettre des alertes.
Un autre aspect important de la validation du plan PC/RA d’une organisation consiste à exécuter un exercice de restauration à un rythme semi-régulier. Cela aide les administrateurs à s’assurer qu’en cas d’incident, ils sont préparés à restaurer des sauvegardes fonctionnelles et à valider le plan de restauration décrit ci-après.
Combien de temps faut-il conserver les fichiers de sauvegarde ?
La durée de conservation des fichiers de sauvegarde dépend de la quantité d'espace disque disponible dont vous disposez et de la flexibilité dont vous avez besoin pour les options de récupération. Si vous n’avez pas besoin de restaurer une version antérieure à la dernière sauvegarde complète, vous pouvez conserver la dernière sauvegarde complète et les sauvegardes incrémentielles créées depuis.
Les sauvegardes incrémentielles créées avec l’outil WebGISDR se cumulent. Vous pouvez appliquer la sauvegarde incrémentielle la plus récente à la dernière sauvegarde complète. Par conséquent, au minimum, vous devez conserver la dernière sauvegarde complète et la sauvegarde incrémentielle la plus récente effectuée depuis cette sauvegarde complète.
Vous pouvez également déplacer certains jeux de sauvegardes plus anciennes vers un autre endroit, par exemple un support de stockage. Ainsi, si vous découvrez que des données et services clés ont été supprimés avant la dernière sauvegarde complète, les fichiers seront toujours disponibles.
Remarque :
L’utilitaire WebGISDR consigne les versions logicielles des composants ArcGIS Enterprise lorsque vous créez un fichier de sauvegarde. La version du déploiement sur lequel vous effectuez la restauration doit être identique à celle utilisée pour créer la sauvegarde. De plus, vous devez restaurer le même type de système d’exploitation. Par exemple, vous ne pouvez pas créer une sauvegarde d’un déploiement ArcGIS Enterprise sur Linux et le restaurer sur des ordinateurs Windows.Bonnes pratiques pour restaurer une organisation
Passez en revue les bonnes pratiques suivantes permettant de restaurer votre organisation ArcGIS Enterprise à l’aide des sauvegardes que vous avez créées.
Éléments à restaurer
Lorsqu’un administrateur a plusieurs types de sauvegarde à sa disposition, il est possible de restaurer les composants de manière plus granulaire que le rétablissement complet du déploiement. Si le cache d’un service de carte ou d’imagerie est supprimé, seuls ces fichiers doivent être récupérés à partir d’une sauvegarde. De même, si une table est accidentellement supprimée d’une enterprise geodatabase, cette base de données peut être récupérée sans que cela n’affecte les autres composants.
Si des mises à jour incorrectes ont été réalisées sur une couche d’entités hébergée et que des données doivent être rétablies, un administrateur a la possibilité de restaurer uniquement le data store relationnel sans restaurer le déploiement ArcGIS Enterprise entier. Cette opération réduit l’impact que la restauration a sur les autres données conservées dans la base de données. Or, si des services hébergés ont été créés pendant ce laps de temps, le site ArcGIS Server pourrait devenir incohérent par rapport aux tables de bases de données restaurées et implique un nettoyage manuel et une nouvelle publication des services concernés.
D’autres fois, il arrive qu’une panne importante impliquant un centre de données ou une région Cloud nécessite la restauration de l’intégralité du déploiement ArcGIS Enterprise ainsi que des sources de données externes. Il s’agit de l’exemple le plus extrême nécessitant une planification appropriée pour s’assurer de la fonctionnalité complète de l’environnement restauré.
Modalités de la restauration
Lorsqu’un déploiement ArcGIS Enterprise subit une panne générale, il existe plusieurs options de récupération qui dépendent des types de sauvegardes disponibles. La réplication vers un site à proximité à l’aide de l’utilitaire WebGISDR est la méthode la plus efficace pour réduire les délais de récupération du déploiement tandis que le fait de disposer d’un site de secours longue durée pour le redémarrage et la restauration peut faciliter les exercices de récupération et réduire le délai global.
Lors du choix de l’approche de récupération, l’option impliquant la plus petite perte de données maximale admissible ou la durée maximale d’interruption admissible la plus courte doit être envisagée en premier. Elle permet le retour d’informations le plus rapide sur le niveau de réussite de la restauration. La présence d’un administrateur maîtrisant la stratégie de sauvegarde et ayant testé régulièrement des restaurations peut également raccourcir les délais de récupération après un incident.
Comme ArcGIS Enterprise a plusieurs niveaux dans les composants internes et externes, l’ordre dans lequel ces composants sont restaurés a une influence sur la stabilité du déploiement suite à une restauration. Il convient, en premier lieu, de mettre à disposition toutes les sources de données référencées et de vérifier leur accessibilité à partir de l’environnement ArcGIS Enterprise, notamment les instances de bases de données et les partages de fichiers externes, avant de restaurer les machines et composants ArcGIS Enterprise.
Dès que les dépendances environnantes sont en place, le déploiement ArcGIS Enterprise doit être restauré dans un état cohérent. Cette procédure permet d’éviter les scénarios dans lesquels le site du serveur d’hébergement a un service d’entités hébergé publié alors que la table de données dépendantes est absente du data store relationnel ou encore que l’organisation détient un élément pour un service qui n’est plus présent dans l’un des sites fédérés.
Validation post-restauration
Une fois l’opération de restauration terminée, la validation doit être entreprise pour les données stratégiques et les fonctions répandues du déploiement de ArcGIS Enterprise. Elle peut être accomplie à l’aide de listes de contrôle créées pour les centres d’affaires et les départements afin de vérifier leur contenu le plus important ou en mode automatisé via des scripts. La validation par le biais de scripts automatisés renforce la confiance dans la réussite de la restauration en moins de temps qu’une vérification manuelle des éléments et des services.
Automatisation des opérations de sauvegarde et de restauration
Il est recommandé d’effectuer des sauvegardes régulières pour éviter les pertes de données importantes et réduire les temps d’arrêt. La fréquence de création des sauvegardes dépend de l’objectif de point de récupération de l’organisation, qui définit la quantité maximale de données que l’organisation peut accepter de perdre. Par exemple, si l’organisation ne peut pas se permettre de perdre plus de 12 heures de données, vous devez définir un programme dans lequel le délai entre deux sauvegardes est inférieur à 12 heures.
La création et la restauration de sauvegardes peuvent être automatisées dans Linux à l’aide d’une tâche cron ou de tout autre logiciel de planification. Gardez à l’esprit que la quantité de données dans l’organisation a également un impact sur la fréquence de création des sauvegardes et sur la vitesse à laquelle elles peuvent être restaurées. Vous pouvez effectuer des tests avant de configurer une tâche planifiée afin de vérifier que les opérations de sauvegarde ou de restauration ont le temps de se terminer avant qu’une nouvelle tentative soit effectuée.
Vous devez également déterminer si les opérations de sauvegarde ou de restauration réussissent. L’outil WebGISDR prend en charge un fichier en sortie dans lequel les résultats de l’opération sont enregistrés au format JSON. Ce fichier peut être analysé pour déterminer l’emplacement de la sauvegarde, si des composants ont échoué et la durée de l’opération pour chaque composant. Ce fichier peut être intégré dans la logique de sauvegarde et de restauration pour informer les administrateurs d’éventuels échecs ou actions à entreprendre.
Vous avez un commentaire à formuler concernant cette rubrique ?