Apache Derby日志权限变更导致Log shipping传输失败问题咨询

你遇到的这个问题我之前帮不少用户排查过，结合你用本地管理员配置Log Shipping、原本正常后来突然权限收缩的背景，大概率是以下几个原因导致的：

1. 日志目录的权限模板被修改或继承中断 #

最常见的情况是**/database/log目录的NTFS权限被手动调整，或者权限继承被意外关闭**：

• 可能有人右键修改了该目录的安全权限，移除了Log Shipping复制作业所用账户的访问权限，同时把权限限定给了管理员组；
• 要是目录的"继承父项权限"被取消（在目录属性→安全→高级里的设置），原本能访问的账户就失去了权限继承路径，新生成的日志文件只会继承当前目录仅管理员可访问的权限。

2. SQL Server服务或备份作业的运行账户变了 #

虽然你用本地管理员配置了Log Shipping，但如果后续SQL Server服务账户或者Log Shipping备份作业的执行账户被修改，会直接影响日志文件的权限：

• 如果现在备份作业用本地管理员账户运行，新生成的日志文件默认所有者就是该管理员，系统可能会自动把权限限定为仅所有者（管理员）可访问（取决于系统的默认文件权限模板）；
• 要是之前备份作业用的是权限更宽松的账户（比如Local System），后来改成了管理员，就会出现权限突然收缩的情况。

3. 组策略或系统安全策略的更新 #

在企业环境里，组策略（GPO）的推送经常是这类问题的幕后黑手：

• 管理员可能更新了文件系统权限策略，强制对数据库日志这类敏感目录设置仅管理员可访问的权限；
• 本地安全策略被修改，比如调整了新创建文件的默认权限规则，导致日志文件自动应用更严格的权限。

4. 安全软件的自动干预 #

杀毒软件、EDR（终端检测与响应）工具这类安全软件，有时候会自作主张修改文件权限：

• 如果它们把数据库日志识别为包含敏感数据（比如业务数据、配置信息），可能会自动锁定权限，只允许管理员访问；
• 有些工具在完成扫描或清理操作后，会重置文件的权限设置，导致原本能访问Log Shipping复制账户的权限丢失。

5. 备份工具的配置变更 #

如果你用了第三方备份工具（而非SQL Server原生的Log Shipping备份功能），工具的配置改动也可能引发问题：

• 备份工具的权限设置被修改，强制生成仅管理员可访问的备份文件；
• 工具的运行账户切换为管理员，导致生成的日志文件继承了该账户的权限范围，其他账户无法访问。

快速排查小技巧 #

• 先去检查/database/log目录的NTFS权限，确认Log Shipping复制作业的运行账户（通常是SQL Server代理账户或你配置的专用账户）是否还有读取权限；
• 打开SQL Server代理，查看Log Shipping备份作业的运行账户，对比之前的配置有没有变更；
• 去事件查看器的Windows安全日志里，搜搜近期有没有权限修改的相关记录，能帮你定位是谁/什么操作改了权限。

内容的提问来源于stack exchange，提问作者J.Doe