我不是 DBA，但事情就是这样，我必须戴上 DBA 的帽子并在我的 SQL Server 实例上设置维护计划。
所以一段时间以来，我一直让我的 SSIS 通宵进程运行Execute SQL Task来执行备份 - 基本上是运行master.dbo.xp_create_subdir以确保目标文件夹存在，然后BACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT.
每当该任务失败时，该过程的其余部分将中止，并且我会收到通知，并在第二天早上注意到事务日志的驱动器已满载，因此我将手动截断它们并继续前进。 ..直到故事重演并且事务日志再次超出可用磁盘空间。
“手动截断”脚本如下所示：
use Staging; alter database Staging set recovery simple alter database Staging set recovery full dbcc shrinkfile ('Staging_log', 0, truncateonly); go
所以我越来越厌倦了，我决定尝试正确地做事，并按照这里的步骤创建一个实际的维护计划：
问题是，我以前从未这样做过，所以我有几个问题：
- 像这样备份事务日志会自动截断它们，还是我需要做其他事情？
- 可以同时运行数据和事务日志备份吗？如果没有，那么这样做的正确方法是什么？
- 备份文件被另一个进程在一夜之间获取，该进程抓取服务器上的所有文件并将它们存储在其他地方 - 将备份集在 2 天后过期是个好主意吗？我需要让它们过期吗？
- 清理任务分别删除 .bak 和 .trn 子文件夹下的“旧”文件
G:\Backups。那有意义吗？ - 在 SSIS 中执行此操作会更好，因此如果/当备份失败时我可以使 ETL 失败？或者我的 ETL 过程是否应该关心？
抱歉，如果一篇文章的问题太多了，如果需要，我会编辑并提出多个问题 - 我认为它们都是紧密相关的。
您应该根据您的业务需求选择您的恢复模式：
基于以上答案，您应该谨慎选择您的数据库恢复模式。
简单来说（不讨论批量日志恢复模型），
请记住，日志截断不是事务日志文件大小的物理减小，这意味着事务日志文件的非活动部分被标记为可重用。
因此，您应该正确地调整您的事务日志文件（和数据文件）的大小。增长日志文件将引发自动增长事件（如果您的数据库设置为自动增长作为最后的手段）。检查我的答案 -自动增长 - 使用百分比？
我强烈建议您放弃维护计划并实施 [智能维护解决方案 - 简单、灵活并遵循最佳实践] - 5。- Ola 的备份解决方案（以及索引维护解决方案）。
让我们解决您的问题：
请不要附加备份或将它们设置为过期。他们制造了一个大混乱。使用
INIT并使用带有日期时间戳的单独日志备份。易于维护。为此，请使用 Ola 的备份解决方案。该解决方案也可以灵活地删除旧备份。完整备份对 T-log 备份没有影响。完整备份仅包含足够的必要事务日志，以便在还原的情况下，数据库可以在事务上与完整备份的数据读取部分完成的时间保持一致。检查 -完整备份包含多少事务日志？
此外，完整备份期间的日志备份不会截断事务日志。完整备份完成后的（几个）日志备份将截断日志。
对于以上两者，请使用 Ola 的备份维护解决方案。它将负责删除旧文件。