-
Notifications
You must be signed in to change notification settings - Fork 1.7k
/
backups.txt
170 lines (131 loc) · 6.57 KB
/
backups.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
======================
MongoDB Backup Methods
======================
.. default-domain:: mongodb
.. contents:: On this page
:local:
:backlinks: none
:depth: 1
:class: singlecol
When deploying MongoDB in production, you should have a strategy for
capturing and restoring backups in the case of data loss
events.
Back Up with |MMS| or Ops Manager
---------------------------------
|MMS| is a hosted back up, monitoring, and automation service for
MongoDB. |mms-home| supports backing up and restoring MongoDB
:term:`replica sets <replica set>` and :term:`sharded clusters <sharded
cluster>` from a graphical user interface.
.. _backup-with-mms:
|MMS|
~~~~~
The |mms-home| supports the backing up and restoring of MongoDB
deployments.
|MMS| continually backs up MongoDB :term:`replica sets <replica set>`
and :term:`sharded clusters <sharded cluster>` by reading the
:term:`oplog` data from your MongoDB deployment. |MMS| creates snapshots
of your data at set intervals, and can also offer point-in-time recovery
of MongoDB replica sets and sharded clusters.
.. tip::
Sharded cluster snapshots are difficult to achieve with other MongoDB
backup methods.
To get started with |MMS| Backup, sign up for |mms-home|. For
documentation on |MMS|, see the |mms-docs|.
.. include:: /includes/replacement-mms.rst
.. _backup-with-mms-onprem:
Ops Manager
~~~~~~~~~~~
With Ops Manager, MongoDB subscribers can install and run the same core
software that powers :ref:`backup-with-mms` on their own infrastructure.
Ops Manager is an on-premise solution that has similar functionality to
|MMS| and is available with Enterprise Advanced subscriptions.
For more information about Ops Manager, see the `MongoDB Enterprise
Advanced
<https://www.mongodb.com/products/mongodb-enterprise-advanced?jmp=docs>`_ page
and the :opsmgr:`Ops Manager Manual </>`.
.. _backup-with-file-copies:
Back Up by Copying Underlying Data Files
----------------------------------------
Back Up with Filesystem Snapshots
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can create a backup of a MongoDB deployment by making a copy of MongoDB's
underlying data files.
If the volume where MongoDB stores its data files supports point-in-time
snapshots, you can use these snapshots to create backups of a MongoDB
system at an exact moment in time.
File system snapshots are an operating system volume manager feature,
and are not specific to MongoDB. With file system snapshots, the operating
system takes a snapshot of the volume to use as a baseline for data backup.
The mechanics of snapshots depend on
the underlying storage system. For example, on Linux, the Logical Volume
Manager (LVM) can create snapshots. Similarly, Amazon’s EBS storage
system for EC2 supports snapshots.
To get a correct snapshot of a running :binary:`~bin.mongod` process, you
must have journaling enabled and the journal must reside on the same
logical volume as the other MongoDB data files. Without journaling
enabled, there is no guarantee that the snapshot will be consistent or
valid.
To get a consistent snapshot of a :term:`sharded cluster`, you must
disable the balancer and capture a snapshot from every shard as well as a
config server at approximately the same moment in time.
For more information, see the
:doc:`/tutorial/backup-with-filesystem-snapshots` and
:doc:`/tutorial/backup-sharded-cluster-with-filesystem-snapshots` for
complete instructions on using LVM to create snapshots. Also see
:ecosystem:`Back up and Restore Processes for MongoDB on Amazon EC2
</tutorial/backup-and-restore-mongodb-on-amazon-ec2>`.
Back Up with ``cp`` or ``rsync``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If your storage system does not support snapshots, you can copy the
files directly using ``cp``, ``rsync``, or a similar tool. Since
copying multiple files is not an atomic operation, you must stop all
writes to the :binary:`~bin.mongod` before copying the files. Otherwise, you will
copy the files in an invalid state.
Backups produced by copying the underlying data do not support point
in time recovery for :term:`replica sets <replica set>` and are difficult to manage for
larger sharded clusters. Additionally, these backups are larger
because they include the indexes and duplicate underlying storage
padding and fragmentation. :binary:`~bin.mongodump`, by contrast, creates
smaller backups.
.. _backup-with-mongodump:
Back Up with ``mongodump``
--------------------------
:binary:`~bin.mongodump` reads data from a MongoDB database and
creates high fidelity BSON files which the :binary:`~bin.mongorestore`
tool can use to populate a MongoDB database.
:binary:`~bin.mongodump` and :binary:`~bin.mongorestore` are simple and
efficient tools for backing up and restoring small
MongoDB deployments, but are not ideal for capturing backups of larger
systems.
:binary:`~bin.mongodump` and :binary:`~bin.mongorestore` operate against a
running :binary:`~bin.mongod` process, and can manipulate the underlying
data files directly. By default, :binary:`~bin.mongodump` does not
capture the contents of the :doc:`local database </reference/local-database>`.
:binary:`~bin.mongodump` only captures the documents in the database. The
resulting backup is space efficient, but :binary:`~bin.mongorestore` or
:binary:`~bin.mongod` must rebuild the indexes after restoring data.
When connected to a MongoDB instance, :binary:`~bin.mongodump` can
adversely affect :binary:`~bin.mongod` performance. If your data is larger
than system memory, the queries will push the working set out of
memory, causing :ref:`page faults <administration-monitoring-page-faults>`.
Applications can continue to modify data while :binary:`~bin.mongodump`
captures the output. For replica sets, :binary:`~bin.mongodump` provides
the :option:`--oplog <mongodump --oplog>` option to include in its
output :term:`oplog` entries that occur during the :binary:`~bin.mongodump`
operation. This allows the corresponding :binary:`~bin.mongorestore`
operation to replay the captured oplog. To restore a backup created
with :option:`--oplog <mongodump --oplog>`, use :binary:`~bin.mongorestore`
with the :option:`--oplogReplay <mongorestore --oplogReplay>` option.
However, for replica sets, consider :ref:`backup-with-mms` or
:ref:`backup-with-mms-onprem`.
See :doc:`/tutorial/backup-and-restore-tools`
and :doc:`/tutorial/backup-sharded-cluster-with-database-dumps`
for more information.
.. class:: hidden
.. toctree::
:titlesonly:
/tutorial/backup-with-filesystem-snapshots
/tutorial/backup-and-restore-tools
/tutorial/restore-replica-set-from-backup
/administration/backup-sharded-clusters
/tutorial/recover-data-following-unexpected-shutdown