Skip to main content

Restore patterns

A restore returns an application — or a whole environment — to a restore point that is still within your retention. It always replaces data, so every pattern below is a reviewed action with a named request rather than a button.

Backups covers what is kept and for how long. This page is about the ways a restore can be run, because choosing the pattern matters more than choosing the restore point.

What every restore has in common​

  • The archive is bound to a review. Its hash and the fingerprint of its expanded contents are both measured, and both are measured again on the way in. An archive swapped after the review stops the operation before the first deletion.
  • Writers are held while it runs. The application being restored stops serving for the duration; its siblings keep serving.
  • It is verified natively before the hold is released. The restored application is checked running, not just checked written.
  • Files and database travel together. They are captured as a matched pair and put back as one, so the site you get is internally consistent rather than a mixture of two moments.

Pattern 1 — roll back the live environment​

Use when a mistake has reached production and you want that environment back as it was.

Your users see an interruption for the duration of the write; the environment is serving again once the native verification passes. This is the pattern that changes what your customers see, so it is the one to choose deliberately rather than by default.

Pattern 2 — restore into a separate environment​

Use when you want the data back without disturbing what is serving — which is most of the time, when you are recovering from a mistake rather than rolling back production.

We restore into an environment that serves your users nothing, and hand you the result: its own address, its own administrator login, its own database identity. Your live site keeps serving throughout, so there is no interruption at all, and you move across — by pointing your domain, or by taking content from it — only after you have compared the two.

This is the pattern to ask for when you are not certain the restore point is the right one. It costs you a second environment while it exists, and it keeps the working one intact as the fallback.

Pattern 3 — one application, not the whole environment​

Use when only one application is wrong.

Each application is restored on its own, with its own database identity, so its siblings are not touched. If an environment runs two applications and only one is affected, this is the smaller change and the smaller interruption.

Choosing​

The situationThe pattern to ask for
One application is wrong; the rest is fine3 — restore that application
A mistake reached production and must be undone1 — roll back the live environment
You are unsure whether the restore point is right2 — restore into a separate environment
You need the data, not the site2 — then take what you need from it

What we need from you​

  1. The environment — Overview → Troubleshooting prints its own identifier for exactly this.
  2. The application you need back.
  3. The time you want to return to.
  4. Which pattern you want, or simply what you need to end up with, and we will tell you which one it is.

What a restore does not do​

  • It does not extend retention. A restore point older than your effective retention is already gone, and extending retention afterwards does not bring it back.
  • It does not merge. The restore point replaces what is there; work done since that point is not kept beside it.
  • It does not move your domain. Addresses follow the environment, so a restore into a separate environment has its own address until you point your domain at it.
  • It is not self-service. Nothing in the application overwrites live data on its own.

Next​