Cet article offre une vue d'ensemble concise des fonctionnalités de verrouillage de rétention (RL) de Data Domain et des réponses aux questions fréquemment posées (FAQ).
Cet article offre une vue d'ensemble concise des fonctionnalités de verrouillage de rétention (RL) de Data Domain et des réponses aux questions fréquemment posées (FAQ).
Qu’est-ce qu’un verrouillage de rétention ?
Le verrouillage de rétention est une fonctionnalité utilisée sur les restaurations Data Domain (DDR) afin d’empêcher toute modification ou suppression de certains ensembles de fichiers pendant une période prédéterminée. Autrement dit, les fichiers faisant l'objet d'un verrouillage de rétention sont en lecture seule jusqu'à expiration de leur période de rétention.
Quelles sont les différentes versions du verrouillage de rétention ?
Le verrouillage de rétention est disponible pour deux fonctions différentes :
- Gouvernance : La moins stricte des deux fonctions de verrouillage de rétention (impliquant que les verrous des fichiers peuvent être désactivés si nécessaire).
- Compliance : La plus stricte des deux fonctions, qui respecte plusieurs normes réglementaires communes. Celle-ci implique que les verrous des fichiers ne peuvent pas être désactivés. La DDR doit être configurée avec un utilisateur disposant des droits de « responsable de la sécurité », qui devra authentifier certaines commandes. Il existe diverses restrictions sur d'autres fonctionnalités permettant d'empêcher la suppression des données verrouillées ou la désactivation anticipée des verrous.
Remarque :
- le mode de conformité n'est disponible que dans DDOS 5.3 (et versions ultérieures).
- Chaque fonction de verrouillage de rétention nécessite une clé de licence distincte.
- La fonctionnalité de verrouillage de rétention est activée par structure MTree.
- Un seul système peut utiliser les deux modes gouvernance et conformité à la fois sur des structures MTree distinctes. Toutefois, des licences de conformité et de gouvernance distinctes doivent être installées.
- N’activez aucun type de verrouillage de rétention DD sur les structures MTree servant à stocker des données Avamar, sauf si cela est indiqué dans la documentation Avamar, dans le cadre de l’exécution de cette fonctionnalité sur Avamar. L’activation du verrouillage de rétention DD sur une telle structure MTree sans suivre le processus Avamar approprié peut rendre la structure MTree inutilisable pour les sauvegardes et nécessiter une restauration longue. Cela est particulièrement vrai si vous activez le verrouillage de rétention automatique (ARL) pour une structure MTree Avamar.
- La fonctionnalité de verrouillage de rétention peut ne pas être prise en charge sur les structures MTree servant à stocker des données à l’aide de versions plus anciennes d’Avamar ou de Protection Software sur une appliance Integration Data Protection Appliance (IDPA) ou PowerProtect série Data Protection. Cela peut empêcher Avamar ou Protection Software dans l’appliance Integrated Data Protection Appliance de fonctionner comme prévu et de passer en lecture seule.
Quels protocoles d'accès aux données sont pris en charge avec le verrouillage de rétention ?
- Les protocoles NFS, CIFS et DD Boost sont entièrement pris en charge par les structures MTree aussi bien à l’aide du mode conformité que du mode gouvernance du verrouillage de rétention.
- Le protocole VTL (Virtual Tape Library) est uniquement pris en charge sur les structures MTree à l'aide du mode gouvernance du verrouillage de rétention. Le verrouillage de rétention automatique n'est pas pris en charge sur Data Domain VTL. Consultez le Guide d’administration de Data Domain pour déterminer comment déverrouiller des bandes faisant l’objet d’un verrouillage de rétention de sorte à pouvoir écrire sur celles-ci.
Le mode de conformité du verrouillage de rétention respecte les normes réglementaires :
Voici une liste des normes réglementaires que le mode de conformité du verrouillage de rétention respecte :
- SEC 17a-4(f)
- Règle CFTC 1.31b
- FDA 21 CFR Partie 11
- Loi Sarbanes-Oxley
- IRS 98025 et 97-22
- Norme ISO 15489-1
- MoREQ2010
Pour des informations complètes sur la certification, contactez votre fournisseur de support contractuel.
Comment le mode de gouvernance du verrouillage de rétention est-il activé ?
- Une licence de gouvernance du verrouillage de rétention est ajoutée à la DDR.
- Le mode de gouvernance du verrouillage de rétention est activé par rapport à n'importe quelle structure MTree requise :
# mtree retention-lock enable mode governance mtree [mtree]
Comment le mode de conformité du verrouillage de rétention est-il activé ?
- Il existe des instructions spécifiques pour certains modèles Data Domain plus récents avec iDRAC.
- Une licence de conformité du verrouillage de rétention est ajoutée à la DDR.
- Un utilisateur doté du rôle de « responsable de la sécurité » doit être créé (en supposant qu’il n’existe pas déjà) :
(ADMIN USER) # user add [username] role security
- Celui-ci doit se connecter à la DDR et activer l’autorisation de l’utilisateur de sécurité :
(SECURITY USER): # authorization policy set security-officer enabled
- Le système doit être configuré pour le mode de conformité du verrouillage de rétention. Une fois que la commande suivante s'exécute jusqu'au bout, le système redémarre automatiquement :
(ADMIN USER) # system retention-lock compliance configure
- Une fois le système redémarré, le mode de conformité du verrouillage de rétention doit être activé sur le système :
(ADMIN USER) # system retention-lock compliance enable
Remarque : Pour les versions plus récentes de DDOS, cette tâche doit être effectuée à l’aide de l’interface utilisateur Data Domain. Administration > Conformité
- Le mode de conformité du verrouillage de rétention est activé par rapport à n'importe quelle structure MTree requise :
(ADMIN USER) # mtree retention-lock enable mode compliance mtree [mtree]
Comment est-il possible de déterminer les structures MTree pour lesquelles le verrouillage de rétention est activé ?
Les structures MTree avec verrouillage de rétention activé sont indiquées dans la sortie de « mtree list », par exemple :
sysadmin@ddxxxx# mtree list
Name Pre-Comp (GiB) Status Tenant-Unit
--------------------------------- -------------- ------- -----------
...
/data/col1/rich-retention-lock 0.0 RW/RLGE -
/data/col1/rl_test 0.0 RW/RLGD -
/data/col1/rl_test_comp 0.0 RW/RLCE -
/data/col1/test 3.1 RW/RLGE -
...
--------------------------------- -------------- ------- -----------
...
RLGE : Retention-Lock Governance Enabled
RLGD : Retention-Lock Governance Disabled
RLCE : Retention-Lock Compliance Enabled
Est-il possible de convertir une structure MTree avec Retention Lock Governance activé en Retention Lock Compliance ?
Comme indiqué dans le Guide d’administration de DDOS, cela n’est pas possible.
Est-il possible de convertir en Retention Lock Governance une structure MTree pour laquelle Retention Lock Compliance est activé ?
Comme indiqué dans le Guide d’administration de DDOS, cela n’est pas possible.
Comment les périodes de rétention ou de verrouillage des fichiers sont-elles définies ?
Une fois qu’un verrouillage de rétention est activé sur une structure MTree, une période de rétention minimale et maximale doit être définie. Elles déterminent la durée minimale et maximale pendant laquelle un fichier au sein de la structure MTree peut être verrouillé. Par exemple :
# mtree retention-lock set min-retention-period [period] mtree [mtree]
# mtree retention-lock set max-retention-period [period] mtree [mtree]
Les périodes peuvent être indiquées dans différentes unités comme suit :
- 1 minute
- 1 heure
- 1 jour
- 1 mois
- 1 an
Remarque :
- une période de rétention minimale ne peut pas être inférieure à 12 heures.
- Une période de rétention maximale ne peut pas être supérieure à 70 ans.
- La période de rétention minimale doit être inférieure à la période de rétention maximale.
- Les périodes de rétention de chaque structure MTree sont définies de la même manière, quelle que soit la version du verrouillage de rétention utilisée.
Comment afficher les périodes de rétention existantes ?
Pour ce faire, utilisez les deux commandes suivantes :
# mtree retention-lock show min-retention-period mtree [mtree]
# mtree retention-lock show max-retention-period mtree [mtree]
Par exemple :
sysadmin@dd630# mtree retention-lock show min-retention-period mtree /data/col1/rl_test
Retention-lock min-retention-period of mtree /data/col1/rl_test is: 720 minutes.
sysadmin@dd630# mtree retention-lock show max-retention-period mtree /data/col1/rl_test
Retention-lock max-retention-period of mtree /data/col1/rl_test is: 30 days.
Comment les fichiers au sein d'une structure MTree avec verrouillage de rétention activé sont-ils verrouillés ?
- Lorsque le verrouillage de rétention est activé sur une structure MTree, les fichiers existants au sein de la structure MTree ne sont pas verrouillés automatiquement (autrement dit, tous les fichiers préexistants restent en lecture ou en écriture).
- Lorsqu'un nouveau fichier est écrit dans une structure MTree avec le verrouillage de rétention activé, le fichier ne fait pas automatiquement l'objet d'un verrouillage de rétention. Autrement dit, le nouveau fichier reste en lecture ou en écriture.
Remarque : à partir de DDOS 6.2.0.20, il existe une fonctionnalité dans DDOS appelée « verrouillage de rétention automatique », qui peut définir automatiquement un verrou sur tous les fichiers écrits. Consultez la section « Verrouillage de rétention automatique » dans la suite de cet article KB pour en savoir plus.
- Pour appliquer le verrouillage de rétention à un fichier spécifique, l'heure de dernier accès au fichier doit être modifiée pour correspondre à la date et l'heure à laquelle le fichier doit faire l'objet du verrouillage de rétention. Il s'agit de la date et de l'heure jusqu'auxquelles le fichier doit rester en lecture seule. Tant que l’heure de dernier accès n’est pas ainsi modifiée, le fichier ne peut pas faire l’objet d’un verrouillage de rétention (et peut être modifié ou supprimé).
L'heure de dernier accès à un fichier peut être modifiée à partir d'un client NFS ou CIFS à l'aide de la commande « touch » :
# touch -a -t [expiry time] [file to be locked]
Par exemple, pour définir l'heure de dernier accès à /data/col1/rl_test/testfile sur 07 h 05 le 8 juin :
# touch -a -t 06080705 /data/col1/rl_test/testfile
La période entre l'heure actuelle et l'heure de dernier accès future doit être comprise entre les périodes de rétention minimale et maximale pour la structure MTree. Dans le cas contraire, une erreur survient lors de la modification de l'heure de dernier accès du fichier :
# touch -a -t 08080705 /data/col1/rl_test/testfile
touch: setting times of `/data/col1/rl_test/testfile': Permission denied
Un message correspondant s’affiche également dans les fichiers journaux du système de fichiers Data Domain (DDFS) :
06/07 13:44:57.197 (tid 0x2b28ee5258c0): Attempt to set atime of /data/col1/rl_test/testfile to larger than maximum retention period of mtree.
Par défaut, les clients CIFS (Windows) n’incluent pas de commande tactile ou d’utilitaire, mais plusieurs de ces utilitaires sont disponibles gratuitement au téléchargement à partir de divers sites Web tiers.
Remarque : les fichiers ne peuvent pas faire l'objet d'un verrouillage de rétention tant qu'ils ne sont pas écrits dans la DDR. Il n'est pas possible de créer un fichier vide, de lui appliquer un verrouillage de rétention, puis d'y écrire des données.
Quelles applications de sauvegarde prennent en charge le verrouillage de rétention automatique des fichiers après leur écriture dans une DDR ?
Le verrouillage de rétention Data Domain est compatible avec les protocoles WORM (Write Once-Read-Many) NAS standards sur le marché. L’intégration est qualifiée au moyen d’applications d’archivage telles que Symantec Enterprise Vault, SourceOne, Cloud Tiering Appliance ou DiskXtender.
Pour Dell NetWorker, les modes de gouvernance et de conformité sont pris en charge.
À compter de juin 2024, les versions récentes d’Avamar prennent en charge à la fois le verrouillage de rétention Data Domain en mode conformité (et gouvernance) dans le cadre de la fonctionnalité « Sauvegardes inaltérables » d’Avamar. Pour plus d’informations, voir l’article ci-dessous et la documentation Avamar :
Avamar et Data Domain : Activation des sauvegardes inaltérables Avamar et du verrouillage de rétention Data Domain en mode conformité
Il est essentiel de respecter strictement les étapes d’activation de la fonctionnalité « Sauvegardes inaltérables » d’Avamar. Dans le cas contraire, vous risquez de vous retrouver avec une structure MTree Avamar dans le DD qui ne peut pas faire l’objet d’écritures supplémentaires ou qui présente des problèmes opérationnels forçant à ralentir la restauration. Avamar ne fonctionne pas avec le verrouillage de rétention automatique (ARL) DD, et l’ARL ne doit pas être activé pour une structure MTree Avamar sur un DD.
Les clients qui utilisent d’autres applications de sauvegarde ne prenant pas nativement en charge le verrouillage de rétention Data Domain peuvent également développer des scripts personnalisés de manière à utiliser Data Domain Retention Lock pour définir manuellement les périodes de rétention des fichiers. Dans ce scénario, assurez-vous que les scripts personnalisés définissent l'heure de dernier accès à un fichier de sorte qu'il soit déverrouillé avant que l'application de sauvegarde ne tente de le supprimer. Dans le cas contraire, l'application de sauvegarde tente de supprimer les fichiers verrouillés (ce qui échoue). Le fichier est laissé sur la DDR, consommant indéfiniment de l'espace disque. Consultez le Guide d'administration de Data Domain.
Verrouillage de rétention automatique
Pour les applications de sauvegarde qui ne prennent pas nativement en charge la fonction de verrouillage de rétention Data Domain, tirer parti de cette fonctionnalité a toujours été un défi pour les clients. Des scripts doivent être configurés par l’administrateur de sauvegarde afin de définir le verrouillage de rétention sur les fichiers nouvellement acquis pour une structure MTree. Le verrouillage doit être défini de sorte à expirer peu de temps avant l’expiration de la sauvegarde (et sa suppression) par l’administrateur de sauvegarde.
L’ARL définit un verrouillage sur chaque fichier écrit sur la structure MTree après l’activation de la fonctionnalité, ce qui empêche le fichier d’être modifié ou supprimé pendant une période donnée à l’issue de la période de réflexion configurée. Cela signifie que l’ARL ne doit pas être activé pour les charges applicatives ou les applications de sauvegarde qui doivent mettre à jour certains fichiers à plusieurs reprises au fil du temps, par exemple, sur des pools VTL (les fichiers de bande VTL sont écrits à plusieurs reprises) ou pour les applications de sauvegarde qui conservent les informations de métadonnées en même temps que les fichiers de sauvegarde du client eux-mêmes (comme NetWorker ou Avamar). Dans ces cas, l’activation de l’ARL peut verrouiller des fichiers importants pendant une certaine période, et lorsque ces fichiers doivent être écrits ultérieurement pour d’autres sauvegardes, l’écriture échoue, de même que toutes les sauvegardes ultérieures.
Pour aider les administrateurs de sauvegarde à réduire la charge liée au maintien du verrouillage de rétention sur les fichiers de sauvegarde et à faire en sorte que le DDOS offre des fonctions équivalentes aux autres fournisseurs, il existe depuis DDOS 6.2.0.20 une fonctionnalité pouvant être activée à partir de la CLI pour chaque structure MTree sur laquelle le verrouillage de rétention est configuré, et permettant de définir un verrou sur chaque fichier acquis (pour une période donnée), après qu’un laps de temps prédéterminé s’est écoulé depuis la fin de l’écriture du fichier sur le disque. De cette façon, les administrateurs n'ont plus à se soucier de définir manuellement (ou par un script) le verrouillage de rétention, lequel peut alors se produire automatiquement sans la coopération de l'application de sauvegarde.
Avant DDOS 7.8, le verrouillage de rétention automatique ne peut pas être utilisé sur les unités de stockage logiques (LSU) DD Boost. Si vous tentez d’activer cette option, une erreur s’affiche indiquant qu’elle n’est pas prise en charge.
À partir de la version 7.8, ARL est pris en charge pour les LSU DD Boost.
(Le verrouillage de rétention automatique utilisé sur les DD cibles pour la réplication de fichiers gérés (MFR), comme le clone NW, doit avoir un délai de verrouillage automatique suffisamment long pour s’assurer que les opérations de clonage sont terminées pour le jeu de sauvegardes avant que le verrouillage ne soit défini sur les fichiers. Exemple : Un fichier de petite taille qui fait partie d’un jeu de sauvegardes termine rapidement la réplication tandis qu’un fichier plus volumineux prend plus de temps, puis un verrouillage de rétention est appliqué au premier fichier lorsque le plus grand fichier termine la réplication et une erreur se produit lorsque NW tente de déplacer tous les fichiers du jeu de sauvegardes vers le répertoire d’archivage final.)
Le verrouillage de rétention automatique n’est pas pris en charge sur Data Domain VTL.
Sur les versions applicables, il existe des options supplémentaires dans la CLI mtree retention-lock, comme indiqué ci-dessous. Cette fonctionnalité peut également être configurée via l'interface utilisateur en choisissant « Automatique » au lieu de « Manuel » dans l'option « Utilisation » :
# mtree retention-lock set
{min-retention-period | max-retention-period |
automatic-retention-period | automatic-lock-delay} <period>
mtree <mtree-path>
La fonction de verrouillage de rétention automatique verrouille un fichier immédiatement après expiration d’une période de refroidissement préconfigurée (automatic-lock-delay). Une fois que le fichier est écrit dans une structure MTree avec verrouillage de rétention activé et que le verrou est valide pour « automatic-retention-period » à compter du moment où il a été défini, si la valeur se trouve entre les valeurs « min-retention-period » et « max-retention-period » définies pour la structure MTree, le verrouillage se produit.
Pour plus d'informations sur l'utilisation et des informations générales sur la fonctionnalité, consultez le Guide d'administration DDOS correspondant. Cette fonctionnalité n’est pas adaptée aux situations dans lesquelles la même structure MTree est utilisée comme cible pour des sauvegardes qui devraient soit présenter des ensembles de verrouillage pour différentes périodes, soit ne présenter aucun ensemble de verrouillage à l’origine.
Qu’est-ce qui peut ou ne peut pas être fait sur un fichier verrouillé ?
- Les fichiers faisant l’objet d’un verrouillage de rétention sont en lecture seule et ne peuvent pas être modifiés ou supprimés.
- Une fois la période de rétention d'un fichier expirée, il est « déverrouillé ». Lorsque le fichier est déverrouillé, il ne peut toujours pas être modifié, mais il peut être supprimé. La DDR ne supprime pas automatiquement un fichier lorsque sa période de rétention expire (la suppression suivante doit être effectuée à partir d'un système client ou d'une application de sauvegarde).
- Une fois définie, la période de rétention d'un fichier spécifique ne peut pas être réduite (autrement dit, l'heure de dernier accès aux fichiers ne peut pas être avancée).
- Toutefois, les périodes de rétention peuvent être prolongées (l'heure de dernier accès peut être repoussée jusqu'à la période de rétention maximale pour la structure MTree).
- Les paramètres de propriété et d’autorisation d’un fichier restent modifiables pendant que le fichier est verrouillé.
- il n'est possible de renommer ou de supprimer un répertoire dans une structure MTree avec verrouillage de rétention activé que si ce répertoire ne contient aucun fichier. Si le répertoire contient des fichiers (même si ces fichiers ne font pas l’objet d’un verrouillage de rétention), la modification du nom ou la suppression du répertoire échoue.
- Même si le contenu du fichier lui-même est modifié, la modification de nom (attribution d’un nouveau nom) n’est pas autorisée pour les fichiers pour lesquels un verrouillage est défini, mais la modification de nom est également interdite une fois le verrouillage du fichier expiré. Pour les fichiers qui ne sont plus verrouillés, la seule opération autorisée est une suppression. Ce n’est plus le cas dans DDOS 7.7.4, où il est possible de renommer les fichiers non verrouillés.
Est-il possible de supprimer complètement le verrouillage de rétention sur un fichier ou un ensemble de fichiers ?
Il est possible de « désactiver » (supprimer) le verrouillage de rétention des fichiers dans des structures MTree à l'aide du mode de gouvernance. Pour ce faire, utilisez la commande suivante :
# mtree retention-lock revert [path]
Une fois le verrouillage de rétention d'un fichier supprimé, celui-ci peut être modifié ou supprimé normalement. Si cette commande est exécutée sur un répertoire, tous les fichiers de ce répertoire et tous les sous-répertoires voient leur verrouillage de rétention supprimé.
Il n'est pas possible de désactiver un verrouillage de rétention sur les fichiers au sein de structures MTree en mode de conformité. Ce genre de tentative entraîne l'affichage d'une erreur correspondante :
# mtree retention-lock revert /data/col1/rl_test_comp/testfile
This operation is not allowed. Mtree is in retention-lock compliance mode.
Que se passe-t-il en cas de tentative de modification ou de suppression d’un fichier faisant l’objet d’un verrouillage de rétention ?
Toute tentative de modification ou de suppression d’un tel fichier entraîne l’affichage d’une erreur « permission denied » correspondante :
# echo " test2" >> /data/col1/rl_test/testfile
bash: testfile: Permission denied
# rm testfile
rm: remove write-protected regular file `testfile'? y
rm: cannot remove `testfile': Permission denied
Les journaux DDFS indiquent que l'opération a échoué en raison du verrouillage de rétention du fichier :
06/07 07:06:59.756 (tid 0x2b5a77605d50): Atime of retention-lock file /data/col1/rl_test/testfile is not expired.
06/07 07:07:42.504 (tid 0x2b5a79111390): Atime of retention-lock file /data/col1/rl_test/testfile is not expired.
Est-il possible de répertorier tous les fichiers faisant l'objet d'un verrouillage de rétention ?
Oui, cette opération peut être effectuée à l'aide de la commande « mtree retention-lock report generate retention-details » :
mtree retention-lock report generate retention-details
mtrees {<mtree-list> | all}
[format {text | tsv | csv}]
[output-file <file-name>]
Report detailed information of
retention-lock files.
Par exemple, pour répertorier les détails de tous les fichiers verrouillés dans la structure MTree /data/col1/rl_test, les opérations suivantes sont effectuées :
sysadmin@ddxxxx# mtree retention-lock report generate retention-details mtrees /data/col1/jftest
Report generated on: Fri Jul 1 14:19:31 2016
Report for mtree: /data/col1/jftest
File Path Mode Size(Bytes) Expiration Date
/data/col1/jftest/file1 governance 10521456 Sat Jul 2 22:35:48 2016
/data/col1/jftest/testdir/file2 governance 10521680 Sat Jul 2 22:35:42 2016
/data/col1/jftest/file3 governance 10521820 Sun Jul 10 22:36:09 2016
Total files: 3
Est-il possible de désactiver complètement le verrouillage de rétention pour une structure MTree (une fois qu'elle est activée) ?
Oui, pour les structures MTree utilisant le mode de gouvernance, cette opération est effectuée à l'aide de la commande « mtree retention-lock disable » :
# mtree retention-lock disable mtree [mtree]
For example:
sysadmin@xxxx# mtree retention-lock disable mtree /data/col1/rl_test
Retention-lock feature is disabled (previously enabled) for mtree /data/col1/rl_test.
Once disabled, MTree list indicates that retention lock was used against the MTree but has since been disabled, that is:
sysadmin@ddxxxx# mtree list
Name Pre-Comp (GiB) Status Tenant-Unit
--------------------------------- -------------- ------- -----------
...
/data/col1/rl_test 0.0 RW/RLGD -
...
Remarque : une fois le verrouillage de rétention désactivé sur une structure MTree :
- Les nouveaux fichiers écrits dans la structure MTree ne peuvent pas faire l'objet d'un verrouillage de rétention.
- Les fichiers qui sont déjà verrouillés le restent pendant toute leur période de rétention précédemment définie (c'est-à-dire que tous les verrous ne sont pas automatiquement désactivés lorsque le verrouillage de rétention est désactivé sur une structure MTree).
- Les verrous existants sur les fichiers d'une structure MTree dont le verrouillage de rétention est désactivé ne peuvent pas être désactivés. Toutes les désactivations nécessaires doivent être effectuées avant la désactivation du verrouillage de rétention :
sysadmin@ddxxxx# mtree retention-lock revert /data/col1/rl_test/testfile
**** Retention-lock feature is disabled (previously enabled) for mtree which contains the path /data/col1/rl_test/testfile.
- Le verrouillage de rétention ne peut pas être désactivé pour une structure MTree à l'aide du mode de conformité :
sysadmin@ddxxxx# mtree retention-lock disable mtree /data/col1/rl_test_comp
**** Operation is not allowed because the system is a retention-lock compliance system
La réplication peut-elle toujours être utilisée sur des structures MTree pour lesquelles le verrouillage de rétention est activé ?
Oui, les structures MTree ou les fichiers faisant l'objet d'un verrouillage de rétention peuvent être répliqués à l'aide de diverses topologies de réplication :
- La réplication de répertoire, uniquement prise en charge pour les fichiers en mode de gouvernance, ne réplique pas les périodes de rétention minimale et maximale vers le système de destination.
- La réplication de structure MTree peut être utilisée aussi bien sur les données en mode de gouvernance qu'en mode de conformité et réplique les périodes de rétention minimale et maximale vers le système de destination.
- La réplication de collection peut être utilisée aussi bien sur les données en mode de gouvernance qu'en mode de conformité et réplique les périodes de rétention minimale et maximale vers le système de destination.
Remarque : pour les verrous de rétention à conserver sur les systèmes de destination :
- Les licences de verrouillage de rétention correspondantes doivent être installées sur les systèmes source et cible.
- Les contextes de réplication de structure MTree doivent avoir le paramètre « Replication propagate-retention-lock » défini sur Activé.
- Pour les fichiers répliqués via une réplication de répertoire, les périodes de rétention minimale et maximale des structures MTree correspondantes doivent être définies manuellement sur le système de destination.
Existe-t-il d'autres restrictions lors de la réplication de fichiers faisant l'objet d'un verrouillage de rétention ?
Oui, les resynchronisations de contextes de réplication (qui tentent de rétablir un contexte précédemment configuré, mais perdu) utilisant des données auxquelles un verrouillage de rétention est appliqué peuvent échouer.
Remarque :
- si la réplication de structure MTree est utilisée et que la structure MTree de destination contient des fichiers faisant l’objet d’un verrouillage de rétention qui n’existent pas sur la source, la resynchronisation échoue.
- Si la réplication de répertoire est utilisée et qu’un verrouillage de rétention est appliqué à la destination, mais pas à la source, alors la resynchronisation échoue.
Remarque : lors de l’utilisation de la réplication de structure MTree, une resynchronisation réussit dans les scénarios suivants, à condition que la structure MTree de destination ne contienne pas de fichiers faisant l’objet d’un verrouillage de rétention qui ne sont pas présents sur la DDR source :
- Le verrouillage de rétention n’est pas activé sur la structure MTree source, mais il l’est sur la structure de destination.
- Le verrouillage de rétention n’est pas activé sur la structure MTree de destination, mais il l’est sur la structure source.
Il n’est pas possible non plus d’activer le mode de conformité du verrouillage de rétention sur une structure MTree qui est déjà membre d’un contexte de réplication de MTree. Dans ce scénario :
# replication break mtree://[destination system]/data/col1/[mtree]
# replication add source mtree://[source system]/data/col1/[mtree] destination mtree://[destination system/data/col1/[mtree]
# mtree retention-lock enable mode compliance mtree [mtree]
# replication resync mtree://[destination system/data/col1/[mtree]
Les fichiers soumis à un verrouillage de rétention peuvent-ils faire l’objet d’une copie rapide ?
Oui, ils peuvent faire l’objet d’une copie rapide tout à fait normalement. Si un verrouillage de rétention est activé sur la structure MTree de destination contenant la copie rapide, le verrouillage de rétention du fichier est conservé sur la copie rapide. Si aucun verrouillage de rétention n’est activé sur la structure MTree de destination, la copie rapide ne fait l’objet d’aucun verrouillage de rétention.
Existe-t-il d'autres restrictions dans les fonctionnalités du système lors de l'utilisation du verrouillage de rétention ?
Les commandes suivantes ne sont pas autorisées sur les systèmes utilisant le mode de conformité du verrouillage de rétention :
# user reset
# filesys destroy
# filesys archive unit del [archive unit name]
De tels systèmes ne peuvent pas être démarrés en mode utilisateur unique pour une récupération par le support technique sans l’utilisation d’une clé USB et un accès physique au système.
Les commandes suivantes ne sont pas autorisées pour les structures MTree utilisant le mode de conformité du verrouillage de rétention :
# mtree delete [mtree]
# mtree retention-lock reset [min-retention-period period | max-retention-period period] mtree [mtree]
# mtree retention-lock disable mtree [mtree]
# mtree retention-lock revert
Toutefois, dans DDOS 7.3 et versions ultérieures, une disposition a été prise pour permettre aux clients de supprimer des structures MTree sur lesquelles le mode de conformité du verrouillage de rétention est activé, à condition que :
- DD exécute DDOS 7.3 ou une version ultérieure.
- La structure MTree RLCE à supprimer soit vide (ne contienne aucun fichier ni répertoire).
- L'administrateur réussisse l'authentification en tant que responsable de la sécurité.
Dans les systèmes configurés avec une rétention à long terme (Cloud Tier), certaines commandes tout aussi destructrices peuvent également être interdites, par exemple :
# cloud unit del <cloud unit name>
Remarque : les structures MTree utilisant le mode de gouvernance du verrouillage de rétention (ou pour lesquelles ce mode a été auparavant activé) ne peuvent être supprimées qu’une fois que la structure MTree ne contient plus aucun fichier. Si des fichiers restent dans la structure MTree, une erreur est renvoyée.
L'horloge système est-elle importante sur les systèmes où le verrouillage de rétention est activé ?
Oui, les systèmes sur lesquels le mode de conformité du verrouillage de rétention est activé permettent à une « horloge de sécurité » interne d’éviter toute altération malveillante de l’horloge système (qui pourrait autoriser la suppression précoce de fichiers faisant l’objet d’un verrouillage de rétention). Les heures des horloges système et de sécurité sont régulièrement comparées et, en cas d’asymétrie cumulée de 2 semaines entre les deux au cours d’une même année civile, le système de fichiers Data Domain (DDFS) est automatiquement désactivé afin d’empêcher tout accès aux données sur la DDR. Cela peut également se produire si l’horloge système est soudainement modifiée et que l’heure est modifiée de plus de 2 semaines.
Dans ce scénario, DDFS peut être réactivé en :
- se connectant à la DDR ;
- vérifiant que l’horloge système est correctement définie ;
- activant le système de fichiers :
# filesys enable
- Lorsque vous y êtes invité, saisissez les détails d’un utilisateur ayant le rôle de responsable de la sécurité afin de permettre la réinitialisation de l’horloge de sécurité et l’activation de DDFS.
L’horloge du système peut-elle être synchronisée avec Active Directory sur les systèmes sur lesquels Retention Lock Compliance est activé ?
Non, lorsque la conformité du verrouillage de rétention est activée, les serveurs CIFS ne synchronisent plus l’heure du système avec Active Directory. En cas de différence temporelle supérieure à cinq minutes entre le système et Active Directory, le serveur CIFS affiche un message d’erreur lorsqu’un utilisateur Active Directory tente de se connecter ou que le système tente de rejoindre un domaine Active Directory. Configurez l’heure Active Directory avec NTP pour éviter cette erreur.
Cela contraste avec les systèmes où la conformité au verrouillage de rétention n’est pas activée, mais où Active Directory est en cours d’utilisation. Dans ce cas, il n’est pas recommandé d’activer NTP, car il peut y avoir des conflits de paramètre d’heure entre Active Directory et NTP.
Quelles mesures peuvent être prises si une DDR utilisant des fichiers verrouillés pour rétention atteint sa capacité maximale ?
En supposant qu'il n'existe pas d'espace « nettoyable » sur la DDR (le nettoyage est exécuté, mais le système reste à capacité maximale), son contenu doit être examiné pour déterminer si :
-
Certains fichiers ne faisant pas l'objet d'un verrouillage de rétention peuvent être supprimés.
-
Certains fichiers faisant l'objet d'un verrouillage de rétention en mode de gouvernance peuvent voir leurs verrous désactivés et supprimés.
Une fois cette opération effectuée, le nettoyage doit être exécuté à nouveau pour libérer de l’espace physique sur le système. Sinon, si aucune donnée physique ne peut être supprimée du système, un stockage physique supplémentaire doit être ajouté à la DDR et le système de fichiers doit être étendu (en supposant que l’extension est prise en charge par la DDR ou la configuration en cours).
Si les seuls fichiers présents sur le système sont verrouillés en mode de conformité, il n’est pas possible de désactiver les verrous et de supprimer ces fichiers. Par conséquent, il est impossible de libérer de l'espace, à moins que :
-
La période de rétention soit atteinte pour certains ou tous les fichiers. Ils peuvent dès lors être supprimés et nettoyés (comme décrit ci-dessus).
-
Le système soit réinstallé à partir d’une clé USB (ce qui entraîne la perte de toutes les données sur la DDR).
-
Davantage de stockage physique soit ajouté au système (comme décrit ci-dessus).
Remarque : il est parfaitement possible de remplir complètement une DDR avec des fichiers verrouillés en mode de conformité. Dans ce scénario, il n'y a rien qu'un administrateur ou le support technique ne puisse faire pour libérer de l'espace (il n'existe aucune fonctionnalité de bas niveau permettant de supprimer/désactiver les verrous en mode de conformité et de supprimer de manière précoce les fichiers correspondants).