44

I have a Maintenance Plan that is suppose to go through the BACKUP folder and remove all .bak older than 5 days. When I run the job, it gives me a success message but older .bak files are still present.

I've tried the step at the following question: https://serverfault.com/questions/245493/sql-maintenance-cleanup-task-success-but-not-deleting-files

Result is column IsDamaged = 0

I've verified with the following question and this is not my issue: https://serverfault.com/questions/94094/maintenance-cleanup-tasks-running-successfully-but-not-deleting-back-up-files

I've also tried deleting the Job and Maintenance Plan and recreating, but to no avail.

Any ideas?

4

10 回答 10

63

试试这些检查：

  1. 使用 *.* 作为文件扩展名或不带点的 bak，如果其他问题也正确，我发现这两种方法都有效。
  2. 确保该路径只是备份所在的路径，但末尾带有反斜杠。
  3. 首先在创建备份时检查是否勾选了验证。
于 2011-07-25T07:40:43.343 回答
8

这通常是由权限问题引起的。当权限阻止运行该步骤的帐户删除文件时，清理任务似乎没有记录任何有用的信息。

您可以按如下方式验证这一点：

  • 在 SQL Server Management Studio 中，右键单击您的维护计划并选择“修改”
  • 找到用于删除 bak 文件的维护清理任务，然后单击“查看 T-SQL”按钮。将脚本复制到剪贴板 - 类似于“EXECUTE master.dbo.xp_delete_file ...”
  • 使用对包含备份的文件夹具有所需权限的 Windows 帐户连接到服务器并运行 SQL
  • 如果确实清理了 bak 文件，则这表明维护计划任务配置正确并且您有权限问题。
  • 在 Management Studio 中，打开作业的属性窗口（SQL Server 代理 > 作业），单击第一步中的编辑按钮。“运行身份”部分将指示哪个帐户正在运行该作业。
于 2014-03-25T17:08:23.407 回答
6

有同样的问题。罪魁祸首是 .Bak 扩展名。将其更改为 Bak，您应该会很好。

于 2013-06-25T15:49:42.230 回答
2

确保在正确的 SQL Server 中创建维护计划。更详细地说，

如果你有 SQL Server 2005 并且你创建了 maint. 在此 SQL Server 2005 计划下，您将只能“清理”（删除）从 SQL Server 2005 Server 生成/备份的那些备份 (bak) 和事务日志 (trn)。如果您尝试从 2008、2008 R2、2012 或更新版本中清理那些 bak 或 trn，它将无法正常工作。（由于文件头信息）。也就是说，2005 无法识别 2008 或更新格式的文件！

但是，您始终可以通过创建 maint 来清理这些文件。SQL Server 2008 下的计划并从 2005 年到 2012 年（已测试）“清理”这些文件。

也就是说，1. 2005 只能清理 2005 格式的 bak/trn 2. 2008 可以清理 2005 ~ 2012 格式

我没有机会测试 2000（太旧）或 2014（太新）。但我想 2014 年应该从 2008 年开始工作。

于 2014-07-17T16:43:28.870 回答
2

我会给我 2 美分，刚刚也解决了这个问题，使用 SQL 2012 进行了新部署。备份作业正常工作，但是日志和旧备份的清理任务虽然成功完成，但没有做任何事情。

在我看来，在这些愚蠢的事情中，我将扩展设置为.bakand .txt，但是一旦我将它们更改为.BAKand .TXT（大写），它就开始起作用了。

希望它可以帮助解决类似问题的人。

于 2014-07-28T09:17:22.163 回答
1

我有同样的问题，我也试图解决它。我想我尝试了每一种组合，但没有奏效。请注意，xp_delete_file 没有记录，而且很明显有很多错误。

但是我所做的并且可以帮助您的是将步骤更改为 PowerShell 步骤。

您可以使用以下方法删除超过 30 天的文件

获取子项 c:\sqlbackup -recurse | 其中 {$ .lastwritetime -lt (get-date).adddays(-30) -and -not $ .psiscontainer} |% {remove-item $_.fullname -force -whatif}

请注意添加的 -whatif 以便您进行测试。

但就我而言，这还不够。PowerShell 方法存在权利问题。运行 SQL 代理的帐户没有删除文件的权限。正确设置权限时，一切都像魅力一样。

祝你好运

于 2013-07-19T08:33:03.100 回答
1

我以前也遇到过类似的工作问题。我遇到它没有删除的情况是因为当我通过 GUI 时没有明确设置位置。即使我没有更改任何内容，当没有具体列出路径位置时，它也好像不知道在哪里处理删除，所以没有发生任何删除。它备份得很好，一切都很好，但它不会按照向导/表单中的指定进行清理。

于 2011-03-16T15:20:13.150 回答
1

我发现我必须将频率从 1 周更改为几天，然后它会删除旧的备份。为什么，我不知道，但这确实解决了问题。

于 2014-07-09T15:57:16.180 回答
0

问题把我逼疯了。我有一个解决方法，尽管其他服务器使用没有问题的维护计划。我复制了T-SQL脚本并将 sp 更改dbo为sys. 这个对我有用。读取脚本

Create Procedure bk_removeTLogBackupFiles
as
Declare @DeleteDate varchar(50)
Declare @DeleteExecuteSQL varchar(1000)
Set @DeleteDate = cast(DATEADD(day,-7,GetDate()) as varchar(50))
Set   @DeleteExecuteSQL =
'EXECUTE master.sys.xp_delete_file 0,N''\\Backupserver\BackupFolder\' + @@servername + '\User'',N''trn'',N' + quotename(@DeleteDate,'''') +  ',1'


Execute (@DeleteExecuteSQL)

这是一个通用脚本，我用于所有备份到某个服务器，服务器\文件夹级别的安全性被分类到用户系统等的文件夹中。不多，但它对我有用。

于 2014-02-04T18:19:11.277 回答
0

当我试图删除维护文件时，我的 2 美分投入......我的失败了。尽管我正确设置了扩展名和文件位置，但我忘记将其从备份文件设置为维护计划文件。

于 2014-01-08T18:08:27.570 回答