Data Domain：与 Retention Lock 集成的备份应用程序可能会因配置问题而遇到备份失败

某些备份作业在备份客户端上失败，并显示如下消息：
 

8212 6df7 12/05 15:47:15 871396 [MEDIAFS    ] 3637866-3138214 Cannot set the access time of [/data/col1/Commvault/SUBDIR/CV_MAGNETIC/V_305788/CHUNK_18517307], error=0xECCC000D:{CQiFile::SetTimes(825)/ErrNo.13.(Permission denied)}
8212 6df7 12/05 15:47:15 871396 [MEDIAFS    ] 3637866-3138214 Cannot mark the file [/data/col1/Commvault/SUBDIR/CV_MAGNETIC/V_305788/CHUNK_18517307] as read only.

备份和映像的“只读”模式是此特定备份软件调用 DD 后端功能的方式，该功能允许管理员设置一段时间，在此期间，无法修改或删除后端中的文件，以防范意外或恶意数据删除。此功能称为 Data Domain Retention Lock（简称 RL）。

在 DD 端，日志显示同一存储单元、子目录和备份文件的以下内容：

12/05 07:47:47.820284 [7f1bc842a000] Attempt to set atime of 16adcf:0:16addb:0:7d70db86:6256fe81:0 to larger than maximum retention period of mtree.
12/05 07:47:47.820289 [7f1bc842a000] ERROR: FM fm_dm1_setattr:1408 - fm_dm1_setattr_intern failed
12/05 07:47:47.820533 [7f1bcdf19d90] ddboost-: ddboost_api ERROR: ddp_utime() failed, su_name=Commvault, path_name=/SUBDIR/CV_MAGNETIC/V_305788/CHUNK_18517307, Err: 5034-nfs setattr failed (nfs: Permission denied)

每个启用了功能的单个 MTree 的 DD RL 配置包括设置允许在 MTree 中的任何文件上设置锁定的最小（保留锁定最小保留期）和最长（保留锁定最大保留期）持续时间。使用 DD RL 时，备份应用程序必须对文件单独设置锁定，除非启用了 DD Automatic Retention Lock （ARL） 功能。示例中 MTree 的选项如下所示：
 

Mtree: /data/col1/Commvault

Option                                      Value
-----------------------------------------   -----------
Retention-lock                              enabled
Retention-lock mode                         governance
Retention-lock uuid                         UUID1:UUID2
Retention-lock min-retention-period         720minutes
Retention-lock max-retention-period         35days
Retention-lock automatic-retention-period   not set
Retention-lock automatic-lock-delay         120minutes
Retention-lock indefinite-retention-hold    disabled
-----------------------------------------   -----------

这意味着，对于 MTree 中的任何文件，RL 只能从当前时间（或更长时间）设置为 720 分钟，从当前时间（或更短时间）设置为 35 天。换言之，对于上述配置，文件只能在超过 12 小时但不到 35 天的时间内受到修改或删除保护。备份应用程序尝试设置锁定（通过更新文件的 atime 来完成，在使用 BOOST 时;通过“ddp_utime”调用）进行更短或更长的持续时间，将导致上述错误：

12/05 07:47:47.820284 [7f1bc842a000] Attempt to set atime of 16adcf:0:16addb:0:7d70db86:6256fe81:0 to larger than maximum retention period of mtree.

当备份应用程序知道如何使用 DD RL 功能时，它将等待备份完成写入后端的映像，然后最终在备份映像（或映像）上设置锁定，因为某些软件可能会使用多个文件来存储单个备份作业。BOOST 库将用于调用“ddp_utime”，以将锁定设置为等于备份应用程序级别的预期备份保留期。这有两个影响：

• 如果备份应用程序与 DD 之间的时间不同步，则备份应用程序可以计算“X days from now”，并获取与 DD 不完全相同的日期和时间，这将导致备份映像锁定更短或更长的时间段，具体取决于时间差异的符号
• 如果预期备份保留与 DD MTree 上的 RL 限制不一致，则备份应用程序可能会尝试在未来设置锁定太远（持续时间超过“Retention-lock max-retention-period”），因此锁定设置将被拒绝。例如，如果备份应用程序保留期为 60 天，并且在 DD 中将“Retention-lock max-retention-period”设置为 30 天，则设置锁定显然会失败

在备份软件保留等于 DD 上的“Retention-lock max-retention-period”的情况下，任何次要时间差异都可能导致锁定设置被拒绝，因为两个主机之间的时差。

备份基础架构中的所有主机都具有正确的时间非常重要，因此它们通过 NTP 或（如果适用）Windows AD 同步。

为避免出现诸如所述这样的角情形，最好将启用 RL 的 MTree 中的“Retention-lock max-retention-period”设置为比该 MTree 中存储的最长保留时间最长的备份策略稍长。例如，如果在备份应用程序中将数据保留设置为 35 天，则在用于将这些策略存储到 36 天甚至 40 天的 DD MTree 上设置“Retention-lock max-retention-period”是正确的做法，以避免意外失败来设置 RL。

请注意，具有高于备份映像保留期的“Retention-lock max-retention-period”不是问题。如果我们有 100 天的“Retention-lock max-retention-period”（保留期最大保留期）为 35 天保留备份策略，则在 35 天后，应用程序将删除映像，清理将在下次运行时处置其已用空间。唯一的缺点是在意外设置锁定较长的映像的情况下，使用 RL Compliance，您将无法删除文件的时间超过预期。因此，建议将“Retention-lock max-retention-period”设置更长时间，但不要太长。