Stage 6 · Operate
Disaster Recovery & Continuity
Backup Validation
Restore tests, checksum verification, backup retention, immutable storage, and audit evidence.
Why Validate Backups?
A backup that has never been restored is not a backup — it is a hope. Backups fail silently. Restore procedures may not work. Data may be corrupted. The only way to know your backup works is to restore it.
The time to discover your backup is corrupt is during a disaster, not during a restore test. Validate your backups regularly. A backup that cannot be restored is worthless.
Restore Tests
restore_test_process:
frequency: "Monthly for critical services, quarterly for others"
steps:
- step: "Select backup"
details: "Choose most recent backup and one from 30 days ago"
- step: "Restore to isolated environment"
details: "Restore backup to test environment, not production"
- step: "Verify data integrity"
details: "Run consistency checks, verify record counts"
- step: "Verify data freshness"
details: "Confirm data matches expected time period"
- step: "Document results"
details: "Record restore time, any issues, data integrity status"
success_criteria:
- "Backup restores without errors"
- "Restore completes within RTO target"
- "Data integrity checks pass"
- "No data corruption detected"
documentation:
- "Date and time of restore test"
- "Backup selected (date, type, location)"
- "Restore duration"
- "Data integrity check results"
- "Any issues encountered"
- "Pass/fail status"
automation:
tool: "Custom script or cloud-native backup validation"
schedule: "Monthly, automated"
notification: "Slack channel + email"Checksum Verification
checksum_verification:
purpose: "Verify backup data has not been corrupted"
process:
- "Generate checksum when backup is created"
- "Store checksum separately from backup"
- "Verify checksum when backup is restored"
- "Alert if checksum mismatch detected"
checksum_types:
- name: "SHA-256"
use: "Standard for file integrity"
speed: "Fast"
collision_risk: "Extremely low"
- name: "MD5"
use: "Legacy systems"
speed: "Very fast"
collision_risk: "Low but possible"
storage:
location: "Separate from backup storage"
retention: "Same as backup retention"
access: "Read-only, immutable"
automation:
script: |
# Generate checksum for backup
sha256sum backup.tar.gz > backup.tar.gz.sha256
# Verify checksum after restore
sha256sum -c backup.tar.gz.sha256
schedule: "After every backup and every restore"Retention Policies
retention_policy:
daily_backups:
retention: "30 days"
storage: "Standard storage"
cost: "Low"
weekly_backups:
retention: "12 weeks"
storage: "Standard storage"
cost: "Low"
monthly_backups:
retention: "12 months"
storage: "Standard storage"
cost: "Medium"
yearly_backups:
retention: "7 years"
storage: "Archive storage"
cost: "Minimal"
compliance_requirements:
financial_data: "7 years"
healthcare_data: "6 years"
general_business: "3 years"
test_data: "30 days"
deletion_process:
- "Automated deletion after retention period"
- "Verify deletion before removing from inventory"
- "Document deletion for audit trail"Immutable Storage
immutable_storage:
purpose: "Protect backups from ransomware and accidental deletion"
aws_s3:
configuration: |
# S3 Object Lock configuration
aws s3api put-object-lock-configuration \
--bucket backup-bucket \
--object-lock-configuration '{
"ObjectLockEnabled": "Enabled",
"Rule": {
"DefaultRetention": {
"Mode": "COMPLIANCE",
"Days": 365
}
}
}'
benefits:
- "Cannot be deleted by anyone, including root"
- "Cannot be modified"
- "Retention period enforced by AWS"
- "Compliance with regulatory requirements"
gcs:
configuration: |
# GCS bucket lock
gsutil retention set 365d gs://backup-bucket
azure:
configuration: |
# Azure Blob Storage immutability
az storage blob service-properties delete \
--enable true
best_practices:
- "Use compliance mode for regulatory data"
- "Use governance mode for operational flexibility"
- "Set retention based on compliance requirements"
- "Test restore from immutable storage"Audit Evidence
audit_evidence:
backup_evidence:
- "Backup schedule and completion logs"
- "Backup size and duration"
- "Storage location and encryption status"
- "Retention policy compliance"
restore_evidence:
- "Restore test dates and results"
- "Restore duration and success rate"
- "Data integrity verification results"
- "Any issues encountered and resolution"
compliance_reports:
- "Monthly backup compliance report"
- "Quarterly restore test summary"
- "Annual disaster recovery test results"
retention:
evidence_retention: "7 years"
storage: "Audit storage bucket"
access: "Compliance team only"Automate backup validation as part of your CI/CD pipeline or as a scheduled job. Manual validation is error-prone and often skipped. Automated validation ensures consistent, reliable backup verification.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.