Review Azure VM backup coverage and restore-test evidence
Compare approved data locations with backup status and recorded restore tests.
Tools for the documented steps
Practice relevance
Cross-practice idea · A general operational method. Review the stated tool and jurisdiction limits before use.
The problem
Compare approved data locations with backup status and recorded restore tests.
Why it matters: A successful backup job does not prove that all required data can be restored. Separating coverage, job status and restore-test evidence helps IT see what remains unproven before a recovery is needed.
Sources & evidence
Proposed / not tested. The public source describes the problem. Documentation supports only the stated method components; no result from this recipe has been verified.
What’s been verified
Source methods and reported problems have been reviewed. We have not run the adapted workflow. The sample below describes expected behavior on synthetic data, not a customer result.
What to measure: In a synthetic pilot, count correctly found exceptions, false alarms, and unresolved inputs. No time or cost saving is assumed.
- Pain evidence: File backup ↗File backup, 2026-01-26, older: a lawyer planning a solo practice asks how to cover both practice-management cloud data and local desktop files without juggling multiple systems. Small-firm storage discussion, 2024-06-26, describes an eight-lawyer firm's roughly 2.5 TB store and backup-upgrade difficulty.
- Pain evidence: Small-firm storage discussion ↗Additional self-reported public account; no independent identity or outcome verification.
- Method: Microsoft 365 Backup reports ↗Microsoft 365 Backup reports documents current enrollment-status reporting. Restore-point-availability and storage-consumption reports are marked coming soon, so this recipe does not rely on them. Azure Backup monitoring documents job-status monitoring for already-configured Azure workloads; it does not establish coverage of unrelated SaaS.
- Method: Azure Backup monitoring ↗Additional official capability reference. The complete adapted recipe has not been tested.
Source checked: October 15, 2026. Pain accounts are self-reported. Documentation supports components; this adapted recipe and prompt have not been tested. We wrote these prompts. The adapted workflow hasn’t been tested.
Suggested approach
Start when: Monthly IT review or new data system
- compare approved data-location inventory with existing backup-job evidence and actual restore-drill records
- Keep source references and report unknowns instead of filling gaps.
- The responsible reviewer checks the report before any separately approved action.
Limits and review
The assistant drafts or reports only. Check source records and review the output before a human performs any separately approved send or change. No automatic legal decision, money movement, account connection or publication is included.
Who reviews it: IT verifies coverage and recovery tests; test a system absent from all jobs and a green job with no restore drill. Security configuration, purchases, retention changes and restorations remain separate authorized actions.
What you need
Your firm-approved AI assistant · prepared files
- Bounded implementation: Azure VMs already protected by Azure Backup in identified Recovery Services vaults, with existing Backup Reader or equivalent read access.
- Independent IT inventory of data locations, approved recovery objectives/freshness thresholds and actual restore-drill evidence. Other backup products need their own verified collection route.
- Firm-approved Excel; optional Copilot entitlement and tenant approval for the exact minimized data. Native Excel analysis can be done manually if Copilot is absent.
- Keep raw exports and identifying source pointers in a separate restricted location. The AI workbook contains only approved alias-based tables and visible policy/scope text, never raw client records on another tab.
- Use synthetic inputs first. Keep real data in firm-approved accounts and processing, with appropriate access, confidentiality and retention controls. Aliases alone do not anonymize records. Never paste credentials, API keys or unnecessary client details.
How to use
Documentation-checked Azure Backup VM route; other products require separate acquisition verification
- This route covers selected Azure Backup VM evidence only, not Microsoft 365/SaaS or every firm data location. Unacquired systems stay unknown.
- A completed job or available restore point does not prove recoverability. An actual authorized restore test with validated result is required for restore evidence; this recipe does not run one.
- The cited guide does not support exporting jobs with a filter applied. An unfiltered export is used only if available and its actual time/status coverage is checked; otherwise staff manually capture the bounded filtered view. Missing history remains unknown.
Check access and setup
- Actual account access, plan and source-data completeness have not been tested.
Inspect protected VM coverage
Azure portal / Azure Backup · All services > Recovery Services vaults > selected vault > Backup Items > Azure Virtual Machine
Open each in-scope vault and inspect the protected VM list, last backup status and latest restore point time. Record the actual VM/resource identity, policy scope and visible protection/exclusion facts. Compare with the independently maintained IT resource list; do not infer all data locations are covered by a VM backup.
- Expected output
- Manually captured protected-resource observations with vault/time/source reference.
- Next step
- Prepare the data-location-to-protection mapping, keeping missing or unverified systems visible.
- Check before continuing
- Do not change policies, trigger backup/restore, stop protection or delete data.
Collect job history with an explicit coverage check
Azure portal / Azure Backup · Selected Recovery Services vault > Backup Jobs > Export jobs (unfiltered, if available); bounded manual fallback: Backup Jobs > Filter > Done
Open Backup Jobs without applying a custom filter. If Export jobs is available and succeeds, preserve its native spreadsheet with summary and per-job sheets; inspect the actual date/status coverage rather than assuming the requested period was exported. The official guide warns that filtered export is unsupported. For missing or unavailable exported scope, use Filter to choose the approved item type, operations, all required statuses and start/end period, then Done, and manually transcribe the resulting rows/details with visible job/resource identities, status, timestamps and source references. Record the exact filter, captured row count, capture time and any pagination, unreadable details or omitted periods. The default view covers 24 hours, which may be insufficient. Separately read the existing restore-drill records and actual validation outcomes. Do not configure Log Analytics or another integration to obtain data.
- Expected output
- Actual unfiltered native jobs spreadsheet where available, plus a bounded manual job log for verified additional scope and independent restore-drill records; a coverage note lists every unacquired period/status.
- Next step
- Keep raw reports restricted and map only verified metadata.
- Check before continuing
- Do not promise a filtered export or full historical coverage. A restore operation marked Completed alone is not a validated recovery test. Missing or unobserved job periods are unknown, not proof of no jobs.
Map the observed records to the starter input
Excel and authorized staff · Separate analysis workbook > Home > Format as Table
Populate data-locations.csv from the independent IT inventory and approved objectives. Map backup-status.csv to actual system_id/job_id,coverage_status,last_success_utc,job_status,exclusions,evidence_timestamp,source_ref. If job completion time/ID is not observable, keep it unknown and retain a source-row reference; do not substitute restore-point time for job completion. Populate restore-drills.csv only from actual test records with system_id,drill_date,result,evidence_ref. Paste scope.txt, cutoff, mapping and unsupported products into Scope. Create named tables for DataLocations, BackupStatus and RestoreDrills. Put the policy and review scope in visible worksheets or paste them into the next prompt. Record whether each observation came from the actual unfiltered export or manual filtered-view capture, and paste the coverage note into Scope. Do not fill gaps with presumed successful jobs.
- Expected output
- DataLocations, BackupStatus and RestoreDrills with explicit unacquired systems.
- Next step
- Check the mapping against each original source before using AI.
- Check before continuing
- Aliases and missing policy fields are staff-created; do not relabel a native export as the kit schema. Unknown stays blank/unknown, not false or zero.
Review the bounded evidence with Copilot
Excel Copilot, optional · Approved analysis workbook > Copilot icon at lower right > Chat only
Use Chat only and submit the prompt. Without Copilot: join the inventory to observed coverage/jobs, then check actual restore-test records against approved review dates.
- Expected output
- IT backup-evidence gap list.
- Next step
- Copy the draft exception list to the reviewer; retain row references.
- Check before continuing
- Check every flagged row and the scope. A fluent answer is not evidence of completeness; no automatic workbook or source-system edits.
Approve the review result
Final human reviewResponsible staff reviewer · Reviewed local worksheet
IT validates the scope and every gap, especially data locations outside the selected Azure VMs. Any new backup setup or recovery drill is planned and authorized separately.
- Expected output
- Reviewed coverage and restore-evidence questions.
- Next step
- Any external message, source change, payment or deletion requires its own authorized process.
- Check before continuing
- No all-clear is possible while required systems, job history or validated restore evidence are missing.
What you’ll get
backup-review.csv: system_id, coverage_gap, job_status, last_success_utc, restore_evidence, review_due, source_refs, uncertainty, IT_question. No backup or restore is performed.
Inputs and a sample test Synthetic example · not a measured result
Input files
- data-locations.csv: system_id, owner_alias, data_class, location_alias, approved_recovery_objective, approved_job_freshness_hours, approved_restore_review_date
- backup-status.csv: system_id, job_id, coverage_status, last_success_utc, job_status, exclusions, evidence_timestamp, source_ref
- restore-drills.csv: system_id, drill_date, result, evidence_ref; scope.txt: as-of UTC and export coverage
Synthetic example
Synthetic inputs are included in the starter kit. data-locations.example.csv backup-status.example.csv restore-drills.example.csv scope.example.txt
Expected output
SYS-A: recent successful job but no restore-drill evidence; do not infer recoverability. SYS-B: absent from backup/status and restore records; coverage unknown and restore evidence missing, not covered. SYS-C: last successful job 122 hours old exceeds 24-hour freshness; latest job failed and restore drill failed. Queue both problems for IT. Approved restore-review date 2026-10-01 has passed for all 3; flag review due separately from backup-job status. No restore is performed.
Test a failure
IT verifies coverage and recovery tests; test a system absent from all jobs and a green job with no restore drill. Security configuration, purchases, retention changes and restorations remain separate authorized actions.
Try with the sample files
Follow the tool steps above and use the inputs named in each step. Where provided, native-* files are blank scaffolds and NATIVE-INPUT-MAPPING explains their fields. Original examples and the optional full review prompt use a separate prepared-input schema. Keep them separate unless the mapping explicitly connects them. Downloading a kit does not connect accounts or prove the workflow works.
Download inputs and checklist 12 files
Instructions, blank templates and separate synthetic examples; these files do not install an automation. Blank templates still need verified source data.
- Download starter kit All inputs, synthetic examples and review notes in one ZIP. No automation is installed.
- Start here: get the sources and prepare the review Documentation-checked acquisition, explicit manual mapping, exact prompts and human review limits
- data-locations.csv Blank input template with exact recipe headers.
- data-locations.example.csv Separate synthetic fixture input. Do not mix these rows into real exports.
- backup-status.csv Blank input template with exact recipe headers.
- backup-status.example.csv Separate synthetic fixture input. Do not mix these rows into real exports.
- restore-drills.csv Blank input template with exact recipe headers.
- restore-drills.example.csv Separate synthetic fixture input. Do not mix these rows into real exports.
- scope.txt Blank text input worksheet. Fill its fields with approved evidence; no default assumptions are supplied.
- scope.example.txt Separate synthetic text input fixture; use with the example CSV files only.
- Expected fixture findings Read-only expected output and failure conditions for the included synthetic input files.
- Setup and review checklist Recipe-specific prerequisites, file mapping, prompt, setup steps, checklist and limits.
Optional full review prompt for prepared inputs
Prepared-input review prompt with Your firm-approved AI assistant · prepared files
Proposed / not tested · editorial prompt. This prompt uses the original prepared-input schema shown in the sample test. Step prompts may use different tables. Follow NATIVE-INPUT-MAPPING where supplied; do not mix the original examples with native-step inputs without mapping and checking every field.