Restore a Sharded Cluster from a Snapshot

Review change to BinData BSON sub-type

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.

Restore using settings given in restoreInfo.txt

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

Snapshots when Agent Cannot Stop Balancer

Cloud Manager displays a warning next to cluster snapshots taken while the balancer is enabled. If you restore from such a snapshot, you run the risk of lost or orphaned data. For more information, see Snapshots when Agent Can't Stop Balancer.

Backup Considerations

All FCV databases must fulfill the appropriate backup considerations.

Encryption Considerations

Disable Client Requests to MongoDB during Restore

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.