Backup and recovery¶
The following section describes the backup and recovery features of the hosted MongoDB offering from ObjectRocket.
Overview¶
A typical configuration of a Mongodb instance utilizes a three-node replica set for a sharded cluster and for individual replica set instances.
This configuration ensures that if a component fails, the MongoDB replica set architecture provides the primary level of high availability, fault tolerance, and uptime. ObjectRocket also performs daily backups to complement the high availability and for overall data protection.
Backups¶
Note
ObjectRocket performs backups daily and retains 14 successful backups by default. You can contact the Support team to change the schedule or retention period. Backups are taken per instance. View a list of backups by selecting the name of a MongoDB or Elasticsearch instance and then by selecting Backups.
ObjectRocket performs backups by using mongodump. These backups are archived internally on the ObjectRocket system. For sharded instances, backups are designed by using best practices to ensure they’re as consistent as possible among the members of an instance. ObjectRocket backs up each instance and each shard individually.
Recovery options¶
This section describes the available recovery options.
Download a backup¶
Each backup is available for download. Email the Support team and tell them which backup you need. You can access a list of backup images in the ObjectRocket control panel for each instance by selecting Backups. ObjectRocket can upload backups to S3 or Cloud Files, but other methods are also possible, if necessary.
In-place restore¶
You can replace or recover an existing instance with a backup image. The backup image data replaces all data in the existing instance, essentially rolling back the entire instance. Email the Support team to request an in-place recovery.
Delayed slaves¶
You can use a time-delayed replica set member to fix code release, mistyping, or other human errors. In the event of an issue, the replica is manually stopped and opened in a read-only mode. Then the data is pieced back together. If you want to add a delayed slave to an instance, email the Support team. There is an extra cost for this feature because it lets tools and scripts directly access the delayed slave via a virtual IP address. Recovery requires knowledge of the schema, application, and customer data. It is a customer responsibility beyond the core components provided by ObjectRocket.
Data validation options¶
The following section describes the available data validation options.
Continuous data validation¶
You might need to validate data occasionally. To accomplish this, point a diff tool or other comparison tool that you created at a slave instance and compare it against some other known archive. You can do this on the ObjectRocket system by pointing the tools at either a regular or delayed slave. In the case of a regular slave, set read preference to secondary. In the case of a delayed slave, you should use the virtual IP address provided for access.
Point-in-time data validation¶
If you need a point-in-time comparison data set, use a downloaded backup image in your environment for comparison.