Data Domain. В приложении резервного копирования, интегрированном с Retention Lock, могут возникать сбои резервного копирования из-за проблемы конфигурации
摘要: Когда приложение резервного копирования настроено и интегрировано с DD Retention Lock (RL), некоторые конфигурации приложения резервного копирования и DD RL могут в некоторых случаях приводить к сбоям резервного копирования, одно из которых описано и устранено здесь. Журналы в этой статье базы знаний предназначены для Commvault, используемой в качестве приложения резервного копирования, но представленные факты в равной мере применимы к любому другому программному обеспечению для резервного копирования, которое поддерживает DD RL. ...
本文适用于
本文不适用于
本文并非针对某种特定的产品。
本文并非包含所有产品版本。
症状
Некоторые задачи резервного копирования на клиенте резервного копирования завершается сбоем со следующими сообщениями:
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)
原因
Конфигурация DD RL для каждого отдельного MTree с включенной функцией включает в себя установку минимального (retention-lock min-retention-period) и максимального срока (retention-lock max-retention-period) блокировки, которые могут быть установлены для любого из файлов в MTree. При использовании DD RL приложение резервного копирования необходимо по отдельности установить блокировку файлов, если не включена функция DD Automatic Retention Lock (ARL). В данном примере параметры MTree были следующими:
Это означает, что для любого файла в MTree для RL может быть установлено только 720 минут от текущего времени (или более) и 35 дней от текущего времени (или более короткого). Другими словами, при использовании указанной выше конфигурации файл может быть защищен только от изменения или удаления на период более 12 часов, но менее 35 дней. Любая попытка приложения резервного копирования установить блокировку (которая выполняется путем обновления atime файла, при использовании BOOST, с помощью вызова «ddp_utime») в течение более короткого или более длительного времени приведет к приведенной выше ошибке:
Когда приложение резервного копирования знает, как использовать функцию DD RL, оно ожидает завершения резервного копирования записи на образ в серверной части программы, а затем в конечном итоге блокирует образ резервного копирования (или образы, так как некоторые программы могут использовать несколько файлов для хранения одного задания резервного копирования). Библиотеки BOOST будут использоваться для вызова ddp_utime, чтобы установить блокировку на срок, равный предполагаемым срокам хранения резервных копий на уровне приложения резервного копирования. Это имеет два последствия:
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, что приведет к блокировке резервного образа на более короткий или более длительный период времени в зависимости от признака разницы во времени.
- Если предполагаемый срок хранения резервных копий не совпадает с ограничениями RL в DD MTree, приложение резервного копирования может попытаться установить блокировку слишком далеко в будущем (на период, более длительный, чем «Retention-lock max-retention-period»), поэтому установка блокировки будет отклонена. Если, например, срок хранения приложения резервного копирования составляет 60 дней с установленным в DD периодом «Retention-lock max-retention-period», то установка блокировки, очевидно, не будет выполнена.
解决方案
Важно, чтобы у всех хостов в инфраструктуре резервного копирования было правильное время, и поэтому они синхронизируются с NTP или (если применимо) Windows AD.
Чтобы избежать угловых случаев (например, описанных выше), рекомендуется установить для параметра «Retention-lock max-retention-period» в MTree с поддержкой RL несколько больше времени, чем на политику резервного копирования с самым длительным сроком хранения, которая хранится в этом MTree. Например, если в приложении резервного копирования для хранения данных установлено значение 35 дней, то во избежание случайных сбоев, задав для DD MTree значение «Retention-lock max-retention-period», используемое для хранения этих политик на уровне 36 или даже 40 дней, — это правильное решение, чтобы избежать случайных сбоев при установке RL.
Обратите внимание, что проблема не связана с тем, что срок хранения «Retention-lock max-retention period» превышает срок хранения образов резервных копий. Если у нас был 100-дн. Срок максимального срока хранения retention-lock для политики резервного копирования на 35 дней, через 35 дней образы будут удалены приложением и очищены при следующем запуске. Единственный недостаток заключается в случайном настройке образов с более продолжительной блокировкой, при этом соответствие требованиям RL не позволяет удалить файлы дольше ожидаемого. Поэтому рекомендуется установить «Retention-lock max-retention-period» немного дольше, но не слишком много.
Чтобы избежать угловых случаев (например, описанных выше), рекомендуется установить для параметра «Retention-lock max-retention-period» в MTree с поддержкой RL несколько больше времени, чем на политику резервного копирования с самым длительным сроком хранения, которая хранится в этом MTree. Например, если в приложении резервного копирования для хранения данных установлено значение 35 дней, то во избежание случайных сбоев, задав для DD MTree значение «Retention-lock max-retention-period», используемое для хранения этих политик на уровне 36 или даже 40 дней, — это правильное решение, чтобы избежать случайных сбоев при установке RL.
Обратите внимание, что проблема не связана с тем, что срок хранения «Retention-lock max-retention period» превышает срок хранения образов резервных копий. Если у нас был 100-дн. Срок максимального срока хранения retention-lock для политики резервного копирования на 35 дней, через 35 дней образы будут удалены приложением и очищены при следующем запуске. Единственный недостаток заключается в случайном настройке образов с более продолжительной блокировкой, при этом соответствие требованиям RL не позволяет удалить файлы дольше ожидаемого. Поэтому рекомендуется установить «Retention-lock max-retention-period» немного дольше, но не слишком много.
受影响的产品
Data Domain文章属性
文章编号: 000207411
文章类型: Solution
上次修改时间: 18 4月 2023
版本: 4
从其他戴尔用户那里查找问题的答案
支持服务
检查您的设备是否在支持服务涵盖的范围内。