Your backups have never been restored.
The job reports success every night, so nobody has looked at it in years. I restore one into somewhere safe, time it, and write down what came back missing. Then I fix what that exposes.
The backup is not the thing. The restore is the thing.
Almost everyone has a backup. Very few people have ever watched one come back, and those are not the same claim.
A backup job that finishes without an error has proved exactly one thing: that it finished. It has not proved the data is complete, that it will load into anything, that the version it was written by still exists, or that the parts nobody thought about — the uploads, the certificates, the environment file, the queue — were ever included. Every one of those is discovered at restore time.
And the second question is worse, because it has no answer at all. How long would it take to come back? There is usually a number, and the number came from somebody estimating on a good day. It counts the restore and not the version mismatch, the DNS wait, the credential nobody can find, or the twenty minutes working out who has the password. On the day it matters, that gap is the outage.
None of this is negligence, and it is worth saying plainly. Testing a restore is genuinely disruptive: it needs somewhere to put the data, a few hours nobody has, and a willingness to find out something unpleasant. Every incentive points at leaving it alone for another month. That is why it has been another month for four years.
The free option here is AWS’s own tool. Run it.
This is the one category where the free competitor is first-party, excellent, and named after the thing on this page. Pretending otherwise would be insulting, so here is exactly where the line falls.
What the free tools give you
Free · run it this afternoon
- The AWS Well-Architected Tool — in the console, evaluates a workload against the pillars and produces an improvement plan. AWS’s words: “there is no additional charge”
- The Well-Architected Framework and its partner program — six pillars, and “hundreds of members” AWS will point you at to run the review with you
- Trusted Advisor mapped into it — automated checks surfaced against the matching questions, so some of the answering has evidence behind it
- My own assessment on this site — 17 questions, four pillars, scored in your browser, no signup
- The downtime cost calculator here turns your uptime into an annual figure, and the uptime trial is the one tool here that watches rather than asks
What this adds
Somebody has to actually do it
- A backup restored, into a scratch environment, with a clock running — the number that does not exist until somebody does it
- What came back missing, which is a list nobody can write in advance, because the whole problem is that nobody knew
- A failure-mode table marked observed or reasoned, so you can see which answers were tested and which were argued
- The findings ranked by what an outage costs you, rather than by pillar
- Then the repair: a backup that restores, and the worst single point of failure gone
Notice what is not in the right-hand column: the questions. AWS’s tool asks better questions than I do and it is free, permanently, from the vendor. There is no version of this page where running it first is the wrong move.
| AWS service | What it does | What AWS charges |
|---|---|---|
| Well-Architected Tool | Asks you the questions and records your answers | Free |
| Resilience Hub | Assesses failure modes and runs resilience tests | $15 per application, per month |
| Fault Injection Service | Actually breaks things, on purpose, to see what happens | From $0.10 per action-minute, plus $5 per report |
| Backup restore testing | Actually restores a recovery point and checks it | $1.50 per recovery point |
Every free option here asks you a question. AWS’s own tool asks. A partner workshop asks. My assessment on this site asks, and its own page markup says so. AWS draws the line in exactly the same place and prices it: free to ask, $15 a month to assess failure modes, $0.10 per action-minute to actually break something, $1.50 to actually restore something. This page is the doing.
One thing not to overstate, since this page is arguing on precision: the Trusted Advisor integration is real and it does surface automated checks against the matching questions. What it does not do is answer them. AWS’s own worked example shows a check reporting volumes without snapshots and a person still deciding what that means and ticking the box.
And the free tool I should be least kind about is mine. The cloud architecture assessment on this site never connects to anything, cannot verify a single answer, and gives you the points for believing your backups work. Its own page markup says: “Structured on the AWS Well-Architected pillars, but it is not a Well-Architected Review and nothing is scanned or measured.” That is not modesty, it is what a questionnaire is.
The restore record, and the four numbers that did not exist before
Rather than describe it, here is one filled in. Every line is something that cannot be answered by asking anybody, including the person who set the backup up.
- What was restored
- The production database, 41 GB, into a scratch instance built for the day and destroyed afterwards. Nothing was written to anything live.
- From which backup
- The nightly dump in object storage, 02:15 UTC. The most recent one that existed — which is not the same thing as the most recent one the schedule says should exist.
- How long it took
- 3 hours 52 minutes, from starting the download to the application answering a request. The runbook said “about an hour”. Nobody had ever checked, because checking means doing it.
- What was missing
- Everything after 02:15, so up to a day of writes depending on when the outage lands. And the uploads directory, which was never in the backup at all — the job backed up the database and nobody had read the job in four years.
- What broke on the way
- The restore failed twice before it worked: the scratch instance ran a newer database server than production and the dump would not load until the version was matched. On the real day, that is 40 minutes of an outage spent reading an error message.
That is the artefact. It is not a document about your architecture — it is the record of something that happened on a specific afternoon, and the reason no free tool produces one is not that the tooling is immature. The number does not exist until somebody restores the backup. A questionnaire cannot return it, a partner workshop cannot return it, and neither can asking a model.
The second half is the architecture, and it needs a column most pages leave out. Not everything can be killed on a live system to see what happens, so the table says which answers were tested and which were argued. Nobody stops your production database to watch.
| Component | What happens when it dies | How that was established | Time to recover |
|---|---|---|---|
| The database | Everything stops. Not degraded — stopped. There is one instance and nothing behind it. |
REASONED
Nobody kills a live production database to watch. The recovery time comes from the drill instead, which is why the drill exists. |
3 h 52 m, measured — not the hour the runbook claimed |
| The web server | The site returns nothing at all. One instance serves every request and there is no second one to take over. |
OBSERVED
Stopped in an agreed window with somebody watching, then started again. This one is safe to test and so it was tested. |
11 minutes from the image — but the image is 14 months old, so add the deploy |
| The deploy process | Nothing breaks today. Nothing can be shipped or rolled back either, including the fix for whatever breaks tomorrow. |
REASONED
One person owns it and it runs from their laptop. You cannot test this by removing the person, and asking them to document it is the fix. |
Unknown, and that is the finding |
A table where every row said OBSERVED would be a lie, and one where every row said REASONED would be a questionnaire with better formatting. The mix is the honest answer, and knowing which is which is the difference between a measured recovery time and a hopeful one.
Six things, and three of them are the same backup
These are the faults the tools on this site route here. The first four cluster tightly, which is why the restore drill is the first line of the first tier rather than a nice extra.
- There is no backup
- Not a bad backup. None. Usually because the platform used to take one, or somebody set one up on a server that has since been replaced, or a trial expired and the emails went to an address nobody reads. This is more common than anyone writing about backups admits, and it is almost never a decision anyone made.
- The backup runs, and nobody has ever restored it
- The job reports success every night. That success means the job finished, which is not the same as the data being complete, loadable, or on a version anything can read. An untested backup is a belief, not a backup, and the moment it gets tested is the worst possible moment to find out.
- One component with nothing behind it
- One server, or one database, or one queue, and when it stops everything stops. Frequently it is not even the obvious one — the database is replicated and the thing with no redundancy is the machine that holds the uploads, or the single VPN box every deploy goes through.
- Nobody has timed the recovery
- There is an answer to “how long would it take to come back”, and it came from somebody estimating. Estimates for this are wrong in one direction, consistently, because they count the restore and not the version mismatch, the DNS wait, the missing credential and the twenty minutes finding who has the password.
- Effective uptime under 99.5%
- Which sounds like a small number until it is converted: 99.5% is nearly two days a year on the floor. The downtime calculator turns that into money using your figures rather than an industry average, and the result is usually what makes this worth doing.
- A new build with no second availability zone
- Everything in one place, because one place was cheaper and the second one felt like something to add later. Later is considerably more expensive than now — retrofitting redundancy means changing how the application stores state, which is a rewrite rather than a setting.
Here is the honest part about how you got to this page. Not one of those six is detected by anything on this site, and nothing on this site could detect them. Every tool here is passive and external; a backup, a restore, a second availability zone and a single point of failure are all inside your infrastructure. The assessment, the engagement builder and the VPS versus managed AWS calculator all ask you, and you type the answer.
Which is exactly the point the rest of this page is making, turned back on itself: that is also all the free competition does, AWS included. The one thing here that measures rather than asks is the uptime trial, and it watches from outside. If you want a number rather than an opinion before spending anything, start with the downtime cost calculator — it works from your revenue and your own outage history, and it is the figure everything below gets ranked against.
Four ways in
Everyone starts with the review, because until something has actually been restored nobody knows how big the job is — including me. Where you go afterwards depends on what the drill finds.
Resilience Review
Everyone starts here. It also scopes everything else.
- One timed restore drill — a real backup, into a scratch environment, with the clock running
- The restore record: what came back, how long it took, what was missing, what broke
- A failure-mode table for the components you have, each row marked observed or reasoned
- Findings ranked by what an outage costs you, not by pillar
- What is already correct, not just what is wrong
- Nothing is changed. One environment, one application, up to 250 GB restored
Review + Repair
Not a starting point. Follows the review.
The tier where the answer changes from “no” to “yes”.
- A backup that restores — covering everything the drill found missing, not just the database
- Monitoring on the restore itself, rather than on the backup job reporting success
- The worst single point of failure removed, chosen by cost rather than by ease
- A second drill after the repair, so the fix is proved rather than asserted
- Everything staged and reversible, with a named rollback
Review fee credited — you pay the difference, not both.
Resilient Baseline
The above, plus changing the shape rather than patching it.
- Everything in the repair
- Redundancy for the components that justify it — and only those, with the monthly cost priced before anything is built
- A recovery runbook written and rehearsed, so it is not fiction
- A second timed drill included, proving the new shape actually recovers faster than the old one
- Handover, so your team can run the drill without me
Review fee credited — you pay the difference, not both.
Recovery Drills
Because a restore that worked in March proves nothing in September.
- A scheduled restore into a scratch environment, every month, timed
- The result diffed against the last run — drift you can see
- New paths, new volumes and new services checked into the backup as they appear
- A one-page record each month you can hand to anyone who asks
- Monthly in advance, cancel anytime, never auto-renewing
Five things about those prices, before you ask
- The cap is one environment, one application, and 250 GB restored. It is data volume rather than server count on purpose: a two-server setup with a large database is a bigger day than a six-server setup with none. Almost nobody hits the cap, and past it I look first and quote before anything is invoiced.
- The recommended tier is the repair, and that is deliberate. The review tells you the backup does not work; the repair means it does. Only one of those changes your position. But you cannot start there — until something has been restored, nobody knows what needs repairing.
- The second drill in the baseline tier is included, not quoted. Selling you a rebuild for redundancy and then charging extra to demonstrate it holds would be the exact failure this page is written against.
- The review fee is credited for 30 days. Come back inside a month and you pay the difference. After that it lapses, and not as a sales tactic: infrastructure drifts, so a drill from last quarter would have to be run again anyway.
- If the review finds you are in good shape, that is the end of it. The fee is earned, you get the record and the reasoning in writing, and there is nothing further to buy — so the credit applies to nothing. Better said now than discovered later.
These are launch prices for a new practice rather than a permanent position, and they will go up once there is finished work behind them. If your situation does not fit any of the four, say so in the form and I will tell you honestly whether it is worth doing at all.
What you have to supply
Two of these are settled before the engagement starts rather than discovered during it, and they are the first two.
Somewhere to restore into, and written permission naming that target. A scratch environment, or the budget for one for a day. Without a restore target there is no drill and therefore no deliverable, so this is agreed up front.
The written permission is the item I will not proceed without, and the reason is blunt: a restore aimed at the wrong path overwrites live data. It is the one way this engagement could cause the exact disaster it exists to prevent, so it gets named rather than assumed away. Nothing is ever restored over a live path, the target is written down before anything starts, and somebody of yours is reachable while the drill runs.
Access — least privilege, always
- Access to the backups themselves. Not a screenshot of the backup schedule and not a green tick in a dashboard. A job that reports success is not a backup — that is the entire premise of this page.
- A restore target that is not production. A scratch account, a spare instance, a separate project. If you do not have one, say so and we build it for the day and destroy it afterwards.
- Read access to the infrastructure, enough to see what components exist and what depends on what. Read-only is sufficient for the review.
- Access removed when the work is delivered. That is your action, not mine, so you never have to trust that I did it.
Information — and the last item is what does the ranking
- What the data is and roughly how big. The cap depends on it and so does the length of the day. A rough figure is fine; “nobody knows” is a legitimate answer and a finding in itself.
- What the components are and what talks to what, including anything running on someone’s laptop or in a personal account. Those are usually the interesting ones.
- A maintenance window, or explicit permission to work live, if anything is to be failed over or removed. Both are workable. Only one of them is comfortable.
- What an hour of downtime costs you. Without it the ranking in tier 1 is guesswork, and the ranking is the product. The free downtime cost calculator computes it from your own numbers in about a minute.
Protecting the work
- Written authorisation naming the systems and the restore target. Before anything is downloaded, let alone restored. This protects you considerably more than it protects me.
- Written agreement that nothing is restored over a live path. Not a formality. It is the single clause that keeps this engagement from becoming the incident it is meant to prevent.
- For repair and baseline work: every change staged and reversible, with a named rollback for each one. A correct change at the wrong moment is still an outage.
What I will not promise you
A tested restore proves that one restore worked once, on one dataset, on one day. It is evidence and it is far more than you have now, but it is not a guarantee that the next one will work. Anyone selling you certainty here is selling you something they cannot deliver.
This is not an AWS Well-Architected Review. AWS reserves that term for its own program and its partner program. My own free assessment on this site already says in its markup that it is not one either, and this page has to agree with its own tool or one of the two is lying to you.
It is a point in time. Architecture drifts — a service gets added, a volume gets attached, a path stops being backed up — and a review of March’s infrastructure says little about September’s. That is an honest limitation of one-off work rather than an argument for the monthly tier, and you should weigh it as one.
Redundancy costs money every month, permanently. A second availability zone roughly doubles the compute half of the bill and adds cross-zone transfer on top. Any page recommending high availability without naming its running cost is selling an outcome and hiding the price, so: price it first with the free AWS cost estimator here, which builds the figure from published rates. Sometimes the redundancy costs more than the outage would, and that is a legitimate answer.
Not everything can be tested on a production system, which is why the third column of the failure-mode table says observed or reasoned. Your primary database is not stopped on a live system to see what happens, and no report of mine will imply that it was.
An outage after a review is not evidence the review was wrong. One restore, one day, one point in time — that is what the work covers and it is stated up front rather than defended afterwards. What a review buys you is a shorter outage and a known recovery path, not the absence of one.
Three things this is not, and one of them is urgent
Worth reading before the form, because in all three cases the right response looks nothing like the rest of this page.
You are down right now
- That is emergency recovery, and it is a phone call rather than a booking form. Different urgency, different hours, different price.
- Folding it into a fixed review fee would be wrong in both directions — against you if it runs long, against me if it does not.
- Say it is live when you get in touch and I will tell you immediately whether I can help today, rather than putting you in a queue behind a review.
The drill finds the backups do not restore at all
- This is the best possible outcome of tier 1, not a failure of it. It is exactly what you paid to find out, and finding it on a Tuesday costs a fraction of finding it during an outage.
- It does change the work. Building a backup that restores is repair, not review, and that is tier 2 rather than something absorbed silently into tier 1.
- You hear at the moment I find it, with the evidence, and you decide. Nothing turns into an invoice without you agreeing to it first.
The restore reveals data already lost, or somebody else in the system
- You hear immediately, in whatever way reaches you fastest — not in a report four days later. Missing data across a date range, or evidence somebody else has been in there, both qualify.
- The engagement pauses there. Continuing down a resilience checklist while either of those is unresolved would be the wrong order of work.
- Incident response is quoted separately. Different urgency, different hours, and it cannot honestly be folded into a fixed fee. I will tell you plainly if it is bigger than one person should take on.
How payment works
Plainly, so nothing about it is a surprise later. There is no account to create, no portal to log into and no card stored anywhere.
-
You apply through the form
No payment at this point, and no commitment. Tell me what the infrastructure is, what the backups are, and what prompted this.
-
I review it and confirm the scope
If it is not worth doing, I say so here and it costs you nothing. If it is, you get the scope and the restore target in writing before any invoice exists.
-
An invoice arrives, payable within 48 hours
It carries an invoice number and a due date. Unpaid past 48 hours, the application lapses and the slot is released to somebody else.
-
Work begins once payment is received
Not before. For one-off work there is nothing to suspend after delivery, so payment comes first — that is the standard arrangement and it runs both ways.
-
Recovery drills, if you take them, are monthly in advance
Non-payment simply stops the work. Nothing is billed silently in the background and you can stop whenever you like.
If you are still building
Everything above assumes infrastructure that has been running for years. Before launch the same work is a fraction of the price, and this is the one page where that gap is enormous rather than merely real.
What that involves
- Designing for a second availability zone now rather than retrofitting one later. Retrofitting means changing how the application holds state, which is a rewrite. Deciding it before launch is a configuration choice.
- A backup that has been restored before the first customer exists, so the recovery time is a measured number from day one rather than an estimate you inherit from nobody.
- The runbook written while the person who built it is still here, which is the only time it gets written accurately.
- Both shapes priced before you commit to either. The free AWS cost estimator will build the monthly figure with and without the second zone, so the trade-off is a number rather than a feeling.
Mention that you are pre-launch in the form and I will quote it as its own piece of work. It is cheaper, and it is the version of this engagement I would rather sell.
Price your downtime first, then tell me when your backup was last restored.
The calculator costs nothing, needs no signup and no email address, and it turns your uptime into an annual figure using your numbers rather than an industry average. Then run the free assessment, and the AWS Well-Architected Tool while you are at it. If all of that comes back healthy and somebody restored a backup last month, you have saved a fee and I would rather tell you that than take it. If the honest answer to the restore question is "never", that is exactly what this is for.
Prefer to talk? Book a free call ↗ · Or hire me on Upwork ↗ · Typical reply within one business day.