MongoDB Backup Print

  • ecb, backup, mongo, mongodb
  • 0

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

Efficient Cloud 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 Efficient Cloud Backup's chunking deduplication engine without requiring any temporary disk space. All backup jobs require only incremental storage using Efficient Cloud Backup'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. Efficient Cloud Backup 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

Efficient Cloud Backup will search the PC for the system installed mongodump and mongo shell binaries. If your binaries are installed in a normal system location, Efficient Cloud Backup will find and use the most recent available binary. If you have special requirements, or if Efficient Cloud Backup 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.

Efficient Cloud Backup 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
    • Efficient Cloud Backup 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 Efficient Cloud Backup device.
    • When using Replica Set connection in Efficient Cloud Backup, Efficient Cloud Backup will only read data from one of the members. You can use the "read preference" option to choose which MongoDB server Efficient Cloud Backup will prefer to back up from.
      • Primary
        • Efficient Cloud Backup will attempt to back up from the primary. If the primary server is unreachable, the backup job will fail.
      • Primary preferred
        • Efficient Cloud Backup will attempt to back up from the primary, but will back up from the secondary if the primary is unreachable.
      • Secondary
        • Efficient Cloud Backup will attempt to back up from the secondary. If the secondary server is unreachable, the backup job will fail.
      • Secondary preferred
        • Efficient Cloud Backup 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 Efficient Cloud Backup device.

Efficient Cloud Backup 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 

Efficient Cloud Backup 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 Efficient Cloud Backup (e.g. neither Kerberos / LDAP when using MongoDB Enterprise; nor, custom authentication mechanisms used by MongoDB software variants).

Sharding 

Efficient Cloud Backup can backup a MongoDB replica set with a consistent point-in-time snapshot.

Efficient Cloud Backup 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 Efficient Cloud Backup 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 Efficient Cloud Backup, enter the mongos front-end server in the Efficient Cloud Backup connection details.

When backing up from a mongos server, Efficient Cloud Backup 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.

Efficient Cloud Backup will back up all MongoDB collections within the selected MongoDB databases.

Restore 

Efficient Cloud Backup'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

Was this answer helpful?

« Back