Frequently asked questions - Azure Backup Monitoring and Reporting

Azure Backup supports multiple alerting options - built-in Azure Monitor alerts, metric alerts, custom log analytics based alerts, custom ARG based alerts, activity log alerts, and classic alerts. If you're currently using classic alerts, we recommend you to start using Azure Monitor based alerts as they provide multiple benefits. Classic alerts will be deprecated and won't be supported in the coming years. Learn more about the different alerting options provided by Azure Backup.

With built-in Azure Monitor alerts, alerts for critical operations/failures generate by default (that you can view in the portal or via non-portal interfaces) at no additional cost. However, to route these alerts to a notification channel (such as email), it incurs a minor cost for notifications beyond the free tier (of 1000 emails per month). Learn more about Azure Monitor pricing.

For custom alerts, in addition to the notification costs described above, there is also a cost per alert rule. The cost of the alert rule varies in proportion to the number of dimensions selected as part of the alert rule. Learn more about Azure Monitor pricing.

With metric alerts, in addition to the notification costs described above, there is also a cost per alert rule. The cost of the alert rule varies in proportion to the number of dimensions selected as part of the alert rule. Learn more about Azure Monitor pricing.

As per backup alerts:

• Alert rule: Refers to a user-created rule that specifies the condition on which an alert should be fired. Learn more
• Alert processing rule (earlier called Action rule): Refers to a user-created rule that specifies the notification channels a particular fired alert should be routed to. You can also use alert processing rules to suppress notifications for a period of time. Learn more
• Action group: Refers to the notification channel (such as email, ITSM endpoint, logic app, webhook, and so on) that a fired alert can be routed to. Learn more

In case of built-in Azure Monitor alerts, as alerts already generate by default, you don't need to create an alert rule. To route these alerts to a notification channel, you should create an alert processing rule and an action group for these alerts. See example

In case of metric alerts, as alerts don't generate by default, you need to first create an alert rule to specify the condition for which an alert should be fired. To route these alerts to a notification channel, you can directly link the alert rule to an action group, or use an alert processing rule. See example

Yes, you can use metric alerts to configure alerts for successful backups. Learn more

If you're using Azure Monitor based alerts, you can configure notifications (Alert processing rules and Action Groups) programmatically. If you're using classic alerts, programmatic creation of notifications isn't supported.

After an event occurs, it might take 20 to 30 mins for data to reach the Log Analytics workspace. As a result, the Log Analytics-based alerts might be slightly delayed. For instant alerts, use built-in Azure Monitor based alerts or metrics based alerts.

Navigate to the Log Analytics Workspace you've configured. Navigate to the Logs menu item, and run the query CoreAzureBackup | take 1. If you see a record being returned, it means data has started flowing into the workspace. The initial data push may take up to 24 hours.

The diagnostic data from the vault is pumped to the Log Analytics workspace with some lag. Every event arrives at the Log Analytics workspace 20 to 30 minutes after it's pushed from the Recovery Services vault. Here are further details about the lag:

• Across all solutions, the backup service's built-in alerts are pushed as soon as they're created. So they usually appear in the Log Analytics workspace after 20 to 30 minutes.
• Across all solutions, on-demand backup jobs and restore jobs are pushed as soon as they finish.
• For all solutions except SQL backup, scheduled backup jobs are pushed as soon as they finish.
• For SQL backup, because log backups can occur every 15 minutes, information for all the completed scheduled backup jobs, including logs, is batched and pushed every 6 hours.
• Across all solutions, other information such as the backup item, policy, recovery points, storage, and so on, is pushed at least once per day.
• A change in the backup configuration (such as changing policy or editing policy) triggers a push of all related backup information.

After you create a Log Analytics Workspace, you can choose to retain data for a maximum of 2 years. By default, a Log Analytics Workspace retains data for 31 days. Learn more.

Data starts flowing in the Log Analytics workspace after you configure diagnostic settings. Data is retained in the workspace from the day of configuration, for the retention period set. The in-progress jobs aren't pushed to the workspace. Events are pushed into the workspace on completion (success/ failure). All the data that is available in the Log Analytics workspace will be available in the reports.

Yes, you can view reports across vaults and subscriptions as well as regions. Your data may reside in a single Log Analytics Workspace or a group of Log Analytics Workspaces.

If you're an Azure Lighthouse user with delegated access to your customers' subscriptions or Log Analytics Workspaces, you can use Backup Reports to view data across all your tenants.

The Azure portal can take up to 15 minutes to reflect the Azure Backup agent job status.

An alert is raised within 20 minutes of the Azure Backup failure.

Yes. In the following situations, notifications aren't sent:

• If notifications are configured hourly, and an alert is raised and resolved within the hour
• When a job is canceled
• If a second backup job fails because the original backup job is in progress

Next steps

Read the other FAQs:

• Common questions about Azure VM backups.
• Common questions about the Azure Backup agent