Data Domain: La aplicación de respaldo integrada con Retention Lock puede experimentar fallas de respaldo debido a un problema de configuración
摘要: Cuando se configura e integra una aplicación de respaldo con DD Retention Lock (RL), ciertas aplicaciones de respaldo y configuraciones de DD RL pueden provocar, en algunas situaciones, fallas de respaldo, una de las cuales se describe y resuelve aquí. Los registros en este artículo de la base de conocimientos son para CommVault utilizado como la aplicación de respaldo, pero los hechos presentados son igualmente aplicables a cualquier otro software de respaldo que sea compatible con DD RL ...
本文适用于
本文不适用于
本文并非针对某种特定的产品。
本文并非包含所有产品版本。
症状
Algunos trabajos de respaldo fallan en el cliente de respaldo con mensajes como los siguientes:
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.
El modo de "solo lectura" para respaldos e imágenes es la forma en que este software de respaldo en particular llama a la función de back-end de DD, que permite a un administrador establecer un período durante el cual el archivo en el back-end no se puede modificar ni eliminar para protegerse contra la eliminación de datos accidentales o maliciosos. Esta función es lo que se denomina Data Domain Retention Lock (RL para abreviar).
En el lado de DD, los registros muestran lo siguiente para la misma unidad de almacenamiento, subdirectorio y archivo de respaldo:
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)
原因
La configuración de DD RL para cada MTree individual que tiene habilitada la función incluye la configuración de la duración mínima (retention-lock min-retention-period) y la duración máxima (Retention-lock max-retention-period) de los bloqueos que se pueden establecer en cualquiera de los archivos del MTree. Con DD RL, la aplicación de respaldo debe configurar individualmente el bloqueo de archivos, a menos que la función DD Automatic Retention Lock (ARL) esté habilitada. Las opciones para el MTree en el ejemplo eran las siguientes:
Esto significa que, para cualquier archivo del MTree, el RL solo se puede configurar 720 minutos a partir del tiempo actual (o más) y 35 días a partir del tiempo actual (o más corto). En otras palabras, con la configuración anterior a un archivo solo se puede proteger de la modificación o eliminación durante un período de más de 12 horas, pero menos de 35 días. Cualquier intento de la aplicación de respaldo de establecer un bloqueo (que se realiza mediante la actualización del archivo atime, cuando se usa BOOST; a través de la llamada "ddp_utime") durante una duración más corta o más larga dará como resultado el error presentado anteriormente:
Cuando la aplicación de respaldo sepa cómo usar la función DD RL, esperará a que el respaldo termine de escribir en la imagen en el back-end y, finalmente, establecerá el bloqueo en la imagen de respaldo (o imágenes, ya que algún software puede usar más de un archivo para almacenar un solo trabajo de respaldo). Las bibliotecas de BOOST se utilizarán para llamar a la "ddp_utime" para establecer el bloqueo durante una duración igual a la retención de respaldo prevista en el nivel de la aplicación de respaldo. Esto tiene dos implicaciones:
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 ----------------------------------------- -----------
Esto significa que, para cualquier archivo del MTree, el RL solo se puede configurar 720 minutos a partir del tiempo actual (o más) y 35 días a partir del tiempo actual (o más corto). En otras palabras, con la configuración anterior a un archivo solo se puede proteger de la modificación o eliminación durante un período de más de 12 horas, pero menos de 35 días. Cualquier intento de la aplicación de respaldo de establecer un bloqueo (que se realiza mediante la actualización del archivo atime, cuando se usa BOOST; a través de la llamada "ddp_utime") durante una duración más corta o más larga dará como resultado el error presentado anteriormente:
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.
Cuando la aplicación de respaldo sepa cómo usar la función DD RL, esperará a que el respaldo termine de escribir en la imagen en el back-end y, finalmente, establecerá el bloqueo en la imagen de respaldo (o imágenes, ya que algún software puede usar más de un archivo para almacenar un solo trabajo de respaldo). Las bibliotecas de BOOST se utilizarán para llamar a la "ddp_utime" para establecer el bloqueo durante una duración igual a la retención de respaldo prevista en el nivel de la aplicación de respaldo. Esto tiene dos implicaciones:
- Si el tiempo no está sincronizado entre la aplicación de respaldo y DD, la aplicación de respaldo puede calcular "X días a partir de ahora" y obtener una fecha y hora que no es exactamente la misma que la de DD, lo que provocaría que la imagen de respaldo se bloquee durante un período más corto o más largo, según el signo de la diferencia de tiempo
- Si la retención de respaldo prevista no está alineada con los límites de RL en el MTree de DD, la aplicación de respaldo puede intentar establecer un bloqueo demasiado lejos en el futuro (durante un período más largo que "Retention-lock max-retention-period") y, por lo tanto, se rechazará la configuración del bloqueo. Si, por ejemplo, la retención de la aplicación de respaldo es de 60 días con un "Retention-lock max-retention-period" configurado en 30 días en DD, configurar el bloqueo obviamente fallará
解决方案
Es importante que todos los hosts de la infraestructura de respaldo tengan la hora correcta y, por lo tanto, se sincronicen a través de NTP o (si corresponde) de Windows AD.
Para evitar casos en esquinas como el descrito, se recomienda que el "Retention-lock max-retention-period" en el MTree habilitado para RL esté configurado en un poco más largo que la política de respaldo de retención más prolongada almacenada en ese MTree. Por ejemplo, si la retención de datos se configura en 35 días en la aplicación de respaldo, configurar "Retention-lock max-retention-period" en el MTree de DD utilizado para almacenar esas políticas en 36 o incluso 40 días es lo correcto para evitar fallas accidentales al configurar RL.
Tenga en cuenta que tener un "retention-lock max-retention-period" mayor que el período de retención de imágenes de respaldo no es un problema. Si tuviéramos 100 días "Retention-lock max-retention-period" para una política de respaldo de retención de 35 días, después de 35 días, la aplicación eliminará las imágenes y limpiará el espacio utilizado la próxima vez que se ejecute. El único inconveniente es que, en el caso de que las imágenes se configuren accidentalmente con un bloqueo más largo, con el cumplimiento de normas de RL, no podrá eliminar los archivos durante más tiempo del esperado. Por lo tanto, la recomendación es establecer "Retention-lock max-retention-period" un poco más largo, pero no demasiado.
Para evitar casos en esquinas como el descrito, se recomienda que el "Retention-lock max-retention-period" en el MTree habilitado para RL esté configurado en un poco más largo que la política de respaldo de retención más prolongada almacenada en ese MTree. Por ejemplo, si la retención de datos se configura en 35 días en la aplicación de respaldo, configurar "Retention-lock max-retention-period" en el MTree de DD utilizado para almacenar esas políticas en 36 o incluso 40 días es lo correcto para evitar fallas accidentales al configurar RL.
Tenga en cuenta que tener un "retention-lock max-retention-period" mayor que el período de retención de imágenes de respaldo no es un problema. Si tuviéramos 100 días "Retention-lock max-retention-period" para una política de respaldo de retención de 35 días, después de 35 días, la aplicación eliminará las imágenes y limpiará el espacio utilizado la próxima vez que se ejecute. El único inconveniente es que, en el caso de que las imágenes se configuren accidentalmente con un bloqueo más largo, con el cumplimiento de normas de RL, no podrá eliminar los archivos durante más tiempo del esperado. Por lo tanto, la recomendación es establecer "Retention-lock max-retention-period" un poco más largo, pero no demasiado.
受影响的产品
Data Domain文章属性
文章编号: 000207411
文章类型: Solution
上次修改时间: 18 4月 2023
版本: 4
从其他戴尔用户那里查找问题的答案
支持服务
检查您的设备是否在支持服务涵盖的范围内。