diff --git a/source/administration/backups.txt b/source/administration/backups.txt index 7fbef631035..43d0ed10fe2 100644 --- a/source/administration/backups.txt +++ b/source/administration/backups.txt @@ -5,57 +5,58 @@ Backup and Restoration Strategies .. default-domain:: mongodb This document provides an inventory of database backup strategies for -use with MongoDB. Use the ":ref:`backup overview `" -and ":ref:`backup considerations `" sections as -you develop the most appropriate strategy for backing up your MongoDB -environment. Then, use the examples from the ":ref:`block level backup -methods `" or the ":ref:`backups using mongodump -`" sections to implement the backup solution that is -best suited to your deployment's needs. - -A robust backup strategy and a well-tested corresponding restoration -process is crucial for every production-grade deployment. Take the -specific features of your deployment, your use patterns, and -architecture into consideration as you develop your own backup system. - -:term:`Replica sets ` and :term:`sharded clusters -` require special considerations. Don't miss the -:ref:`backup considerations for sharded clusters and replica sets -`. +use with MongoDB. This document contains the following sections: + +- :ref:`backup-overview` and :ref:`backup-considerations` describe the + approaches for backing up your MongoDB environment. + +- :ref:`block-level-backup` and :ref:`database-dumps` describe specific + strategies. + +- :ref:`backups-with-sharding-and-replication` describes considerations + specific to :term:`replica sets ` and :term:`sharded + clusters `. .. _backup-overview: -Overview --------- +Backup Overview +--------------- -If you are familiar with backups systems in the context of database -systems please skip ahead to :ref:`backup considerations `. +A robust backup strategy and well tested restoration process are crucial +for production-grade deployments. The goal of a backup strategy is to +produce a full and consistent copy of the data that you can use to bring +up a new or replacement database instance. With MongoDB, there are two major approaches to backups: -using system-level tools, like disk image snapshots, and using various -capacities present in the :ref:`mongodump tool `. -The underlying goal of these strategies is to produce a full and consistent -copy of the data that you can use to bring up a new or replacement -database instance. - -The methods described in this document operate by copying the data -file on the disk level. If your system does not provide functionality -for this kind of backup, see the section on :ref:`using database dumps -for backups ` for more information. - -Ensuring that the state captured by the backup is consistent and -usable is the primary challenge of producing backups of database -systems. Backups that you cannot produce reliably, or restore from -feasibly are worthless. - -Because every environment is unique it's important to regularly test -the backups that you capture to ensure that your backup system is + +- Using system-level tools, like disk image snapshots. + + See :ref:`block-level-backup`. + +- Using various capacities present in the :program:`mongodump` tool. + + See :ref:`database-dumps`. + +The methods described in this document operate by copying the data file +on the disk level. If your system does not provide functionality for +this kind of backup, see the section on :ref:`database-dumps`. + +Ensuring that the state captured by the backup is consistent and usable +is the primary challenge of producing backups of database systems. +Backups that you cannot produce reliably, or restore from feasibly are +worthless. + +As you develop your backup system, take into consideration the specific +features of your deployment, your use patterns, and your architecture. + +Because every environment is unique it's important to regularly test the +backups that you capture to ensure that your backup system is practically, and not just theoretically, functional. .. _backup-considerations: -Production Considerations -------------------------- +Production Considerations for Backup Strategies +----------------------------------------------- When evaluating a backup strategy for your node consider the following factors: @@ -97,10 +98,10 @@ for your database. Remember that all backup plans must be: .. _block-level-backup: -Block Level Methods -------------------- +Using Block Level Backup Methods +-------------------------------- -This section will provides an overview of using disk/block level +This section provides an overview of using disk/block level snapshots (i.e. :term:`LVM` or storage appliance) to backup a MongoDB instance. These tools make a quick block-level backup of the device that holds MongoDB's data files. These methods complete quickly, work @@ -108,12 +109,12 @@ reliably, and typically provide the easiest backup systems method to implement. Snapshots work by creating pointers between the live data and a -special snapshot volume: these pointers are theoretically equivalent -to "hard links." Then, as the working data diverges from the snapshot, +special snapshot volume. These pointers are theoretically equivalent +to "hard links." As the working data diverges from the snapshot, the snapshot process uses a copy-on-write strategy. As a result the snapshot only stores modified data. -After making the snapshot, you will mount the snapshot image on your +After making the snapshot, you mount the snapshot image on your file system and copy data from the snapshot. The resulting backup contains a full copy of all data. @@ -129,8 +130,8 @@ Snapshots have the following limitations: backup occurs, the data files will reflect an inconsistent state. With :term:`journaling ` all data-file states resulting from in-progress writes are recoverable; without - journaling you must flush all pending writes and to disk before - running the backup operation and ensure that no writes occur during + journaling you must flush all pending writes to disk before + running the backup operation and must ensure that no writes occur during the entire backup procedure. If you do use journaling, the journal must reside on the same volume @@ -149,11 +150,11 @@ Snapshots have the following limitations: .. _backup-with-journaling: -With Journaling -~~~~~~~~~~~~~~~ +Backup With Journaling +~~~~~~~~~~~~~~~~~~~~~~ If your system has snapshot capability and your :program:`mongod` instance -has journaling enabled then you can use any kind of file system or +has journaling enabled, then you can use any kind of file system or volume/block level snapshot tool to create backups. .. warning:: @@ -164,7 +165,7 @@ volume/block level snapshot tool to create backups. MongoDB. To enable journaling on all other builds, specify - ":setting:`journal` = ``true`` in the configuration or use the + :setting:`journal` = ``true`` in the configuration or use the :option:`--journal ` run-time option for :program:`mongod`. @@ -177,12 +178,11 @@ LVM-based setups *within* a cloud/virtualized environment. .. note:: Running :term:`LVM` provides additional flexibility and enables the - possibility of using snapshots to backup MongoDB. + possibility of using snapshots to back up MongoDB. - If you use Amazon's EBS service in a software RAID 10 (e.g. 1+0) - configuration, use :term:`LVM` to capture a consistent disk image. - - Also consider, :ref:`backup-amazon-software-raid` +If you use Amazon's EBS service in a software RAID 10 configuration, use +:term:`LVM` to capture a consistent disk image. Also, see the special +considerations described in :ref:`backup-amazon-software-raid`. The following sections provide an overview of a simple backup process using :term:`LVM` on a Linux system. While the tools, commands, and paths may @@ -194,7 +194,7 @@ high level overview of the backup operation. Create Snapshot ``````````````` -To create a snapshot with :term:`LVM` issue a command, as root, in the +To create a snapshot with :term:`LVM`, issue a command, as root, in the following format: .. code-block:: sh @@ -239,7 +239,7 @@ Archive Snapshots ````````````````` After creating a snapshot, mount the snapshot and move the data to -separate storage. Your system may wish to compress the backup images as +separate storage. Your system might try to compress the backup images as you move the offline. Consider the following procedure to fully archive the data from the snapshot: @@ -248,19 +248,19 @@ archive the data from the snapshot: umount /dev/vg0/mdb-snap01 dd if=/dev/vg0/mdb-snap01 | tar -czf mdb-snap01.tar.gz -This command sequence: +The above command sequence: -1. Ensures that the ``/dev/vg0/mdb-snap01`` device is not mounted. +- Ensures that the ``/dev/vg0/mdb-snap01`` device is not mounted. -2. Does a block level copy of the entire snapshot image using the - ``dd`` command, and compresses the result in a gziped tar archive - in the current working directory. +- Does a block level copy of the entire snapshot image using the ``dd`` + command, and compresses the result in a gziped tar archive in the + current working directory. - .. warning:: + .. warning:: - This command will create a large ``tar.gz`` file in your current - working directory. Make sure that you run this command in a - file system that has enough free space. + This command will create a large ``tar.gz`` file in your current + working directory. Make sure that you run this command in a file + system that has enough free space. Restore Snapshot ```````````````` @@ -274,34 +274,33 @@ procedure: tar -xzf mdb-snap01.tar.gz | dd of=/dev/vg0/mdb-new mount /dev/vg0/mdb-new /srv/mongodb -This sequence: +The above sequence: -1. Creates a new logical volume named ``mdb-new``, in the - ``/dev/vg0`` volume group. The path to the new device will be - ``/dev/vg0/mdb-new``. +- Creates a new logical volume named ``mdb-new``, in the ``/dev/vg0`` + volume group. The path to the new device will be ``/dev/vg0/mdb-new``. - .. warning:: + .. warning:: - This volume will have a maximum size of 1 gigabyte. The original - file system must have had a total size of 1 gigabyte or smaller, - or else the restoration will fail. + This volume will have a maximum size of 1 gigabyte. The original + file system must have had a total size of 1 gigabyte or smaller, or + else the restoration will fail. - Change ``1G`` to your desired volume size. + Change ``1G`` to your desired volume size. -2. Uncompresses and unarchives the ``mdb-snap01.tar.gz`` into the - ``mdb-new`` disk image. +- Uncompresses and unarchives the ``mdb-snap01.tar.gz`` into the + ``mdb-new`` disk image. -3. Mounts the ``mdb-new`` disk image to the ``/srv/mongodb`` - directory. Modify the mount point to correspond to your MongoDB - data file location, or other location as needed. +- Mounts the ``mdb-new`` disk image to the ``/srv/mongodb`` directory. + Modify the mount point to correspond to your MongoDB data file + location, or other location as needed. .. _backup-restore-from-snapshot: Restore Directly from a Snapshot ```````````````````````````````` -To combine the above processes without writing to a compressed ``tar`` -archive, use the following sequence: +To restore a backup without writing to a compressed ``tar`` archive, use +the following sequence: .. code-block:: sh @@ -314,8 +313,12 @@ Remote Backup Storage ````````````````````` You can implement off-system backups using the :ref:`combined process -` and SSH. Consider the following -procedure: +` and SSH. + +This sequence is identical to procedures explained above, except that it +archives and compresses the backup on a remote system using SSH. + +Consider the following procedure: .. code-block:: sh @@ -325,51 +328,48 @@ procedure: ssh username@example.com tar -xzf /opt/backup/mdb-snap01.tar.gz | dd of=/dev/vg0/mdb-new mount /dev/vg0/mdb-new /srv/mongodb -This sequence is identical to procedures explained above, except that -it archives and compresses the backup on a remote system using SSH. - .. _backup-without-journaling: -Without Journaling -~~~~~~~~~~~~~~~~~~ +Backup Without Journaling +~~~~~~~~~~~~~~~~~~~~~~~~~ If your :program:`mongod` instance does not run with journaling enabled, or if your journal is on a separate volume, obtaining a -functional backup of a consistent state is more complicated. Flush all +functional backup of a consistent state is more complicated. As described in this section, you must flush all writes to disk and lock the database to prevent writes during the -backup process. If you have a :term:`replica set` configuration, use a +backup process. If you have a :term:`replica set` configuration, then for your backup, use a :term:`secondary` that is not receiving reads (i.e. :term:`hidden -member`) for backup purposes. +member`). -You can flush writes to disk, and "lock" the database to prevent -further writes with the :method:`db.fsyncLock()` command in the -:program:`mongo` shell, as follows: +1. To flush writes to disk and to "lock" the database (to prevent + further writes), issue the :method:`db.fsyncLock()` method in the + :program:`mongo` shell: -.. code-block:: javascript + .. code-block:: javascript - db.fsyncLock(); + db.fsyncLock(); -Perform the :ref:`backup operation described above -` at this point. To unlock the database after -the snapshot has completed, use the following command in the -:program:`mongo` shell: +#. Perform the backup operation described in :ref:`lvm-backup-operation`. -.. code-block:: javascript +#. To unlock the database after the snapshot has completed, use the + following command in the :program:`mongo` shell: - db.fsyncUnlock(); + .. code-block:: javascript -.. note:: + db.fsyncUnlock(); - Version 1.9.0 added :method:`db.fsyncLock()` and - :method:`db.fsyncUnlock()` helpers to the :program:`mongo` shell. - Prior to this version, use the following commands: + .. note:: - .. code-block:: javascript + Version 1.9.0 added :method:`db.fsyncLock()` and + :method:`db.fsyncUnlock()` helpers to the :program:`mongo` shell. + Prior to this version, use the following commands: - db.runCommand( { fsync: 1, lock: true } ); - db.runCommand( { fsync: 1, lock: false } ); + .. code-block:: javascript - .. include:: /includes/note-disable-profiling-fsynclock.rst + db.runCommand( { fsync: 1, lock: true } ); + db.runCommand( { fsync: 1, lock: false } ); + + .. include:: /includes/note-disable-profiling-fsynclock.rst .. _backup-amazon-software-raid: @@ -384,75 +384,74 @@ tool. As a result you may: - Flush all writes to disk and create a write lock to ensure consistent state during the backup process. - If you choose this option see the section on ":ref:`Backup without - Journaling `" + If you choose this option see :ref:`backup-without-journaling`. - Configure LVM to run and hold your MongoDB data files on top of the RAID within your system. - If you choose this option see the section that outlines the - ":ref:`LVM backup operation `" + If you choose this option, perform the LVM backup operation described + in :ref:`lvm-backup-operation`. .. _database-dumps: -Binary Dump/Restore Formats ----------------------------- +Using Binary Database Dumps for Backups +--------------------------------------- This section describes the process for writing the entire contents of -your MongoDB instance, to a file in a binary format. This command -provides the best option for full system database backups if -disk-level snapshots are not available. +your MongoDB instance to a file in a binary format. If +disk-level snapshots are not available, this approach +provides the best option for full system database backups. .. seealso:: The :doc:`/reference/mongodump` and :doc:`/reference/mongorestore` documents contain complete documentation of these tools. If you - have questions about the function and parameters of these tools not - covered here, please refer to these documents. + have questions about these tools not covered here, please refer to + these documents. If your system has disk level snapshot capabilities, consider the - backup methods described :ref:`above `. + backup methods described in :ref:`block-level-backup`. Database Dump with :program:`mongodump` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The :program:`mongodump` utility performs a live backup the data, or +The :program:`mongodump` utility can perform a live backup of data or can work against an inactive set of database files. The :program:`mongodump` utility can create a dump for an entire -server/database/collection (or part of a collection using of query,) +server/database/collection (or part of a collection using of query), even when the database is running and active. If you run -:program:`mongodump` without any arguments the command will connect to +:program:`mongodump` without any arguments, the command connects to the local database instance (e.g. ``127.0.0.1`` or ``localhost``) and -create a database backup in in the current directory named -``dump/``. +creates a database backup named ``dump/`` in the current directory. .. include:: /includes/note-mongodump-compatibility-2.2.rst -You can specify database and collection as options to the -:program:`mongodump` command to limit the amount of data included in the -database dump. For example: +To limit the amount of data included in the database dump, you can +specify :option:`--database ` and +:option:`--collection ` as options to the +:program:`mongodump` command. For example: .. code-block:: sh mongodump --collection collection --db test This command creates a dump in of the database in the ``dump/`` -directory of only the collection named ``collection`` in the -database named ``test``. :program:`mongodump` provides the -":option:`--oplog `" option that forces the dump -operation to use the operation log to take a point-in-time snapshot of -the database. - -With ":option:`--oplog `" , :program:`mongodump` -copies all the data from the source database, as well as all of the -:term:`oplog` entries from the beginning of the backup procedure to -until the backup procedure completes. This backup procedure, in -conjunction with :option:`mongorestore --oplogReplay `, allows you to -restore a backup that reflects a consistent and specific moment in -time. +directory of the collection named ``collection`` in the database named +``test``. + +To force the dump operation to use the operation log to take a +point-in-time snapshot of the database, use the :program:`mongodump` +:option:`--oplog ` option. With :option:`--oplog +`, :program:`mongodump` copies all the data from the +source database as well as all of the :term:`oplog` entries from the +beginning of the backup procedure to until the backup procedure +completes. This backup procedure, in conjunction with +:option:`mongorestore --oplogReplay `, +allows you to restore a backup that reflects a consistent and specific +moment in time. If your MongoDB instance is not running, you can use the -":option:`--dbpath `" option to specify the +:option:`--dbpath ` option to specify the location to your MongoDB instance's database files. :program:`mongodump` reads from the data files directly with this operation. This locks the data directory to prevent conflicting writes. The @@ -464,8 +463,8 @@ configuration. Consider the following example: mongodump --dbpath /srv/mongodb -Additionally, the ":option:`--host `" and -":option:`--port `" options allow you to specify a +Additionally, the :option:`--host ` and +:option:`--port ` options allow you to specify a non-local host to connect to capture the dump. Consider the following example: @@ -473,7 +472,7 @@ example: mongodump --host mongodb1.example.net --port 3017 --username user --password pass --out /opt/backup/mongodump-2011-10-24 -On any :program:`mongodump` command you may, as above specify username +On any :program:`mongodump` command you may, as above, specify username and password credentials to specify database authentication. Database Import with :program:`mongorestore` @@ -489,9 +488,9 @@ The :program:`mongorestore` utility restores a binary backup created by Here, :program:`mongorestore` imports the database backup located in the ``dump-2011-10-25`` directory to the :program:`mongod` instance running on the localhost interface. By default, :program:`mongorestore` -will look for a database dump in the ``dump/`` directory and restore +looks for a database dump in the ``dump/`` directory and restores that. If you wish to restore to a non-default host, the -":option:`--host `" and ":option:`--port `" +:option:`--host ` and :option:`--port ` options allow you to specify a non-local host to connect to capture the dump. Consider the following example: @@ -499,14 +498,14 @@ the dump. Consider the following example: mongorestore --host mongodb1.example.net --port 3017 --username user --password pass /opt/backup/mongodump-2011-10-24 -On any :program:`mongorestore` command you may, as above specify -username and password credentials as above. +On any :program:`mongorestore` command you may specify +username and password credentials, as above. If you created your database dump using the :option:`--oplog ` option to ensure a point-in-time snapshot, call :program:`mongorestore` with the :option:`--oplogReplay ` -option as in the following example: +option, as in the following example: .. code-block:: sh @@ -514,7 +513,7 @@ option as in the following example: You may also consider using the :option:`mongorestore --objcheck` option to check the integrity of objects while inserting them into the -database, or the :option:`mongorestore --drop` option to drop each +database, or you may consider the :option:`mongorestore --drop` option to drop each collection from the database before restoring from backups. :program:`mongorestore` also includes the ability to a filter to all input before inserting it into the new database. Consider the @@ -535,101 +534,108 @@ interacting with your shell environment. mongorestore --dbpath /srv/mongodb --journal Here, :program:`mongorestore` restores the database dump located in -``dump/`` folder into the data files located at ``/srv/mongodb``, with -the :option:`--dbpath ` option. Additionally, -the ":option:`--journal `" option ensures that +``dump/`` folder into the data files located at ``/srv/mongodb``. Additionally, +the :option:`--journal ` option ensures that :program:`mongorestore` records all operation in the durability :term:`journal`. The journal prevents data file corruption if anything (e.g. power failure, disk failure, etc.) interrupts the restore operation. -.. seealso:: ":doc:`/reference/mongodump`" and - ":doc:`/reference/mongorestore`." +.. seealso:: :doc:`/reference/mongodump` and + :doc:`/reference/mongorestore`. .. _backups-with-sharding-and-replication: -Sharded Clusters and Replica Sets Considerations ------------------------------------------------- +Sharded Cluster and Replica Set Considerations +---------------------------------------------- + +The underlying architecture of :term:`sharded clusters ` and :term:`replica sets ` presents several +challenges for creating backups. This section describes how to make +quality backups in environments with these configurations and how to +perform restorations. -The underlying architecture of sharded clusters and replica sets -present several challenges for creating backups of data stored in -MongoDB. This section provides a high-level overview of these -concerns, and strategies for creating quality backups in environments -with these configurations. +Back Up Sharded Clusters +~~~~~~~~~~~~~~~~~~~~~~~~ -Creating useful backups for sharded clusters is more complicated, -because it's crucial that the backup captures a consistent state +Creating useful backups for :term:`sharded clusters ` is complicated +because it's crucial that a given backup capture a consistent state across all shards. -Sharded Clusters -~~~~~~~~~~~~~~~~ +Depending on the size of your data, you can back up the cluster as a +whole or back up each database instances. Both procedures are described +here. -Using Database Dumps From a Cluster -``````````````````````````````````` +Back Up the Cluster as a Whole Using :program:`mongodump` +````````````````````````````````````````````````````````` -If you have a small collection of data, the easiest way to connecting -to the :program:`mongos` and taking a dump of the database from the -running copy. This will create a consistent copy of the data in your -database. If your data corpus is small enough that: +If your :term:`sharded cluster` comprises a small collection of data, +you can connect to a :program:`mongos` and issue the +:program:`mongodump` command. You can use this approach if the following +is true: -- it's possible to store the entire backup on one system, or a single - storage device. Consider both backups of entire instances, and +- It's possible to store the entire backup on one system or on a single + storage device. Consider both backups of entire instances and incremental dumps of data. -- the state of the database at the beginning of the operation is +- The state of the database at the beginning of the operation is not significantly different than the state of the database at the - end of the backup. If the backup operation cannot capture a backup + end of the backup. If the backup operation cannot capture a backup, this is not a viable option. -- the backup can run and complete without impacting the performance of +- The backup can run and complete without affecting the performance of the cluster. -Using Conventional Backups from All Database Instances -`````````````````````````````````````````````````````` +.. note:: If you use :program:`mongodump` without specifying the a database or + collection, the output will contain both the collection data and the + sharding config metadata from the :ref:`config servers `. -If you there is no way to conduct a backup reasonably with a dump, -then you'll need to either snapshot the database using the -:ref:`snapshot backup procedure ` or create a -binary dump of each database instance using :ref:`binary dump methods -`. + The :program:`mongodump` :option:`--oplog ` option + cannot be used when dumping from a mongos. This option is only + available when running directly against a :term:`replica set` member. -These backups must not only capture the database in a consistent -state, as described in the aforementioned procedures, but the -:term:`sharded cluster` needs to be consistent in itself. Also, disable -the balancer process that equalizes the distribution of data among the -:term:`shards ` before taking the backup. +Back Up from All Database Instances +``````````````````````````````````` -You should also lock all cluster members at once so that your backups -reflect your entire database system at a single point in time. +If your :term:`sharded cluster` is to large for the :program:`mongodump` +command, then you must back up your data either by creating a snapshot of the cluster +or by creating a binary dump of each database. This section describes both. -.. warning:: +In both cases: - It is essential that you stop the balancer before creating - backups. If the balancer remains active, your resulting backups - could have duplicate data or miss some data, as :term:`chunks ` - migrate while recording backups. +- The backups must capture the database in a consistent state. - Similarly, if you do not lock all shards at the same time, - the backup can reflect an inconsistent state that is impossible to - restore from. +- The sharded cluster must be consistent in itself. -To stop the balancer, connect to the :program:`mongos` with the :option`mongo` -shell and issue the following 2 commands: +This procedure describes both approaches: -.. code-block:: javascript +1. Disable the :term:`balancer` process that equalizes the distribution + of data among the :term:`shards `. To disable the balancer, see + :ref:`sharding-balancing-disable-temporally`. - use config - db.settings.update( { _id: "balancer" }, { $set : { stopped: true } } , true ); + .. warning:: -After disabling the balancer, proceed with your backup in the -following sequence: + It is essential that you stop the balancer before creating + backups. If the balancer remains active, your resulting backups + could have duplicate data or miss some data, as :term:`chunks + ` migrate while recording backups. -1. Lock all shards, using a process to lock all shard - instances in as short of an interval as possible. +#. Lock all shards so that your backups reflect your entire database + system at a single point in time. Lock all shards in as short of an + interval as possible. -2. Use :program:`mongodump` to backup the config database. Issue this command - against the config database itself or the - :program:`mongos`, and would resemble the following: + .. warning:: + + If you do not lock all shards at the same time, the backup can + reflect an inconsistent state that is impossible to restore from. + +#. Use :program:`mongodump` to backup one of the :ref:`config servers + `. This backs up the cluster's metadata. You + only need to back up one config server, as they all have replicas of + the same information. + + Issue this command against the config server itself or the + :program:`mongos`: .. code-block:: sh @@ -638,22 +644,33 @@ following sequence: .. note:: In this situation :program:`mongodump` will read from - :term:`secondary` nodes. See: ":ref:`mongodump feature - `" for more information. + :term:`secondary` nodes. See: :ref:`mongodump feature + ` for more information. -2. Record a backup of all shards +#. Back up each shard. Shards can be backed up one at a time or in + parallel. For each shard, do one of the following: -3. Unlock all shards. + - If your system has disk level snapshot capabilities, create a + snapshot each shard. Use the procedures in + :ref:`block-level-backup`. -4. Restore the balancer. + - Create a binary dump of each shard using the operations described + in :ref:`database-dumps`. -Use the following command sequence when connected to the :program:`mongos` -with the :program:`mongo` shell: +#. Unlock all shards. -.. code-block:: javascript +#. Restore the balancer. - use config - db.settings.update( { _id: "balancer" }, { $set : { stopped: false } } , true ); + Use the following command sequence when connected to the + :program:`mongos` with the :program:`mongo` shell: + + .. code-block:: javascript + + use config + db.settings.update( { _id: "balancer" }, { $set : { stopped: false } } , true ); + +Schedule Automated Backups +`````````````````````````` If you have an automated backup schedule, you can disable all balancing operations for a period of time. For instance, consider the @@ -671,26 +688,92 @@ window when the balancer is running *and* that the balancer can effectively balance the collection among the shards in the window allotted to each. +Restore Sharded Clusters +~~~~~~~~~~~~~~~~~~~~~~~~ + +1. Stop all :program:`mongod` and :program:`mongos` processes. + +#. If shard hostnames have changed, you must manually update the + ``shards`` collection in the :ref:`config-database` to use the new + hostnames. Do the following: + + a. Start the three :ref:`config servers ` by + issuing commands similar to the following, using values appropriate + to your configuration: + + .. code-block:: sh + + mongod --configsvr --dbpath /data/configdb --port 27018 + + #. Restore the :ref:`config-database` on each config server. + + #. Start one :program:`mongos` instance. + + #. Update the :ref:`config-database` collection named ``shards`` to reflect the + new hostnames. + +#. Restore the following: + + - Data files for each server in each :term:`shard` For each shard + that is comprised of a :term:`replica set`, restore all the members + of the replica set or use the other standard approaches for + restoring a replica set from backup. + - Data files for each :ref:`config server `, + if you have not already done so in the previous step. + +#. Restart the all the :program:`mongos` instances. + +#. Restart all the :program:`mongod` instances. + +#. Connect to a :program:`mongos` instance from a :program:`mongo` shell + and run the following sequence of commands to make sure all shards + are running: + + .. code-block:: javascript + + printShardingStatus() + show collections + +Restore a Single Shard +~~~~~~~~~~~~~~~~~~~~~~ + +:term:`Sharded clusters ` are designed to be restored +as a whole. When you restore a single shard, keep in mind that the +:term:`balancer` process might have moved :term:`chunks ` onto or +off of this shard since the last backup. If that's the case, you must +manually move those chunks, as described in this procedure. + +1. Restore the shard. + +#. For chunks that were migrated away from this shard, you need not do + anything. Their documents do not need to be deleted from + the shard because the chunks are automatically filtered out from queries + by :program:`mongos`. + +#. For chunks that were migrated to this shard since the last backup, + you must manually recover the chunks. To determine what chunks have + moved, view the ``changelog`` collection in the :ref:`config-database`. + .. _replica-set-backups: Replica Sets ~~~~~~~~~~~~ -In most cases, backing up data stored in replica is similar to backing -up data stored in a single instance. It's possible to lock a single -:term:`slave` or :term:`secondary` database and then create a backup -from that instance. When you unlock the database, the slave will catch -:term:`master` or :term:`primary` node. You may also chose to deploy a -dedicated :term:`hidden member` for backup purposes. +In most cases, backing up data stored in a :term:`replica set` is +similar to backing up data stored in a single instance. It's possible to +lock a single :term:`secondary` or :term:`slave` database and then +create a backup from that instance. When you unlock the database, the secondary or +slave catches up with the :term:`primary` or :term:`master`. You may also +chose to deploy a dedicated :term:`hidden member` for backup purposes. -If you have a cluster where each shard is itself a replica +If you have a :term:`sharded cluster` where each :term:`shard` is itself a replica set, you can use this method to create a backup of the entire cluster without disrupting the operation of the node. In these situations you should still turn off the balancer when you create backups. -For any cluster, using a non-master/primary node to create backups is -particularly advantageous, in that the backup operation does not -affect the performance of the master or primary node. Replication +For any cluster, using a non-primary/non-master node to create backups is +particularly advantageous in that the backup operation does not +affect the performance of the primary or master. Replication itself provides some measure of redundancy. Nevertheless, keeping point-in time backups of your cluster to provide for disaster recovery and as an additional layer of protection is crucial. diff --git a/source/administration/sharding.txt b/source/administration/sharding.txt index d59bd083e2b..b8b6f88b5bb 100644 --- a/source/administration/sharding.txt +++ b/source/administration/sharding.txt @@ -838,6 +838,8 @@ all migration, use the following procedure: #. Connect to any :program:`mongos` in the cluster using the :program:`mongo` shell. +.. TODO Does the user have to switch to the config db to do this? + #. Issue the following command to disable the balancer: .. code-block:: javascript