DevOps Services
Your backups run every night. Has anyone ever restored one?
Backups that run on their own and get test-restored on a schedule, so you know they work before the day you need them. Part of the free server review.
Most teams start with the free AWS bill check. Once the bill is down, we review the rest of your setup for free, and this is one of the things we can take on. How the steps work
The backup that looks fine until the day you need it
Your hosting dashboard says backups are on. There is a green checkmark next to the database. Somebody set it up during launch week, and nobody has looked at it since.
That is how it works on most small teams. Backups are switched on once, and the only real test happens on the worst day of the year, when something has been deleted and everyone is watching the restore bar.
A backup is a copy of your data. A restore is putting that copy back so your app works again. Only the second one counts.
What could happen
None of this is rare. It just doesn't happen often to any one team, so it is easy to put off.
- A bad change deletes data. A database update runs against the wrong environment on a Friday afternoon. The backup exists, but restoring it takes nine hours because nobody has done it before (example). Your team loses the weekend, and customers see errors until Saturday morning.
- The backup is missing the part you need. The database is copied, but the uploaded files, the settings or the encryption keys are not. You get your tables back and your app still won't start.
- The copy lives in the same place as the original. If an account is locked, compromised or deleted, the backups usually go with it.
- The newest working copy is older than you think. Backups failed quietly for three weeks and no alert went anywhere (example). You can restore, but only to last month.
- A customer asks the question. A larger prospect sends a security questionnaire with "When did you last test a restore, and how long did it take?" Without an answer, the deal can stall.
As one founder put it: you never knew you needed it, until it was too late.
What we do, step by step
We set up your backups to run on their own, the right way, and we test-restore them on a schedule. So you know they work before you need them.
- Find everything worth saving. Software lists your databases, file storage, servers and settings, and shows which of them have a backup today. A senior engineer goes through the list with you and marks what your business can't lose.
- Decide two numbers with you. How much recent data you could afford to lose (an hour? a day?), and how long you could be down while restoring. These set how often we back up and where the copies go.
- Set up the backups. Copies run automatically, are kept for an agreed period, and at least one copy sits outside your main account or provider. The engineer reviews every setting before it goes live, and you approve the change first.
- Test-restore on a schedule. Our tooling restores a recent backup into a separate test copy, times it, and checks that the data is complete (row counts, file counts, the app starting up). A senior engineer reviews each result. A backup counts as working only once it has been restored.
- Alert on a missed backup. If a backup fails or comes out much smaller than usual, the alert comes to us that day, not three weeks later.
- Write down the recovery steps. A short, plain document: where the backups are, who can reach them, and the exact steps to bring each part back. So a second person can do it, not only the one who set it up.
You get a monthly note with what was backed up, what was restored, and how long each restore took.
What a restore test looks like
Tested on a schedule, timed, written down
Our tooling restores a recent backup into a separate test copy and checks it. A senior engineer reviews each result. You get the time it took, so the next real restore holds no surprises.
From backup to working app. Example result.
What you can do yourself today
You don't need us for this. Block out an hour this week.
- Pick your main database and restore last night's backup into a test copy. Time it from start to the app working.
- Check what the backup covers: the database only, or also uploaded files, settings and secrets?
- Look at where the backups are stored. Would they survive if your main account were locked tomorrow?
- Find out who gets told when a backup fails. If the answer is "nobody" or "an old email address," fix that first.
- Write the restore steps down while you do it. Next time it will take half as long.
What's included in which plan
| Guard $700/mo | Watch $1,200/mo | Operate $2,800/mo | |
|---|---|---|---|
| Backups set up the right way | No | Yes | Yes |
| Test-restores on a schedule | No | Yes | Yes |
| Alert on a missed or odd backup | No | Yes | Yes |
| Written recovery steps | No | Yes | Yes, kept up to date with every change |
| We run the restore during an incident | No | No | Yes |
Guard and Watch start with a one-time setup of $1,500. Operate setup is quoted after the server review. Month to month, no exit fee. See all plans.
Backups are the first thing the free server review looks at, once the free AWS bill check has brought your bill down. It tells you whether your backups have ever been restored, and you can do the fixes yourselves from the list.
Questions about backups
Our hosting provider already does automatic backups. Isn't that enough?
It can be. The provider's backup is often the right base. What it usually doesn't do is restore the copy and confirm your app runs from it, cover your uploaded files, or keep a copy outside the same account. We check those gaps and tell you which ones matter for you.
Will test-restores slow down or touch our live app?
No. We restore into a separate, temporary copy and delete it afterward. Your live database is only read, the same way a normal backup reads it.
Can you see our customer data during a test-restore?
The restore runs inside your own account, and our checks look at counts and whether the app starts, not at the records themselves. During the free bill check and the server review we have view-only access and cannot open your stored files or database records at all.
How often should we test a restore?
For most small teams, monthly for the main database and after any big change to how data is stored. If you change your setup often, more often. We set the schedule with you based on what you can't afford to lose.
How we work with your systems
You stay in control
Read-only access first
The free bill check needs read access and nothing else. Nothing in your systems changes.
You approve every change
Each change comes as a short written note first: what, why, and how to undo it.
Your data and billing stay yours
Everything stays in your own account. We never become your billing contact.
Every action logged
Every action we take is logged, and the log is visible to you.
One-click access removal
Delete the access role and our access ends at once, with no penalty.
Month to month
There is no minimum term and no exit fee. Stop at the end of any month.
Your free AWS bill check, in 48 hours
One read-only template. Every dollar you could stop paying, ranked. You keep the report even if you never hire us.
read-only accessno savings, no feemonth to month
