直接 db.grantrolestouser() 会失败，因为 restore 是集群级内置角色，必须在 admin 数据库上下文中、由具备 useradminanydatabase 或 root 权限的用户显式授予。
restore 权限不是单独授予的“操作”，而是一个内置角色，必须显式分配给用户，且仅在 admin 数据库上下文中生效。
为什么直接 db.grantRolesToUser() 会失败？
常见错误是：在业务数据库（如 myapp）里执行 db.grantRolesToUser("backup_user", [{role: "restore", db: "admin"}])，结果报错 no role found 或 not authorized。原因有二：
– restore 是集群级角色，只能在 admin 数据库中授予；
– 执行授予操作的当前用户，必须自身拥有 userAdminAnyDatabase 或 root 角色，且已通过 admin 认证。
正确授予 restore 权限的三步操作
必须切换到 admin 数据库，并用高权限账号操作：
- 连接时指定
authSource=admin：mongo --username admin --password xxx --authenticationDatabase admin - 执行
use admin - 运行授予命令：
db.grantRolesToUser("backup_user", [{role: "restore", db: "admin"}])注意：这里db: "admin"不表示“把 restore 权限给 admin 库”，而是声明该角色作用域为admin—— 这是 MongoDB 对集群角色的固定写法
restore 角色的实际能力边界
它只允许执行 mongorestore 命令所需的最小权限，不等于能读写任意数据：
- 可访问
local、config和所有业务数据库的元数据（如集合结构、索引定义） - 可写入目标数据库（即
mongorestore -d targetdb中的targetdb），但不能绕过该库自身的读写权限控制 - 不能执行
drop、createUser、shutdown等管理操作 —— 那些需要dbAdminAnyDatabase或root - 若恢复时使用
--drop，还需额外授予dbAdmin角色到目标库，否则报not authorized on xxx to execute command drop
容易被忽略的兼容性陷阱
mongorestore 要求源 dump 文件与目标 MongoDB 版本兼容，但权限本身不校验版本 —— 这导致一个隐蔽问题：
- 用户有
restore角色，mongorestore命令能连上、能列出 collections，但在真正写入时卡住或静默失败 - 根本原因常是：dump 来自 6.0，目标为 7.0，但未设置
--legacy或未升级 FCV（featureCompatibilityVersion） - 验证方式：先用
mongorestore --dryRun测试解析，再检查目标节点日志是否有incompatible BSON version类错误
