Someone deleted 400 customer records. Here is how you get them back.

The usual answer is last night. An overnight snapshot means everything entered between midnight and the mistake goes too, including a morning's work by people who did nothing wrong.

Shoovels can put the database back to any moment you name, down to the second. If the import ran at 14:12, you go back to 14:11 and the morning survives.

How going back to 14:11 works

No backup was taken at 14:11, and there doesn't need to be one.

What exists is a recent full copy of the database, plus a continuous record of every change made to it since. To reach 14:11, the platform starts from that copy and replays the changes in order up to the second you picked, then stops. You get the database as it was at that moment.

So you don't scroll through a list of snapshots looking for the closest one. You pick a date, then a time. The range you can go back to is shown before you confirm anything.

The backups that are files

Alongside that, ordinary backups do exist as real files: one taken automatically every day, plus any you take yourself. Those you can list and filter by day, environment and status, restore, download or keep permanently.

Production backups are kept for as long as the project exists. Staging backups are kept for a month.

The two answer different questions. Reach for a backup file when you want a specific known-good state, like the database the day before a migration. Reach for the rewind when you want the minute before something went wrong.

Check on staging first

Rebuild a staging instance from production at that same moment. Same data, same version, nobody else using it. Open the records, make sure they're back and that you landed on the right side of the mistake. Then restore production to that moment.

It takes a bit longer, but it saves you from restoring production twice.

Backups you take on purpose

Before an import, a module upgrade, or anything you would rather be able to undo, take a backup yourself. With or without the filestore. Keep it permanently if it marks something worth keeping.

It is not strictly necessary now that you can rewind to any moment, but it is a labelled point you chose, which is easier to find in six months than a timestamp you would have to remember.

Copies that leave the platform

Any backup can be downloaded as a password protected archive, for your own records or your own retention rules.

You can also neutralise the copy, which switches off outgoing email, payment providers and scheduled jobs. Worth doing when the copy is going to a developer or into a test environment, so nothing reaches real customers by accident.

Worth knowing

Going back replaces the current data with the earlier state. Anything written after the moment you pick is gone, which is why the staging check is worth the time.

On production, turn on maintenance mode before you restore, so visitors see a holding page instead of a half restored site. Tick the safety backup too, so the restore itself can be undone.

Restoring, going back in time and downloading need User or Admin rights on the project. A Viewer can see the backups but can't act on them.