Defines backup scope, immutability, retention tiers, encryption, access separation, restore objectives, and recurring restore evidence for object data plus the metadata needed to interpret it.
Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.
Decision
Back up both object bytes and their ownership/version metadata under a separately protected administrative boundary. Treat a backup as useful only after a representative restore verifies integrity and application readability.
Scope
- Inventory, backup selection, encryption, retention, immutability, replication, monitoring, restore, evidence, and expiration.
- Application objects and the database metadata required to map them.
- RPO/RTO profiles and restore drills.
Outside this block
- High availability replicas presented as backups.
- A universal retention policy independent of data class and legal holds.
Contract
- The protected scope names buckets/prefixes, metadata stores, encryption dependencies, exclusions, and owners.
- Backup operators and deletion principals are separated from ordinary application credentials.
- Retention is versioned by data class and respects holds without making every backup permanent.
- Backup copies are encrypted and recovery of their keys is tested under the same continuity plan.
- Restore chooses a point or version, writes to an isolated target first, and verifies manifest digests plus referential mapping.
- RPO and RTO are measured from observed backup and restore evidence, not configuration alone.
Implementation guidance
- Maintain immutable manifests with backup job ID, source watermark, objects, versions, metadata snapshot, digests, and encryption-key reference.
- Use provider-native version or backup capabilities but export evidence outside the protected resource boundary.
- Exercise small monthly restores and broader scheduled disaster scenarios.
- Document how deleted, corrupted, and ransomware-affected versions are selected safely.
Failure handling and safeguards
- If backup coverage or encryption-key access cannot be verified, fail the job and alert; do not record success from scheduler exit alone.
- If restore validation fails, preserve the isolated target for investigation and do not switch production reads.
- If retention deletion is uncertain, reconcile manifest and provider state before retry.
Verification and operations
- Track latest successful recovery point, protected bytes/objects, skipped objects, immutable retention coverage, restore duration, digest failures, and time since last drill.
- Alert before RPO breach and when no successful restore evidence exists inside the policy window.
- Review backup access and destructive permissions after personnel or incident changes.
The executable-looking examples in this package are fixtures and acceptance contracts. Run
python tools/validate.py from the collection root to check package structure and metadata; then
implement and execute the scenarios in the target repository.
Adoption assumptions
- Names and numeric values in
example.yamlare an adoption profile, not universal defaults. - The adopting team must map actors, data classes, error vocabulary, and ownership to its system.