Getting it back is a procedure too

• A change broke it

  Revert the merge — the same pipeline that shipped it redeploys the last known-good version.

  Data loss

  None. Nothing was deleted; the deploy just goes back to what was already running.

  While it happens

  Serving the whole time — a redeploy, not an outage.

  The Loop · Environments · Case files

• Data was deleted or corrupted

  Restore from the nightly backup, or roll a database with point-in-time recovery back to the moment before it happened.

  Data loss

  Depends on the tier — see the retention ladder below.

  While it happens

  Brief downtime while the restored copy is confirmed and promoted.

  Retention ladder ↓

• The machine or service failed

  Rebuilt from the infrastructure definition, with the latest backup restored onto the replacement — because the stack is code, not something clicked together by hand.

  Data loss

  Up to the gap since the last backup — typically under 24 hours.

  While it happens

  Brief downtime while the replacement stands up.

• You want a copy of something from last Tuesday

  Ask through the same quote channel — pulling an old backup for a look is routine, not an escalation.

  Data loss

  None. This is a read, not a rollback.

  While it happens

  Nothing about the live system changes to answer this.

1. You

   Say what's gone, and roughly when it was last right

   Through the quote form — what happened, and the last time it looked correct.

   ~10 min
2. CustomHosted

   The right path gets picked

   A revert, a backup restore, or a point-in-time rollback — whichever fits what actually happened.

   Nothing
3. CustomHosted

   Restored into a throwaway copy first

   The chosen backup or moment in time is pulled into a copy of the stack, not applied straight to the live one.

   Nothing
4. You

   Confirm it's the right copy

   A look at what came back before it replaces anything live.

   ~10 min
5. CustomHosted

   The copy is promoted

   The confirmed copy replaces the broken one, and traffic is already pointed at it.

   Nothing
6. CustomLabs

   If the cause was a code bug, not just data

   The fix ships as a briefed change through the same pipeline, once the data itself is back.

   Nothing
7. You

   Confirm it's really back

   A quick check on your end closes it out.

   ~5 min

1. 1

   Restore into a throwaway environment

   A real backup, pulled into a copy of the stack that is never the live one.

2. 2

   Boot the app against it

   Start the application on top of the restored data — a running check, not just a file check.

3. 3

   Walk the traffic paths that matter

   Log in, load the pages that hit the database directly, confirm the data matches the moment it was taken from.

4. 4

   Write down what broke

   If a step needed a manual fix or ran long, that goes in the record — a drill that always goes perfectly is not being run honestly.

5. 5

   Destroy the copy

   The throwaway environment comes back down. Nothing about the drill ever touches the live system.

• Anything past the retention window

  Once a backup ages out, it's gone. Ask before the window closes, not after.

• A compliance archive

  A backup is built to restore a broken system, not to satisfy a multi-year audit requirement — that's a separate, deliberate arrangement, not something a nightly backup happens to double as.

• Data held in a third-party service

  Anything living in a service we don't run — a payment processor, an email platform, an analytics tool — backs up on that service's own schedule, not ours.

• A change you asked for and regret

  That's a revert, not an incident — the first failure mode above, not this one.

One number is deliberately missing from this page: a stopwatch recovery-time figure. We haven't measured one across every stack we run, and an invented number is exactly the kind of claim this site refuses to print — what we publish instead is the procedure above, the retention window for your tier, and who to ask.

1. 01How fast will my site be back?

   We don't publish a stopwatch recovery-time figure, because we haven't measured one across every stack we run, and an invented number would be exactly the kind of claim this site refuses to print. What we publish instead: the procedure above, the retention window for your tier, and who to ask.

2. 02How much data can I actually lose?

   It depends on the tier. Every plan keeps daily backups · 7-day retention by default, so the most you can lose to a plain restore is the gap since the last nightly run. The PITR tiers cut that down to minutes — see the retention ladder above.

3. 03What does a restore cost, on my side?

   Under 25 minutes of your own time, spread across the steps above — mostly confirming what came back rather than doing anything yourself.

4. 04Do you actually test the backups, or just take them?

   Both. Taking a backup nightly and never restoring it is a false sense of security — the drill above runs against a throwaway copy, on a schedule, specifically to catch a backup that looks fine but wouldn't actually boot.

5. 05What if the problem is a bug in my own code, not lost data?

   That still isn't a restore — see the first failure mode above. Revert the merge and the same pipeline redeploys the last working version, no data touched at all.

6. 06Can I just ask for an old copy without it being an emergency?

   Yes — pulling a backup from a specific day for a look is routine, not an incident. Ask through the same channel as everything else.