HYCU propose désormais la restauration complète d'une instance Jira

La plupart des administrateurs Jira partent du principe que, si leurs données sont sauvegardées, ils peuvent les récupérer. Cette hypothèse se vérifie pour les éléments individuels. Elle s'effondre rapidement lorsque le problème prend de l'ampleur.

Une suppression en masse qui efface des dizaines de projets. Une migration ratée. Une attaque par ransomware qui met hors service l’ensemble de l’environnement Atlassian. Dans chacune de ces situations, le réflexe est de restaurer à partir d’une sauvegarde. Or, en réalité, la restauration d’une instance Jira n’est pas comparable à celle d’un fichier ou d’une boîte mail, et la plupart des outils de sauvegarde ne sont pas conçus pour la nature même de Jira. 

Jira est une application à plusieurs couches, et non un ensemble de données plat

Pour comprendre pourquoi la restauration est difficile, il est utile de saisir la structure de Jira. Une instance Jira opérationnelle est construite en couches. À la base se trouve la configuration globale : définitions de champs, schémas de workflow, schémas d’autorisations, schémas de types de tickets. Les projets s’appuient sur cette configuration. Les tickets se trouvent au sein des projets. Les liens et références inter-projets viennent couronner le tout.

Chaque objet dans Jira fait référence à d’autres objets par leur ID. Un projet ne contient pas ses propres définitions de champs. Il y fait simplement référence. Une tâche ne contient pas son propre workflow. Elle y fait référence. Ce sont ces identifiants qui assurent la cohésion de l’instance, mais ce sont également eux qui compliquent la restauration.

Pourquoi la restauration granulaire n’est pas suffisante

La plupart des solutions de sauvegarde pour Jira restaurent les objets un par un. Certaines se sont étendues aux restaurations au niveau du projet. Ces deux approches fonctionnent bien pour une restauration ciblée. Elles posent toutefois de sérieux problèmes lorsqu’il faut restaurer l’instance dans son intégralité. Il y a trois raisons à cela. 

1. Le séquencement provoque des dysfonctionnements. Les objets de Jira dépendent les uns des autres selon un ordre strict. Si un projet est restauré avant que sa configuration globale n’existe dans la destination, le projet n’a plus rien à quoi se référer. Ses schémas pointent vers des identifiants qui n’existent pas encore. Il en résulte un projet défectueux. 
2. Les références inter-projets sont perdues. Jira permet aux tickets d’un projet d’être liés à ceux d’un autre. Lorsque les projets sont restaurés indépendamment les uns des autres, ces liens sont rompus car les projets cibles n’existent pas encore, ou existent avec des identifiants différents. Corriger cela manuellement sur des centaines de projets ne constitue pas une solution de récupération viable.
3. La seule alternative fiable ne relève pas du libre-service. Atlassian propose une restauration interne à un instant donné, mais les clients ne peuvent pas la déclencher eux-mêmes. Elle nécessite une demande d’assistance, prend du temps et offre une visibilité limitée sur ce qui a été restauré et ce qui ne l’a pas été. 

Ce qu’implique réellement la restauration complète d’une instance

Pour remettre une instance Jira en état de fonctionnement, il ne suffit pas de disposer des données. Il faut effectuer la restauration dans le bon ordre et rétablir toutes les références entre les objets une fois que tout est en place. Sans cela, vous disposez certes de données, Mais vous ne disposez pas d’un Jira opérationnel.

Les restaurations inter-sites, telles que la reprise après sinistre, le clonage d’environnement ou la migration vers un nouveau tenant, présentent un niveau de complexité supplémentaire. Chaque objet se voit attribuer un nouvel identifiant dans la destination. Le projet qui existait sous un identifiant donné dans la source se retrouve avec un identifiant différent dans la destination. Un schéma qui était référencé d’une certaine manière dans l’instance d’origine est désormais référencé différemment. Sans suivi de ces changements au fur et à mesure de la restauration, les liens inter-projets, les références de champs et les relations ne peuvent pas être reconstitués avec précision. Une restauration qui ne tient pas compte de cela vous fournit les données, mais perd les liens qui les relient. Or, dans Jira, ces liens constituent souvent l’élément le plus important.

Une véritable restauration complète de l’instance doit :

1. Restaurer d’abord la configuration globale afin que tous les schémas, champs et configurations soient en place avant la création de tout projet. 
2. Restaurer tous les projets en veillant à ce que leurs configurations soient correctement reliées à la couche globale. 
3. Suivre l’évolution des identifiants pendant la restauration et s’en servir pour rétablir avec précision toutes les références et relations inter-projets dans la destination.
4. Restaurez les métadonnées inter-projets en dernier, afin que les liens et les relations entre les projets soient rétablis une fois que tous les projets existent et que leurs nouveaux identifiants sont connus. 

HYCU R-Cloud permet désormais la restauration complète d’une instance Jira, sur plusieurs sites

HYCU R-Cloud permet désormais la restauration complète d’une instance Jira. En une seule opération, les administrateurs peuvent restaurer l’intégralité d’un site Jira vers une destination distincte : la configuration globale est d’abord restaurée, tous les projets sont restaurés en parallèle, et chaque lien et relation inter-projets est rétabli avec précision à la fin. 

Il s’agit de la procédure de restauration pour la reprise après sinistre, la migration de locataires et le clonage d’environnements. C’est également ainsi que les équipes maintiennent un environnement Jira parallèle en parité constante avec l’environnement de production. La restauration gère toute la complexité d’un déplacement entre sites, de sorte que le résultat est un Jira opérationnel et prêt à l’emploi sur le nouveau site.

Vos données Jira méritent un véritable plan de reprise

Jira est l’endroit où le travail d’ingénierie est planifié, suivi et livré. Le considérer comme un simple problème de sauvegarde SaaS revient à ignorer le fonctionnement réel de l’application.

Lorsqu’un incident se produit à grande échelle, une simple copie des données ne suffit pas. Vous avez besoin d’un processus de restauration qui comprenne la structure de Jira, restaure les données dans le bon ordre et rétablisse les relations entre les objets. C’est précisément ce que la restauration complète d’une instance Jira dans HYCU R-Cloud est conçue pour offrir.

Prêt à le voir en action ? 

Demandez une démonstration.