3

I have MongoDB setup like this:

 Primary   | Server1  
-----------+---------  
 Secondary | Server2  
-----------+---------  
 Arbiter   | Server3  
-----------+---------  
 Backup    | Server4  

I have a backup server for daily backup using mongodump. Now I have to test my backup dump using mongorestore.

The main question is the following: What is the best way to restore the backup?

Q1: I have to follow these steps?

  1. Stop arbiter & secondary
  2. Drop database in primary
  3. Restore backup to primary
  4. Drop database on secondary
  5. Restart all the server

Q2: Restore the backup on primary without stopping any of the servers?

Q3. Make secondary as primary and restore the backup to secondary ( previous primary), and make it primary.

Q4: Is there is any way to restore both the server?

Please suggest the best approach to restore MongoDB.

  • Welcome to the site. What is the size of your database? – Md Haidar Ali Khan Mar 1 '18 at 5:35
  • Min size 5Tb and max it can grow up to 30Tb, for this testing i have around 1.5Tb of data – SGRao Mar 1 '18 at 5:54
  • How much RAM do you have? Is that 1.5TB of raw data or the size of your data files on disk? What version of MongoDB server are you using? Unless you have oodles of RAM and fast disks (or great patience), that scale of data in a single replica set is unsuitable for using mongodump as a backup strategy. The general case of having TBs of data to restore is also going to be a challenge even with great network speed. I would consider sharding your data into multiple replica sets so you have more manageable backup and restore granularity, and would definitely recommend a different backup strategy. – Stennie Mar 1 '18 at 14:59
  • A note re: your replica set configuration (primary, secondary, arbiter, and a secondary for backup): the arbiter does not improve fault tolerance and is not required (or likely useful) in this scenario. Replica sets of 3 or 4 members have the same strict majority of voting members required to maintain a primary (2) and only tolerate unavailability of a single replica set member. An even number of voting members can potentially delay the time it takes to reach consensus during a replica set election. – Stennie Mar 1 '18 at 15:14
0

As per MongoDB BOL documented Here MongoDB provides two options for restoring secondary members of a replica set:

1) Manually copy the database files to each data directory.

2) Allow initial sync to distribute data automatically.

Note:- If your database is large, initial sync can take a long time to complete. For large databases, it might be preferable to copy the database files onto each host.

  • This both applicable to snapshot /Ops Manager backup but I have only dump files means gzip files. Do you have any idea on this – SGRao Mar 1 '18 at 5:59
0

The main question is the following: What is the best way to restore the backup?

If you want to restore a mongodump backup into a replica set, you need to mongorestore into the current primary. Data will be replicated to other replica set members via the normal means. You can use mongorestore --drop ... to drop each collection (if it already exists) before import, but in a full recovery scenario you would normally be rebuilding the replica set starting from an empty deployment. As at MongoDB 3.6, mongorestore only inserts documents - it will not drop any existing databases or upsert/update/replace any existing documents.

Q1: I have to follow these steps?

The only applicable step in this list is "Restore backup to primary". With mongodump you are exporting data and index definitions, and must mongorestore into the primary to rebuild the data files. Your secondaries must be online while you are restoring and be able to keep up via replication. You can use the --writeConcern majority option to wait for a writes to be acknowledged by a majority of the replica set and ensure your restore doesn't outpace replication.

Q2: Restore the backup on primary without stopping any of the servers?

This is the correct approach.

Q3. Make secondary as primary and restore the backup to secondary ( previous primary), and make it primary.

A replica set can only have one primary, so you wouldn't gain anything by swapping the roles of the current primary and secondary. The data still needs to be replicated.

Q4: Is there is any way to restore both the server? Please suggest the best approach to restore MongoDB.

You have to restore the mongodump into the primary in order to build the data files. If you are looking for alternatives to replicating the data to each of your secondaries: you could mongorestore into a single node replica set, stop the primary, and then copy the data files to seed new secondaries and avoid initial sync.

There are certainly much better ways to take a backup, especially if your objective is to have faster (and less impactful) backup & recovery times. Backing up a large deployment with mongodump can have a significant impact on performance (particularly if your data set is much larger than available RAM) and has a longer time to restore because all of the data files and indexes need to be rebuilt.

For a general comparison of backup strategies see Backup and its Role in Disaster Recovery. The MMS product referenced in this comparison is now known as MongoDB Cloud Manager, but the general considerations and comparison points are still applicable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.