如何为Azure Blob存储文件夹配置保留期？为Azure中SQL Server日志备份设置7天保留期

这个场景最稳妥的实现方式是用Blob存储自带的生命周期管理能力，不依赖SQL Server侧的备份清理任务，可靠性更高，具体配置步骤如下：

• 先精准定位日志备份的目标路径
  先核对你存SQL日志备份的实际Blob路径，比如常见的备份路径结构为https://<你的存储账户名>.blob.core.windows.net/backup-container/sql-log-backups/，后续规则的匹配前缀要严格指向backup-container/sql-log-backups/这层文件夹，千万别把规则覆盖整个容器，避免误删同容器下保留周期更长的全量备份、差异备份文件。
• 进入对应存储账户的「生命周期管理」模块，新建规则
  • 规则适用范围选择「为所选Blob应用规则」，通过Blob前缀匹配锁定刚才记录的日志备份文件夹路径
  • 规则动作选择「删除Blob」
  • 触发条件设置为「Blob的最后修改时间达到7天之后执行删除」

    这里要特意说明：SQL Server备份到Blob的文件，最后修改时间和备份完成时间是完全对齐的，不存在写入中途导致时间戳不准的问题；千万别选「Blob创建时间」作为触发条件，万一你后续做备份迁移，把老路径的日志备份复制到新路径，文件创建时间会远早于实际备份生成时间，容易误删合规的备份文件。

• 规则校验和避坑
  • 不要把Blob软删除的保留期当成备份保留规则用：软删除是给误删恢复做兜底的，时间计算起点是文件被删除的时刻，不是备份生成的时刻，用它做保留管控会导致日志备份实际留存时长远超7天的要求
  • 不要额外开启规则对Blob快照、版本的联动删除逻辑，除非你明确给备份文件开启了Blob版本管理，避免无意义的版本残留占用存储
  • 规则创建后不用等实时生效，生命周期任务最快每小时运行一次，你可以提前在目标文件夹里放一个早于7天的测试Blob，验证规则触发逻辑正常即可，不用反复刷新页面等结果
• 额外对齐注意事项
  如果你的SQL Server是用Azure自带的托管备份能力对接的Blob存储，记得把SQL侧的日志备份保留设置也对齐成7天，避免和Blob侧的规则产生冲突——实际执行时Blob侧的规则优先级更高，但两边配置一致能避免产生不必要的存储费。

内容的提问来源于stack exchange，提问作者AVB