Answers:
由于需要10TB的备份，这变得有些复杂。
尽管延迟的副本集成员可以提供一种相对简便的方法来帮助您进行意外操作，但无法替代适当的备份，就像RAID不能替代基于文件系统的备份一样。
这在很大程度上取决于您的设置。
对于10TB，我假设您已连接某种SAN。在这些环境中备份MongoDB的最简单方法是，确保已在文件系统和MongoDB上同时激活了日记功能，并且只需对其中一个辅助磁盘的SAN卷进行快照，最好是隐藏的快照，以确保您的操作不会不会被打扰。通常只需几秒钟，但是请确保您的复制操作日志窗口足够。否则，您可能需要重新同步辅助服务器。
对于mongodump的用法，我不得不不同意RolandoMySQLDBA。首先，它在服务器上强加了锁。尽管解除锁定的速度相对较快，但大量的锁定可能会加起来并干扰您的操作，除非在隐藏节点上运行或在没有读取优先级击中次要节点时运行。另外，它并不是很快。我希望它至少运行几个小时，最有可能花费比备份时间更长的时间。旁注：始终使用该--oplog选项运行mongodump。还请记住，mongodump不会备份索引，而是创建索引的操作。这些索引必须在还原期间重新创建，这可能会大大增加您需要的时间。根据我的经验，如果必须还原数据库，则希望尽快恢复它。为什么mongodump不适合备份10TB的另一点。
您可以在正在运行的mongod实例上创建LVM快照，前提是您已在mongod中启用了日记功能（根据我的经验，也可以在FS级别启用日记功能也没有什么坏处）。但是，LVM快照会带来一些影响。首先，您显然需要有足够的磁盘空间来在备份操作期间进行更改。让我澄清一下。
假设您的每小时更改率为500GB。并且您希望在将备份上传到某些存储之前将其备份。即使使用并行bzip2，10TB的压缩也需要花费几个小时才能完成，这仅仅是因为最有可能导致海量存储吞吐量成为限制因素。假设将数据压缩到2TB需要2个小时。因此，到目前为止，我们总共需要2TB + 2 * 500GB的可用磁盘空间，而LVM快照则需要1TB。这将导致至少需要过度配置文件系统30％。如果您希望有一个适当的安全裕度，则可以很容易地将其提高到60-70％（原始文件系统的利用率为0.8时为20％，快照大小以及压缩后的备份本身所需的空间相同） ）。在大多数生产环境中，这是不可接受的，因为过度配置是静态的（您不希望备份脚本动态地与LVM冲突，对吗？）。
尽管MMS备份具有一些很棒的功能（连续备份，简单的时间点恢复），但它也具有一些严重的缺点：大型部署的价格很容易达到数千美元。假设这10TB的每小时更改率为500GB，那么对于云备份而言，这将是中等的六位数。每月一次
我的建议是，为您的服务器进行企业订阅，以便有资格拥有本地MMS实例（包括备份）。
以下是我按照偏好的降序排列的选项。
有两种选择
如果您不介意停机，最简单的方法是
service mongod stop将LVM快照或cpMongo数据文件夹的暴力破解到另一个磁盘
service mongod start当然，如果10TB的数据位于独立计算机上，则您不希望停机。
如果您的副本集包含三个节点，请使用其中一个节点进行备份
{
"_id" : "myreplica",
"version" : 1,
"members" : [
{
"_id" : 1,
"host" : "10.20.30.40:27017",
"priority" : 2
},
{
"_id" : 2,
"host" : "10.20.30.41:27017"
},
{
"_id" : 3,
"host" : "10.20.30.42:27017",
"priority" : 0,
"slaveDelay" : 3600
}
]
}
将节点与"_id' : 3所有物理备份一起使用。因此，没有停机时间。要获取午夜快照，您可以在1:00 AM启动备份，因为隐藏节点要晚1小时。
当然，这样做的缺点是要再增加两台服务器，每台服务器的容量均为10TB，这将使sysadmin的运行状况受到威胁。
您可以在独立计算机上使用mongodump，但由于mongodump是使用其他连接的连接的客户端程序，因此必须降低性能。
如果要进行时间点备份，则应使用
mongodump --oplog 逻辑BSON备份将比物理备份小（尤其是压缩或bzip压缩）。
使用mongodump --oplog最能对隐藏节点来完成。这样一来，主机上的性能就不会受到影响。
我对MongoDB（偶然/偶然的MongoDBA）比较陌生。希望我的回答有帮助。