为帮助 Data Protection Manager 使用磁带的全部容量而执行的操作

微软中国 TechNet 团队博客

IT 专业人士自己的博客!与您分享最新产品技术文章!

为帮助 Data Protection Manager 使用磁带的全部容量而执行的操作

  • Comments 0
  • Likes

嗨,我是 Mike Jacquet。今天,我想谈一下为帮助 Data Protection Manager (DPM) 使用磁带的全部容量而执行的操作。许多客户报告说,DPM 磁带备份使用的磁带比在保护组上备份大型数据源或许多小型数据源时所需的磁带更多。例如,磁带的纯容量为 800GB,但 DPM 似乎从未充满磁带,甚至在仅仅写入几 GB 字节之后停止使用磁带。其他客户则声称,在执行大到足以充满磁带的备份时,他们在单独备份会话期间从未遇到填充磁带方面的问题,但是,在磁带没有充满或者标记为场外就绪的情况下,磁带仍然不可用于在以后的日期或星期所安排的后续备份作业。

这些问题似乎相互关联,但在现实中,存在一些需要了解的根本原因,而且在实现最佳磁带使用率之前,需要解释/配置 DPM 设置。

磁带驱动器/库硬件和设备驱动程序。

Data Protection Manager 没有配备或使用用于磁带驱动器和磁带库的 Microsoft 专有设备驱动程序;相反,DPM 依赖来自 OEM 硬件供应商的 Windows 2008 X64 兼容设备驱动程序。我们为客户提供的指导原则是,如果 Windows Server 目录的硬件/存储部分列出了磁带库,而且显示为与 Windows 2008 X64 和 Windows 2008 R2 相兼容,则该磁带库应与 Data Protection Manager 完美地配合工作。

Windows Server 目录:http://www.windowsservercatalog.com

DPM 产品组发现的一个问题是,当达到磁带尾端时,一些磁带驱动器不能正确地报告或正确地处理介质 EOM 的尾端,而是报告一则 IO_DEVICE_ERROR 0x8007045D 错误。这个问题会导致 DPM 磁带备份作业在填充磁带的任何时间失败。发现的另一个问题是,一些磁带驱动器不能非常充分地处理多个缓冲区,而且还会导致报告 IO 错误。为了缓减这两个问题,向 DPM 代理添加了一些逻辑,以处理这些超出我们控制范围的问题类型。

如今,如果磁带驱动程序返回 IO_DEVICE_ERROR,DPM 将自动将 IO_DEVICE_ERROR 转换为 END_OF_TAPE_REACHED 并跨至下一介质,而且不会出现任何问题。但是,这给我们带来了最初报告的问题,即 DPM 将不会充满磁带,而是在仅仅写入几 GB 之后获取另一磁带。

您现在会问,如何辨别正在使用的磁带驱动器/驱动程序/固件组合背后是否存在这些问题/隐藏的设备 I/O 错误 0x8007045D?

要查看磁带驱动器是否报告 IO 错误 0x8007045D,即“由于 IO 设备错误,无法运行此项请求”,您可以在 DPM 服务器上运行以下命令。

  1. 打开管理命令提示符。
  2. CD C:\Program file\Microsoft DPM\DPM\Temp
  3. 查找 /I "0x8007045D" MSDPM*.Errlog >C:\temp\MSDPM0x8007045D.TXT
  4. 记事本 C:\temp\MSDPM0x8007045D.TXT
  5. 查看文件中是否存在任何条目,如果没有,请查看 DPMRA 日志
  6. 查找 /I "0x8007045D" DPMRA*.Errlog >C:\temp\DPMRA0x8007045D.TXT
  7. 记事本 C:\temp\DPMRA0x8007045D.TXT

另请搜索等效的十进制数 "-2147023779"。

注意 DPMLA*.errlog 可能包含 0x8007045D 错误,但显示正常,因此不要查看该文件。

如何修复这个 I/O 0x8007045D 错误问题?

1.如果磁带库具有自动清洁脏磁带驱动器的功能,必须禁用该功能。DPM 不支持在正常操作期间启用自动清洁功能。

示例:取消选中磁带库管理软件或磁带库控制面板中的选项。

clip_image002[1]

请考虑以下内容…

A) DPM 开始一些备份作业,并且可能在向磁带写入一些小型数据源之后完成备份。
B) 在下次备份到同一磁带期间,磁带驱动器在数据源备份过程中报告脏状态。
C) 磁带库自动清洁功能将磁带拉离 DPM 以清洁该驱动器。
D) 由于驱动器不再包含介质,DPM 备份作业失败。
D) 这使磁带部分地充满以前创建的唯一成功的恢复点,然后,由于我们在内部遇到 IO 错误 0x8007045D,DPM 将磁带标记为场外就绪。
E) 现在显示 DPM 没有像预期一样使用磁带的全部容量。

您可以专门配置 DPM,使特定的插槽包含清洁磁带,当驱动器变脏时,必须手动运行磁带清洁作业。

对于 DPM 2010:如何清洁磁带驱动器:http://technet.microsoft.com/zh-cn/library/ff399452.aspx
对于 DPM 2007:如何清洁磁带驱动器:http://technet.microsoft.com/zh-cn/library/bb795736.aspx

2.  请与磁带驱动器/磁带库 OEM 供应商核对,以了解是否存在任何可用的新固件或驱动程序更新。如有,请更新至最新修订版。检查控制器设置以及 scsi 或光纤连接(包括终止)。

3.默认情况下,当写入磁带驱动器时,DPM 将使用 10 个磁带缓冲区。下面的 BufferQueueSize 注册表设置将缓冲区数量减少为三个。大多数时候,这足以减少或消除 IO 错误,而且不会对磁带备份性能造成负面影响。但是,如果值 3 不起帮助作用,可能需要进一步减少缓冲区数量。

注意 如果需要将设置减少到 3 以下,备份极有可能成功,而且不会出现错误,但是,磁带还原或磁带库库存作业可能挂起。如果出现这种情况,需要将 BufferQueueSize 条目重新增加至三个或更多以便执行还原,然后再次减少,即可进行正常备份。

复制下面的内容并保存在记事本中,然后在 DPM 服务器上另存为 BufferQ.REG。

Windows 注册表编辑器 5.00 版
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Agent]
"BufferQueueSize"=dword:00000003

右键单击 BufferQ.REG,然后选择“合并”或“用注册表编辑器打开”选项,将其添加到注册表。停止并重新启动 DPMRA 服务。

同样似乎有助于解决以上问题的另一种解决方案是向每个磁带设备添加以下 Storport 注册表项和 BusyRetryCount 注册表值。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\SCSI\<DEVICEID>\<INSTANCE>\DeviceParameters\Storport\
值 - BusyRetryCount
类型 - DWORD
数据 - 250 十进制或(0xFA 十六进制)

要获取 DPM 服务器中需要添加注册表项的所有磁带设备的列表,请从管理命令提示符运行以下命令。这将返回可用于作出以上更改的磁带驱动器 Scsi\DeviceID\Instance 的列表。

C:\Windows\system32>wmic 磁带驱动器简要列表

clip_image002

下面是根据以上 wmic 命令的输出要添加到 DPM 服务器的注册表项。

Windows 注册表编辑器 5.00 版

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SCSI\Sequential&Ven_IBM&Prod_ULTRIUM-TD3\5&31cf2afa&0&000001\Device Parameters\StorpPort]
"BusyRetryCount"=dword:000000fa

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SCSI\Sequential&Ven_IBM&Prod_ULTRIUM-TD3\5&31cf2afa&0&000002\Device Parameters\StorpPort]
"BusyRetryCount"=dword:000000fa

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SCSI\Sequential&Ven_IBM&Prod_ULTRIUM-TD3\5&31cf2afa&0&000003\Device Parameters\StorpPort]
"BusyRetryCount"=dword:000000fa

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SCSI\Sequential&Ven_IBM&Prod_ULTRIUM-TD3\5&31cf2afa&0&000004\Device Parameters\StorpPort]
"BusyRetryCount"=dword:000000fa

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SCSI\Sequential&Ven_IBM&Prod_ULTRIUM-TD3\5&31cf2afa&0&000005\Device Parameters\StorpPort]
"BusyRetryCount"=dword:000000fa

Data Protection Manager 2007/2010 具体配置设置

现在,让我们了解一些对磁带可用于备份作业的时长有重大影响的 Data Protection Manager 具体配置设置。

磁带归置 - 此功能允许将来自共享相同恢复目标的不同保护组的数据源写至同一磁带。此功能通过使用跨保护组的备份填充磁带,从而帮助充分利用磁带。只有共享完全相同磁带恢复目标和加密设置的保护组才可以在相同的磁带上归置在一起。

注意 DPM 2012 具有一个增强的选项,该选项允许您选择可以归置的保护组,而不考虑保持期目标。

下面的 LT-Goals.PS1 DPM powershell 脚本可以在 DPM 2007/2010 服务器上运行,以分析所有保护组,并列出可以根据保护组的共同目标和加密设置而归置在一起的保护组。

复制下面的内容,粘贴进记事本中,另存为 LT-Goals.PS1 - 然后在 DPM Power Shell 窗口中运行。

cls
$confirmpreference='none'
$dpmversion = ((get-process | where {$_.name -eq "msdpm" }).fileversion)
write-host "DPM Version - " $dpmversion "`nCollecting Long Term protection Information. Please wait..." -foreground yellow
$dpmserver = (&hostname)
out-file longterm.txt
$pg = @(get-protectiongroup $dpmserver | where { $_.ProtectionMethod -like "*Long-term using tape*"})
write-host "We have" $pg.count "groups with tape protection"
foreach ($longterm in $pg)
{
    "-----------------------------------------------------------`n" | out-file longterm.txt -append
    "" | out-file longterm.txt -append
    "Protection Group " + $longterm.friendlyname | out-file longterm.txt -append
    "" | out-file longterm.txt -append
    switch ($dpmversion.substring(0,1))
    {
        2 { $policySchedule = @(Get-PolicySchedule -ProtectionGroup $longterm -longterm)}
        3 { $policySchedule = @(Get-PolicySchedule -ProtectionGroup $longterm -longterm tape)}
        default { write-host "NOT TESTED ON THIS DPM VERSION. Exiting script" -foreground red;exit }
       
    }

    $tb = Get-TapeBackupOption $longterm;
    "Is encryption enabled? " + $tb.OffsiteEncryption | out-file longterm.txt -append
    "" | out-file longterm.txt -append
        $tb.RetentionPolicy | out-file longterm.txt -append
#    $tb = $tb.labelinfo
    $label = @($tb.label);
    $count = $policySchedule.count -1
    while ( $count -ne -1)
    {
        if ($label[$count].length -eq 0 -or $label[$count].length -eq $null)
        {
            "Default Label Name" | out-file longterm.txt -append
        }
        else
        {
            "Tape Label: " + $label[$count] | out-file longterm.txt -append
        }
        $policyschedule[$count] | fl *              | out-file longterm.txt -append
#              (Get-TapeBackupOption $longterm).RetentionPolicy | out-file longterm.txt -append

       
        $count--
    }
}
#exit
if ($pg.count -gt 1)
{
    $pgcount=0
    while ($pgcount -ne ($pg.count-1))
    {
        $collocation = @($pg[$pgcount].friendlyname)
        write-host $pgcount -background green
                (Get-TapeBackupOption $pg[$pgcount]).RetentionPolicy   | out-file policyretention.txt
        (Get-TapeBackupOption $pg[$pgcount]).OffsiteEncryption | out-file policyretention.txt -append
        write-host "policyretention.txt" -foreground green
        type policyretention.txt
        $pgcountinnerloop = 0
        while ($pgcountinnerloop -ne $pg.count)
        {
            write-host $pgcountinnerloop -background yellow
            if ($pgcount -eq $pgcountinnerloop) {$pgcountinnerloop++}
                    (Get-TapeBackupOption $pg[$pgcountinnerloop]).RetentionPolicy   | out-file policyretention1.txt
            (Get-TapeBackupOption $pg[$pgcountinnerloop]).OffsiteEncryption | out-file policyretention1.txt -append
            write-host "policyretention1.txt" -foreground green
            type policyretention1.txt

            $compare = Compare-Object -ReferenceObject $(get-content policyretention.txt) -DifferenceObject $(Get-content policyretention1.txt)
            if ($compare.length -eq $null)
            {
                if ($pgcountinnerloop -lt $pgcount)
                {
                    Break
                }
                else
                {
                    $collocation = $collocation + $pg[$pgcountinnerloop].friendlyname
                    $collocation
                    write-host "done"
                    $collocationcount++
                }
            }
            $pgcountinnerloop++
        }
        if ($collocation.count -gt 1)
        {
            "-----------------------------------------------------------" | out-file longterm.txt -append
            "Protection Groups that can share the same tape based on recovery goals/Encryption:" | out-file longterm.txt -append
            " " | out-file longterm.txt -append   
            write-host $collocation   
            foreach ($collocation1 in $collocation)
            {
                $collocation1 | out-file longterm.txt -append
            }
        }
        $pgcount++

    }
}

               
"-----------------------------------------------------------" | out-file longterm.txt -append
$dir = dir longterm.txt; write-host "`nDONE`n`nOutput file Created:" $dir.fullname -foreground yellow
del policyretention*.txt
notepad longterm.txt

启用磁带归置之后,DPM 具有两个可配置的选项 [TapeWritePeriodRatioTapeExpiryTolerance],这两个选项影响磁带标记为场外就绪的时间,以及在尚未标记为场外就绪时,是否可将磁带用于另一备份作业。请参阅下面的 Technet 文章。

启用磁带归置:

DPM 2007 - http://technet.microsoft.com/zh-cn/library/cc964296.aspx
DPM 2010 - http://technet.microsoft.com/zh-cn/library/ff399230.aspx

启用磁带归置之后,当满足以下任何一个条件时,磁带将显示为“场外就绪”:

- 磁带已满或标记为已满。(这包括上面描述的 I/O 0x8007045D 错误问题。)
- 其中一个数据集已过期。
- 写周期比率交叉。

(默认情况下,这是首次备份时间 + 保持期的 15%。)

当磁带被标记为场外就绪时,在所有恢复点过期之前,没有其他数据集被写入到该磁带。一旦磁带被标记为已过期,DPM 将在 DPM 控制台中显示磁带已到期,而且可以在后续备份期间覆盖磁带。如果需要新磁带,DPM 将在搜索可供使用的磁带时,始终优先使用可用磁带而非已过期磁带。

注意 如果启用了 DPM 库共享,则在默认情况下,只有最初向磁带写入的 DPM 服务器可以重新使用该磁带,除非手动释放已过期磁带。磁带被标记为可用之后,任何共享磁带库的 DPM 服务器都将可以使用该可用磁带。

TapeWritePeriodRatio - 这是只能在启用了归置时可以设置的 DPM 全局属性,它表示数据可以写入到磁带的天数,其表示形式为写入到磁带的首个数据集的保持期的百分比。此全局设置影响所有保护组。

TapeWritePeriodRatio 值可以介于 0.0 至 1.0 之间,默认值为 0.15(例如 15%)

注意 DPM 2012 不具有此全局属性,而是在 GUI 中具有其他配置选项,以便允许为不同的保护组配置不同的写周期。这为确定您希望在保护组级别使用磁带的时长增加了更大的灵活性。

默认值为 15% 的 TapeWritePeriodRatio 设置的影响示例 - 如果让保护组执行每日备份,而且保持期为 2 周(14 天),则无论写入到磁带的数据是多少,磁带将在仅仅 2.1 天之后被标记为场外就绪。如果希望 DPM 向磁带写入的周期为一周,则需要使用下面的 DPM Power Shell 命令将 TapeWritePeriodRatio 更改为 50%。

Set-DPMGlobalProperty –DPMServerName <dpm server name> -TapeWritePeriodRatio .5

TapeExpiryTolerance - 此注册表设置表示写入到磁带的下一数据集的到期日必须归属的时间范围。它表示为百分比的形式。如果注册表不存在,则默认值为 17%。

这是位于 HKLM\Software\Microsoft\Microsoft Data Protection Manager\1.0\Colocation 下的 DWORD 类型的注册表值。DPM 不自动创建 CoLocation 注册表项。您必须手动创建 Colocation 注册表项,然后采用新的 TapeExpiryTolerance 值设置该注册表项。

存在一种误解是,磁带归置功能仅将相同恢复目标的数据集归置到同一磁带上。例如:每周备份从不在已写入每月备份的磁带上归置。这并不正确,因为 DPM 将评估没有标记为场外就绪的每个磁带,并查看即将写入的数据集是否将满足以下检查。这样做有助于帮助实现完全利用磁带的目标,而且不妨碍磁带按时到期。如果将 TapeExpiryTolerance 调整太高(使其达到 100%),则面临将较短保持期数据集置于具有更长保持期目标之磁带上的风险,以及提前将磁带标记为场外就绪的风险,这将影响完��利用磁带的目标。一般而言,将此值设为 60 可以带来恰当的好处,而且不会导致任何问题。

假如,已在磁带上归置的所有数据集的到期日中的最远到期日 = FurthExpDate

时间范围 =

FurthExpDate - TapeExpiryTolerance *(FurthExpDate –今天日期)(下限)
FurthExpDate + TapeExpiryTolerance *(FurthExpDate –今天日期)(上限)

那么,只有当到期日在时间范围(含上限和下限)内时,当前的数据集将才被归置到指定的磁带上。

利用我们前面使用的相同示例,保护组执行每日备份,保持期为 2 周(14 天),而且由于您希望 DPM 使用磁带的周期为 1 周,因此将 TapeWritePeriodRatio 设为 0.5 (50%)。但是,在默认 TapeExpiryTolerance 为 17% 的情况下,如果一项备份出于任何原因而失败,而且错过了某一天的备份,则可能无法实现该目标。

在下面的示例中,我将 TapeWritePeriodRatio 设为 0.50,并于 5 月 7 日将首个备份集写入到磁带。请注意,根据 50% 的 TapeWritePeriodRatio 设置,直到期望的 7 天之后才设置场外就绪。最后一个备份集于 5 月 9 日被写入,但由于 5 月 10 日出现妨碍当天备份的服务器问题,下一备份集被写入的时间是 5 月 11 日。对于默认 17% 的 TapeExpiryTolerance 窗口,下一数据集到期日处于下限和上限之间。这将导致 DPM 为下一备份集选择新的磁带,但是,由于 TapeExpiryPeriodRatio 没有交叉,而且恢复点没有过期,磁带将不被标记为场外就绪。这个示例说明了磁带不可用于任何其他备份的原因,然而,由于不存在可见指示,令您对 DPM 为何使用的磁带比所需的磁带更多产生疑问。

clip_image004

现在,将 TapeExpiryTolerance 从 17% 更改为 60% 即可,请注意如何延长时间范围,以及允许下一数据集在 5 月 11 日写入到该磁带。

clip_image006

我在以下站点共享了这份 Excel 电子表格,以便帮助您计算场外就绪:http://cid-885774776d4f197a.office.live.com/self.aspx/Public/tape-offsite-ready-calculator.zip

最后,我希望本文解释了您可能遇到的问题,并且有助于配置 DPM 服务器,从而可以在未来备份期间完全利用您的磁带。

Mike Jacquet | 高级支持升级工程师

 

App-V 团队博客:http://blogs.technet.com/appv/
ConfigMgr 支持团队博客:http://blogs.technet.com/configurationmgr/
DPM 团队博客:http://blogs.technet.com/dpm/
MED-V 团队博客:http://blogs.technet.com/medv/
Orchestrator 支持团队博客:http://blogs.technet.com/b/orchestrator/
Operations Manager 团队博客:http://blogs.technet.com/momteam/
SCVMM 团队博客:http://blogs.technet.com/scvmm
Server App-V 团队博客:http://blogs.technet.com/b/serverappv
Service Manager 团队博客:http://blogs.technet.com/b/servicemanager
System Center Essentials 团队博客:http://blogs.technet.com/b/systemcenteressentials
WSUS 支持团队博客:http://blogs.technet.com/sus/

Forefront Server Protection 博客:http://blogs.technet.com/b/fss/
Forefront Endpoint Security 博客:http://blogs.technet.com/b/clientsecurity/
Forefront Identity Manager 博客:http://blogs.msdn.com/b/ms-identity-support/
Forefront TMG 博客:http://blogs.technet.com/b/isablog/
Forefront UAG 博客:http://blogs.technet.com/b/edgeaccessblog/

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment