Foire aux questions – Monitoring et création de rapports avec le service Sauvegarde Azure

Le service Sauvegarde Azure prend en charge plusieurs options d’alerte : alertes Azure Monitor intégrées, alertes liées aux métriques, alertes personnalisées basées sur l’analytique des journaux d’activité, alertes personnalisées basées sur ARG, alertes de journal d’activité et alertes classiques. Si vous utilisez actuellement des alertes classiques, nous vous recommandons de commencer à utiliser des alertes basées sur Azure Monitor, car elles offrent plusieurs avantages. Les alertes classiques seront déconseillées et ne seront plus prises en charge dans les années à venir. Découvrez plus en détail les différentes options d’alerte fournies par le service Sauvegarde Azure.

Avec les alertes Azure Monitor intégrées, des alertes pour les opérations critiques/échecs sont générées par défaut (que vous pouvez afficher dans le portail ou via d’autres interfaces) sans coût supplémentaire. Toutefois, le routage de ces alertes vers un canal de notification (par exemple, une adresse de messagerie) induit un coût mineur pour les notifications au-delà du niveau gratuit (de 1 000 e-mails par mois). En savoir plus sur la tarification Azure Monitor.

Pour les alertes personnalisées, en plus des coûts de notification décrits ci-dessus, il existe également un coût par règle d’alerte. Le coût de la règle d’alerte varie en fonction du nombre de dimensions sélectionnées dans le cadre de la règle d’alerte. En savoir plus sur la tarification Azure Monitor.

Avec les alertes de métriques, en plus des coûts de notification décrits ci-dessus, il existe également un coût par règle d’alerte. Le coût de la règle d’alerte varie en fonction du nombre de dimensions sélectionnées dans le cadre de la règle d’alerte. En savoir plus sur la tarification Azure Monitor.

Pour ce qui est des alertes de sauvegarde :

• Règle d’alerte : fait référence à une règle créée par l’utilisateur qui spécifie la condition sur laquelle une alerte doit être déclenchée. En savoir plus
• Règle de traitement des alertes (ancienne règle d’action) : fait référence à une règle créée par l’utilisateur qui spécifie les canaux de notification vers lesquels une alerte déclenchée particulière doit être routée. Vous pouvez également utiliser des règles de traitement des alertes pour supprimer les notifications pendant une période donnée. En savoir plus
• Groupe d’actions : fait référence au canal de notification (par exemple, une adresse e-mail, un point de terminaison ITSM, une application logique, un webhook, etc.) vers lequel une alerte déclenchée peut être routée. En savoir plus

Dans le cas des alertes Azure Monitor intégrées, comme les alertes sont déjà générées par défaut, vous n’avez pas besoin de créer une règle d’alerte. Pour router ces alertes vers un canal de notification, vous devez créer une règle de traitement des alertes et un groupe d’actions pour ces alertes. Consultez l’exemple

Dans le cas d’alertes de métriques, comme les alertes ne sont pas générées par défaut, vous devez d’abord créer une règle d’alerte pour spécifier la condition pour laquelle une alerte doit être déclenchée. Pour router ces alertes vers un canal de notification, vous pouvez lier directement la règle d’alerte à un groupe d’actions ou utiliser une règle de traitement d’alerte. Consultez l’exemple

Oui, vous pouvez utiliser des alertes de métriques pour configurer des alertes pour les sauvegardes réussies. En savoir plus

Si vous utilisez des alertes basées sur Azure Monitor, vous pouvez configurer des notifications (règles de traitement d’alerte et groupes d’actions) par programmation. Si vous utilisez des alertes classiques, la création de notifications par programmation n’est pas prise en charge.

Une fois qu’un événement s’est produit, il peut s’écouler 20 à 30 minutes pour que les données atteignent l’espace de travail Log Analytics. Ainsi, les alertes basées sur Log Analytics peuvent être légèrement retardées. Pour les alertes instantanées, utilisez les alertes Azure Monitor intégrées ou les alertes basées sur des métriques.

Accédez à l’espace de travail Log Analytics que vous avez configuré. Accédez à l’élément de menu Journaux et exécutez la requête CoreAzureBackup | take 1. Si vous voyez un enregistrement retourné, cela signifie que les données ont commencé à arriver dans l’espace de travail. Le Push de données initial peut prendre jusqu’à 24 heures.

Les données de diagnostic provenant du coffre sont injectées dans l’espace de travail Log Analytics avec un certain décalage. Chaque événement arrive dans l’espace de travail Log Analytics 20 à 30 minutes après son envoi (push) depuis le coffre Recovery Services. Voici plus d’informations sur le décalage :

• Dans toutes les solutions, les alertes intégrées du service de sauvegarde sont envoyées (push) dès qu’elles sont créées. Elles apparaissent donc généralement dans l’espace de travail Log Analytics après 20 à 30 minutes.
• Dans toutes les solutions, les travaux de sauvegarde et les travaux de restauration à la demande sont envoyés (push) dès qu’ils se terminent.
• Pour toutes les solutions, à l’exception de la sauvegarde SQL, les travaux de sauvegarde planifiés sont envoyés (push) dès qu’ils se terminent.
• Pour la sauvegarde SQL, comme des sauvegardes de journal peuvent se produire toutes les 15 minutes, les informations pour tous les travaux de sauvegarde planifiés terminés, y compris les journaux, sont traitées par lot et envoyées (push) toutes les 6 heures.
• Dans toutes les solutions, d’autres informations, comme l’élément de sauvegarde, la stratégie de sauvegarde, les points de récupération de sauvegarde, le stockage de sauvegarde, etc., sont envoyées (push) au moins une fois par jour.
• Une modification dans la configuration de sauvegarde (comme la stratégie de changement ou de modification) déclenche un envoi (push) de toutes les informations de sauvegarde associées.

Une fois que vous avez créé un espace de travail Log Analytics, vous pouvez choisir de conserver les données pendant deux ans au maximum. Par défaut, un espace de travail Log Analytics conserve les données pendant 31 jours. Plus d’informations

Les données commencent à circuler dans l’espace de travail Log Analytics une fois que vous avez configuré les paramètres de diagnostic. Les données sont conservées dans l’espace de travail à partir du jour de la configuration, pour la période de rétention définie. Les travaux en cours d’exécution ne sont pas envoyés (push) vers l’espace de travail. Les événements sont envoyés (push) vers l’espace de travail à la fin de l’opération (succès/échec). Toutes les données disponibles dans l’espace de travail Log Analytics le seront dans les rapports.

Oui, vous pouvez afficher des rapports sur différents coffres et abonnements, ainsi que sur différentes régions. Vos données peuvent résider dans un seul espace de travail Log Analytics, ou dans un groupe d’espaces de travail Log Analytics.

Si vous êtes un utilisateur Azure Lighthouse disposant d’un accès délégué aux abonnements ou aux espaces de travail Log Analytics de vos clients, vous pouvez utiliser les Rapports de sauvegarde pour voir les données de tous vos tenants (locataires).

Une quinzaine de minutes peuvent être nécessaires avant que l’état du travail de l’agent Sauvegarde Azure ne s’affiche dans le portail Azure.

Une alerte est générée dans les 20 minutes qui suivent l’échec de Sauvegarde Azure.

Oui. Dans les cas suivants, les notifications ne sont pas envoyées :

• Si les notifications sont configurées sur une base horaire, et qu’une alerte est déclenchée et résolue dans l’heure
• Si un travail est annulé
• Si un travail de sauvegarde secondaire a échoué, parce que le travail de sauvegarde principal est en cours

Étapes suivantes

Lire les autres forums aux questions :

• Questions courantes sur la sauvegarde des machines virtuelles Azure.
• Questions courantes sur l’agent Sauvegarde Azure.