Navigation
This version of the documentation is archived and no longer supported. It will be removed on EOL_DATE. To learn how to upgrade your version of MongoDB Ops Manager, refer to the upgrade documentation.
You were redirected from a different version of the documentation. Click here to go back.
This version of the manual is no longer supported. It will be removed on EOL_DATE.

Manage Blockstore Snapshot Storage

Ops Manager can back up MongoDB databases as snapshots to one or more of the following storage options:

  • Another MongoDB database, called a Blockstore,
  • As files stored on a local or network-attached file system, and/or
  • An AWS S3 bucket.

This tutorial covers backing up your MongoDB databases to snapshots stored in other MongoDB databases. Blockstores can exist on any MongoDB instance that Ops Manager can access.

Note

You may have issues that require you to use more than one snapshot store like needing more capacity, localizing data, or meeting privacy regulations. To learn how to assign snapshot stores to different data centers, see Assign Snapshot Stores to Specific Data Centers.

Prerequisites

Before creating any blockstore snapshot stores:

  • Ensure storage volumes with sufficient capacity to store the blockstore and the Oplog Store MongoDB database is attached to the Ops Manager or MongoDB host. The Oplog Store does not need to reside on the same host as the blockstore. The Oplog Store can be created using the same replica set as the blockstore if you need to conserve storage and compute resources.
  • Deploy the dedicated MongoDB instance(s) to host the blockstore database and Oplog Stores.
  • Ensure the host running the Ops Manager Backup Daemon service has sufficient capacity to store the head database.
  • Secure the instance that stores your blockstores using authentication and SSL. Blockstores support all authentication mechanisms.

Add a Blockstore

1
2

Click Create New Blockstore.

3

Provide the blockstore details.

Field Contents
Name A name for the blockstore
Datastore Type Select Standalone, Replica Set or Sharded Cluster.
MongoDB Host List (replica set and sharded cluster only)

Type a comma-separated list of mongod instances (for a Replica Set) or mongos instances (for a Sharded Cluster) in the <hostname:port> format that comprise the blockstore database.

Example

host1.example.com:27017, host2.example.com:27017, host2.example.com:27018

MongoDB Hostname (Standalone only) Type the hostname of the standalone MongoDB instance.
MongoDB Port (Standalone only) Type the port number of the standalone MongoDB instance.
Username
Auth Mechanism Action Configure Instructions
Username and Password (SCRAM-SHA-1) Type the name of the user authorized to access the blockstore database. SCRAM
x.509 (X.509) Type the RFC2253-formatted subject from the client certificate of the user authorized to access the blockstore database. x.509
Kerberos (GSSAPI) Type the UPN of the user authorized to access the blockstore database. Kerberos
LDAP (PLAIN) Type the name of the LDAP user authorized to access the blockstore database. LDAP
Password (optional)

Warning

If you did not use the credentialstool to encrypt this password, it is stored as plaintext in the database.

Auth Mechanism Action Configure Instructions
Username and Password (SCRAM-SHA-1) Type the password associated with the username that can access the blockstore database. SCRAM
x.509 (X.509) Leave it blank. x.509
Kerberos (GSSAPI) Kerberos retrieves the password from its keytab file. You do not need to type a password into this field. Kerberos
LDAP (PLAIN) Type the password of the LDAP user authorized to access the blockstore database. LDAP
Connection Options (optional)

Type any additional configuration file options for the MongoDB instance. This field supports unescaped values only.

For proper syntax, see Connection String URI Format in the MongoDB manual.

Encrypted Credentials (optional) Select if the Username and Password for the database were encrypted using the credentialstool.
Use TLS/SSL (optional)

Select if the blockstore database requires TLS encryption.

Beyond this checkbox, to connect this blockstore using TLS, you must enable:

  • TLS on the blockstore database.

  • Ops Manager to use TLS to connect to this blockstore.

    Note

    All backing databases share the same TLS certificates. If you have enabled TLS for another backing database, you need only select this checkbox to enable a TLS connection to this blockstore.

New Assignment Enabled (optional) Select if you want to enable this blockstore after creating it. This is selected by default so the blockstore can be assigned backup jobs. If you clear this checkbox, the blockstore is created but you cannot assign backups to this blockstore.
4

Click Create.

Edit an Existing Blockstore

Once created, blockstores are listed directly on the Snapshot Storage page in a table. Each row contains the settings for each blockstore.

1

Navigate to the Snapshot Storage page.

  1. Click the Admin link.
  2. Click the Backup tab.
  3. (Optional) If you have not previously set the head directory, set it in the Head Directory box.
  4. Click the Snapshot Storage page.
2

Go to the row for the blockstore you want to edit.

3

In the MongoDB Connection column, update any values that need to be changed in the following fields:

Field Contents
<hostname>:<port>

Type in one or more hosts that comprise the blockstore database in the <hostname:port> format.

Important

If these hosts are changed, the blockstore database they host must have the same data as the original blockstore database. Changing the host to a new blockstore databases results in data loss.

  • If the blockstore database is a Replica Set or Sharded Cluster, type a comma-separated list of mongod instances (for a Replica Set) or mongos instances (for a Sharded Cluster).

    Example

    host1.example.com:27017, host2.example.com:27017, host2.example.com:27018

  • If the blockstore database is a standalone MongoDB instance, type the hostname:port of the instance.

MongoDB Auth Username
Auth Mechanism Action Configure Instructions
Username and Password (SCRAM-SHA-1) Type the name of the user authorized to access the blockstore database. SCRAM
x.509 (X.509) Type the RFC2253-formatted subject from the client certificate of the user authorized to access the blockstore database. x.509
Kerberos (GSSAPI) Type the User Principal Name of the user authorized to access the blockstore database. Kerberos
LDAP (PLAIN) Type the name of the LDAP user authorized to access the blockstore database. LDAP
MongoDB Auth Password

Warning

If you did not use the credentialstool to encrypt this password, it is stored as plaintext in the database.

Auth Mechanism Action Configure Instructions
Username and Password (SCRAM-SHA-1) Type the password associated with the username that can access the blockstore database. SCRAM
x.509 (X.509) Leave it blank. x.509
Kerberos (GSSAPI) Kerberos retrieves the password from its keytab file. You do not need to type a password into this field. Kerberos
LDAP (PLAIN) Type the password of the LDAP user authorized to access the blockstore database. LDAP
Encrypted Credentials Select if the Username and Password for the database were encrypted using the credentialstool.
Use TLS/SSL

Select if the blockstore database only accepts connection encrypted using TLS.

Beyond this checkbox, to connect this blockstore using TLS, you must enable:

  • TLS on the blockstore database.

  • Ops Manager to use TLS to connect to this blockstore.

    Note

    All backing databases share the same TLS certificates. If you have enabled TLS for another backing database, you need only select this checkbox to enable a TLS connection to this blockstore.

Connection Options Type any additional configuration file options for the MongoDB instance. This field supports unescaped values only.
Assignment Labels Type a comma-separated list of labels to assign the blockstores to specific projects.
Blockstore Max Capacity (GB) Type a maximum size for a blockstore.
Load Factor

Type any positive integer that expresses how much backup work you want this snapshot store to perform compared to another snapshot store.

Important

If you have only one snapshot store, skip this setting.

Backup work includes running backups, restoring snapshots or grooming blockstores. The term of backup work ratio assigned to a single snapshot store is called its Load Factor.

By default, Ops Manager assigns each snapshot store a Load Factor of 1. This means each snapshot store would perform the same amount of backup work.

As a snapshot store’s Load Factor increases, it performs more backup work compared to another snapshot store. If the Load Factor of snapshot store A is set to 2 and the Load Factor of snapshot store B is set to 1, A performs two times the backup work of B.

Example

How to estimate Load Factor

Consider a five-shard sharded cluster with the following backup storage configuration:

  • File system store (F) manages the backup work for one shard in the cluster. F is running on a single two-core physical server.
  • Blockstore (B) manages the backup work for four shards in the cluster. B is running as a four-node sharded cluster on four physical servers with two cores on each server.

In this example, B has four times the capability of F. B should receive the greater part of the ratio of backup work: 4:1. For every one backup task F performs, B performs 4.

Set the Load Factors of B to 4 and F to 1.

Snapshot stores with greater compute or storage performance should be given a greater Load Factor:

  • A file system store with 16-cores and 128 GB of RAM can back up more databases in less time than a file system store with only 2 cores and 8 GB of RAM.
  • A blockstore backed by a 10-node sharded cluster can back up more databases and groom more databases than a blockstore backed by a single replica set.

Load Factor can be set to 0. When one snapshot store’s Load Factor is set to 0, it performs no backup work at all. If a snapshot store’s Load Factor is changed while backup work is in progress, all jobs or tasks running on that snapshot store are allowed to finish. All future backup work then is re- distributed among the remaining snapshot stores with a Load Factor of 1 or greater and have Assignment Enabled selected.

Write Concern

Select your preferred Write Concern:

Default
Deployment Type Default Write Concern
Standalone Journaled
Replica sets or sharded clusters W2
Journaled A primary or standalone MongoDB instance acknowledged the write and wrote that write to their on-disk journals.
Acknowledged A primary or standalone acknowledged the write.
W2 More than one of the cluster members acknowledged the write.
Majority A majority of the replica set members acknowledged the write.
4

Select the checkbox in the Assignment Enabled column.

Select if you want to enable this blockstore after creating it. This is selected by default so the blockstore can be assigned backup jobs. If you clear this checkbox, the blockstore is created but you cannot assign backups to this blockstore.

5

Click Save.

6

If you change any connection string values or the Write Concern, restart all the Ops Manager instances including those running Backup Daemons.

Warning

Modifying the connection string values or the Write Concern for an existing blockstore requires you to restart all Ops Manager components, including those only running the Backup Daemon to apply those changes. Connection parameters include:

  • <hostname>:<port>
  • MongoDB Auth Username
  • MongoDB Auth Password
  • Encrypted Credentials
  • Use TLS/SSL
  • Connection Options
  • Write Concern

If you change to another blockstore host, the data on the existing blockstore is not copied automatically to the other blockstore.

See also

For more details on the MongoDB connection string uri, see Connection String URI Format in the MongoDB Manual.

Delete a Blockstore

1

Navigate to the Snapshot Storage page.

  1. Click the Admin link.
  2. Click the Backup tab.
  3. (Optional) If you have not previously set the head directory, set it in the Head Directory box.
  4. Click the Snapshot Storage page.
2