forked from mongodb/docs
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathbackup-sharded-cluster-with-filesystem-snapshots.txt
81 lines (60 loc) · 2.67 KB
/
backup-sharded-cluster-with-filesystem-snapshots.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
====================================================
Back Up a Sharded Cluster with File System Snapshots
====================================================
.. default-domain:: mongodb
.. contents:: On this page
:local:
:backlinks: none
:depth: 1
:class: singlecol
.. versionchanged:: 3.2
Starting in MongoDB 3.2, the procedure can be used with the
:doc:`MMAPv1 </core/mmapv1>` and the :doc:`WiredTiger
</core/wiredtiger>` storage engines. With previous versions of
MongoDB, the procedure applied to :doc:`MMAPv1 </core/mmapv1>` only.
Overview
--------
This document describes a procedure for taking a backup of all
components of a :term:`sharded cluster`. This procedure uses file system
snapshots to capture a copy of the :program:`mongod` instance. An
alternate procedure uses :program:`mongodump` to create binary
database dumps when file-system snapshots are not available. See
:doc:`/tutorial/backup-sharded-cluster-with-database-dumps` for the
alternate procedure.
.. include:: /includes/note-shard-cluster-backup.rst
For more information on backups in MongoDB and backups of sharded
clusters in particular, see :doc:`/core/backups` and
:doc:`/administration/backup-sharded-clusters`.
Considerations
--------------
Balancer
~~~~~~~~
It is *essential* that you stop the :ref:`balancer
<sharding-internals-balancing>` before capturing a backup.
If the balancer is active while you capture backups, the backup
artifacts may be incomplete and/or have duplicate data, as :term:`chunks
<chunk>` may migrate while recording backups.
Precision
~~~~~~~~~
In this procedure, you will stop the cluster balancer and take a backup
up of the :term:`config database`, and then take backups of each
shard in the cluster using a file-system snapshot tool. If you need an
exact moment-in-time snapshot of the system, you will need to stop all
application writes before taking the file system snapshots; otherwise
the snapshot will only approximate a moment in time.
For approximate point-in-time snapshots, you can minimize the impact on
the cluster by taking the backup from a secondary member of each
replica set shard.
Consistency
~~~~~~~~~~~
If the journal and data files are on the same logical volume, you can
use a single point-in-time snapshot to capture a consistent copy of the
data files.
If the journal and data files are on different file systems, you must
use :method:`db.fsyncLock()` and :method:`db.fsyncUnlock()` to ensure
that the data files do not change, providing consistency for the
purposes of creating backups.
.. include:: /includes/fact-backup-snapshots-with-ebs-in-raid10.rst
Procedure
---------
.. include:: /includes/steps/backup-sharded-cluster-with-snapshots.rst