This topic describes how to download a backup from an ApsaraDB for MongoDB instance with local disks and restore it to a self-managed standalone or replica set MongoDB database.
Restore a logical backup
Usage notes
-
Because MongoDB is continuously updated, older versions of mongorestore are not compatible with newer versions of MongoDB. For information about how to select a compatible mongorestore version, see mongorestore.
-
If your self-managed database is a sharded cluster, you must set the
<hostname>parameter to the address of the mongos component in your self-managed database. -
If your self-managed database is a sharded cluster, you must add the
--nsExclude="config.*"parameter to the restore command. Otherwise, errors may occur during the restore process. -
When you restore data from a sharded cluster instance to a self-managed database, you need to download the backup data for each shard of the cluster instance and import it into the self-managed database. If the sharded cluster instance contains orphaned documents, this may result in dirty data in the self-managed database.
Prerequisites
-
Download and install a version of MongoDB that is the same as the database version of your ApsaraDB for MongoDB instance on the client where your self-managed MongoDB database is located. The client can be a local server or an ECS instance. For installation instructions, see Install MongoDB.
-
You have downloaded the logical backup. If you have not, see Download backup files.
Procedure
-
Copy the downloaded backup file to the client that hosts your self-managed MongoDB database. This client must have the mongorestore tool installed.
-
Run the following command to import the data from the backup file to your self-managed MongoDB database.
mongorestore -h <hostname> --port <server port> -u <username> -p <password> --drop --gzip --archive=<backupfile> -vvvv --stopOnErrorModify the following parameters:
-
<hostname>: The server address of your self-managed MongoDB database. Use 127.0.0.1 for a local instance.
If your self-managed database is a sharded cluster, set this parameter to the address of the mongos component.
-
<server port>: The port of your self-managed MongoDB database.
-
<username>: The username for logging in to your self-managed MongoDB database. Ensure the user has permissions for all databases. We recommend using the root account.
-
<password>: The password for the database user.
-
<backupfile>: The name of the downloaded logical backup file.
The following command parameters do not need to be modified:
-
--drop: Drops each collection from the target database before restoring it from the backup.
NoteWhen restoring backups from multiple shards to the same sharded cluster, use this parameter only when restoring the backup of the first shard.
-
--gzip: Decompresses the backup file, since it is compressed with gzip.
NoteThis parameter is supported starting from MongoDB 3.1.4. For more information, see mongo-tools.
-
-vvvv: Specifies the verbosity level of the output. More 'v' characters result in more detailed output.
-
--stopOnError: Stops the import process if an error occurs.
-
--nsExclude: Excludes matching collections from the restore. For example,
--nsExclude="config.*".
Example:
mongorestore -h 127.0.0.1 --port 27017 -u root -p ******** --drop --gzip --archive=hins1111_data_20190710.ar -vvvv --stopOnError -
Restore a physical backup
Prerequisites
-
The instance must be a replica set.
-
The TDE feature must be disabled for the instance.
-
The storage engine of the instance must be WiredTiger or RocksDB. If the storage engine is TerarkDB, see Restore data from a cloud disk backup.
Note-
You can view the storage engine of your instance on the Basic Information page in the ApsaraDB for MongoDB console.
-
If the storage engine of the instance is RocksDB, you must compile and install MongoDB with the RocksDB storage engine.
-
Database version requirements
The version of the ApsaraDB for MongoDB instance must be compatible with the version of the self-managed MongoDB database. The following table shows the version mappings.
|
MongoDB instance |
Self-managed MongoDB |
|
Version 3.2 |
Version 3.2 or 3.4 |
|
Version 3.4 |
Version 3.4 |
|
Version 4.0 |
Version 4.0 |
|
Version 4.2 |
Version 4.2 |
Physical backup file formats
|
Backup format |
File extension |
Description |
|
TAR |
.tar.gz |
For instances created before March 26, 2019, physical backup files are in TAR format. |
|
xbstream |
_qp.xb |
For instances created on or after March 26, 2019, physical backup files are in xbstream format. Note
Because Windows does not support the Percona XtraBackup tool required to decompress these files, they can be decompressed only on Linux systems. |
Environment
-
The server used in this example is an Alibaba Cloud ECS instance running an Ubuntu 16.04 (64-bit) image. For more information about how to create an ECS instance, see Create an ECS instance by using the wizard.
-
The corresponding version of MongoDB is installed on the ECS instance. For installation instructions, see the official MongoDB documentation.
-
MongoDB environment variables are configured on the ECS instance. You do not need to enter the full path to executable files when running commands.
-
The /test/mongo/data directory serves as the database directory for the physical restore.
-
The /test/mongo/data1 and /test/mongo/data2 directories serve as the database directories for the replica set nodes.
Step 1: Configure environment variables
Configure environment variables for MongoDB in your self-managed environment to avoid typing full paths when running commands. Before you start, make sure you have installed MongoDB.
If you have already configured environment variables for MongoDB, skip this step and proceed to Step 2: Download and decompress the physical backup file.
-
Run the following command to open the
profilefile in Linux:sudo vi /etc/profile -
Press
ito enter insert mode, and add the following line to the end of the file:export PATH=$PATH:/<path_to_mongodb_server>/binNoteIn this example, the MongoDB server path is /test/mongo/bin. Replace this with your actual path.
Example:
export PATH=$PATH:/test/mongo/bin -
Press Esc, type
:wq, and press Enter to save and exit. -
Run the following command to apply the changes:
source /etc/profile
Step 2: Download and decompress the backup file
-
Download the MongoDB physical backup file.
wget -c '<public_download_URL_of_backup_file>' -O <custom_filename>.<extension>Example:
wget -c 'http://rdsbak-hz-v3.oss-cn-hangzhou-internal.aliyuncs.com/custins5475****/hins1907****_data_20210906103710_qp.xb?Expires=......' -O backupfile._qp.xbNote-
Based on the file type, ensure the file extension is either
.tar.gzor_qp.xb. -
Enclose the download URL in single quotation marks (') to ensure it is parsed correctly.
-
-
Run the following command to create a
datadirectory in /test/mongo/ and move the downloaded MongoDB physical backup file to the /test/mongo/data/ directory.mkdir -p /test/mongo/data && mv <physical_backup_filename.extension> /test/mongo/data -
Decompress the physical backup file.
-
If the downloaded physical backup file has a .tar.gz extension, such as hins20190412.tar.gz, use the following method to decompress it.
cd /test/mongo/data/ && tar xzvf hins20190412.tar.gz -
If the downloaded physical backup file has a _qp.xb extension, such as hins20190412_qp.xb, use the following method to decompress it.
-
Install the Percona XtraBackup tool and the qpress package. For more information, see the installation steps on the official Percona XtraBackup website.
-
Decompress the physical backup file.
# Navigate to the directory where the file is located. cd /test/mongo/data/ # Unpack the file. cat hins20190412_qp.xb | xbstream -x -v # Decompress the physical backup file. innobackupex --decompress --remove-original /test/mongo/data
-
-
Step 3: Restore in standalone mode
-
Run the following command to create a configuration file named mongod.conf in the /test/mongo directory.
touch /test/mongo/mongod.conf -
Run
vi /test/mongo/mongod.confto open the mongod.conf file, then pressito enter insert mode.Select a startup configuration template based on the storage engine of your ApsaraDB for MongoDB instance and copy it into the mongod.conf file.
NoteThe configuration file sets the startup mode to standalone and enables authentication.
-
WiredTiger storage engine
systemLog: destination: file path: /test/mongo/mongod.log logAppend: true security: authorization: enabled storage: dbPath: /test/mongo/data directoryPerDB: true net: port: 27017 unixDomainSocket: enabled: false processManagement: fork: true pidFilePath: /test/mongo/mongod.pidNoteApsaraDB for MongoDB uses the WiredTiger storage engine by default and enables the directoryPerDB option. Therefore, this option is included in the configuration.
-
RocksDB storage engine
systemLog: destination: file path: /test/mongo/logs/mongod.log logAppend: true security: authorization: enabled storage: dbPath: /test/mongo/data engine: rocksdb net: port: 27017 unixDomainSocket: enabled: false processManagement: fork: true pidFilePath: /test/mongo/mongod.pid
-
-
Press Esc, type
:wq, and press Enter to save and exit. -
Start MongoDB with the new mongod.conf configuration file.
mongod -f /test/mongo/mongod.conf -
After the startup is complete, run the following command to log in to the MongoDB database.
mongo --host 127.0.0.1 -u <username> -p <password> --authenticationDatabase admin-
<username>: The database account for the MongoDB instance. The default is root.
-
<password>: The password for the database user.
NoteIf your password contains special characters, enclose it in single quotation marks ('), for example: 'test123!@#'. Otherwise, the login may fail.
-
-
In the mongo shell, run
show dbsto view all databases on your local MongoDB instance and verify that the restore was successful. -
The restore process is now complete. You can run the
exitcommand to quit the mongo shell.
After completing these steps, you can start the MongoDB database in standalone mode. To start the database in replica set mode, see Step 4.
Step 4: Start in replica set mode
By default, a physical backup from ApsaraDB for MongoDB contains the replica set configuration of the original instance. To start the database in replica set mode, you must first remove this configuration. Follow these steps:
-
From the command line, use the mongo shell to log in to the MongoDB database as the test user.
mongo --host 127.0.0.1 -u test -p <test_user_password> --authenticationDatabase adminNoteIf your password contains special characters, enclose it in single quotation marks ('), for example: 'test123!@#'. Otherwise, the login may fail.
-
After logging in, run the commands in the code block below to perform the following actions:
-
In the admin database, create a temporary user and grant it temporary read and write permissions on the local database.
-
Switch to the temporary user and remove the original replica set configuration from the local database.
-
Switch back to the test user and delete the temporary user and its permissions.
NoteReplace the
<test_user_password>placeholder in the following code with your actual test user password before running it.
use admin db.runCommand({ createRole: "tmprole", roles: [ { role: "test", db: "admin" } ], privileges: [ { resource: { db: 'local', collection: 'system.replset' }, actions: [ 'remove' ] } ] }) db.runCommand({ createUser: "tmpuser", pwd: "tmppwd", roles: [ 'tmprole' ] }) db.auth('tmpuser','tmppwd') use local db.system.replset.remove({}) use admin db.auth('test','<test_user_password>') db.dropRole('tmprole') db.dropUser('tmpuser') -
-
Run the following commands to shut down the MongoDB service and exit the mongo shell.
use admin db.shutdownServer() exit -
Create a replica set authentication file.
To start MongoDB in replica set mode, you must create a keyfile that replica set members use for mutual authentication.
-
Run the following command to create a keyFile directory in the mongo directory and create a key file within it.
mkdir -p /test/mongo/keyFile && touch /test/mongo/keyFile/mongodb.key -
Run
vi /test/mongo/keyFile/mongodb.keyto open the key file. Pressito enter insert mode and input the key content. For example:MongoDB Encrypting FileNoteThe keyfile content has the following restrictions:
-
Must be 6 to 1024 characters in length.
-
Can only contain characters from the base64 character set.
-
Cannot contain the equals sign (=).
-
-
Press Esc, type
:wq, and press Enter to save and exit. -
Run the following command to change the permissions of the authentication file to
400. This ensures that the file is readable only by its owner.sudo chmod 400 /test/mongo/keyFile/mongodb.key
NoteThis authentication file will be used by all nodes in the replica set.
-
-
Follow these steps to prepare two empty nodes for the replica set.
-
Run the following command to copy the mongod.conf file twice to serve as startup configuration files for the other two nodes.
cp /test/mongo/mongod.conf /test/mongo/mongod1.conf && cp /test/mongo/mongod.conf /test/mongo/mongod2.conf -
Run the following command to create data directories for the other two nodes.
mkdir -p /test/mongo/data1 && mkdir -p /test/mongo/data2
-
-
Modify the configuration file for each node as follows:
-
Run
vi /test/mongo/mongod.confto open the configuration file for Node 1. Update the file with the following content, then save and exit.systemLog: destination: file path: /test/mongo/mongod.log logAppend: true security: authorization: enabled keyFile: /test/mongo/keyFile/mongodb.key storage: dbPath: /test/mongo/data directoryPerDB: true net: bindIp: 127.0.0.1 port: 27017 unixDomainSocket: enabled: false processManagement: fork: true pidFilePath: /test/mongo/mongod.pid replication: replSetName: "rs0" -
Run
vi /test/mongo/mongod1.confto open the configuration file for Node 2. Update the file with the following content, then save and exit.systemLog: destination: file path: /test/mongo/mongod1.log logAppend: true security: authorization: enabled keyFile: /test/mongo/keyFile/mongodb.key storage: dbPath: /test/mongo/data1 directoryPerDB: true net: bindIp: 127.0.0.1 port: 27018 unixDomainSocket: enabled: false processManagement: fork: true pidFilePath: /test/mongo/mongod1.pid replication: replSetName: "rs0" -
Run
vi /test/mongo/mongod2.confto open the configuration file for Node 3. Update the file with the following content, then save and exit.systemLog: destination: file path: /test/mongo/mongod2.log logAppend: true security: authorization: enabled keyFile: /test/mongo/keyFile/mongodb.key storage: dbPath: /test/mongo/data2 directoryPerDB: true net: bindIp: 127.0.0.1 port: 27019 unixDomainSocket: enabled: false processManagement: fork: true pidFilePath: /test/mongo/mongod2.pid replication: replSetName: "rs0"
Key parameter descriptions:
-
systemLog.path / path: The path to the MongoDB log file for the current node,
-
storage.dbPath: The path to the MongoDB data files for the current node.
-
processManagement.pidFilePath: The path to the PID file (which stores the process ID) for the current node's MongoDB process.
-
security.keyFile: The path to the replica set authentication file. All nodes must use the same file.
-
net.bindIp: The IP address of the current node. If all nodes are deployed on the same server, they can use the same IP address.
-
net.port: The port number for the current node. If all nodes are deployed on the same server, they must use different port numbers.
-
replication: The replica set configuration.
-
replication.replSetName: The name of the replica set.
-
-
Run the following command to start the three nodes.
mongod -f /test/mongo/mongod.conf && mongod -f /test/mongo/mongod1.conf && mongod -f /test/mongo/mongod2.conf -
After the nodes have started, log in to the MongoDB database as the test user.
mongo --host 127.0.0.1 -u test -p <test_account_password> --authenticationDatabase adminNoteIf your password contains special characters, enclose it in single quotation marks ('), for example: 'test123!@#'. Otherwise, the login may fail.
-
In the mongo shell, run the following command to add the nodes to the replica set and initialize it.
rs.initiate( { _id : "rs0", version : 1, members: [ { _id: 0, host: "127.0.0.1:27017" , priority : 1}, { _id: 1, host: "127.0.0.1:27018" , priority : 0}, { _id: 2, host: "127.0.0.1:27019" , priority : 0} ] })Successful initialization example:
> rs.initiate( { ... _id : "rs0", ... version : 1, ... members: [ ... { _id: 0, host: "127.0.0.1:27017" , priority : 1}, ... { _id: 1, host: "127.0.0.1:27018" , priority : 0}, ... { _id: 2, host: "127.0.0.1:27019" , priority : 0} ... ] ... }) { "ok" : 1 } rs0:SECONDARY>NoteThis step uses the
rs.initiate()command. For detailed usage, see the official MongoDB documentation on rs.initiate().After the command runs successfully, the two new nodes will start synchronizing data from the primary node. The time required for this process varies depending on the size of the backup file. Once data synchronization is complete, the replica set is fully operational.
-
Follow these steps to verify that the startup was successful.
-
Run
exitto quit the mongo shell. -
Run the following command to log back in to the MongoDB database.
mongo -u <username> -p <password> --authenticationDatabase admin-
<username>: The database account for the MongoDB instance. The default is root.
-
<password>: The password for the database account.
NoteIf your password contains special characters, enclose it in single quotation marks ('), for example: 'test123!@#'. Otherwise, the login may fail.
-
-
Observe the left side of the mongo shell prompt. If it displays
<replica_set_name>:PRIMARY>, the replica set has started successfully.
-