backup角色仅在admin数据库中生效，必须在admin库上下文中创建用户并指定db:"admin"，且需配合readanydatabase等数据访问角色才能完成备份。
backup角色只在admin数据库中生效
给用户授backup权限，必须在admin数据库上下文中创建用户或更新角色，否则权限不生效。MongoDB不会把backup角色识别为普通数据库里的有效角色——哪怕你在目标业务库（比如myapp）里执行db.createUser()并指定{ role: "backup", db: "myapp" }，这个角色也会被忽略。
正确做法是：先use admin，再调用db.createUser()或db.grantRolesToUser()，且db字段必须为"admin"。
-
backup角色本身不包含任何数据库读写权限，它只允许执行mongodump等备份操作，但前提是用户能连上并认证到对应数据库 - 若要备份多个数据库，建议同时授予
readAnyDatabase（只读）或readWriteAnyDatabase（读写），否则mongodump会因无权访问而报错not authorized on <db> to execute command { find: ... }</db> - 不要混淆
backup和restore：前者用于导出，后者用于导入；两者需分别授权，不能靠一个角色覆盖
mongodump命令必须显式传入认证参数
即使用户已拥有backup和readAnyDatabase角色，mongodump也不会自动读取.mongorc.js或环境变量里的凭据。不带认证参数直接运行mongodump -d mydb，会收到Failed: can't get database names: not authorized on admin to execute command { listDatabases: 1 }。
必须显式提供用户名、密码、认证库（authSource）：
- 最简形式：
mongodump -u backupuser -p 'pass123' --authenticationDatabase admin -d mydb - 如果 MongoDB 启用了 SCRAM-SHA-256（4.0+ 默认），需加
--authenticationMechanism SCRAM-SHA-256，否则可能报Authentication failed - 连接字符串方式更可靠：
mongodump --uri "mongodb://backupuser:pass123@localhost:27017/mydb?authSource=admin"
备份用户不能绕过数据库级权限检查
backup角色不是“免检通行证”。它只赋予执行备份命令的权限，不豁免底层数据访问控制。例如：
- 用户有
backup角色但没read权限，mongodump -d sensitive_db会失败，报错not authorized on sensitive_db to execute command { find: ... } - 用户有
readWrite但没backup，mongodump仍会失败，报错not authorized on admin to execute command { listDatabases: 1 }（因为listDatabases需admin库权限） - 常见组合是：
backup+readAnyDatabase（全库备份）或backup+read（单库备份）
注意密码里别含@符号
如果密码含@，用连接字符串方式传参时会被误解析为 URI 分隔符，导致认证失败或连接地址错误。例如mongodb://user:P@ssw0rd@localhost:27017/db?authSource=admin实际被拆成user:P和ssw0rd@localhost:27017两段。
解决方法只有两个：
- URL 编码密码：
P%40ssw0rd（@→%40） - 改用
-u/-p参数分离传入，避开 URI 解析：mongodump -u user -p 'P@ssw0rd' --authenticationDatabase admin
真正容易被忽略的是：这个限制不仅影响连接字符串，也影响mongoexport、mongorestore等所有工具——只要走 URI 解析路径，@就必须编码。
