Data Domain: O aplicativo de backup integrado ao Retention Lock pode apresentar falhas de backup devido a um problema de configuração

Alguns trabalhos de backup falham no client de backup com mensagens como as seguintes:
 

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.

O modo "somente leitura" para backups e imagens é como esse software de backup específico chama o recurso de back-end do DD, que permite que um administrador defina um período durante o qual o arquivo no back-end não pode ser modificado ou excluído, para proteção contra exclusão de dados acidentais ou mal-intencionados. Esse recurso é o que é chamado de Data Domain Retention Lock (RL, abreviação).

No lado do DD, os registros mostram o seguinte para a mesma unidade de armazenamento, subdiretório e arquivo de backup:

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)

A configuração do DD RL para cada MTree individual que tem o recurso ativado inclui a configuração da duração mínima (retention-lock min-retention-period) e máxima (retention-lock max-retention-period) dos bloqueios que podem ser definidos em qualquer um dos arquivos no MTree. Com o DD RL, o aplicativo de backup precisa definir individualmente o bloqueio nos arquivos, a menos que o recurso DD Automatic Retention Lock (ARL) esteja ativado. As opções para o MTree no exemplo eram as seguintes:
 

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

Isso significa que, para qualquer arquivo no MTree, o RL só pode ser definido 720 minutos a partir da hora atual (ou mais) e 35 dias a partir da hora atual (ou mais curta). Em outras palavras, com a configuração acima, um arquivo só pode ser protegido contra modificação ou remoção por um período de mais de 12 horas, mas inferior a 35 dias. Qualquer tentativa do aplicativo de backup de definir um bloqueio (que é feito atualizando o ambiente do arquivo, ao usar o BOOST; por meio da chamada "ddp_utime") por uma duração mais curta ou mais longa resultará no erro apresentado acima:

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.

Quando o aplicativo de backup souber usar o recurso DD RL, ele aguardará até que o backup conclua a gravação na imagem no back-end e, por fim, defina o bloqueio na imagem de backup (ou imagens, pois alguns softwares podem usar mais de um arquivo para armazenar um único trabalho de backup). As bibliotecas boost serão usadas para chamar o "ddp_utime" para definir o bloqueio por uma duração igual à retenção de backup pretendida no nível do aplicativo de backup. Isso tem duas implicações:

• Se o tempo não estiver sincronizado entre o aplicativo de backup e o DD, o aplicativo de backup poderá calcular "X dias a partir de agora" e obter uma data e hora que não são exatamente as mesmas para o DD, o que resultaria em uma imagem de backup bloqueada por um período mais curto ou mais longo, dependendo do sinal da diferença de tempo
• Se a retenção de backup pretendida não estiver alinhada com os limites de RL no DD MTree, o aplicativo de backup poderá tentar definir um bloqueio muito longe no futuro (por um período maior que "Retention lock max-retention-period") e, portanto, a configuração do bloqueio será negada. Se, por exemplo, a retenção do aplicativo de backup for de 60 dias com um "retention lock max-retention-period" definido como 30 dias no DD, a configuração do bloqueio apresentará falha

Em situações em que a retenção do software de backup é igual ao "retention lock max-retention-period" no DD, quaisquer pequenas diferenças de tempo podem fazer com que a configuração de bloqueio seja negada devido à diferença de tempo entre os dois hosts.

É importante que todos os hosts na infraestrutura de backup tenham o horário correto e, portanto, sincronizem por meio do NTP ou (se aplicável) do Windows AD.

Para evitar casos de canto, como o descrito, é uma boa prática que o "retention lock max-retention-period" no MTree habilitado para RL seja definido como um pouco mais longo do que a política de backup de retenção mais longa armazenada nesse MTree. Por exemplo, se a retenção de dados estiver definida como 35 dias no aplicativo de backup, definir o "retention-lock max-retention-period" no DD MTree usado para armazenar essas políticas para 36 ou até mesmo 40 dias é a coisa certa a fazer para evitar falhas acidentais para definir o RL.

Observe que ter um "retention lock max-retention-period" maior do que o período de retenção de imagens de backup não é um problema. Se tínhamos 100 dias de "retention lock max-retention-period" para uma política de backup de retenção de 35 dias, após 35 dias, as imagens serão excluídas pelo aplicativo e a limpeza descartará o espaço usado na próxima vez que for executada. Somente a desvantagem é no caso de configuração acidental de imagens com um bloqueio mais longo. Com a conformidade de RL, você não poderá excluir os arquivos por mais tempo do que o esperado. Portanto, a recomendação é definir "Retention Lock max-retention-period" um pouco mais longo, mas não muito.