Identifier les cas de non-respect du forfait de sauvegarde dans la console de gestion de l'appliance

Les modèles de règles et les profils de ressources sont définis dans la section "Plans de sauvegarde" de la console de gestion de l'appliance. Elles s'appliquent aux applications et aux VM dans App Manager. Un cas de non-respect du plan de sauvegarde se produit lorsqu'un job (ou une action) ne répond pas aux exigences définies par une règle dans un modèle de règle.

Cette section décrit en détail les causes potentielles d'un non-respect du plan de sauvegarde, la façon dont la console de gestion des appliances identifie un non-respect du plan de sauvegarde et les méthodes que vous pouvez utiliser pour surveiller les non-respects du plan de sauvegarde lorsqu'ils se produisent. Par exemple :

Causes potentielles de non-respect des règles concernant les plans de sauvegarde

La console de gestion des appliances applique des plans de sauvegarde aux applications et aux ensembles de données. La gestion des données de copie de votre application dans le service Gestionnaire d'applications est basée sur les règles que vous définissez dans un modèle de sauvegarde et ses règles associées. Un modèle de sauvegarde inclut une ou plusieurs règles qui définissent la source des données (instantané ou réplication) et la planification (fréquence, durée de conservation, heure de début, heure de fin) pour chaque source de données. Un non-respect du plan de sauvegarde se produit lorsque le job (ou l'action) défini par une règle de plan de sauvegarde ne démarre pas selon le calendrier de la règle.

Chaque appliance de sauvegarde/récupération exécute automatiquement une analyse du plan de sauvegarde toutes les heures pour identifier les cas de non-respect du plan de sauvegarde au fur et à mesure qu'ils se produisent au cours de la journée pour les jobs planifiés. Cette opération en arrière-plan vous alerte sur les éventuels non-respects du plan de sauvegarde le plus près possible de la fin de la période de la règle du plan de sauvegarde. Pour en savoir plus, consultez Comment un dispositif de sauvegarde/restauration surveille les non-respects du plan de sauvegarde.

La console de gestion des appliances permet à ses administrateurs de créer une bibliothèque de modèles de règles. L'une des principales caractéristiques de chaque règle de plan de sauvegarde est le calendrier qui détermine quand cette règle sera exécutée.

Les cas de non-respect du plan de sauvegarde sont souvent considérés comme provenant de problèmes liés aux paramètres du nombre d'emplacements de job. Le nombre d'emplacements détermine le nombre de jobs pouvant être exécutés simultanément. Toutefois, l'augmentation du nombre d'emplacements de job ne garantit pas la fin des cas de non-respect du plan de sauvegarde. En réalité, un non-respect du plan de sauvegarde peut être lié à l'une des conditions décrites dans les sections suivantes.

Jobs ayant échoué

Les échecs de jobs sont une cause fréquente de non-respect des plans de sauvegarde. Par exemple, si un hôte Oracle n'est pas accessible, l'appliance de sauvegarde/récupération ne peut pas capturer les données d'Oracle RMAN, ce qui entraîne l'échec du job de snapshot. Lorsqu'un job échoue, vérifiez votre environnement pour confirmer que toutes les applications et tous les hôtes sont accessibles.

Plusieurs applications par hôte

Si un hôte comporte plusieurs applications et que chacune d'elles est gérée par un modèle de stratégie distinct (plutôt que regroupées dans un groupe de cohérence), une seule application peut exécuter un job de snapshot à la fois, même si des emplacements libres sont disponibles.

Si une VM est gérée en tant que VM et que des applications sont également gérées via l'agent Backup and DR, une seule des applications peut exécuter un job de capture de données à la fois.

Si un hôte possède des lecteurs D:\, E:\ et F:\, et que les lecteurs individuels sont gérés par des modèles de sauvegarde distincts, chaque lecteur sera géré en série. Par exemple, si la période d'exécution autorisée pour la règle est de 01h00 (UTC) à 03h00 (UTC) et que le premier lecteur met trois heures à effectuer son job de snapshot, les deux autres lecteurs ne recevront pas de job de snapshot ce jour-là.

Une solution possible consiste à étendre la période de validité de la règle du forfait de sauvegarde afin d'étendre la durée d'exécution totale. Une autre solution consiste à inclure plusieurs applications dans un groupe de cohérence.

Les cas de non-respect du forfait de sauvegarde peuvent être des faux positifs

Dans certains cas, un non-respect du forfait de sauvegarde est en fait un faux positif (un résultat qui indique à tort qu'une condition particulière est présente). Gardez à l'esprit que tous les cas de non-respect du règlement sur les plans de sauvegarde n'en sont pas réellement. Il est possible de recevoir de faux positifs, comme illustré dans les deux exemples suivants :

  • Vous gérez les données de copie d'une VM qui possède un volume en cluster. Si la règle du plan de sauvegarde est en cours d'exécution, mais que la VM n'a pas le contrôle du volume, cet échec est considéré comme une violation du plan de sauvegarde.
  • Si le planificateur basé sur un plan de sauvegarde est désactivé pour un job (par exemple, une VM ou une application), cela peut entraîner une violation du plan de sauvegarde chaque fois que la règle du plan de sauvegarde doit être appliquée.

Ressources limitées dans l'appliance de sauvegarde/récupération

Les ressources limitées dans un dispositif de sauvegarde/récupération peuvent être liées à des problèmes tels que le débit des ports réseau, le nombre maximal d'initiateurs iSCSI, la capacité de débit du stockage de backend ou du stockage de frontend. Dans ce cas, augmenter le nombre d'emplacements ne vous aidera pas.

Taille de la fenêtre de stratégie ou durée d'exécution du job

Les jobs qui s'exécutent pendant de nombreuses heures occupent des emplacements de job qui pourraient être utilisés par d'autres applications. Si chaque application termine son job en une minute en moyenne et que vous disposez de cinq emplacements, vous pouvez exécuter 300 jobs par heure. Si chaque application prend une heure en moyenne et que vous disposez de cinq emplacements, vous pouvez exécuter cinq jobs par heure. Toutefois, si la fenêtre totale de la règle est de trois heures, le nombre d'applications qui tentent d'utiliser cette règle de plan de sauvegarde aura un impact considérable sur la gestion totale des données de copie d'application possible sur une période de 24 heures.

Par exemple, s'il y a 100 applications, l'appliance terminera toutes les applications en 20 minutes environ dans le premier exemple (300 jobs par heure). Toutefois, si nous avons 100 applications dans le deuxième exemple (cinq tâches par heure), l'appliance ne gérera que 15 applications par jour. Cela entraînera 85 cas de non-respect du plan de sauvegarde.

Bien que vous ne puissiez pas contrôler la durée d'exécution des jobs, vous pouvez examiner la durée pendant laquelle les applications en cours d'exécution sont planifiées. Des durées de job longues peuvent également se produire lors du premier job d'instantané pour une nouvelle application. Les paramètres d'intégration peuvent être utilisés pour empêcher les jobs d'ingestion de bloquer des emplacements et d'empêcher l'accès aux applications déjà ingérées.

Comment un appareil de sauvegarde/restauration surveille les cas de non-respect du plan de sauvegarde

Chaque appliance de sauvegarde/récupération exécute automatiquement une analyse du plan de sauvegarde toutes les heures pour identifier les cas de non-respect du plan de sauvegarde au fur et à mesure qu'ils se produisent au cours de la journée pour les jobs planifiés. Cette opération en arrière-plan vous alerte sur les éventuels non-respects du plan de sauvegarde le plus près possible de la fin de la période de la règle du plan de sauvegarde.

Lors de l'analyse, l'appliance recherche toutes les règles de plans de sauvegarde dont les heures de travail se sont terminées au cours de la dernière heure. Chaque règle est examinée pour détecter les cas de non-respect des règles du plan de sauvegarde. Si une règle de plan de sauvegarde présente un cas de non-respect dans les 60 minutes suivant la fin de la période de la règle, une entrée est ajoutée à la base de données des événements pour ces cas de non-respect. Si une règle ne présente pas de non-respect du plan de sauvegarde, aucune alerte ni aucun événement ne sont générés.

Lorsqu'une violation du plan de sauvegarde se produit dans le délai de 60 minutes prévu par le règlement, une alerte est déclenchée et une notification d'événement est générée. Vous pouvez recevoir des alertes de non-respect du forfait de sauvegarde sous forme d'événements System Monitor (voir Surveiller) ou de notifications d'événements par e-mail. Chaque alerte inclut des informations sur chaque règle du forfait de sauvegarde qui n'est pas respectée pour une application spécifique, y compris le message d'événement, le nom et le type de la règle, l'heure et le type de non-respect, ainsi que des informations sur le job (jobs attendus, tolérance, réussis, échec). Les alertes de non-respect des plans de sauvegarde contiennent le même niveau de détail que les rapports de non-respect des plans de sauvegarde inclus dans les rapports de conformité des plans de sauvegarde du Gestionnaire de rapports.

Un journal du serveur de plate-forme (fichier journal udppm) est également créé pour indiquer quand l'analyse a été exécutée, quelles règles ont été analysées et quel a été le résultat de l'analyse.

L'analyse du plan de sauvegarde tient compte des écarts qui peuvent résulter de jobs en cours. Dans certaines circonstances, un job commence dans le délai de début autorisé par le règlement, mais peut durer plus longtemps que prévu et ne pas se terminer dans le délai spécifié par le règlement (par exemple, un job commence à 22h et se termine à 23h30). Au départ, le job est considéré comme réussi et ne génère pas d'alerte de non-respect du plan de sauvegarde. Toutefois, une fois le job terminé, il est réévalué lors du prochain cycle d'analyse du plan de sauvegarde et peut être signalé comme non conforme. La réussite ou l'échec d'une règle de plan de sauvegarde dépend du moment où un job se termine réellement.

Si, lors de l'analyse, l'appliance détermine qu'une ou plusieurs tâches d'une règle de plan de sauvegarde n'ont pas été exécutées, une violation du plan de sauvegarde se produit et l'alerte ou l'événement généré contient les informations supplémentaires suivantes concernant la tâche ayant échoué :

  • Durée d'exécution du job prévue
  • Motif de l'échec de l'exécution du job

L'appliance examine également le calendrier pour déterminer si aucun job n'a été exécuté, car aucun emplacement n'était disponible pour ce type de job. Si tel est le cas, l'alerte ou l'événement incluent cette information.

Si l'application comporte plusieurs règles de forfait de sauvegarde dont les fenêtres de règles se chevauchent et qu'une tâche est manquée pour les deux règles pendant cette période de chevauchement, l'appliance ne génère qu'une seule alerte. Il n'initiera pas d'alertes en double pour les règles qui se chevauchent afin d'éliminer les doublons. Les alertes de jobs manquées sont agrégées par application, type de règle et période.

Surveiller les cas de non-respect des plans de sauvegarde

Vous pouvez surveiller et afficher les cas de non-respect du plan de sauvegarde depuis l'onglet Surveillance ou depuis une appliance gérée via des notifications par e-mail ou à l'aide du Gestionnaire de rapports.

Surveillance

Vous pouvez consulter les détails d'un non-respect du forfait de sauvegarde en tant qu'événement dans l'onglet Surveillance (Surveillance > Événements). Pour en savoir plus sur l'onglet Surveillance, consultez Surveillance.

Administrateur des rapports

Une bibliothèque complète de rapports sur les cas de non-respect des forfaits de sauvegarde est disponible dans le gestionnaire de rapports de la console de gestion des appliances. Ces rapports peuvent vous aider à simplifier la façon dont vous confirmez le taux de réussite actuel et à distinguer plus facilement plusieurs applications portant le même nom.

Étapes suivantes