# Review Azure VM backup coverage and restore-test evidence

Canonical page: https://agents.paretoid.com/workflows/find-gaps-in-backup-and-restore-evidence/

Category: Operations & Reporting

Practice relevance: cross-practice. A general operational method. Review the stated tool and jurisdiction limits before use.

Jurisdiction/provider scope: 

Compare approved data locations with backup status and recorded restore tests.

Status: Proposed / not tested. The public source describes the problem. Documentation supports only the stated method components; no result from this recipe has been verified.

Verification: 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.

## 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 and evidence

- pain: [Pain evidence: File backup](https://www.reddit.com/r/LawFirm/comments/1qnw5im/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: [Pain evidence: Small-firm storage discussion](https://www.reddit.com/r/LawFirm/comments/1douxal)
  Additional self-reported public account; no independent identity or outcome verification.

- method: [Method: Microsoft 365 Backup reports](https://learn.microsoft.com/en-us/microsoft-365/backup/backup-reports?view=o365-worldwide)
  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: [Method: Azure Backup monitoring](https://learn.microsoft.com/en-us/azure/backup/monitoring-and-alerts-overview)
  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.

## Suggested approach

Start when: Monthly IT review or new data system

1. compare approved data-location inventory with existing backup-job evidence and actual restore-drill records

2. Keep source references and report unknowns instead of filling gaps.

3. The responsible reviewer checks the report before any separately approved action.

## What you need

- 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.

Access and setup:

- Actual account access, plan and source-data completeness have not been tested.

### 1. Inspect protected VM coverage

Tool: Azure portal / Azure Backup

Location: 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.

Execution status: Official documentation checked 2026-10-15; account and workflow not personally tested

Step documentation: https://learn.microsoft.com/en-us/azure/backup/backup-azure-manage-vms https://learn.microsoft.com/en-us/azure/backup/security-overview

### 2. Collect job history with an explicit coverage check

Tool: Azure portal / Azure Backup

Location: 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.

Execution status: Official documentation checked 2026-10-15; account and workflow not personally tested

Step documentation: https://learn.microsoft.com/en-us/azure/backup/backup-azure-manage-windows-server

### 3. Map the observed records to the starter input

Tool: Excel and authorized staff

Location: 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.

Execution status: Official documentation checked 2026-10-15; account and workflow not personally tested

Step documentation: https://support.microsoft.com/en-us/excel/tutorial-import-data-into-excel-and-create-a-data-model

### 4. Review the bounded evidence with Copilot

Tool: Excel Copilot, optional

Location: 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.

Prompt:

```text
Compare DataLocations, BackupStatus and RestoreDrills by verified system_id under Scope. List observed covered, explicitly excluded, unacquired/unknown systems, failed/stale jobs under approved thresholds and missing/failed/outdated restore-test evidence. Cite timestamps and source refs. A green job or restore point does not prove recoverability or meet an RTO/RPO by itself. Do not change settings, run restores, recommend deletions or promise protection.
```

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.

Execution status: Official documentation checked 2026-10-15; account and workflow not personally tested

Step documentation: https://support.microsoft.com/en-us/excel/copilot/get-started-with-copilot-in-excel https://support.microsoft.com/en-us/excel/copilot/frequently-asked-questions-about-copilot-in-excel

### 5. Approve the review result

Tool: Responsible staff reviewer

Location: 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.

Execution status: Official documentation checked 2026-10-15; account and workflow not personally tested

Step documentation: https://support.microsoft.com/en-us/excel/tutorial-import-data-into-excel-and-create-a-data-model

## What you will 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.

## Human review and limits

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.

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.

What to measure: In a synthetic pilot, count correctly found exceptions, false alarms, and unresolved inputs. No time or cost saving is assumed.

## Original prepared-input schema

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 input:

```text
Synthetic inputs are included in the starter kit.
data-locations.example.csv
backup-status.example.csv
restore-drills.example.csv
scope.example.txt
```

Expected synthetic output:

```text
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.
```

Failure check: 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.

## Starter files

Native blank scaffolds and original synthetic examples may use different schemas. Follow NATIVE-INPUT-MAPPING where supplied. These files do not connect accounts or install automation.

- [Download starter kit](https://agents.paretoid.com/assets/starter-kits/s13-starter-kit.zip) — All inputs, synthetic examples and review notes in one ZIP. No automation is installed.

- [Start here: get the sources and prepare the review](https://agents.paretoid.com/assets/starter-kits/s13/START-HERE.txt) — Documentation-checked acquisition, explicit manual mapping, exact prompts and human review limits

- [data-locations.csv](https://agents.paretoid.com/assets/starter-kits/s13/data-locations.csv) — Blank input template with exact recipe headers.

- [data-locations.example.csv](https://agents.paretoid.com/assets/starter-kits/s13/data-locations.example.csv) — Separate synthetic fixture input. Do not mix these rows into real exports.

- [backup-status.csv](https://agents.paretoid.com/assets/starter-kits/s13/backup-status.csv) — Blank input template with exact recipe headers.

- [backup-status.example.csv](https://agents.paretoid.com/assets/starter-kits/s13/backup-status.example.csv) — Separate synthetic fixture input. Do not mix these rows into real exports.

- [restore-drills.csv](https://agents.paretoid.com/assets/starter-kits/s13/restore-drills.csv) — Blank input template with exact recipe headers.

- [restore-drills.example.csv](https://agents.paretoid.com/assets/starter-kits/s13/restore-drills.example.csv) — Separate synthetic fixture input. Do not mix these rows into real exports.

- [scope.txt](https://agents.paretoid.com/assets/starter-kits/s13/scope.txt) — Blank text input worksheet. Fill its fields with approved evidence; no default assumptions are supplied.

- [scope.example.txt](https://agents.paretoid.com/assets/starter-kits/s13/scope.example.txt) — Separate synthetic text input fixture; use with the example CSV files only.

- [Expected fixture findings](https://agents.paretoid.com/assets/starter-kits/s13/expected-fixture-result.txt) — Read-only expected output and failure conditions for the included synthetic input files.

- [Setup and review checklist](https://agents.paretoid.com/assets/starter-kits/s13/README.txt) — Recipe-specific prerequisites, file mapping, prompt, setup steps, checklist and limits.

## Optional original prepared-input prompt

Destination: Your firm-approved AI assistant · prepared files

This original prompt uses its own prepared-input schema. Do not mix it with native-step tables without the supplied mapping.

```text
Compare these sanitized data-location, backup-status and restore-drill tables by system ID. Use only the supplied recovery objectives and freshness thresholds. List covered, explicitly excluded and unknown systems, stale or failed jobs, and missing restore-test evidence. Link every finding to a source row and timestamp. Do not infer recoverability from a successful job, promise complete protection, change backup settings or perform a restore. Prepare questions for the IT owner.

INPUTS
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

OUTPUT
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.

Use only these synthetic or firm-approved inputs and preserve source row/page IDs. Keep missing or conflicting evidence unresolved. Return a draft for the named reviewer. Do not send messages, connect accounts, change records or permissions, move money, or make legal decisions. Keep source files unchanged. List missing prerequisites before continuing.
```

Proposed / not tested · editorial prompt

Published by Law Firm Agents. Proposed adaptation; not tested. Not legal advice.