热备份目录没读权限，数据库备份就出问题了怎么办？

“热备份目录没读权限，数据库备份就出问题了怎么办？”这个问题，说白了就是在数据库还在正常对外服务、还在被读写的时候，你想给它做个备份，结果存放备份文件的那个文件夹，你的备份程序没有权限去读它，导致备份任务直接失败了，这种情况虽然看起来是个小问题，但关键时刻能急死人，因为备份是数据安全的最后一道防线。

最直接的反应：别慌，看清楚错误信息。

当备份失败时,管理备份的软件或者你运行的备份命令一定会给你一个错误提示，你一定要仔细读这个提示，它会明确告诉你是因为“Permission denied”（权限被拒绝）还是“Access is denied”（访问被拒绝），这能帮你快速锁定问题就是出在权限上，而不是磁盘空间满了、网络断了之类其他原因，确认是权限问题，我们再进行下一步。

我们来解决这个权限问题，核心思路就是：让执行备份操作的那个“身份”有权利去读写你指定的那个备份目录。

这个“身份”是谁？这很关键，根据参考资料中的说明，这取决于你用什么方式做备份。

• 如果你是在操作系统命令行里,直接用数据库自带的备份工具（比如MySQL的mysqldump或者PostgreSQL的pg_dump），那么执行备份的“身份”就是当前登录系统的这个用户。
• 如果你是在数据库管理系统内部发起备份命令（比如一些图形化界面工具或者数据库调度任务），那么执行备份的“身份”通常是数据库软件本身运行时所使用的那个系统用户（比如MySQL用户、postgres用户）。

解决办法因情况而异：

你是在命令行手动备份。 这说明当前登录的用户对备份目录权限不足，解决方法有几种：

1. 更改备份目录的权限（最简单直接，但需谨慎）： 你可以用管理员权限（比如用sudo）修改那个备份目录的权限，让当前用户能够读写，例如在Linux系统下，你可以运行命令 sudo chmod 755 /你的备份目录路径，或者更直接地 sudo chmod 777 /你的备份目录路径（777意味着所有用户都能读写执行，不够安全，仅在测试环境临时用用），在Windows上，你可以右键点击文件夹，选择“属性”，然后在“安全”选项卡里给相应用户添加“完全控制”或“修改”权限。
2. 换一个有权限的目录： 如果上面操作你觉得有风险或者不会弄，有个更省事的办法：干脆换个地方备份，比如在Linux下，你可以把备份文件直接放到你的家目录（/home/你的用户名/）下，这个目录你肯定有完全权限，备份完成后，你再把它移动到别的地方存档。
3. 切换用户身份： 你可以退出当前登录，换一个已知对备份目录有读写权限的用户重新登录，然后再执行备份命令，或者在命令前加上sudo -u 另一个用户名来临时切换身份执行。

备份任务是由数据库服务自己触发的（比如定时自动备份）。 这种情况更常见，也更容易出这个问题，因为数据库服务（比如mysql服务）是在后台默默运行的，它是以一个特定的系统用户（比如mysql用户）的身份在干活，这个用户可能非常“低调”，权限限制得很严格，所以它很可能无法访问你随便指定的一个目录。

1. 找到正确的“当事人”： 你要搞清楚你的数据库服务是用哪个系统用户运行的，在Linux上，可以用命令 ps aux | grep mysql（如果是MySQL的话）来查看，第一列就是用户名，假设查出来是mysql用户。
2. 给“当事人”授权： 就要把这个备份目录的所有权或者读写权限交给这个mysql用户，推荐的做法是更改目录的所有者，你可以用命令 sudo chown mysql:mysql /你的备份目录路径（把mysql:mysql换成你查到的实际用户名和用户组），这样，数据库服务就有权在这个目录里创建和写入备份文件了。
3. 检查上级目录的权限： 你虽然给了备份目录本身的权限，但如果它上面好几层的父目录没有“执行（x）”权限，数据库用户依然无法进入这个目录，你需要确保从根目录开始，每一层目录至少对数据库用户有r-x（读和执行）的权限。

非常重要的一步：测试！

无论你用了哪种方法,都不要想当然认为问题已经解决了，你一定要手动触发一次备份操作，亲眼看着它成功完成，并且去备份目录下确认备份文件已经正常生成，文件大小看起来也合理，你才能放心。

遇到热备份目录没权限，步骤就是：看错误信息确认问题 -> 搞清楚是谁（哪个用户）在备份 -> 给这个用户授予备份目录的读写权 -> 亲自测试验证。 平时就要养成好习惯，规划备份策略时，提前为备份目录设置好正确、安全的权限，避免临时抱佛脚，毕竟，备份这件事，宁可备而不用，不可用而无备，根据一些数据库管理实践的建议，专门为备份创建一个属主为数据库运行用户的目录，是避免此类问题的最佳方法。