Docs Menu
Docs Home
/
MongoDB Ops Manager
/ /

Restore a Replica Set from a Snapshot

On this page

  • Considerations
  • Prerequisites
  • Restore a Snapshot

When you restore a replica set from backup, Ops Manager provides you with a restore file for the selected restore point. To learn about the restore process, please see Restore Overview.

The BSON specification changed the default subtype for the BSON binary datatype (BinData) from 2 to 0. Some binary data stored in a snapshot may be BinData subtype 2. The Backup automatically detects and converts snapshot data in BinData subtype 2 to BinData subtype 0. If your application code expects BinData subtype 2, you must update your application code to work with BinData subtype 0.

Tip

See also:

The notes on the BSON specification explain the particular specifics of this change.

The backup restore file includes a metadata file named restoreInfo.txt. This file captures the options the database used when the snapshot was taken. The database must be run with the listed options after it has been restored. This file contains:

  • Group name

  • Replica Set name

  • Cluster ID (if applicable)

  • Snapshot timestamp (as Timestamp at UTC)

  • Restore timestamp (as a BSON Timestamp at UTC)

  • Last Oplog applied (as a BSON Timestamp at UTC)

  • MongoDB version

  • Storage engine type

  • mongod startup options used on the database when the snapshot was taken

  • Encryption (Only appears if encryption is enabled on the snapshot)

  • Master Key UUID (Only appears if encryption is enabled on the snapshot)

    If restoring from an encrypted backup, you must have a certificate provisioned for this Master Key.

All FCV databases must fulfill the appropriate backup considerations.

To perform manual restores, you must have the Backup Admin role in Ops Manager.

To restore from an encrypted backup, you need the same master key used to encrypt the backup and either the same certificate as is on the Backup Daemon host or a new certificate provisioned with that key from the KMIP host.

If the snapshot is encrypted, the restore panel displays the KMIP master key id and the KMIP server information. You can also find the information when you view the snapshot itself as well as in the restoreInfo.txt file.

You must ensure that the MongoDB deployment does not receive client requests during restoration. You must either:

  • Restore to new systems with new hostnames and reconfigure your application code once the new deployment is running, or

  • Ensure that the MongoDB deployment will not receive client requests while you restore data.

Important

Rotate Master Key after Restoring Snapshots Encrypted with AES256-GCM

If you restore an encrypted snapshot that Ops Manager encrypted with AES256-GCM, rotate your master key after completing the restore.

← Restore a Sharded Cluster from a Snapshot