对于 AI 代理:可在 https://www.mongodb.com/zh-cn/docs/llms.txt 获取文档索引—通过在任何 URL 路径后添加 .md 可获取所有页面的 Markdown 版本。
Docs 菜单

Back Up and Restore mongot Data

You can back up MongoDB Search and MongoDB Vector Search index data using filesystem snapshots. A filesystem snapshot creates a point-in-time copy of the mongot data directory, which you can use to restore your indexes without rebuilding them from source data.

mongot is not the primary data store for your data. If mongot data is corrupted or lost, MongoDB can rebuild MongoDB Search and MongoDB Vector Search indexes from the source data in mongod. However, index builds can be slow and in some cases can take days to complete.

If your application requires minimal recovery time, use regular filesystem snapshots.

mongot replicates data from mongod through a change stream. A mongot backup is only valid for the change-stream retention period. If you restore from a backup that is older than the retention period, mongot detects that it fell off the oplog and rebuilds indexes from the source data in mongod. The restored snapshot data remains immediately queryable during the rebuild. Search results may reflect a point in time earlier than the current state of mongod until the rebuild completes.

To back up mongot, stop your mongot instance and take a filesystem snapshot of the mongot data directory using the tool of your choice. For a complete example using LVM on Linux, see Back Up and Restore Using LVM on Linux.

To restore mongot from a filesystem snapshot, use the tool of your choice to restore a backup snapshot to the mongot data directory. You also must delete the serverId.txt file from the mongot data directory before you restart mongot to generate a new server identity.

After you restore the snapshot and restart mongot, MongoDB reads the restored index data and resumes replication from your mongod instance. For a complete example using LVM on Linux, see Restore a Snapshot.

Retaining recent snapshots of mongot persistent volumes provides a faster recovery path for pod replacement, node maintenance, and storage recovery compared to rebuilding indexes from source data. MongoDB Controllers for Kubernetes Operator doesn't automatically back up or restore mongot persistent volumes. Plan backups of the persistent volume that stores the mongot data directory using your storage platform's filesystem or volume snapshot capability.

If MongoDB Controllers for Kubernetes Operator reschedules or replaces a mongot pod, attach its existing persistent volume to the new pod to reuse local index data instead of rebuilding all indexes from source data. If you made changes to your deployment after you took the backup snapshot, mongot must catch up from mongod after startup.

To restore mongot in Kubernetes, restore the backup snapshot to the persistent volume. Ensure that the replacement pod mounts that volume and that you delete the serverId.txt file before you restart mongot.