时间点恢复（PITR）必须结合全量快照与oplog回放，前提是oplog覆盖目标时间且备份与oplog匹配；oplog为capped集合，若目标时间早于其最早时间戳则不可恢复。
不能直接靠 mongorestore 实现时间点恢复（PITR），必须结合全量快照 + oplog.rs 回放。关键前提是：你得有覆盖目标时间点的完整 oplog，且备份与 oplog 必须匹配。
确认 oplog 是否覆盖目标时间点
副本集的 oplog.rs 是固定大小的 capped collection，旧日志会被自动覆盖。如果目标恢复时间早于 oplog 最早时间戳，就彻底不可恢复。
- 在 PRIMARY 节点执行
db.printReplicationInfo()，看oldest timestamp是否早于你要恢复的时间 - 用
db.oplog.rs.find().sort({$natural: -1}).limit(1)查最新写入时间，用db.oplog.rs.find().sort({$natural: 1}).limit(1)查最老时间 - 注意：
printReplicationInfo()输出的 “oldest” 是估算值，实际以find().sort({$natural: 1})结果为准 - 如果 oplog 时间窗口太短（比如只保留 2 小时），而你上次备份是 24 小时前，那中间 22 小时的数据就无法还原
使用 mongodump + --oplog 创建可恢复备份
--oplog 不是“开启 oplog”，而是让 mongodump 在备份结束那一刻记录下当前 oplog.rs 的最后位置（即 ts 字段），并把该位置写入备份目录下的 oplog.bson 文件。这个文件是后续回放的基础。
- 必须在 PRIMARY 上执行，且期间不能发生主从切换（否则
oplog位置失效） - 命令示例：
mongodump --host rs0/192.168.10.41:27017 --oplog --out /backup/20260721 -
--oplog本身不捕获备份过程中的所有变更——它只记一个起始位点；真正用于 PITR 的 oplog 日志，要从备份时刻开始，从副本集实时拉取或从归档中获取 - 如果你用的是 Ops Manager 或 Atlas，它们会自动管理 oplog 归档和快照对齐，不用手动处理
oplog.bson
还原时回放 oplog 到指定时间戳
先用 mongorestore 恢复全量快照，再用 mongorestore --oplogReplay 回放 oplog ——但这个选项只支持回放到 oplog.bson 记录的那个**终点时间**，不支持任意时间点。
- 要精确到秒级时间点，必须手动筛选 oplog：用
mongodump --collection oplog.rs --query '{ts: {$lt: Timestamp(1753158420, 1)}}'导出截止到某时间的 oplog 子集 - 然后用
mongorestore --oplogReplay --oplogFile oplog_filtered.bson应用 - 注意：回放 oplog 前，目标实例必须停写、关闭 journal（或设
--nojournal）、以--replSet模式启动但不加入副本集（避免触发复制） - 回放完成后，需手动执行
rs.initiate()或rs.reconfig()重建副本集配置，否则节点无法正常选举
真正容易被忽略的不是命令怎么写，而是 oplog 的生命周期管理和快照-日志对齐。Ops Manager 和 Atlas 把这事封装掉了，但自建环境里，oplog.rs 大小、备份频率、网络延迟导致的 oplog 同步滞后，三者稍一错位，时间点就断档。别等故障了才查 oplog 能不能撑住 24 小时。
