Recovery, by design.
A synthetic repair shop’s job register depended on one Proxmox VM. Losing that machine meant losing access to the application and its SQLite data.
The constraints shape the system.
A small Python/SQLite workload, a single application server, and a need for a documented recovery path beyond the original host. This was an executed synthetic engagement, not a paid client deployment.
The implementation.
- Define the target infrastructure in Terraform and move the workload to AWS.
- Use Systems Manager for administration with no inbound security-group rules.
- Keep versioned backups in S3 and configure CloudWatch/SNS monitoring.
- Replace the application server, restore the data, and validate both SQLite integrity and application health.
What the checks showed.
RECORDED LAB OUTCOME
Six jobs were recovered, including DR-TEST. SQLite integrity and application health returned ok. One recorded lab recovery took 12 minutes, including a CloudShell interruption.
What this result means.
The 12-minute observation is one lab result, not a production RTO commitment. No measured RPO is claimed. AWS resources were destroyed after evidence preservation and cleanup checks.
What I would improve.
The next iteration should repeat the exercise under several failure conditions, define a measured RPO, and test backup access when primary credentials or the original environment are unavailable.
Inspect the work.
Read the original case study, browse the preserved evidence, or inspect the implementation repository.
Related service: Backup & Disaster Recovery. A production engagement starts with your actual workload, risks, and acceptance criteria.