Skip to main content

Good day All,

I am in the process of onboarding a MongoDB cluster in the backup environment. It is a 3-node replica set.

During the initial configuration and testing all the settings were left as default. This includes using the Native snap engine.
The backup fails due to insufficient free capacity/extents on the Volume Group. I understand how this need to be fixed.

What are the considerations for selecting a different Snap Engine? These MongoDB instances are located on VMWare.

Or is the only supported engine the Native one?https://community.commvault.com/commvault-q-a-2/backup-mongodb-without-intellisnap-4327

 

Since mongodump can only be used on Standalone instances as part of a Pre/Post script according to the following link "https://documentation.commvault.com/2022e/expert/43131_performing_full_backup_of_standalone_mongodb_deployment.html" when using the File System agent what are the other options?

Am I correct in assuming that mongodump is not supported on replica sets?


I have setup VM based snapshots as a another test. The VMs are located on vVol which then requires the snap engine to be Virtual Server Agent. This however leaves a trail of snapshot in VMWare.

This solution also doesn't cater for OpLog backups.

 

Thanks.

Ignes

 

Hey @Iggy,

If its on VMware you’ll be restricted to the native snap engine (software snap) as the other engines will not be able to translate between the virtualized storage layer and the array. The exception may be if the mongodb data is located on a physical RDM which is essentially a direct mapping of the volume to the VM bypassing storage virtualization - but that is probably unlikely.

 

With VMware VVOL snapshots, they function entirely differently from traditional VMFS snapshots - there is no issue with leaving a VVOL snapshot around using the IntelliSnap framework - its backed by a hardware snapshot on the array, so it does not suffer from the perils of traditional VMware software snapshots. That being said, you’d be getting a dirty copy of the data since there would be no coordination with mogodb to prepare the database for the snapshot - so you are probably better off using the agent or a combination of both if you wanted to recover a node quickly before recovering the data without having to reinstall the OS, software etc. Like you also said, it also doesn't handle the logs since its not an integrated solution

I am not familiar with mongodump but according to the mongodb documentation (it is not a Commvault tool) it can be used on replica sets:

https://www.mongodb.com/docs/database-tools/mongodump/

 

mongodump is a utility that creates a binary export of a database's contents.

mongodump can export data from:

  • Standalone deployments

  • Replica sets

  • Sharded clusters

Reply


Terms & ConditionsCookie settings