Data Domain : L’application de sauvegarde intégrée à Retention Lock peut rencontrer des échecs de sauvegarde en raison d’un problème de configuration

Certaines procédures de sauvegarde échouent sur le client de sauvegarde avec des messages tels que:
 

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.

Le mode « lecture seule » pour les sauvegardes et les images correspond à la façon dont ce logiciel de sauvegarde particulier appelle la fonction DD back-end qui permet à un administrateur de définir une période pendant laquelle le fichier du back-end ne peut pas être modifié ou supprimé, pour une protection contre la suppression accidentelle ou malveillante des données. Cette fonctionnalité est ce qu’on appelle le verrouillage de rétention Data Domain (RL pour résumer).

Du côté DD, les logs affichent les éléments suivants pour la même unité de stockage, le même sous-répertoire et le même fichier de sauvegarde:

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 configuration DD RL pour chaque structure MTree dont la fonction est activée inclut la définition de la durée minimale (Retention-lock min-retention-period) et maximale (Retention-lock max-retention-period) de verrous qui sont autorisés à être définis sur l’un des fichiers de la structure MTree. Avec DD RL, l’application de sauvegarde doit définir individuellement le verrou sur les fichiers, sauf si la fonction DD Automatic Retention Lock (ARL) est activée. Les options de la structure MTree dans l’exemple étaient les suivantes:
 

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

Cela signifie que pour n’importe quel fichier de la structure MTree, la liste RL ne peut être définie que 720 minutes à partir de l’heure actuelle (ou plus) et 35 jours à partir de l’heure actuelle (ou plus courte). En d’autres termes, avec la configuration ci-dessus, un fichier ne peut être protégé contre toute modification ou suppression que pendant une période de plus de 12 heures, mais de moins de 35 jours. Toute tentative par l’application de sauvegarde de définir un verrou (qui est effectué en mettant à jour l’atime du fichier, lors de l’utilisation de BOOST; via l’appel « ddp_utime ») pour une durée plus courte ou plus longue entraîne l’erreur présentée ci-dessus:

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.

Lorsque l’application de sauvegarde sait comment utiliser la fonction DD RL, elle attend que la sauvegarde finisse d’écrire sur l’image dans le back-end, puis finit par définir le verrou sur l’image de sauvegarde (ou les images, car certains logiciels peuvent utiliser plusieurs fichiers pour stocker une seule procédure de sauvegarde). Les bibliothèques BOOST sont utilisées pour appeler le « ddp_utime » afin de définir le verrou pour une durée égale à la rétention de sauvegarde prévue au niveau de l’application de sauvegarde. Cela a deux implications:

• Si l’heure n’est pas synchronisée entre l’application de sauvegarde et DD, l’application de sauvegarde peut calculer « X jours à partir de maintenant » et obtenir une date et une heure qui ne sont pas exactement les mêmes que pour le DD, ce qui entraînerait un verrouillage de l’image de sauvegarde pour une période plus courte ou plus longue en fonction du signe de la différence d’heure.
• Si la rétention de sauvegarde prévue n’est pas alignée sur les limites de la liste de révocation des certificats sur la structure MTree DD, l’application de sauvegarde peut tenter de définir un verrou trop loin à l’avenir (pendant une période plus longue que « Retention-lock max-retention-period ») et, par conséquent, la définition du verrou sera refusée. Si, par exemple, la rétention de l’application de sauvegarde est de 60 jours avec un paramètre « Retention-lock max-retention-period » défini sur 30 jours dans DD, la définition du verrou échoue évidemment.

Dans les situations où la rétention du logiciel de sauvegarde est égale à « Retention-lock max-retention-period » sur le DD, toute différence de temps mineure peut entraîner le refus du paramètre de verrouillage en raison de la différence d’heure entre les deux hôtes.

Il est important que tous les hôtes de l’infrastructure de sauvegarde aient l’heure correcte, et qu’ils se synchronisent par le biais du protocole NTP ou (le cas échéant) Windows AD.

Pour éviter les cas d’angle tels que celui décrit, il est recommandé que la « période de rétention max-lock max-retention » dans la structure MTree avec RL soit définie sur légèrement plus longue que la règle de sauvegarde de rétention la plus longue stockée dans cette structure MTree. Par exemple, si la rétention des données est définie sur 35 jours dans l’application de sauvegarde, la définition de la « période de rétention max-retention lock » sur la structure MTree DD utilisée pour stocker ces règles sur 36 ou même 40 jours est la bonne chose à faire pour éviter les défaillances accidentelles pour définir la RL.

Notez que le fait de disposer d’une période de rétention max-lock max-retention supérieure à la période de rétention des images de sauvegarde n’est pas un problème. Si nous disposions de 100 jours « Retention-lock max-retention-period » pour une règle de sauvegarde de rétention de 35 jours, au bout de 35 jours, les images seront supprimées par l’application, et le nettoyage éliminera l’espace utilisé la prochaine fois qu’elle s’exécutera. Le seul inconvénient est qu’en cas de définition accidentelle d’images avec un verrouillage plus long, avec RL Compliance, vous ne serez pas en mesure de supprimer les fichiers plus longtemps que prévu. Il est donc recommandé de définir « Retention-lock max-retention-period » un peu plus longtemps, mais pas trop.