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 les suivants :
 

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 est la façon dont ce logiciel de sauvegarde particulier appelle la fonction DD Backend 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 se protéger contre la suppression accidentelle ou malveillante des données. Cette fonctionnalité est appelée Data Domain Retention Lock (RL).

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-<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 configuration DD RL pour chaque structure MTree individuelle pour laquelle la fonctionnalité est activée inclut la définition de la durée minimale (Retention-lock min-retention-period) et maximale (Retention-lock max-retention-period) des verrous pouvant être définis sur l’un des fichiers de la structure MTree. Avec DD RL, l’application de sauvegarde doit définir individuellement le verrouillage sur les fichiers, sauf si la fonction DD Automatic Retention Lock (ARL) est activée. Les options pour 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, le RL ne peut être défini que 720 minutes à partir de l’heure actuelle (ou plus) et 35 jours à partir de l’heure actuelle (ou moins). En d’autres termes, avec la configuration ci-dessus, un fichier ne peut être protégé contre la modification ou la suppression que pendant une période de plus de 12 heures, mais inférieure à 35 jours. Toute tentative de l’application de sauvegarde de définir un verrou (ce qui se fait en mettant à jour l’atime du fichier, lors de l’utilisation de BOOST ; via l’appel « ddp_utime ») pour une durée plus ou moins longue entraînera 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 termine l’écriture sur l’image du back-end, puis finit par verrouiller 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 « 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 celles du DD, ce qui entraîne le verrouillage de l’image de sauvegarde pour une période plus ou moins longue selon le signe de la différence d’heure
• Si la rétention de sauvegarde prévue n’est pas alignée sur les limites RL sur la structure MTree DD, l’application de sauvegarde peut tenter de définir un verrou trop loin dans le futur (pour une période supérieure à « Retention-lock max-retention-period »). Par conséquent, le paramètre du verrouillage est refusé. Si, par exemple, la rétention de l’application de sauvegarde est de 60 jours avec une période de rétention maximale définie sur 30 jours dans DD, la définition du verrouillage échouera évidemment

Dans les situations où la rétention du logiciel de sauvegarde est égale à la « Retention-lock max-retention-period » sur DD, toute différence temporelle 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 disposent de l’heure correcte et, par conséquent, qu’ils se synchronisent via NTP ou (le cas échéant) Windows AD.

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

Notez que le fait d’avoir une « Retention-lock max-retention-period » 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 politique de sauvegarde de rétention de 35 jours, après 35 jours, les images seront supprimées par l’application, et Clean éliminera leur espace utilisé lors de sa prochaine exécution. Le seul inconvénient est qu’en cas de définition accidentelle des images avec un verrou plus long, avec la conformité RL, vous ne pourrez pas 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.