Overview

Taking regular backups and knowing what to do to recover from data loss and corruption events are both very important. A multi-node replica set cluster helps protect against system failure, but it will not protect your data from human error (e.g., accidentally deleting data or deploying bad code). This is why backups are such a crucial part of any production database deployment.

In addition, taking and restoring backups is often a useful way to migrate known datasets between environments.

You can implement a backup and recovery strategy for your mLab-hosted deployment by using:

Using mLab’s backup system

mLab’s backup system offers an easy way, through the mLab management portal, for users to create a one-time backup or schedule recurring backups.

In addition, mLab’s backup system offers a easy ways to restore a backup into an mLab-hosted deployment.

Supported backup methods

There are two different methods used by mLab’s backup system to take a backup: using the mongodump tool or taking a block storage snapshot (i.e., filesystem snapshot).

For replica set cluster plans (Shared or Dedicated), mLab’s backup system exclusively takes backups from secondary members to minimize the impact of backups.

mongodump

For Sandbox or Shared plan deployments, the mLab backup system uses MongoDB’s mongodump tool. This utility queries your database deployment and creates BSON files which can then be used by the mongorestore tool to populate a database deployment.

Dedicated plan deployments can choose to use the mongodump method or use block storage snapshots as described in the following section.

mongodump is great for small MongoDB deployments because the resulting backup is both portable and space-efficient. However, it is not a good backup and recovery strategy for larger deployments because of how time- and resource-intensive the strategy can be; most importantly, mongorestore must rebuild indexes as part of the restore. Also, note that mongodump backups do not include the local database which includes the operations log (oplog).

When using the mongodump method through the mLab backup system, backups can be stored with mLab or in custom Amazon S3 buckets.

Block storage snapshot of underlying data files

Available for Dedicated plans only

Another way to create a MongoDB backup is to snapshot MongoDB’s underlying data files using a file system or “block-level” backup method.

On Dedicated plans, mLab’s backup system takes block storage snapshots to create backups of a MongoDB deployment at an exact moment in time. The mechanics of how these block storage snapshots are taken and how they can be used will vary by cloud provider. For example, we use Amazon EBS Snapshots on AWS, and we use Microsoft’s blob snapshot features on Azure.

Block storage snapshots are preferred for larger MongoDB deployments because they tend to be orders of magnitude faster to both take and restore than the mongodump/mongorestore method. In addition, block storage snapshots include the local database which holds the oplog while the mongodump method does not back up this operations log.

Creating backups

You can use mLab’s backup system to take a one-time backup or set up a backup plan to take backups on a recurring schedule.

Step-by-step guide

Backing up your Sandbox or Shared plan deployment
When you request a backup for your Sandbox or Shared plan deployment, the mLab backup system will use MongoDB’s mongodump utility to create it.

Follow these instructions to create backups for your Sandbox or Shared plan deployment:

Backing up your Dedicated plan deployment
Creating backups for your Dedicated plan deployment has an option not available with other plan types: the ability to choose between block storage snapshots or mongodump as the backup method.

By default, all newly provisioned Dedicated plans come with one daily recurring backup plan using the block storage snapshot method. You can delete this backup plan if you want and/or create additional backup plans to suit your needs.

Backups taken as block storage snapshots

Block storage snapshots are file system or “block-level” snapshots of MongoDB’s underlying data files. Backups of these types can only be stored in mLab’s cloud account:

Block storage snapshots are stored in mLab’s account with the same cloud provider and in the same region that your deployment is hosted on (e.g., AWS, Azure, or Google).

On AWS, if your deployment has encrypted data disks, EBS Snapshots of those disks can not be shared with another AWS account. However, if its data disks are not encrypted, EBS Snapshots can be shared with another AWS account. When you fill out the backup creation form, enter the AWS Account ID that you want to share the EBS Snapshot with. On Azure and Google Cloud Platform, block storage snapshots are not shareable.

EBS Snapshots (applicable to AWS only) are still owned and managed by mLab’s AWS account even if they are shared with another AWS account. If you’d like them to be owned and managed by your own AWS account, you can copy the EBS Snapshot to your own AWS account either manually or programatically via AWS’s API.

If you’re having trouble finding the EBS Snapshots that we have shared with your account through AWS’s management console, be sure to pull down the drop-down such that it says “Private Snapshots” in the same region that your mLab deployment is hosted.

Accessing backups

All completed backups appear under the “Backups” tab of each deployment with informative details such as when the backup started/ended, the size of the original source, the size of the resulting backup, and more.

Backups for deployments that have already been deleted can be accessed by going to the Account Settings page for your account and clicking on the “Backups” tab.

Backups taken using mongodump
For backups taken using mongodump, the icons on the far right side of each row allow you to delete, download, or view the log file for the backup. The backup itself is compressed into a .tar file and when extracted, the backup-related files are in the form of a binary dump which is the standard output of MongoDB’s mongodump utility.

If you need to programatically access your backups, one option is to store your backups in your own Amazon S3 bucket and use the boto python interface to access them.

Backups taken as block storage snapshots
For Dedicated plan deployments that use this method, block storage snapshots can be restored very quickly. See the Restoring a backup section below.

Additionally, for EBS Snapshots (AWS only), there is a button on the far right side of the row which, when clicked, allows you to share the EBS Snapshot with another AWS account. However, EBS Snapshots from deployments with encrypted data disk can not be shared with another AWS account.

Retention policies

Depending on the type of backup and where it is stored, the retention policy for backups taken using mLab’s backup system is based on the following rules:

If a deployment is deleted, the retention policy is the same as if the recurring backup plan were deleted (as specified above). Backups for deleted deployments can be accessed by going to the Account Settings page for your account and clicking on the “Backups” tab.

Restoring backups

Supported restore methods

There are two ways to restore a backup taken by mLab’s backup system:

Create a new deployment from a backup.

Replace an existing deployment with a backup.

Create a new deployment from a backup

If you want to use your mLab-created backup to create a new mLab deployment, follow these instructions:

Click “Submit Order” and your new deployment will be created using your selected backup.

Replace an existing deployment from a backup

Not available for Sandbox databases

When you restore a backup into an existing deployment, it is require that the target deployment be empty before we can replace it with a backup. You can either delete all the databases in your target deployment before attempting to do an in-place restore, or you will be prompted to delete it before the backup restore happens.

If you want to use your mLab-created backup to take the place of an existing mLab deployment, follow these instructions:

From your account’s Home page, navigate to the deployment into which you want to restore a backup.

Click the “Restore from backup” button.

Select the backup source (all eligible backups will be listed here).

Click the “Restore from backup” button again to start the process.

If you have not deleted all the databases in your deployment, you will be prompted to delete it before the backup restore happens.

If you want to delete all the databases in your deployment, you must manually enter your replica set ID as shown in the pop-up window.

This deployment will not be available for the duration of the restore. Also, all changes (i.e., inserts/updates/deletes) that occurred since the backup will be lost.

Restore considerations

mLab’s restore features will only allow options/actions that apply to a given backup. Therefore, it is important to keep in mind the following limitations and restrictions when restoring a backup. If you continue to have questions or problems while restoring your backup, contact our support team at support@mlab.com, and we’d be happy to help.

General limitations and restrictions

The MongoDB release version from which the backup was taken must match the target MongoDB release version.

For example, a backup taken from a deployment running MongoDB 3.0.5 can be restored into version 3.0.12 but not version 3.2.12.

To workaround this restriction, you can change the version of the source deployment prior to taking the backup or change the version of the target deployment prior to restoring.

The target deployment must be in the same mLab account.

Restoring from a block storage snapshot

In general mLab recommends restoring using a block storage snapshot whenever possible, as block storage snapshots are generally orders of magnitude faster to restore. That being said, there are certain restrictions specific to block storage snapshots that you must keep in mind:

The target deployment must be a Dedicated plan.

The target deploymnt must be in the same region as the backup source.

The target deployment’s storage capacity needs to be at least as big as the backup source’s storage capacity.

For restores of High Performance plan backups, the target must be another High Performance plan and/or a plan with 1 TB of storage capacity.

Only full deployment restores are possible (i.e., not possible to restore a single database).

Restoring from a mongodump

When it’s not possible to restore from a block storage snapshot, you can restore from a mongodump. Note the following restrictions when restoring from a mongodump:

If the target is a Sandbox, --oplogReplay is not possible.

This means that if you need a consistent restore to a Sandbox, you’ll need to ensure that no writes are occuring on the source while the mongodump is running.

The storage capacity of the target plan/deployment must be large enough to fit the restored mongodump.

The RAM available on the target must be sufficient to build all of the indexes in a reasonable amount of time.

Recommendations for common restore use cases

Below are some common backup restore use cases and mLab’s recommendations how to address them.

mLab always recommends restoring a block storage snapshot over a mongodump unless it’s not an option to restore a mongodump.

Human error causing lost data and/or corrupted data

Create a new deployment from a backup.

After the new deployment is running, retrieve the lost data/fix the corrupted data using the data from the new deployment.

Create another environment (e.g., development, staging, etc.)

Create a new deployment from a backup.

This method currently will not migrate the user(s) from the original backup to the new deployment. For security reasons, we highly recommend using different database user(s) from the production database(s).

Refresh of an existing non-production environment

Replace an existing deployement from a backup.

Fees

mLab does not charge for restoring backups. However, fees may apply when taking and storing backups (see below).

Backup fees for Sandbox and Shared plan deployments
Custom backups (i.e., backups taken using mLab’s backup system) incur a fee, charged on a per-run basis with fees determined by overall data size and storage option. For example, the table below shows the estimated monthly cost based on 30 days (i.e., 30 runs), calculating what you might pay for different data sizes and storage options.

The mLab management portal includes a command-line helper tool that provides pre-filled command-line strings specific to your database. You can copy and paste them directly into a terminal session, filling in any placeholders before executing the command.

To minimize the possibility of error, the versions of your target database, source database, and mongodump/mongorestore utility should match. For example: use mongodump 3.2 to restore a backup taken from MongoDB 3.2 into a MongoDB 3.2 database.

Note that the version of your mongodump/mongorestore utility must match the version of MongoDB you have deployed. If you have multiple MongoDB versions installed, be sure to use the correct one.

Basic method

Before you take a backup of a single database, you must first stop writes to that database.

Then, to take a backup of that database, run a command in a terminal window that looks similar to this:

Point-in-time method

Applicable to Dedicated plans only

If you have a Dedicated plan, you can take server-wide mongodumps to export all of the databases on the server.

This method is useful because it allows you to use the the --oplog and --oplogReplay options to mongodump and mongorestore (respectively). The options allow for a point-in-time snapshot of the server by also including the oplog in the dump. This oplog is then replayed when you use the --oplogReplay option upon restore.

When doing a point-in-time server-wide dump or restore you must use credentials to the admin database.

To take a backup of an entire server, run a command in a terminal window that looks similar to this:

All mongodump backups taken by mLab’s backup system are server-wide except for Sandbox plan backups. Use the --oplogReplay option with mongorestore to restore to the point in time when the mongodump completed.

Frequently Asked Questions

Help - I lost my data and do not have a backup!

Rest assured, we take daily system-level backups of the databases that we host for disaster recovery purposes. These backups are stored for a limited time (approximately one week), so in the event that you need to restore from a system-level backup, contact support@mlab.com and we will let you know if it’s available. If a backup is available, we will do our best to restore it for you.

It typically takes anywhere from three to 18 hours to restore a system-level backup. If you feel that you will need to self-service backup restores, we encourage you to create a custom backup plan.

I cannot mongodump because of a “system.users: not authorized” error

If you are running MongoDB 3.0 or above and trying to take a mongodump of a specific database you might encounter the following error:

Why can’t I restore my EBS Snapshot into a smaller plan?

The reason why our management portal is restricting what plans you can restore into is that AWS requires that EBS Volumes created from EBS Snapshots be at least as large as the original snapshot.

If your source deployment is on our High Performance line, note that the plans on this line utilize in-chassis/local disks for the electable nodes but also include a third, hidden node that is EBS-backed and designated for EBS Snapshot backups. This backup node often utilizes very large General Purpose SSD (gp2) EBS Volumes because performance on this volume type scales with volume size, and we need these backup nodes to keep up with the electable nodes. Therefore, if you’re restoring from an EBS Snapshot taken from our High Performance line, you will likely need to restore into the same High Performance plan as your source deployment or a Single-node High Storage M5+ plan.

I cannot find the EBS Snapshot that was shared

If you have shared your EBS Snapshot backup with your AWS account but cannot find your shared EBS Snapshot when you log into your AWS account, make sure that you are in the Amazon EC2 console and in the same region that your mLab deployment is hosted. Finally, make sure you have selected the drop-down option “Private Snapshots” from the snapshot filter list.

Note that EBS Snapshots from deployments with an encrypted data disk can not be shared with another AWS account.

When you start the mongod process set storage.directoryPerDB to true. Set the storage.engine to mmapv1 or wiredTiger depending on the storage engine of the source deployment.

“Stored in mLab’s cloud account” refers to either mongodump backups stored in mLab’s cloud container or block storage snapshots taken in mLab’s account with the cloud provider that your deployment is hosted on (e.g., AWS, Azure, or Google). ↩

Backup plans resulting in block storage snapshots stored in mLab’s account have a “number to keep” of 8 backups. This number is not customizable. ↩