Rollback and Recovery
A defined, rehearsed way to undo a bad release and restore data from backup, covering both code and database changes, so a failed release costs a short interruption instead of a full day of firefighting.
Two Different Problems
A bad release and lost data need different responses. Rollback returns your application to its last working version. Recovery restores data that has been damaged or lost. Both need a defined, tested procedure rather than being figured out for the first time during an actual failure.
Rolling Back a Release
Reverting Code to the Last Working Build
The previous version is kept ready, so returning to it is one action instead of a rebuild under pressure.
Reversible Database Migrations
Schema changes are written to be undone where the change allows it, with a backup taken before they run.
Feature Flags as a Faster Kill Switch
Risky new functionality can be switched off instantly without a full rollback, when it was released behind a flag.
When a Change Cannot Be Cleanly Reversed
For changes that genuinely cannot be undone — some data transformations, some third-party integrations — we agree an alternative safeguard before release, not after.
Recovering From Backup
Backup Schedule Matched to Tolerance for Loss
How often backups run is set by how much data you can afford to lose, not a default interval.
Restore Drills on a Set Schedule
Backups are actually restored on a schedule to confirm they work, rather than assumed to be fine until the day they are needed.
Off-Site or Separate-Account Backup Copies
At least one copy is kept outside the primary environment, so a single failure cannot take out both the live system and its backup.
Why We Rehearse Rather Than Document
A written rollback or recovery procedure that has never actually been run is a theory, not a plan. We practise the reversal with your team on staging, and where sensible once on production in a planned window, before calling either procedure finished.
Frequently asked questions
How often should our backups actually be tested?
On a fixed schedule, not left until an incident forces the question — the right interval depends on how often your data changes and how damaging a failed restore would be to discover in the moment.
What is the real difference between rollback and recovery?
Rollback undoes a release that went wrong. Recovery restores data that was lost or corrupted, often through a backup. A single bad release can need both if it also damaged data before being caught.
What drives the cost of defining these procedures?
How many applications and databases need a defined procedure, and how complex your data model is to migrate reversibly.
What drives how long rehearsing these procedures takes?
Mostly how much rehearsal is needed — a first rollback drill on an unfamiliar system takes longer than repeating one that is already documented.
Does rehearsing a rollback on production cause downtime?
It is scheduled in a planned window outside your busy hours specifically to avoid surprise downtime, and a tested way back is confirmed before we begin.
Who owns the backups and where are they stored?
You do. Backups are stored under your own cloud or storage account, with at least one copy kept separate from the primary environment.
What should you have ready before we start?
Access to your current backup arrangement if one exists, and a decision on how much data loss would be acceptable in the worst case.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private