Understand your Azure backup estate, from protection flow to reviewed change

A protected item exists. Its policy has a sensible name. The vault appears in the inventory.

Before a busy booking period, the reliability team still has a practical question: which part of this protection chain needs attention, and what should we actually change?

Azure Backup supplies the protection capabilities, recovery points, jobs, and vault controls. Azure Resource Graph, Azure Resource Manager, Log Analytics, and Cost Management supply complementary evidence. The challenge at estate scale is bringing that evidence together around an operational decision.

Azure Support Agent's Backup Manager provides that review workflow. Start with a workload, follow an item through its policy and vault, investigate failures, and prepare a supported correction for explicit review. Cost helps explain the estate; recovery objectives help establish priority. Neither replaces understanding what is protected and how recently it was protected.

Our example is Contoso Booking, the capture's label for the built-in Contoso Hotels estate. Follow its legacy property-management VM, contoso-pms-vm, through protection review toward a possible vault-alerting proposal. The synthetic snapshot contains four vaults, four protected items, and one failed job in the 24-hour summary. Investigating that failure remains separate from improving the vault's alerts.

About the examples: Contoso's resources, jobs, and costs are synthetic. The five GIFs use native application components with deterministic browser-local fixtures. Demo writes are disabled; no proposal, approval, apply, or backend workflow was executed. Visible amounts and timestamps are illustrative. Live-operation instructions below are source-grounded procedures, not captured outcomes or performance measurements.

Watch the Backup Manager tour

The faster-paced, approximately 60-second tour visits all ten Manager tabs, including Managed changes, then Fleet and Cleanup. Use it for orientation; the focused animations below show flow controls, job triage, vault posture, DR context, and cost review.

Synthetic native-UI tour with demo writes disabled. The ledger is empty; navigation does not demonstrate proposal submission, approval, execution, or Azure change completion.

Start with one completed analysis

For a live scope, choose the connection and workload or subscription, then select Analyze backups. Ordinary Manager data tabs read the completed snapshot; changing tabs does not start another estate sweep. Built-in demo scopes need no analysis and offer no Analyze button.

That snapshot keeps item, policy, job, and vault views on the same analysis. Read the header's analyzed time alongside the protection percentage.

Azure Resource Graph provides the inventory backbone, including protected items, backup instances, policies, jobs, and Site Recovery information. Supplemental ARM reads inspect vault configuration. Cost Management and retail prices supply different cost inputs; Log Analytics supports longer-horizon reporting when vault diagnostics and access are configured.

Start with Reader-equivalent access to the selected resources and vaults, plus the application's backup_manager.read permission. Actual-spend queries need additional Cost Management access. Backup Reports need a suitable workspace and a service-principal or managed-identity connection; a pasted ARM token cannot query that different Log Analytics audience.

During analysis, inspect the phases and source results. An unreadable job source is different from a completed collection containing no matching jobs. Individual source failures can leave partial results, and per-vault enrichment warnings deserve attention even when the headline status looks reassuring. If every Resource Graph source fails, the previous snapshot is kept rather than replaced with a misleading empty estate.

There is an important scope detail: workload analysis currently collects the backup estate of the workload's member subscriptions. It is not a strict per-datasource membership filter. Match resource IDs before attributing every row, or every charge, to Contoso Booking.

For a broader review, management-group scope resolves visible descendant subscriptions and is analysis-only. Narrow to a workload or subscription before authoring Azure changes, and always inspect each ledger entry's own target and connection.

Read-only Azure analysis can save reports in the application. It does not mean that no local state changes, nor that all later interactions are cache-only: cost-period changes, retention modeling, scope discovery, and mutation preflights can make additional Azure reads.

Follow the protected item through policy and vault

Open Protection flow. The default chain runs from subscription through workload, resource type, policy, vault, and outcome. Add the Item column when the question concerns a particular machine rather than the estate's overall shape. Search by a visible resource, policy, or vault name to narrow the paths.

Trace contoso-pms-vm → its protected item → DefaultPolicy → rsv-demo-legacy.

These are relationships, not interchangeable labels. The source is the resource the team owns. The protected item represents its backup protection. The policy describes the relevant schedule and retention. The vault supplies the protection-management and security context.

Search the native flow, put Vault first, then switch to Cost weighting. These ribbons use synthetic estimates, not billed item charges. The unprotected branch represents detected gaps; verify its underlying rows before acting.

Click a bar or ribbon to highlight its complete paths. Begin with Items weighting: where does protection concentrate, and which policies or vaults are shared? Later, Cost weighting uses allocated actuals when available, otherwise estimates. A wider ribbon is not inherently a worse configuration; it may represent a deliberately shared service.

Use presets or a custom column chain to make the relationship readable. A saved perspective belongs to this browser, not a shared account-wide configuration.

Now open Protection and inspect contoso-pms-vm. Confirm its source, vault, policy, and protection state. Its latest recovery-point timestamp is missing and its age is unknown. The last-backup timestamp accompanies a failed status; it is not a successful recovery point. Verify the latest usable point against the workload's recovery objective.

Flow outcomes are prioritization cues. Their freshness rule uses a fixed 48-hour threshold, while Job inbox and DR use separate reference thresholds. Missing age can also produce an attention outcome. Read the timestamp and applicable objective before interpreting the color.

Keep unknown sources separate from protection gaps

The snapshot also contains retired-app-vm in rsv-demo-regional, flagged orphaned with protection stopped and data retained. That is separate from the failing PMS VM. Before treating the retained item as obsolete, ask whether its source is truly absent or outside the available evidence.

An orphaned item means the source was not found by the lookup. Retained backup data can still exist and incur charges. Source lookup is bounded, and a failed resource sweep disables orphan detection rather than making every item look deleted. Independently confirm important source-absence findings in Azure before making a lifecycle decision.

Unknown source status is therefore not equivalent to an unprotected resource. The former needs identity and visibility investigation; the latter needs a protection decision once the detection is verified. Stopped protection is another distinct state: the team may intentionally retain existing backup data without creating new points.

Gaps brings together detected backup-eligible resources without matched protection and findings ingested from Backup & DR Coverage. Keep their provenance visible. Coverage is the separate reference-based scoring workflow; its current live collector uses best-effort Resource Graph properties and does not collect the deep protected-item, job, restore-test, or Site Recovery pair evidence that its synthetic examples can display. Backup Manager has its own job collection.

That distinction prevents an empty Coverage job field from becoming “this workload has no backup jobs.” Use the Coverage reference to understand the finding, then verify the item and service evidence here or in Azure.

For a confirmed supported gap, select the intended resources, vault, and policy, then preview. Blocked targets explain their constraints, including subscription compatibility. Submission creates pending managed requests, not immediate protection. If arriving from a flow action, recheck the selection: the gap handoff can preselect snapshot gaps beyond the searched ribbon.

For retired-app-vm, assign source and retention verification before any lifecycle decision. Its orphan flag is not permission to discard retained backups.

Work the failure cluster, then verify each item's recovery point

Open Job inbox for the same completed analysis. This is not simply another failed-job list. It groups failures by Azure Backup error code and enriches known codes with a cause and remediation from the editable failure knowledge base.

In our scenario, contoso-pms-vm appears in a guest-agent availability cluster. The relevant code, UserErrorGuestAgentStatusUnavailable, points the reviewer toward the guest agent and backup extension prerequisites. The cluster connects the error to affected items and guidance, giving the platform owner a focused starting point.

Expand the guest-agent failure cluster, then open the contoso-aks protected-item drawer to illustrate detail inspection. That drawer is not the failing VM's recovery-point evidence. No retry, cancellation, guest repair, or backup operation is executed.

The cluster is a grouping of reported errors, not proof that every member shares one verified underlying cause. Read representative job messages and confirm each target. An unclassified code remains an investigation rather than acquiring a confident explanation from its badge.

Then check chronic failures. A recent successful job elsewhere in the vault does not resolve this item's unknown recovery point. Even a success for the same resource needs its operation type checked: configuration work is not the same as producing a usable backup point. For Booking, the handoff should include the source, error, missing recovery-point evidence, expected interval, and owner investigating the guest prerequisites.

Keep the history windows straight. Resource Graph supplies approximately seven days of backup job history, while Overview counters use a trailing 24-hour window. Here the summary shows one failed job; the wider cluster contains three failures for contoso-pms-vm. Job inbox also has display limits and filters. A missing row is not proof a job never ran. Longer-horizon questions belong with properly configured Backup Reports.

After investigating the cause, an authorized operator can draft Back up now where appropriate. That is an on-demand-backup proposal; applying it starts a real backup. Cancellation similarly has an operational effect and is supported for running Recovery Services jobs, not every job type.

Investigate before retrying; the example demonstrates neither repair nor a reduction in incidents.

Review retention without confusing a model with a policy edit

DefaultPolicy in rsv-demo-legacy is the next stop. Policies puts retention, protected-item counts, duplication, unused policies, and below-baseline findings together. The question is whether the policy matches the workload's obligations, not whether its name sounds standard.

Duplicate-looking policies can serve different operational boundaries. A policy with no matched items might be obsolete, intentionally staged, or incompletely observed. Unknown retention is not zero retention. Resolve those questions before consolidating anything.

For a live review, select the intended policy and open Model retention change. If you arrived from Protection flow, confirm the selection: that handoff opens Policies, not an already-selected impact model. Enter a proposed retention period and inspect the direction and recovery-point impact.

This is a read-only model, not a policy submission. Exact enumeration is bounded to a subset of candidate Recovery Services items; remaining items and Backup vault cases use estimates. The dialog distinguishes exact and estimated coverage. Those labels matter more than the apparent precision of a single removed-point total.

For Booking, ask whether the proposed period supports the actual recovery scenario and retention obligations. A shorter policy might look cheaper while removing the older point needed to recover from an error discovered late. Increasing retention does not repair the failed guest prerequisites or retroactively create points that were never produced.

Bring the workload owner and any relevant compliance owner into that decision. Record why a period is appropriate, which items were modeled exactly, and what still needs service-level verification. A model with an unknown starting policy is not ready to authorize a decrease.

The change registry supports policy targets, but the current Policies tab provides modeling, not a general policy-creation or policy-editing form. Arrange an actual edit through a separately reviewed supported workflow. Reversing a retention setting cannot recover points already pruned.

Turn vault posture into a specific control decision

Follow rsv-demo-legacy into Vaults. A vault score helps prioritize review, but the expanded control rows explain what that score represents. Read the values and any enrichment errors before choosing an action.

Azure provides several complementary protections. Soft delete retains eligible deleted backup data for a recovery window. Immutability addresses changes that could remove recovery points prematurely. Multi-user authorization, or MUA, uses Resource Guard to add a separate authorization boundary around protected critical operations. These controls answer different questions; one is not a replacement for the others.

Microsoft's guidance on soft delete and multi-user authorization is the right companion to the review. In particular, Resource Guard authorization is not the same mechanism as approving a request inside Azure Support Agent.

In rsv-demo-legacy, soft delete is Disabled, MUA is None, and built-in backup failure alerts are Disabled. These are known fixture values, not unreadable controls. Review deletion protection and Resource Guard configuration as separate work; the narrow proposal example below addresses only alerts, not the vault's entire posture. In another estate, an unreadable Resource Guard association would mean unknown, not confirmed absence.

Expand the native vault controls, then inspect DR & drills. Soft delete and alerts are disabled; MUA is absent. This capture contains no hardening proposal, ledger handoff, or execution.

The native hardening controls support selected operations such as enabling soft delete, extending its retention, enabling built-in alerts, configuring diagnostics, and eligible storage or Cross Region Restore settings. They do not mean “automatically harden everything.” Unsupported and portal-only controls remain visible as separate work.

Resource Guard configuration, immutability locking, customer-managed keys, and private endpoints stay outside this drawer's automated actions. Redundancy also has lifecycle constraints: an occupied Recovery Services vault cannot simply switch backup redundancy, and Backup vault redundancy is fixed at creation. Cross Region Restore requires geo-redundant storage; enabling that capability is not executing a restore.

Beyond the capture, on a live writable connection, select Enable built-in alerts only and choose Draft hardening changes. Review created and skipped outcomes. Authoring reads and merges the current monitoring settings to preserve surrounding configuration; an unreadable setting prevents that alert proposal. This prepares a pending request, not an improved vault. Apply submits the change; verify its result in Azure. Enabling alerts neither fixes the guest-agent issue nor proves notification delivery.

If long-horizon reporting is also needed, treat diagnostics as another explicit decision with a reviewed workspace destination and ingestion implications. An enabled setting alone does not prove the resource-specific reporting tables contain usable data.

A proposal is not an Azure operation

For an authorized live proposal, Managed changes separates review from execution. Open the resulting alerting request and read its target, connection, operation, reason, and risk. Explain the intent: enable the vault's built-in failure alerts while the workload owner investigates the backup failures. No such request exists in the captured empty ledger.

Drafting the vault request requires backup_manager.vault_write. Approval and apply require backup_manager.approve; execution also needs a writable connection and the relevant Azure rights. An application role cannot manufacture Azure permissions. Autonomous chat does not bypass this managed approval/apply sequence, and a gated connection is recommended. Arrange independent review operationally: requester/approver separation is not generally enforced.

Only Apply to Azure submits the approved operation. Azure Backup operations can be long-running, so an accepted request may remain applying while the server polls it. Closing the browser does not turn it into a failure or abandon its ledger tracking.

Read terminal errors carefully. A tracking timeout does not cancel or reverse the Azure operation; check the actual job before retrying. Updates carrying an expected-state hash can fail when the target changed during review. Backup Manager records that conflict as failed, not a separate stale status, and not every target has the same concurrency check.

For that proposed alerting correction, verification means reading the actual vault configuration, confirming the intended alert setting and preserved surrounding configuration, and running a fresh analysis. Notification behavior needs separate verification. None of these post-apply checks was performed in the synthetic capture.

Rollback is also bounded. Where offered, it creates a new pending inverse for review, approval, apply, and verification. Some updates require a stored before-state. A protection-create inverse can stop protection while retaining data; it is not deletion of the backups.

On-demand backups, job cancellations, Site Recovery tests and their cleanup, new vaults, and diagnostic creates have no general rollback here. Do not assume every control change has an inverse merely because the ledger includes a rollback action.

The manager exposes no Azure backup restore operation or destructive backup-data operation: no backup-data deletion, soft-deleted-item purge, immutability locking, soft-delete disabling, or container unregistration. Those stay in separately controlled Azure procedures. Restoring local history or reference revisions is different, as are Cross Region Restore configuration and Site Recovery test failover.

Protection coverage is not recovery assurance

At this point the Booking team can explain a protection relationship, an execution problem, and a possible alerting correction. It still has not established that the reservation service can recover to its required business state.

Recovery point objective, or RPO, concerns tolerable data loss expressed in time. A recent point helps assess that objective. Recovery time objective, or RTO, concerns restoring the service within the required time. That involves application dependencies, access, procedures, validation, and people, not just a backup timestamp.

Backup Manager's RPO assessment uses the editable reference tiers. Those are assessment inputs, not Azure settings. Missing point ages remain evidence gaps, and an apparently perfect percentage over an empty eligible set is not recovery proof. Likewise, a protection percentage describes the detector's eligible resources, not every dependency necessary to serve bookings.

DR & drills adds Site Recovery health, RPO context, and the drill register. A healthy replica and a recently exercised recovery procedure answer different questions. Follow Azure Site Recovery guidance for the applicable replication and test workflow.

Schedule drill creates an application register entry. It does not schedule or execute an Azure restore. A team performs an authorized rehearsal outside Backup Manager, reviews the result, and then records Passed or Failed with evidence. Recording an outcome is an immediate local governance action, not a pending Azure proposal. Never mark an unperformed exercise passed.

Actual Site Recovery test failover is a different supported workflow. Its request requires two distinct approvers and individual approval; that target-specific rule is not universal for every high-risk action. The UI defaults the test to NoNetwork. Applying it creates billable test resources, and later cleanup requires a separate reviewed request.

Neither workflow was executed here. Assign Booking's recovery exercise and establish its evidence requirements before changing the register; configuration review cannot stand in for that exercise.

Read cost as measured, estimated, and apportioned evidence

Now return to the same vault in Cost & waste. This is a supporting lens on the protection decision, not a separate hunt for the smallest bill. A retained item, a shared vault, and a policy obligation need operational explanation before a cost recommendation is useful.

The default period is the last complete month. Begin with the period, currency, and source status, then distinguish three kinds of input:

• Reported actual spend: Cost Management supplies charges associated with the vault for the selected period and cost basis. This is the financial anchor when available.
• Measured consumption: Backup Reports can provide consumption data used to weight an allocation. A measured quantity is not itself a directly metered item charge.
• Estimated cost: Retail list prices and footprint assumptions model a monthly amount. They are planning inputs, not an invoice or a promised future charge.

The per-item view adds a fourth label that connects those inputs: apportioned actuals. Backup Manager takes vault-level spend and allocates it across protected items, using measured consumption when available, then estimated cost, then equal shares. Each row identifies the basis. The allocated figures reconcile to the vault total; reconciliation does not turn them into independently billed item records.

Review seeded list-price estimates and unavailable actuals, then move to Policies. Demo mode does not query Azure Cost Management; no measured consumption or apportioned actuals are shown. This is policy review, not a retention-change demonstration.

On a live scope with actuals available, inspect the meter breakdown and per-item allocation basis before attributing vault spend to a resource. Check the analysis scope: workload collection can include other resources in its member subscriptions. rsv-demo-legacy itself protects just one item in this fixture.

An absent actual-spend value is not zero spend. Read whether access, period coverage, or another source limitation prevented the result. Unattributed charges remain visible rather than being silently spread over convenient rows. Mixed currencies are kept separate, and partial periods are not used for a misleading estimate-versus-actual variance.

Similarly, the estimate assumes a full month at the current footprint. A vault populated during the month can legitimately differ from that model. Some protection mechanisms have costs outside the Backup service meters: Azure Disk Backup's snapshot billing is an important example. An unpriced or flagged zero is a reason to inspect the relevant service charges, not declare it free.

Recoverable waste prioritizes review candidates using actual spend when available and list prices otherwise. A stopped or apparently orphaned item may still be intentionally retained. Confirm ownership, source status, and obligations before proposing anything. The Cleanup view discussed below does not remove those Azure backups.

Keep the cost basis attached to the review. Savings would require an authorized change and a comparable billing review afterward; none is claimed here.

Use Fleet to choose the next review

The Manager · Fleet · Cleanup strip separates different levels of work. Manager investigates the selected scope. Fleet compares workloads using their stored analysis summaries. Opening that grid does not query Azure; selecting Analyze selected deliberately starts collection. Demo workloads cannot be launched.

For a reliability lead, the useful first sort is often the default worst-first order: workloads never analyzed, then gaps, protection percentage, and failing jobs. An unmeasured workload is an unknown needing attention, not automatically the least protected application.

Read Last analysis alongside every score. A freshly reviewed row should not be casually compared with a stale row collected before another workload's migration. The Fleet cost column is Est. cost / mo, even when the underlying analysis also collected actual spend. Open the workload's Cost & waste view for that distinction.

Selected workloads run through a server-owned durable batch, with two Backup Manager analyses admitted at a time. The queued work does not depend on an open browser. Return to inspect phases and outcomes; use the batch summary to distinguish failed, partial, and cancelled items.

Cancel pending removes queued work, not completed results or already-submitted Azure operations. Retry failed includes failed, partial, and cancelled batch outcomes. Check the reason before launching more work, and avoid overlapping Fleet and single-scope analyses under the assumption that they share one job record.

Fleet is workload-based. Subscription and management-group reviews remain individual Manager analyses. Use the grid to select the next evidence review, not to turn a stored score into a claim about the estate's current recoverability.

Keep review evidence without confusing Cleanup with backup deletion

The Booking review should leave something another operator can understand. Excel review pack exports the last completed snapshot: source context and limitations, protected items, jobs, policies, posture, gaps, DR, and cost. Downloading it does not start a new Azure collection.

Read Coverage & limitations before interpreting blank sheets or totals. During another analysis, the workbook still exports the previous completed result. Managed changes and drills are live application ledgers with a separate read timestamp; their connection-wide entries are not necessarily limited to the analyzed workload. Review identifiers before sharing the file.

Do not assume an applied request automatically created Evidence Locker evidence. Current apply tracking does not do that. Preserve the completed snapshot explicitly when required, and use actual exercise evidence for drill outcomes rather than a dashboard image.

Cleanup manages application storage. Its stored analyses are the reports used by the tabs; its analysis history contains compact records of earlier results. An orphaned stored analysis can refer to a deleted workload, removed connection, or obsolete report shape. That is unrelated to an orphaned protected item in Azure.

Purging a stored analysis also removes its Fleet summary, and the scope needs analysis again. History supports restorable trash and permanent purge. Permanent deletion requires the approve permission, but it is an immediate local operation, not an Azure change awaiting ledger approval.

Nothing here deletes backup data or modifies Azure protection. Audit records and Evidence Locker snapshots have independent retention. Treat Cleanup as report lifecycle management, with its own governance consequences, rather than a button for realizing the Cost & waste estimate.

How it's judged

A successful Backup Manager review is an explanation that survives a handoff. For Contoso Booking, the questions are concrete:

• Can we trace the item? The source, protected item, policy, vault, and recovery-point evidence agree, with the connection and analysis time preserved.
• Can we explain the concern? The failed-job cluster leads to specific source evidence; unknown sources and unreadable controls remain distinct from confirmed gaps.
• Can we justify the action? The built-in-alerts proposal has an explicit purpose, target, owner, and permission boundary. It is not described as fixing the underlying backup failure.
• Can we distinguish decisions from outcomes? Pending, approved, applying, and terminal states remain separate, with Azure readback required after an actual apply.
• Can we state what remains unproven? Recovery assurance, notification behavior, and any financial benefit need evidence beyond the configuration and synthetic examples.

Keep a compact review note with the item identity, policy, vault, latest verified point or explicit unknown, failure investigation, control decision, and next responsible owner. Attach the cost basis if it influenced the decision. Record unavailable sources and the plan to resolve them alongside completed checks; uncertainty should not disappear when the meeting ends.

Revisit that note after policy, workload, or ownership changes and exercises. Compare the same scope and source visibility before claiming that a better headline score means better protection.

Try it read-first

Start with a narrow exercise that ends before any operational change:

1. Open Backup Manager in Azure Support Agent with an appropriately scoped read-only Azure connection. Choose one workload or subscription and inspect or explicitly refresh its analysis.
2. Trace one protected item through Protection flow, then confirm its source, policy, vault, and latest recovery point in Protection.
3. Inspect a related job cluster or an unavailable-source case. Record the evidence window and the difference between an observed failure and missing information.
4. Expand the vault's controls. Identify one supported proposal candidate and any separate portal-only work, without submitting a change or recording a drill outcome.
5. Check the cost basis and write a short review note. Stop before backup, test, cancellation, apply, reference edits, or Cleanup actions unless those are separately authorized.

The Backup Manager reference and operations guide cover permissions, supported workflows, source limitations, and verification in detail.

Azure Support Agent is open source on GitHub. Explore the project, contribute feedback, and review the installation guide before deploying. Hosting and connected Azure or model services can incur charges; self-hosting does not remove those costs or configured external-service data flows.

Start with a protection chain you can explain. The next step may be a reviewed change or a better question, not an unsupported recovery claim.