DBAtlas · 数据库运维图谱

MongoDB 备份与恢复 (mongodump, mongorestore, snapshot)

MongoDB难度: 中级耗时: 45–90 分钟

为已安装的 MongoDB 建立备份机制，并按场景逐一说明如何从备份恢复。备份：用 mongodump 备份单个 collection、数据库或整个 deployment（--archive --gzip；在 replica set 上用 --oplog 取得一致时间点，并从 secondary 读取）、凭据文件、通过 systemd timer/cron 执行带保留期的定时备份、测试恢复，以及可选的文件系统 snapshot。恢复：恢复演练、完整恢复、单个数据库/collection、基于备份 + oplog 恢复到指定时间点、克隆到其他 cluster，以及 sharded cluster。数据量达数百 GB、需要快速恢复或使用 sharded cluster 时，应优先选择 snapshot 或企业级工具 (PBM, Ops Manager)，而不是 mongodump；前几个步骤会说明如何选择。

架构: 备份服务器或某个成员 + replica set / 单实例 / sharded cluster (mongos)

场景

  • 配置备份：mongodump、定时与测试恢复 — 备份用户、凭据文件、手动和定时 mongodump、以新名称进行测试恢复；可选 snapshot 和 mongoexport。首次配置请从这里开始。
  • 备份真的能恢复吗？(--dryRun 及在临时实例上演练) — 不触碰生产数据：检查归档完整性、其中包含的 namespace 和 oplog，并可选择完整恢复到临时 mongod 并核对文档数。
  • 从备份恢复全部数据 (完整恢复, --drop) — 数据大量丢失或损坏，deployment 将回到备份时刻。备份之后的写入会丢失；恢复期间应用停机。
  • 恢复单个数据库或 collection (--nsInclude，以新名称或原位) — 某个 collection/数据库被删除或损坏，其余数据完好：只从备份恢复该 namespace；其他数据不受影响，应用可继续运行。
  • 恢复到指定时间点：备份 + oplog (误 drop、错误的 update/delete) — 错误操作发生在备份之后，且到该时刻为止的写入也需要保留：先恢复最近一次完整备份，再将生产 oplog 应用到错误操作之前 (--oplogReplay --oplogLimit)。仅适用于 replica set。
  • 将备份恢复到其他 cluster / 服务器 (克隆、测试环境、迁移) — 不触碰源 deployment：备份恢复到另一个 replica set 或实例（测试/报表副本、服务器迁移、版本升级）；可选迁移用户。
  • 恢复 sharded cluster：mongodump 的局限与正确方法 — 备份的拓扑是 sharded cluster：通过 mongos 进行逻辑恢复（重建 shard key、balancer），或使用协调一致的 snapshot 以物理方式重建整个 cluster。

开始之前

  • 被备份的服务器运行受支持的操作系统；时钟已通过 NTP 同步，时区正确（备份文件名和定时均基于本地时间）。
  • 本服务器能解析 … 的名称并访问其端口。…在 replica set 上，连接字符串中的名称必须与 rs.conf() 中的成员名称一致；驱动程序会连接这些名称。…
  • … 位于独立于数据盘的磁盘或网络共享上，可用空间至少为压缩备份大小（通常为数据量的 20–50%）乘以保留期。与数据在同一磁盘上的备份会在磁盘损坏时一同丢失。
  • 已启用授权，且掌握 … 用户（root，或 userAdminAnyDatabase + clusterAdmin 角色）及其密码。备份用户由该用户创建。
  • oplog 窗口明显长于完整备份所需时间（至少数小时）。--oplog 会收集备份期间产生的 oplog 条目；窗口短于备份时间时，备份会失败。…进行时间点恢复时，生产 oplog 的第一条记录必须早于所用完整备份的结束时刻；否则两者之间的操作将无处可寻。…
  • 可通过 HTTPS 访问 MongoDB repo (repo.mongodb.org)，或已配置内部 mirror；如果服务器上已安装工具，会显示其版本。
  • dbPath (…) 位于 … LV 上，且卷组至少有 … 可用空间。WiredTiger journal (…/journal) 必须位于同一 LV；如果已移到其他磁盘，snapshot 之前必须执行 fsyncLock。
  • 具有 root 或 sudo 权限。如果要进行完整恢复，已取得维护窗口和应用团队的批准。…恢复之前已记录事件（时间、操作、执行人）；应用团队清楚哪些数据会恢复。…
  • 已通过本指南的“配置备份”场景完成备份配置：本服务器上已有工具 (mongorestore, mongosh) 和凭据文件 … (…: backup + restore)。如果没有，请先执行 配置备份 场景的前两个阶段。
  • 恢复会重写数据和索引：目标服务器数据盘的可用空间至少为待恢复数据（未压缩）的 1.5 倍。…在 replica set 上，secondary 通过复制接收相同的写入；恢复期间 oplog 窗口会缩短。…
  • … 的可用空间不小于待恢复数据的未压缩大小（完整备份 + oplog）。临时 mongod 只在 127.0.0.1 上监听 … 端口；该端口必须空闲。
  • 目标 (…) 已安装并运行，已启用授权，且掌握 … (root) 用户的密码。目标版本与源相同或更新（如 7.0 → 8.0）；不支持恢复到更旧的版本。

指南阶段

  • 安装工具 — 添加 MongoDB … repo · 添加 MongoDB … repo · 安装 mongodump、mongorestore 和 mongosh · 准备备份目录
  • 备份用户与凭据文件 — 创建备份用户 · 写入凭据文件 (--config) · 测试连接
  • 手动备份 (mongodump) — 检查数据大小和 oplog 窗口 · 停止 balancer · 使用 mongodump 备份 · 重新启动 balancer · 验证备份 (gzip 和 dryRun) · 按查询备份子集 (--query)
  • 恢复 (mongorestore) — 以新名称进行测试恢复 (--nsFrom/--nsTo) · 比较文档数 · 删除测试数据库 · 为 oplogReplay 定义角色 · 原位完整恢复 (--drop) · 收回临时权限 …
  • mongoexport / mongoimport（数据迁移，不是备份） — 导出 collection (mongoexport) · 导入到单独的 collection (mongoimport) · 比较类型并清理
  • 文件系统 snapshot — 创建 LVM snapshot（配合 fsyncLock） · 将 snapshot 归档到备份目录 · 配合 fsyncLock 复制文件
  • Sharded cluster 备份：限制与企业级方案 — 选择一致的 sharded cluster 备份方法
  • 定时备份与保留 — 限制 balancer 在备份时段之外运行 · 编写备份脚本 · 使脚本可执行 · 准备到远程服务器的 SSH 访问 · 创建 systemd service 和 timer · 手动触发定时备份并验证 …
  • 监控与维护 — 监控最后一次备份的时长 · 定期恢复演练
  • 1. 诊断：备份文件与工具 — 按顺序列出备份文件和最近的备份
  • 2. 演练：读取归档 — 检查压缩完整性 (gzip -t) · 不写入数据试运行恢复 (--dryRun) · 归档中是否包含 oplog？（一致时间点）
  • 3. 演练：完整恢复到临时实例 — 为临时实例准备 mongod · 启动临时 mongod · 将备份恢复到临时实例 · 统计恢复的数据 · 停止并删除临时实例
  • 4. 后续 — 记录演练结果
  • Sharded cluster：不使用本场景进行完整恢复 — 转到 sharded cluster 场景
  • 1. 诊断：完整恢复是否是正确的场景？ — 查看当前状态和受影响的数据 · 不写入数据试运行恢复 (--dryRun)
  • 2. 安全保障 — 停止应用并检查连接 · 备份当前状态（回退点）
  • 3. 执行：完整恢复 — 为 oplogReplay 授予临时权限 · 原位恢复备份 (--drop… --oplogReplay…) · 收回临时权限 · 清理恢复产生的临时用户 collection
  • 4. 验证 — 检查文档数和索引数 · 检查 replica set 是否已追平
  • 5. 后续 — 做一次新的完整备份并启动应用
  • 1. 诊断：namespace 的当前状态与备份中的状态 — 查看生产环境的状态 · 不写入数据试运行恢复 (--dryRun)
  • 2. 安全保障 — 备份当前状态（回退点）
  • 2. 执行：以新名称恢复 — 以新名称恢复备份 (--nsFrom/--nsTo) · 比较备份与生产环境中的计数 · 将被删除的文档补回生产环境 ($merge) · 删除临时副本
  • 3. 执行：原位恢复 (--drop) — 保留 shard key：重新对 collection 分片 · 原位恢复 namespace
  • 时间点恢复仅适用于 replica set — 此 deployment 无法使用 oplog 进行时间点恢复
  • 1. 诊断：错误操作的时刻与 oplog 窗口 — 在 oplog 中查找错误操作 · 确认完整备份位于 oplog 窗口内
  • 2. 安全保障：复制生产 oplog — 复制生产 oplog · 备份当前状态（回退点）
  • 3. 执行：在临时实例上回到该时刻 — 为临时实例准备 mongod · 启动临时 mongod · 将完整备份恢复到临时实例 · 将生产 oplog 应用到错误操作之前 · 在临时实例上检查恢复的数据 · 将恢复的数据复制到生产环境 …
  • 4. 后续 — 做一次新的完整备份并消除根本原因
  • 1. 诊断：目标是否正确、是否兼容？ — 确认目标不是源，并检查其版本 · 不写入数据试运行恢复 (--dryRun)
  • 2. 安全保障与目标凭据 — 为目标编写临时凭据文件 · 备份目标上的现有数据
按您的环境打开分步计划 →