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-<backupsoftware.example.com-56892>: 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)

Конфигурация DD RL для каждого отдельного MTree, в котором включена эта функция, включает в себя настройку минимальной (Retention-lock min-retention-period) и максимальной (Retention-lock max-retention-period) продолжительности блокировки, которую разрешено устанавливать для любого из файлов в MTree. При использовании DD RL приложение резервного копирования должно индивидуально устанавливать блокировку файлов, если не включена функция автоматической блокировки хранения DD (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 дней от настоящего момента» и получить дату и время, которые не совпадают с датой DD, что приведет к блокировке образа резервной копии на более короткий или длительный период времени в зависимости от знака разницы во времени
• Если предполагаемое хранение резервных копий не соответствует ограничениям RL на DD MTree, приложение резервного копирования может попытаться установить блокировку слишком далеко в будущем (на период дольше, чем «Retention-lock max-retention-period»), и, следовательно, установка блокировки будет отклонена. Если, например, срок хранения приложения резервного копирования составляет 60 дней с параметром «Retention-lock max-retention-period», равным 30 дням в DD, установка блокировки, очевидно, завершится ошибкой

В ситуациях, когда срок хранения программного обеспечения для резервного копирования равен значению «Retention-lock max-retention-period» на DD, любая незначительная разница во времени может привести к отказу в настройке блокировки из-за разницы во времени между двумя хостами.

Важно, чтобы на всех хостах в инфраструктуре резервного копирования было установлено правильное время, и чтобы синхронизация осуществлялась через NTP или (если применимо) Windows AD.

Чтобы избежать крайних случаев, подобных описанному, рекомендуется установить для параметра «Retention-lock max-retention-period» в MTree с поддержкой RL значение немного больше, чем для политики резервного копирования с самым длительным сроком, хранящейся в этом MTree. Например, если в приложении резервного копирования для хранения данных установлено значение 35 дней, то для параметра «Retention-lock max-retention-period» в DD MTree, используемом для хранения этих политик, будет правильным значением 36 или даже 40 дней, чтобы избежать случайных сбоев при настройке RL.

Обратите внимание, что если значение параметра «Retention-lock max-retention-period» превышает срок хранения резервных копий, это не является проблемой. Если для политики резервного копирования в течение 35 дней используется 100-дневный интервал хранения «Retention-lock max-retention-period», то через 35 дней образы будут удалены приложением, а при следующем запуске clean очистит используемое пространство. Единственный недостаток в том, что в случае случайной установки образов с более длинной блокировкой, с RL Compliance вы не сможете удалить файлы дольше, чем ожидалось. Поэтому рекомендуется установить параметр «Retention-lock max-retention-period» немного дольше, но не слишком сильно.