TableCore
Sign in

Restoring a backup

Requires Pro (RestoreBackup). See Plans and Pro features.

This is the recovery page, so it leads with the destructive cases.

What a restore can cost you

Before you press it

  • A restore writes into a live database. Documents whose _id already exists are replaced by the archived version. Whatever was in them is gone.
  • Documents that are not in the archive are left alone. A restore is not a reset: a collection ends up holding the union of what was there and what was archived, not a copy of the archive.
  • It is not atomic. An interrupted restore leaves a database part restored, and there is no undo.
  • Restore is blocked on a read-only connection, which is the recommended state for production. That refusal is doing its job — change the connection deliberately, once, rather than working around it.
  • Restore into a new database name first whenever you can. It costs disk and nothing else, and it turns "I hope this archive is good" into a fact you can check.

Choosing what to restore

The restore dialog has one field that decides what happens: the archive path. You can type it, or fill it with the native picker — separately for a .zip file and for a directory, because an uncompressed backup is a directory and no single system dialog picks both.

The list of archives found in your backup directory only fills that field in. Pointing at a path from outside the directory clears the selection in the list, so the list can never contradict the path.

A path from outside the list is validated before the button is enabled: an unreadable archive is refused right there rather than when you try to restore it.

Choosing where it goes

A restore always lets you pick the target connection and the target database name, independently of where the archive came from. That is the point of the feature — moving a database between environments. The database name in the archive is only a suggestion that pre-fills the field.

So the three shapes you will use are:

You wantDo
To recover after a mistakeRestore into a new database name, check it, then swap
To copy production into stagingPick the staging connection and the staging database name
To restore in placeRestore over the same database, knowing the rules above

How it runs

Each collection is created with a raw create command carrying the saved options — capped, validator and the rest — and its indexes are rebuilt with createIndexes after the documents are inserted. The _id_ index and the ns/v fields from the metadata are skipped: they belong to the source server.

A truncated .bson file is reported as an error rather than restoring half a document.

Verifying that it worked

An unverified restore is a belief, not a backup. Three checks, in order of how much they prove:

  1. Counts. Compare the document count of each restored collection against the count recorded in the archive's manifest — the restore dialog shows both. If the archive has no manifest, the count was already unknown; that is one more reason to keep the manifest.
  2. Indexes. Open the index dialog on a restored collection. Indexes are the part that is rebuilt separately and therefore the part that can be missing while the data looks fine.
  3. A query you know the answer to. Run one that touches real data — a total, a recent record, a document you can recognise. A count matches when the documents are all there and all wrong far less often than never, but it is the query that convinces you.

If you restored into a new database name, do all three there and only then switch over. That order is the whole reason to restore into a new name.

What is not restored

Users, roles, server settings and the oplog are not in the archive, so they are not restored. If your application depends on a database user that existed on the source server, it will not exist on the target because of this.

Related

  • Backups — the archive format, and why mongorestore can read it too.
  • Migrating from SQL — for data that is not in MongoDB yet.