Data Domain: La aplicación de respaldo integrada con Retention Lock puede experimentar fallas de respaldo debido a un problema de configuración

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 la protección contra la eliminación accidental o maliciosa de datos. Esta característica es lo que se denomina Data Domain Retention Lock (RL, por sus siglas en inglés).

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-<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)

La configuración de DD RL para cada MTree individual que tiene la función habilitada incluye el ajuste de la duración mínima (Retention-lock min-retention-period) y máxima (Retention-lock max-retention-period) de los bloqueos que se permite establecer en cualquiera de los archivos del MTree. Con DD RL, la aplicación de respaldo debe establecer individualmente el bloqueo de archivos, a menos que la función de bloqueo de retención automático (ARL) de DD esté habilitada. Las opciones para el MTree en el ejemplo fueron las siguientes:
 

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 en el MTree, el RL solo se puede establecer 720 minutos a partir de la hora actual (o más) y 35 días a partir de la hora actual (o menos). En otras palabras, con la configuración anterior, un archivo solo puede protegerse contra modificaciones o eliminaciones durante un período de más de 12 horas, pero menos de 35 días. Cualquier intento por parte de la aplicación de copia de seguridad de establecer un bloqueo (que se realiza actualizando el atime del archivo, cuando se usa BOOST; a través de la llamada "ddp_utime") por 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 utilizar la función DD RL, esperará a que el respaldo termine de escribirse en la imagen en el back-end y, finalmente, establecerá el bloqueo en la imagen de respaldo (o imágenes, ya que algunos software pueden usar más de un archivo para almacenar un solo trabajo de respaldo). Las bibliotecas de BOOST se utilizarán para llamar al "ddp_utime" a fin de establecer el bloqueo durante un período igual a la retención de respaldo prevista en el nivel de la aplicación de respaldo. Esto tiene dos implicaciones:

• Si la hora no está sincronizada 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 son exactamente las mismas que para DD, lo que daría como resultado 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 horaria
• 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 denegará el ajuste 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" establecido en 30 días en DD, el ajuste del bloqueo obviamente fallará

En situaciones en las que la retención del software de respaldo es igual al "período de retención máximo de bloqueo de retención" en DD, cualquier diferencia de tiempo menor puede hacer que se rechace la configuración de bloqueo debido a la diferencia horaria entre los dos hosts.

Es importante que todos los hosts de la infraestructura de respaldo tengan la hora correcta y, por lo tanto, que se sincronicen a través de NTP o (si corresponde) Windows AD.

Para evitar casos extremos como el descrito, se recomienda que el "Retention-lock max-retention-period" en el MTree habilitado para RL se configure en un valor ligeramente mayor 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 establece en 35 días en la aplicación de respaldo, establecer el "Retention-lock max-retention-period" en el MTree de DD que se usa para almacenar esas políticas en 36 o incluso 40 días es lo correcto para evitar fallas accidentales en la configuración de RL.

Tenga en cuenta que tener un "Retention-lock max-retention-period" mayor que el período de retención de las imágenes de respaldo no es un problema. Si tuviéramos "Retention-lock max-retention-period" de 100 días 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 eliminará de manera limpia el espacio utilizado la próxima vez que se ejecute. El único inconveniente es en el caso de configurar accidentalmente imágenes con un bloqueo más largo, con RL Compliance, no podrá eliminar los archivos por más tiempo del esperado. Por lo tanto, la recomendación es configurar "Retention-lock max-retention-period" un poco más, pero no demasiado.