Skip to main content

MongoDB

Using this Protected Item type may incur a Booster charge.

MongoDB is a general purpose NoSQL database developed by MongoDB, Inc.

Comet Backup supports backing up MongoDB databases as a Protected Item type.

No temporary disk space is required: database content is streamed directly from the MongoDB server into Comet's chunking deduplication engine without requiring any temporary disk space. All backup jobs require only incremental storage using Comet's chunking technology.

Backing up data from your MongoDB server will cause some additional load on the MongoDB server for the duration of the backup job.

Version support

The underlying technology is mongodump. Comet will use your system installed mongodump version for best compatibility with the exact feature set of your MongoDB server. This is the officially supported mechanism for backing up a MongoDB database.

This technology is also compatible with MongoDB forks, variants and cloud services, including but not limited to

Comet will search the PC for the system installed mongodump and mongo shell binaries. If your binaries are installed in a normal system location, Comet will find and use the most recent available binary. If you have special requirements, or if Comet is unable to automatically detect the binary path, you can override the binary path to use a custom mongodump and mongo shell binary.

Connection details

Connection details should be set before picking databases for backup. Enter your MongoDB connection details in the lower part of the window.

Comet supports connecting to MongoDB in different ways:

  • Direct connection
    • Enter a hostname and port for the MongoDB server (mongod / mongos). The default port is 27017.
  • Direct connection through SSH tunnel
    • Comet will open an SSH tunnel to the remote server, and then run the locally installed mongodump binary against the forwarded port connection. The use of SSH as a transport layer is independent of whether SSL is also enabled (described below).
  • Replica set
    • You must specify the name of the replica set (e.g. rs0)
    • Add the hostname and port for each of the replica set members that are reachable from the Comet device.
    • When using Replica Set connection in Comet, Comet will only read data from one of the members. You can use the "read preference" option to choose which MongoDB server Comet will prefer to back up from.
      • Primary
        • Comet will attempt to back up from the primary. If the primary server is unreachable, the backup job will fail.
      • Primary preferred
        • Comet will attempt to back up from the primary, but will back up from the secondary if the primary is unreachable.
      • Secondary
        • Comet will attempt to back up from the secondary. If the secondary server is unreachable, the backup job will fail.
      • Secondary preferred
        • Comet will attempt to back up from the secondary, but will back up from the primary if the secondary is unreachable.
      • Nearest
        • This option will back up data from the server in the replica set that has the lowest latency (ping) to the Comet device.

Comet supports the following transport layers:

  • Plain
  • SSL (TLS)
    • If your MongoDB server is using self-signed certificates, you can choose whether to trust an invalid SSL certificate from the MongoDB server.

Authentication

Comet supports the following authentication mechanisms:

  • Unauthenticated
  • Username/password (SCRAM)
    • You must specify the authentication database for looking up the credentials inside MongoDB. The default authentication database is admin.
  • Client certificates (MONGODB-X509)
    • This option is only available if the MongoDB server connection is going over an SSL (TLS) transport layer.
    • To use this feature, you should have a .pem file that contains the client SSL (TLS) certificate, intermediates, and private key in text X.509 format.
    • A private key password is optionally supported.

Other authentication mechanisms are not currently supported in Comet (e.g. neither Kerberos / LDAP when using MongoDB Enterprise; nor, custom authentication mechanisms used by MongoDB software variants).

Sharding

Comet can backup a MongoDB replica set with a consistent point-in-time snapshot.

Comet can back up a sharded MongoDB cluster, but depending on your MongoDB server version, there are some limitations:

  • In MongoDB 4.2 and later, the backup may not be point-in-time consistent, unless writes are temporarily suspended to the MongoDB cluster (e.g. by running custom Before and After commands on the Comet Protected Item configuration).
  • If you are using a variant MongoDB engine (e.g. Amazon DocumentDB or Azure CosmosDB), different consistency guarantees may apply to sharded backups. You should check with your vendor for additional information.

To back up a sharded cluster in Comet, enter the mongos front-end server in the Comet connection details.

When backing up from a mongos server, Comet cannot make use of the "read preference" selection as data is proxied through mongos. The backup will read from the primary replica set member of each shard replica set.

Selecting databases

Use the plus button on the right to open a database browser, allowing you to select individual MongoDB databases for backup.

Comet will back up all MongoDB collections within the selected MongoDB databases.

Restore

Comet's MongoDB Protected Item type produces a .bson file for each selected MongoDB database. You can restore all databases, or selected databases only.

When restoring, you can choose to either

  • restore back to a .bson files on disk, and then import them into your MongoDB server; or
  • you can use the Program Input restore type to pipe the restore data directly back into your MongoDB server