Backup & Disaster Recovery
A backup nobody has restored is a hope, not a plan.
We work out what a real outage would cost, then build the backup and recovery process to match: what is protected, how often, where the copies live, who can restore and how long it actually takes. Then we restore it in front of you.
Tools we work in
- AWS Backup
- Azure Backup
- PostgreSQL
- Restic
- Velero
- Terraform
- S3
Scope
What this covers
The specific work included when you engage us for this service.
- Recovery objectives agreed per system: how much data can be lost and how long an outage is survivable
- Automated backups with encryption, retention rules and copies in a second location
- A restore procedure that has been executed, not just written down
- Scheduled restore tests so the process does not rot quietly
- Failover and failback runbooks with the decision points named in advance
- Monitoring that alerts when a backup job has silently stopped running
What you receive
- 01A written recovery plan stating the objective, the procedure and the measured restore time for each system
- 02Backup configuration committed as code, with retention and cross-region copies in place
- 03Evidence of a completed restore test, including what went wrong and what changed as a result
Questions
Backup & Disaster Recovery, answered
We already have backups. What is missing?
Usually the restore. A backup job that reports success is evidence that a file was written, not that the data can be brought back in a usable state within a tolerable time. Databases need point-in-time recovery tested at a specific timestamp, and application state often includes object storage and configuration that the database backup does not cover.
How often should we test a restore?
At least quarterly for anything the business cannot operate without, and after any significant change to the data model or the platform. The test should be performed by the people who would run it during a real incident, not by the person who built it, because the point is to find the steps that only exist in one person's memory.
Do we need a second region?
Not always, and it is an expensive answer to a question most businesses have not asked precisely. A second region protects against a provider-level outage, which is rarer and shorter than the outages caused by a bad deploy or deleted data. We start with immutable backups in a separate account, which addresses the more likely disaster, and price the regional failover separately.
Most often requested by
Related
More in Cloud, DevOps & Security
Cloud Migration
Move to the cloud without carrying the old problems with you.
Cloud Architecture & Design
Decisions that are cheap now and expensive to reverse later.
Cloud Cost Optimisation
Most cloud bills contain spend that nobody decided to make.
CI/CD & Release Engineering
Deploys that are boring, which is exactly the point.
Tell us where the manual work is
A 30-minute call. We map the process, tell you what we would automate or build first, and what it costs. No retainer before you agree the scope.
- No retainer before scope is agreed
- Written plan you can act on alone
- Worldwide delivery, on your hours