Pour les systèmes d’entreprise avec des attentes, des exigences ou des engagements en matière de disponibilité, une approche de sauvegarde et de récupération d’urgence clairement définie, exploitable et bien testée est essentielle. La conception d’une stratégie de sauvegarde ou d’une approche de récupération d’urgence exige que les organisations comprennent d’abord l’étendue et les dépendances de leurs systèmes. Il convient ensuite de définir soigneusement les objectifs de récupération, de connaître les ressources informatiques disponibles et d’envisager le processus de récupération (déclenchement d’une sauvegarde ou d’une restauration, soutien possible du personnel et impacts sur les utilisateurs).
L’importance ou le rôle des sauvegardes sont principalement liés à la criticité métier d’un système, aux processus pris en charge et aux catégories de données qui y sont stockées. Certains systèmes, comme un serveur de développement ou un serveur utilisé par une petite équipe, peuvent ne pas avoir besoin d’une stratégie de sauvegarde, tandis que d’autres systèmes peuvent utiliser des mécanismes de sauvegarde et de récupération d’urgence principalement pour tester les processus et indiquer s’ils ont été appliqués avec succès à un système de production.
Cette section fournit une vue d’ensemble du processus de sauvegarde et de récupération d’urgence. Elle décrit les implications pour les composants logiciels ArcGIS et les options disponibles pour prendre en charge une approche de sauvegarde ou de récupération d’urgence pour diverses applications ArcGIS.
La sauvegarde d’un système, d’une donnée ou d’un composant matériel a toujours été un critère important pour les systèmes informatiques. Alors que, par le passé, les sauvegardes étaient généralement mises en œuvre au niveau du stockage, la prolifération des services Cloud a changé la donne. Outre la nécessité de sauvegarder les données hébergées dans le Cloud et les systèmes SaaS, il est important de rechercher de nouveaux emplacements et fournisseurs pour stocker des sauvegardes au niveau des données.
Les considérations relatives aux sauvegardes exigent que les éléments suivants soient clairement définis :
La méthode utilisée pour restaurer un système à partir d’une sauvegarde, tout comme son impact sur ses utilisateurs, sont également des facteurs importants à prendre en compte.
Historiquement, seuls les systèmes ou les données d’entreprise les plus critiques étaient sauvegardés de manière fiable, de sorte que la portée des sauvegardes se limitait aux systèmes, serveurs ou bases de données les plus importants. Le coût actuel du stockage étant nettement inférieur à celui du passé, la portée des sauvegardes s’est considérablement élargie. Au lieu d’une sauvegarde sélective d’un composant d’application ou d’un type de données, c’est l’ensemble du système qui est aujourd’hui sauvegardé.
Les méthodes utilisées pour créer des sauvegardes peuvent varier considérablement, allant de formats de sauvegarde spécifiques à une application (tels qu’un vidage de base de données binaire ou des images de machine virtuelle), à des sauvegardes de configurations ou des sauvegardes composites (qui peuvent combiner l’état d’une application avec des données et le code de l’application lui-même). Ces méthodes peuvent avoir un impact significatif sur le temps nécessaire à la création d’une sauvegarde, la fréquence à laquelle elle peut être exécutée et la façon dont elle est restaurée. Les sauvegardes peuvent également différer dans la façon dont elles sont créées et dans la façon dont elles capturent l’état d’un système en cours d’exécution. Il existe trois principaux types de sauvegardes à prendre en compte dans les systèmes ArcGIS :
La fréquence à laquelle un système est sauvegardé et l’heure de lancement de ces sauvegardes sont également des considérations importantes. Une sauvegarde trop fréquente peut entraîner des coûts excessifs ou une augmentation des interruptions du système, tandis qu’une sauvegarde trop inhabituelle peut entraîner une perte de données inacceptable (entre le moment où une panne se produit et la sauvegarde la plus récente). La plupart des sauvegardes sont conçues pour éviter d’interrompre autant que possible les utilisateurs dans leur travail, mais le calendrier d’une sauvegarde peut avoir un impact sur les données et les processus capturés lors de la sauvegarde. Habituellement, les sauvegardes sont effectuées pendant les « heures creuses » d’un système (le cas échéant) afin de capturer la plupart des données et des informations de la veille, plutôt qu’en plein milieu d’une journée de travail. Dans ce cas, en effet, la sauvegarde risque de concerner seulement une partie d’un processus ou d’un ensemble de données de grande ampleur.
La raison d’être d’un processus de sauvegarde peut sembler évidente : restaurer l’état d’un système, par exemple, mais il existe d’autres raisons plus subtiles de faire appel aux sauvegardes. Certaines sauvegardes sont liées aux mises à niveau du système. Si une mise à niveau pose un problème, le système peut être ainsi ramené à un état connu. Elles peuvent être motivées également par un changement de système perturbateur, comme la suppression d’un serveur ou l’ajout d’un nouveau composant. Certaines sauvegardes sont créées uniquement pour faire face à un scénario catastrophe et garantir une solution de reprise après sinistre. D’autres sont utilisées pour capturer l’état d’un environnement et créer une nouvelle copie de niveau inférieur, ou faire l’opération inverse, c’est-à-dire aller d’un environnement inférieur vers un système de niveau de production supérieur.
La récupération d’urgence (appelée aussi reprise après sinistre ou DR pour Disaster Recovery) est souvent liée ou confondue avec le processus de sauvegarde et de restauration, mais ces termes ne sont pas synonymes. La récupération d’urgence fait spécifiquement référence à « ce que nous faisons pour nous remettre d’un sinistre », au processus de rétablissement requis et au sens des mots « sinistre » et « récupération » dans un contexte spécifique à l’organisation. Les sinistres désignent généralement des pannes importantes du système informatique, qu’elles soient causées par des problèmes de matériel, d’environnement ou de configuration utilisateur. Ces problèmes peuvent nuire à la disponibilité, au temps de fonctionnement ou à la fonctionnalité d’un système.
L’une des premières choses à faire est de savoir dans quelles circonstances envisager un processus de récupération d’urgence. Il est donc crucial de définir précisément le sens du mot « sinistre », car une définition trop sensible (par exemple, l’échec d’une requête à un système principal) peut entraîner des actions de récupération d’urgence trop fréquentes. Mais attendre qu’une panne dure plus de quatre heures pour la considérer comme un sinistre peut être trop permissif et perturber durablement le travail de l’utilisateur. En fin de compte, la définition de « ce qui constitue un sinistre » afin qu’un système puisse prendre des mesures pour lancer une procédure de récupération ou de basculement, implique une prise de décision à la fois automatisée et gérée par l’homme. La disponibilité, la criticité et le temps de fonctionnement sont également des facteurs importants à prendre en compte. La perte d’accès à un centre de données, une défaillance du stockage, un dysfonctionnement de l’hyperviseur de machine virtuelle (VM), une panne du système de noms de domaine (DNS) ou un problème de connectivité réseau, et même une corruption de données ou une attaque de ransomware sur un système sont autant de raisons différentes pour déclencher une récupération d’urgence.
L’objectif de point de reprise (RPO) et l’objectif de temps de reprise (RTO) de l’organisation sont deux autres critères clés du processus de récupération d’urgence. Le RPO correspond à la quantité de données perdue dans un scénario catastrophe et fait référence au type de sauvegardes créées et à la fréquence à laquelle les données ou les configurations sont sauvegardées. Un RPO de quatre heures signifie qu’au pire, quatre heures de données ou de travail seraient perdues à la suite d’une récupération d’urgence liée à une panne, et que l’organisation est disposée à assumer ce risque. Un RPO relativement bas semble plus pertinent à première vue. Dans la plupart des systèmes cependant, la complexité des sauvegardes et le risque d’interruption des utilisateurs signifient qu’un faible RPO aura un coût trop élevé en termes de ressources, de stockage ou d’impact sur l’utilisateur.
Le RTO désigne le délai au terme duquel nous serons de nouveau opérationnels. Il fait référence au temps nécessaire pour restaurer les sauvegardes d’un système de récupération d’urgence, créer un nouveau système à partir de zéro ou déployer automatiquement des ressources pour se remettre d’un sinistre. Le RTO est souvent inférieur au RPO, car s’il existe déjà un système de basculement ou des composants d’un système de basculement, basculer vers ce système ne nécessite qu’une modification du DNS ou du réseau. La définition et la réalisation d’un RPO et d’un RTO réalistes sont deux éléments importants de l’élaboration d’une stratégie de récupération d’urgence. Il est essentiel, à ce titre, que les parties prenantes se mettent d’accord sur les coûts et les processus liés à la mise en œuvre de cette stratégie.
L’un des moyens de répondre à un scénario catastrophe consiste à rediriger le trafic vers un système de basculement. Celui-ci aura pour fonction de prendre en charge le trafic dès lors qu’un système principal identifie ou rencontre des problèmes. Cette approche a plusieurs exigences importantes qui ont des implications en termes de coûts et de processus :
Une autre approche en matière de récupération d’urgence consiste à utiliser des sauvegardes pour reconstruire un système. Cela risque d’accroître le RTO, mais réduit les dépenses courantes dans la mesure où un système de basculement n’a pas besoin d’être tenu à jour en permanence. Cela peut impliquer d’effectuer, dans un premier temps, des sauvegardes de machine virtuelle ou une sauvegarde au niveau de l’application. Il conviendra, dans un deuxième temps, de reconstruire le système, soit automatiquement par le biais de l’automatisation du déploiement de l’infrastructure en tant que code et du logiciel, soit manuellement avec une équipe expérimentée, avant que la sauvegarde ne soit restaurée, que le trafic ne soit rétabli dans le système et que les utilisateurs puissent reprendre leurs charges de travail.
Les processus de récupération d’urgence peuvent également avoir des implications ou des approches plus larges qui ne sont pas propres au système d’entreprise créé avec ArcGIS. Par exemple, un centre de données peut avoir une stratégie de récupération d’urgence qui tire parti de la réplication de machine virtuelle pour conserver un ensemble de machines virtuelles dans un centre de données distinct. Dès qu’une panne liée à un composant de stockage ou d’hyperviseur est identifiée, tous les utilisateurs peuvent alors basculer sur le centre de données secondaire.
Les processus de récupération d’urgence doivent également tenir compte de ce qui se passe après une reprise. S’il existe un système principal ou un centre de données et qu’un événement de récupération d’urgence entraîne un basculement vers un système secondaire, l’approche standard consiste-t-elle à rediriger le trafic vers les systèmes principaux une fois la panne résolue ? Ou est-ce que le système de secours devient maintenant le système principal et que le système d’origine fait office de système de secours pour la prochaine récupération d’urgence ? Les deux scénarios sont pertinents. Avoir une vision claire de ce qui se passe après la résolution de l’incident est un élément important de la mise en œuvre de la stratégie et de l’approche de récupération d’urgence.
Dans les systèmes ArcGIS, plusieurs approches intégrées au logiciel ArcGIS ont été prévues pour lancer un processus de sauvegarde. Les sauvegardes de type mono-composant, qui s’appliquent uniquement au contenu et à l’état d’une seule application, sont disponibles pour les composants ArcGIS Enterprise, notamment Portal for ArcGIS, ArcGIS Server et ArcGIS Data Store. Ces sauvegardes spécifiques aux composants sont plus destinées aux opérations de sauvegarde et de restauration sur place qu’aux récupérations d’urgence, l’outil WebGISDR étant recommandé pour celles-ci. Chaque composant suit une approche de sauvegarde différente :
Plusieurs rôles ArcGIS Server sont généralement sans état, c’est-à-dire que toutes les configurations pertinentes sont stockées en tant qu’éléments de portail et n’ont généralement pas besoin d’être sauvegardées. Il s’agit, en l’occurrence, de Notebook Server, Business Analyst Enterprise Server (GeoEnrichment Server) et Raster Analytics Server. Chacun de ces composants peut généralement être recréé à partir d’une machine vierge ou d’une image installée au lieu d’avoir à restaurer le déploiement spécifique, car le contenu est stocké dans ArcGIS Enterprise. En plus de cela, il faut également prendre en compte les scénarios impliquant le déploiement de code personnalisé ou de bibliothèques tierces sur le système pour permettre l’exécution d’un processus basé sur Python ou d’un autre processus.
Au-delà de la fonctionnalité de sauvegarde spécifique aux composants, ArcGIS Enterprise propose également un utilitaire de sauvegarde multi-composant appelé Web GIS Disaster Recovery (abrégé en WebGISDR). Cet utilitaire permet de sauvegarder l’état de plusieurs composants ArcGIS Enterprise en même temps.
L’utilitaire WebGISDR est décrit en détail dans la documentation d’ArcGIS Enterprise, mais il est important de noter qu’il privilégie la cohérence et l’état des applications dans leur ensemble, plutôt que la vitesse de sauvegarde ou la souplesse. Cela signifie, en pratique, que l’utilitaire essaie de capturer l’état du système au moment précis où la requête a été exécutée. Si d’autres contenus ou données sont publiés pendant la sauvegarde, ils n’apparaîtront dans aucun des fichiers de sauvegarde et ne pourront pas être restaurés sur un système de basculement. L’utilitaire met l’accent sur le RPO plutôt que sur le RTO, en privilégiant la richesse fonctionnelle d’un système plutôt que la rapidité avec laquelle le système peut être restauré (ce qui peut entraîner des erreurs de configuration ou des données incorrectes).
Au-delà des sauvegardes spécifiques à une application ArcGIS, de nombreuses autres méthodes (propres à un composant ou un fournisseur d’infrastructure) peuvent être suggérées ou préférées par une organisation. Ces méthodes peuvent convenir à un processus de sauvegarde ou de récupération d’urgence ArcGIS, mais elles doivent être évaluées avec soin, car leur utilisation risque également de perturber un système.
Par exemple, les instantanés de machine virtuelle (VM), fréquemment employés dans le cadre d’une sauvegarde d’un système, peuvent présenter des défis complexes si la méthode de création de l’instantané nécessite un redémarrage soudain de la machine ou une capture de l’état des données uniquement. Une capture partielle ou l’échec de la capture des opérations ou des configurations en cours peuvent entraîner un état inattendu et altéré lors de la restauration ou de la récupération.
Les stratégies de sauvegarde basées sur les machines virtuelles (VM) déplacent parfois les ressources VM entre deux sources de données pour éviter une panne. Dans ces scénarios, assurez-vous que les hôtes ArcGIS Server et ArcGIS Pro accèdent à une base de données dans leur propre centre de données et n’envoient pas de requêtes au centre de données d’origine, car cela générerait une latence qui nuirait à l’expérience utilisateur.
Les outils de sauvegarde et de récupération d’urgence basés sur le cloud, tels que Microsoft Azure Site Recovery, peuvent être compatibles avec les systèmes ArcGIS Enterprise à condition de les planifier avec soin. Cela permet de préserver la résolution DNS, la connectivité de la base de données et la connectivité du client au système dans le cas d’une opération de récupération de site. Ces approches de sauvegarde fonctionnent à un niveau d’accès relativement faible pour les machines virtuelles, de sorte qu’elles ne garantissent pas la cohérence des applications. Cela signifie que même si le système de récupération est souvent restauré et exploité avec succès, dans certains cas, des incohérences au niveau de l’application peuvent se produire (processus de publication en cours ou mise à jour d’un service d’entités effectuée pendant le processus de sauvegarde). Il existe des moyens de s’y préparer : en réalisant, par exemple, des instantanés de machines virtuelles pendant les périodes creuses. Les conseils consistant à « planifier, tester et examiner attentivement les implications » restent d’actualité pour ce type d’approche faisant appel à des outils externes.
Les fournisseurs de bases de données qui créent les bases de données relationnelles exploitées par ArcGIS (en tant que géodatabase d’entreprise ou source d’une couche de requête) proposent leurs propres solutions de sauvegarde spécifiques à la base de données. Ces solutions permettent, en principe, de créer une sauvegarde (fichier) du contenu et des configurations de la base de données en vue de sa restauration sur un nouveau système ou déploiement, si nécessaire.
ArcGIS Online, en tant qu’offre et système SaaS, doit être abordé différemment du point de vue de la sauvegarde et de la restauration. Pour garantir la stabilité du système, Esri gère les conditions de sauvegarde et de restauration en cas de panne matérielle et système, sans intervention de l’utilisateur. Le contrat de niveau de service pour ArcGIS Online reflète cet engagement. ArcGIS Online ne propose actuellement pas de méthode permettant aux utilisateurs de créer des sauvegardes de contenu ou des sauvegardes à l’échelle de l’organisation. Les organisations sont donc tenues de définir une stratégie adaptée à leurs propres sauvegardes supplémentaires de contenu ou de configurations dans ArcGIS Online par le biais de divers modèles, notamment :
Notez que les partenaires d’Esri ont également conçu des solutions de sauvegarde qui peuvent être consultées ou achetées via le catalogue ArcGIS Marketplace.
ArcGIS Online a récemment introduit la fonctionnalité Corbeille, qui stocke le contenu supprimé pendant une période de 14 jours (par défaut) avant sa suppression définitive. Le contenu de la corbeille peut être restauré à son état et à son emplacement précédents à l’aide d’un simple processus. Cela évite d’effacer un contenu lié à un autre contenu, mais qui n’est pas clairement identifié comme tel ou comme dépendant de cet autre contenu.
Pour les données de base du service d’entités hébergé, utilisez la fonctionnalité de suivi des modifications pour stocker le contenu des lignes précédentes au fur et à mesure des mises à jour. Ces versions précédentes sont accessibles via l’opération Extraire les modifications.