MongoDB
MongoDB is a general purpose NoSQL database developed by MongoDB, Inc.
With Zmanda Pro, no temporary disk space is required: database content is streamed directly from the MongoDB server into Zmanda's chunking deduplication engine without requiring any temporary disk space. All backup jobs require only incremental storage using Zmanda'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
. Zmanda 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
Self-hosted MongoDB server software
MongoDB Community Server
MongoDB Enterprise Server
TokuMX / Percona Server for Mongo
Cloud-hosted MongoDB services (SaaS)
Zmanda will search the PC for the system installed mongodump
and mongo
shell binaries. If your binaries are installed in a normal system location, Zmanda will find and use the most recent available binary. If you have special requirements, or if Zmanda 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.
Zmanda Pro 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
Zmanda Pro 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 Zmanda Pro device.
When using the Replica Set connection in Zmanda, Zmanda will only read data from one of the members. You can use the "read preference" option to choose which MongoDB server Zmanda will prefer to back up from.
Primary
Zmanda will attempt to back up from the primary. If the primary server is unreachable, the backup job will fail.
Primary preferred
Zmanda will attempt to back up from the primary, but will back up from the secondary if the primary is unreachable.
Secondary
Zmanda will attempt to back up from the secondary. If the secondary server is unreachable, the backup job will fail.
Secondary preferred
Zmanda 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 Zmanda device.
Zmanda 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
Zmanda 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 textX.509
format.A private key password is optionally supported.
Other authentication mechanisms are not currently supported in Zmanda (e.g. neither Kerberos / LDAP when using MongoDB Enterprise; nor, custom authentication mechanisms used by MongoDB software variants).
Sharding
Zmanda can backup a MongoDB replica set with a consistent point-in-time snapshot.
Zmanda 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 Zmanda Pro 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 Zmanda, enter the mongos
front-end server in the Zmanda connection details.
When backing up from a mongos
server, Zmanda 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.
Zmanda Pro will back up all MongoDB collections within the selected MongoDB databases.
Restore
Zmanda'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 Restore as
as Files and Folders
backup OR Restore as
as Program Input
When you select Restore as Files and Folders
Zmanda Pro restore back the MongoDB backup as a
.bson
files on disk. You can then restore the.bson
file into the MongoDB using themongorestore
command.
When you select Restore as Program Input
during the restore using Program Input; Zmanda Pro will directly stream the restored data into the
STDIN
of themongorestore
command.
Last updated
Was this helpful?