 Automatic remediation of transient backup failures is key to ensuring that my backup goals are met. In this video, I will walk through how I can seamlessly integrate Azure Backup with different Azure services to automatically retry backup jobs in cases of backup failures. Being able to query all the failed backup jobs and their associated metadata in a scalable manner is a prerequisite for such a scenario. Azure Backup integrates with Azure Resource Graph or ARG to help me efficiently query all backup related information at scale. I can run a query on Azure Resource Graph from either the portal or from any of the other clients such as PowerShell, CLI, SDK or REST API. Here, I'll attempt to run a query in the Azure portal. I navigate to Resource Graph Explorer where I see a query editor. In the past, I would have had to run multiple get commands on each vault individually to get information on backup jobs associated with each vault. On the other hand, Azure Resource Graph allows me to run a simple Kusto query that works across more than hundreds of subscriptions. What's more, if I'm using Azure Lighthouse and have access to subscriptions spread across multiple tenants, I can use Azure Resource Graph to query data across tenants as well. Azure Resource Graph honors RBAC, which means that I can only query those resources for which I have the relevant RBAC rights. Here, I'm running a query to get all the failed backup jobs in Azure VMs in the last 24 hours. I can create my own custom queries to get the fields that I am interested in. The left pane contains a list of all entities that are available for querying along with their schemas. Most of the backup-related metadata such as backup jobs, policies and protected items are available in the Recovery Services Resources table. The resources table contains information on all the top-level Azure resources such as walls, VMs, storage accounts and so on. What's more, I can also perform joins between two different tables. For example, I can query backup VMs from Recovery Services Resources and then join this with the resources table to get more information about each VM such as the VM tags or the OS that the VM is running. Now that I have a scalable way to get the list of all items on which there was a failed backup job, how do I ensure that pretrial of backups is done automatically? Here, I've created a simple Azure Runbook which runs a PowerShell script on a periodic basis. The script runs an ARG query to get information on all VMs that had backup failures in the last 24 hours and then triggers an ad hoc backup job on each of these items. The Runbook is configured to trigger once a day but I can also choose to trigger the Runbook on demand in cases where there is a known Azure outage and I want to run backups as soon as the outage is over. Once I trigger the Runbook, I can see whether it ran successfully and then I can navigate to Backup Center to monitor the status of the in-progress ad hoc backups created by the Runbook. In summary, using automation can help monitor transient issues in the health of backups and remediate these issues at the earliest.