# Backup Restore Evidence Guide

Use this reference for AWS Backup, backup plans, vaults, vault lock, restore testing, cross-account/cross-Region copy, EBS/RDS/EFS/S3 recovery patterns, retention, lifecycle, encryption, and recoverability evidence.

## What people get wrong

The lazy story is:

> Backup jobs are successful, so the data is protected.

Wrong. Protection means recoverability, immutability where required, correct retention, tested restore permissions, and business-aligned recovery evidence.

Common bad assumptions:

- Successful backup job equals successful restore.
- Cross-Region copy equals disaster recovery.
- Vault Lock protects against every deletion path.
- KMS encryption is operationally invisible during restore.
- Lifecycle cold/archive transitions have no recovery-time impact.
- Native service backups and AWS Backup coverage are equivalent for every resource.

## Backup-specific failure modes

- Backup selection misses resources because tags, opt-in services, or new accounts are not covered.
- Restore role lacks KMS, network, IAM, or target service permissions.
- Vault policies allow deletion, copy disablement, or ransomware-impacting changes.
- Cross-account/cross-Region copies fail or are not monitored.
- Retention/lifecycle conflicts with legal hold, compliance, or RTO.
- Restore test validates infrastructure but not application consistency.

## Minimum safe workflow

1. Identify protected resources, business owner, data classification, RPO/RTO, retention, and compliance requirements.
2. Review AWS Backup plans, selections, vaults, copy actions, lifecycle, encryption, vault policies, and Vault Lock posture.
3. Verify coverage gaps across accounts, Regions, services, tags, and newly created resources.
4. Demand restore evidence: restore job, operator, target environment, application validation, and elapsed time.
5. Check recovery permissions, KMS keys, network, secrets, and dependency readiness.
6. Recommend non-destructive fixes first; deletion, retention reduction, or vault policy changes need explicit approval.
7. Label evidence as configuration, job success, restore test, or business acceptance.

## Verification targets

- AWS Backup plans, backup rules, selections, copy actions, lifecycle, continuous backup/PITR, and protected resource inventory
- backup vault policies, Vault Lock mode, access policy, KMS key policy, and cross-account/cross-Region copy jobs
- restore jobs, restore testing plans, restore role permissions, elapsed restore time, and application validation evidence
- EBS snapshots, RDS/Aurora backups, EFS backups, DynamoDB PITR, S3 versioning/Object Lock/replication, and service-native backup overlap
- AWS Organizations backup policies, Control Tower/account coverage, Config/Backup Audit Manager evidence, and compliance reports
- alerting for failed/missed backup jobs, copy failures, vault policy changes, and backup age

## When to push back

Push back if the user asks to:

- claim recoverability from backup-job success alone
- reduce retention or delete recovery points without compliance approval
- skip restore tests because backups are encrypted and replicated
- ignore KMS/permission dependencies for restore
- treat cross-Region copy as full DR without runbook and application validation
- mutate vault lock or backup policies from advisory evidence alone

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html
- https://docs.aws.amazon.com/aws-backup/latest/devguide/logicallyairgappedvault.html
- https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html
- https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-account-backup.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- AWS Backup logically air-gapped vaults are isolated vaults intended to secure backups, support cross-account sharing, multi-party approval recovery, and cross-Region copies.
- AWS Backup vault lock, cross-account backup, lifecycle, encryption, and restore workflows are design inputs; recoverability is proven only by successful restore evidence against the required RTO/RPO.

Sampled live evidence:
- Read-only regional availability sampling reported AWS Backup as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `Backup+ListBackupVaults` and `Backup+ListRecoveryPointsByBackupVault` were reported `isAvailableIn` in those regions.

Review implications:
- Backup existence is not recovery readiness. Require restore-test results, restore IAM/KMS access, backup selection scope, lifecycle/retention evidence, vault lock posture, copy status, and recovery-account access.
- Treat ransomware-resilience claims as unproven without isolation, immutability or lock controls, cross-account/cross-Region strategy, and tested recovery.

# Safety checklist

Use this reference before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.

## Non-negotiables

- Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
- Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
- Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, or production-impacting actions.
- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
- Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.

## Stress checks

- What can expose data?
- What can escalate privilege?
- What can break production or block rollback?
- What can create unbounded cost?
- What compliance or audit evidence is missing?
- What rollback or validation path is unproven?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

# Workflow and output contract

Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:
- Protected resources, data classification, retention, legal hold, RTO/RPO, and owner
- Backup plan, vault policy, vault lock, KMS key access, copy actions, lifecycle, and cold storage
- Restore testing, recovery account, least-privilege restore role, runbooks, and evidence retention
- Gaps: unsupported resources, failed jobs, missing tags, expired recovery points, and untested dependencies

## Safe workflow

1. **Frame scope**
   - Workload/account/Region/environment:
   - Business criticality and owner:
   - Data classification and compliance driver:
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
   - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What can expose data?
   - What can escalate privilege?
   - What can break production or block rollback?
   - What can create unbounded cost?
   - What evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow scope, staged rollout, validation, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.

## Output contract

Return this structure:
```markdown
# AWS Data Protection Backup Steward: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```