MMS Backup is a relatively new offering by MongoDB for real-time incremental backup of your MongoDB instances, replica sets, and shards, and offers you point in time recovery of your instances. The service is available as on-premise (in your data center) or cloud. However, we will demonstrate the on-cloud service that is the only option for the Community and Basic subscription. For more details on the available options, you can visit different product offerings by MongoDB at https://www.mongodb.com/products/subscriptions.
Mongo MMS Backup service will work only on Mongo 2.0 and above. We will start a single server that we will backup. MMS backup relies on the oplog for continuous backup and since oplog is available only in replica sets, the server needs to be started as a replica set. Refer to the recipe Connecting to a single node using a Python client in Chapter 1, Installing and Starting the Server to learn more about how to install Python and PyMongo, the Python client of Mongo.
If you don't already have a MMS account, then log in to https://mms.mongodb.com/ and sign up for an account. For screenshots, refer to the recipe Signing up for MMS and setting up an MMS monitoring agent in this chapter.
- Start a single instance of Mongo and replace the value of the appropriate filesystem path on your machine:
$ mongod --replSet testBackup --smallfiles --oplogSize 50 --dbpath /data/mongo/dbNote that the
smallfilesandoplogSizeare options only set for testing purposes and are not to be used in production. - Start a shell, connect to the instance in step 1 and initiate the replica set as follows:
> rs.initiate()The replica set will be up and running in some time.
- Go back to the browser to
mms.mongodb.com. Add a new host by clicking on the + Add Host button. Set the type as replica set and the hostname as your hostname and the port as the default one27017in our case. Refer to the recipe Signing up for MMS and setting up an MMS monitoring agent for the screenshots of the Add Host process. - Once the host is successfully added, register for MMS backup by clicking on the Backup option the left and then Begin Setup.
- An SMS or Google authenticator can be used for registration. If a smartphone is available with Android, iOS, or Blackberry OS, Google authenticator is a good option. For countries like India, Google Authenticator is the only option available.
- Assuming Google Authenticator is not configured already and we are planning to use it, we would need the app to be installed on your smartphone. Go to the respective app store of your mobile OS platform and install the Google Authenticator software.
- With the software installed on the phone, come back to the browser. You should see the following screen on selecting the Google Authenticator:
- Begin the setup for a new account by scanning the QR code from the Google Authenticator application. If barcode scanning is a problem, you may choose to manually enter the key given on the right side of the screen.
- Once the scanning or the key is entered successfully, your smartphone should show a 6-digit number that changes every 30 seconds. Enter that number in the Authentication Code box given on the screen.
Note
It is important not to delete this account in Google Authenticator on your phone as this will be used in future whenever we wish to change any settings related to backup, such as stopping backup, changing exclusion list, and almost any operation in MMS backup. The QR code and key will not be visible again once the setup is done. You will have to contact MongoDB support to get the configuration reset.
- Once the authentication is done, the next screen you should see is the billing address and billing details, such as the card you register. All charges below $5 are waived so you should be ok to try out a small test instance before being charged.
- Once the credit card details are saved, we move ahead with the setup. We will have for installation a backup agent. This is a separate agent from the monitoring agent. Choose the appropriate platform and follow the instructions for its installation. Take a note of the location where the configuration files of the agent will be placed.
- A new popup will contain the instruction/link to the archive/installer for the platform and the steps to install. It should also contain the
apiKey. Take a note of the API key; we will need it in the next step. - Once the installation is complete, open the
local.configfile placed in theconfigdirectory of the agent installation (the location that was shown/modified during installation of the agent) and paste/type in theapiKeynoted down in the previous step. - Once the agent is configured and started, click on the Verify Agent button.
- Once the agent is successfully verified, we will start by adding a host to back up. The drop-down menu should show us all the replica sets and shards we have added. Select the appropriate one and set the Sync source as the primary instance, as that is the only one we have in our standalone instance. Sync source is only used for the initial sync process. Whenever we have a proper replica set with multiple instances, I prefer using a secondary as a sync process instance.
Since the instance is not started with security, leave the DB Username and DB Password fields blank.
- Click on the button Manage excluded namespaces if you wish to skip a particular database or collection being backed up. If nothing is provided, by default everything will be backed up. The format for the collection name will be
<databasename>.<collection name>. Alternatively, it could be just the database name, in which case all collections in that database would not be eligible for backup. - Once the details are all ok, click on the Start button. This should complete the setup of the backup process for a replica set on MMS.
The steps are pretty simple and this is all we need to do to set up a server for Mongo MMS backup. One important thing mentioned earlier is that MMS backup uses multifactor authentication for any operation once the backup is set up, and the account set up in Google Authenticator for MongoDB should not be deleted. There is no way to recover the original key used for setting up the authenticator. You will have to clear the Google Authenticator settings and set up a new key. To do that, click on the Help & Support link in the bottom-left corner of the screen and click on How do I reset my two-factor authentication?.
On clicking the link, a new window will open up and ask for the username. An e-mail will be sent out to the registered e-mail ID which allows you to reset the two-factor authentication.
As mentioned, oplog is used to synchronize the current MongoDB instance with the MMS service. However, for the initial sync, an instance's data files are used. The instance to use is provided by us when we set up the backup of replica set. As this is a resource-heavy operation, I prefer to use a secondary instance for this on busy systems so as not to add more querying on the primary instance by the MMS backup agent. Once the instance is done with initial synchronization, the oplog of the primary instance will be used to get the data on a continuous basis. Agent does write to a collection called mms.backup in admin database periodically.
The backup agent for MMS backup is different from the MMS monitoring agent. Though there is no restriction on having them both running on the same machine, you might need to evaluate that before having such a setup in production. The safe bet would be to have them running on separate machines. Never run either of these agents with a mongod or mongos instance on the same box in production. There are a couple of important reasons why it is not recommended to run the agent on the same box as the mongod instances:
- The resource utilization of the agent is dependent on the cluster size it monitors. We don't want the agent to use a lot of resources affecting the performance of the production instance.
- The agent could be monitoring a lot of server instances at a time. Since there is only one instance of this agent, we do not want it to go down during database server maintenance and restart.
The community edition of MongoDB built with SSL or enterprise versions with the SSL option used for communication between the client and the mongo server must do some additional steps. The first step is to check the My deployment supports SSL for MongoDB connections flag when we set up the replica set for backup (see step 15). Note the check box at the bottom in the screenshot that should be checked. Secondly, open the local.config file for the MMS configuration and look out for these two properties:
sslTrustedServerCertificates= sslRequireValidServerCertificates=true
The first is the fully qualified path of the certifying authority's certificate in PEM format. This certificate will be used to verify the certificate presented by the mongod instance running over SSL. The second property can be set to false if certificate verification is to be disabled, this is however not a recommended option. As far as the traffic between the backup agent and MMS backup is concerned, data sent from the agent to the MMS service over SSL is secure irrespective of whether SSL is enabled on your MongoDB instances or not. The data at rest in the data center for the backed up data is not encrypted.
If security is enabled on the mongod instance, a username and password need to be provided, which will be used by the MMS backup agent. The username and password are provided while setting up backup for the replica set, as in step 15. Since the agent needs to read the oplog, possibly all databases for the initial sync and write data to admin database the following roles are expected for the user: readAnyDatabase, clusterAdmin, readWrite on admin and local databases, and userAdminAnyDatabase. This is in case in version 2.4 and above. In versions prior to v2.4, we would expect the user to have read access on all the databases and read/write access to admin and local databases.
While setting up a replica set for backup you may get an error like, Insufficient oplog size: The oplog window must be at least 1 hours over the last 24 hours for all active replica set members. Please increase the oplog.. While you may think this is always something to do with oplog size, it is also seen when the replica set has an instance that is in recovering state. This might feel misleading, so do look out for recovering nodes, if any, in the replica set while setting up a backup for a replica set. As per the MMS support too, it seems too restrictive to not set up a replica set for backup with some recovering nodes, and it might be fixed in the future.