@@ -65,8 +65,8 @@ practically, and not just theoretically, functional.
65
65
Production Considerations for Backup Strategies
66
66
-----------------------------------------------
67
67
68
- When evaluating a backup strategy for your node consider the following
69
- factors:
68
+ When evaluating a backup strategy for your MongoDB deployment consider
69
+ the following factors:
70
70
71
71
- Geography. Ensure that you move some backups away from the your
72
72
primary database infrastructure. It's important to be able to
@@ -81,7 +81,7 @@ factors:
81
81
time of the backup schedule relative to peak usage and maintenance
82
82
windows.
83
83
84
- - System capabilities. In order to use some of the block-level
84
+ - System capabilities. Some of the block-level
85
85
snapshot tools requires special support on the operating-system or
86
86
infrastructure level.
87
87
@@ -149,11 +149,11 @@ Snapshots have the following limitations:
149
149
files, journal (if applicable), and configuration on one logical
150
150
disk that doesn't contain any other data.
151
151
152
- Alternately, store all MongoDB data files on a dedicated device to
152
+ Alternately, store all MongoDB data files on a dedicated device
153
153
so that you can make backups without duplicating extraneous data.
154
154
155
155
- Ensure that you copy data from snapshots and onto other systems to
156
- ensure that data is safe from site- failures.
156
+ ensure that data is safe from site failures.
157
157
158
158
.. _backup-with-journaling:
159
159
@@ -168,7 +168,7 @@ volume/block level snapshot tool to create backups.
168
168
169
169
.. versionchanged:: 1.9.2
170
170
171
- Journaling is only enabled by default on 64-bit builds of
171
+ Journaling is only enabled by default on 64-bit builds of
172
172
MongoDB.
173
173
174
174
To enable journaling on all other builds, specify
@@ -229,7 +229,7 @@ current state of ``/dev/vg0/mongodb`` and the creation of the snapshot
229
229
data growth, particularly for the period of time that it takes to copy
230
230
data out of the system or to a temporary image.
231
231
232
- If you your snapshot runs out of space, the snapshot image
232
+ If your snapshot runs out of space, the snapshot image
233
233
becomes unusable. Discard this logical volume and create another.
234
234
235
235
The snapshot will exist when the command returns. You can restore
@@ -342,10 +342,12 @@ Backup Without Journaling
342
342
343
343
If your :program:`mongod` instance does not run with journaling
344
344
enabled, or if your journal is on a separate volume, obtaining a
345
- functional backup of a consistent state is more complicated. As described in this section, you must flush all
345
+ functional backup of a consistent state is more complicated.
346
+ As described in this section, you must flush all
346
347
writes to disk and lock the database to prevent writes during the
347
- backup process. If you have a :term:`replica set` configuration, then for your backup, use a
348
- :term:`secondary` that is not receiving reads (i.e. :term:`hidden
348
+ backup process. If you have a :term:`replica set` configuration,
349
+ then for your backup use a
350
+ :term:`secondary` which is not receiving reads (i.e. :term:`hidden
349
351
member`).
350
352
351
353
1. To flush writes to disk and to "lock" the database (to prevent
@@ -368,7 +370,7 @@ member`).
368
370
.. note::
369
371
370
372
.. versionchanged:: 2.0
371
- In 2.0 added :method:`db.fsyncLock()` and
373
+ MongoDB 2.0 added :method:`db.fsyncLock()` and
372
374
:method:`db.fsyncUnlock()` helpers to the :program:`mongo`
373
375
shell. Prior to this version, use the :dbcommand:`fsync`
374
376
command with the ``lock`` option, as follows:
@@ -427,8 +429,8 @@ Database Dump with :program:`mongodump`
427
429
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
428
430
429
431
The :program:`mongodump` utility can perform a live backup of data or
430
- can work against an inactive set of database
431
- files. The :program:`mongodump` utility can create a dump for an entire
432
+ can work against an inactive set of database files.
433
+ The :program:`mongodump` utility can create a dump for an entire
432
434
server/database/collection (or part of a collection using of query),
433
435
even when the database is running and active. If you run
434
436
:program:`mongodump` without any arguments, the command connects to
@@ -446,13 +448,13 @@ specify :option:`--database <mongodump --database>` and
446
448
447
449
mongodump --collection collection --db test
448
450
449
- This command creates a dump of the database in the ``dump/ ``
450
- directory of the collection named ``collection `` in the database named
451
- ``test`` .
451
+ This command creates a dump of the collection named ``collection ``
452
+ from the database ``test `` in a :file:`dump/` subdirectory of the current
453
+ working directory .
452
454
453
- Use :option:`--oplog <mongodump --oplog>` option with
455
+ Use the :option:`--oplog <mongodump --oplog>` option with
454
456
:program:`mongodump` to collect the :term:`oplog` entries to build a
455
- point-in-time snapshot of the database. With :option:`--oplog
457
+ point-in-time snapshot of a database within a replica set . With :option:`--oplog
456
458
<mongodump --oplog>`, :program:`mongodump` copies all the data from
457
459
the source database as well as all of the :term:`oplog` entries from
458
460
the beginning of the backup procedure to until the backup procedure
@@ -497,9 +499,9 @@ The :program:`mongorestore` utility restores a binary backup created by
497
499
mongorestore dump-2011-10-25/
498
500
499
501
Here, :program:`mongorestore` imports the database backup located in
500
- the `` dump-2011-10-25` ` directory to the :program:`mongod` instance
502
+ the :file:` dump-2011-10-25` directory to the :program:`mongod` instance
501
503
running on the localhost interface. By default, :program:`mongorestore`
502
- looks for a database dump in the `` dump/` ` directory and restores
504
+ looks for a database dump in the :file:` dump/` directory and restores
503
505
that. If you wish to restore to a non-default host, the
504
506
:option:`--host <mongorestore --host>` and :option:`--port <mongorestore --port>`
505
507
options allow you to specify a non-local host to connect to capture
@@ -535,7 +537,7 @@ following example:
535
537
mongorestore --filter '{"field": 1}'
536
538
537
539
Here, :program:`mongorestore` only adds documents to the database from
538
- the dump located in the `` dump/` ` folder *if* the documents have a
540
+ the dump located in the :file:` dump/` folder *if* the documents have a
539
541
field name ``field`` that holds a value of ``1``. Enclose the
540
542
filter in single quotes (e.g. ``'``) to prevent the filter from
541
543
interacting with your shell environment.
@@ -545,7 +547,8 @@ interacting with your shell environment.
545
547
mongorestore --dbpath /srv/mongodb --journal
546
548
547
549
Here, :program:`mongorestore` restores the database dump located in
548
- ``dump/`` folder into the data files located at ``/srv/mongodb``. Additionally,
550
+ :file:`dump/` folder into the data files located at :file:`/srv/mongodb`.
551
+ Additionally,
549
552
the :option:`--journal <mongorestore --journal>` option ensures that
550
553
:program:`mongorestore` records all operation in the durability
551
554
:term:`journal`. The journal prevents data file corruption if anything
@@ -624,8 +627,8 @@ In both cases:
624
627
625
628
This procedure describes both approaches:
626
629
627
- 1. Disable the :term:`balancer` process that equalizes the
628
- distribution of data among the :term:`shards <shard>`. To disable
630
+ 1. Disable the :term:`balancer` process that balances
631
+ data among the :term:`shards <shard>`. To disable
629
632
the balancer, use the :method:`sh.stopBalancer()` method in the
630
633
:program:`mongo` shell, and see the
631
634
:ref:`sharding-balancing-disable-temporally` procedure.
@@ -637,7 +640,7 @@ This procedure describes both approaches:
637
640
could have duplicate data or miss some data, as :term:`chunks
638
641
<chunk>` migrate while recording backups.
639
642
640
- #. Lock one member of each replica set in shard so that your backups reflect your
643
+ #. Lock one member of each replica set in each shard so that your backups reflect your
641
644
entire database system at a single point in time. Lock all shards
642
645
in as short of an interval as possible.
643
646
0 commit comments