Réplication de données dans des ensembles de conservation
Même s'il est possible de définir des règles de conservation et des ensembles de conservation sur les serveurs de réplication source ou cible, il est préférable de le faire uniquement sur le serveur de réplication source et de planifier la création de l'ensemble de conservation lorsque la règle de conservation proprement dite est créée. Cette pratique permet de garantir la cohérence entre les serveurs de réplication source et cible et de veiller à ce que tous les fichiers soient disponibles pour être inclus dans l'ensemble de conservation. Pour plus d'informations sur la réplication des données client vers un autre serveur, voir Réplication des données client sur un autre serveur.
Les règles de conservation et les ensembles de conservation qui sont définis sur le serveur de réplication source ne sont pas répliqués sur le serveur cible. Seules les données des ensembles de conservation sont répliquées. Les métadonnées de réplication sont également mises à jour lorsque l'objet de données répliqué passe à l'état CONSERVE. Un objet de données passe à l'état CONSERVE à l'expiration des données ou quand ces données sont doivent être supprimées mais sont conservées car elles se trouvent dans un ensemble de conservation actif. Les données conservées le sont jusqu'à expiration ou suppression de l'ensemble de conservation.
Pour activer la réplication de noeud, suivez les instructions fournies dans la section Activation de la réplication de noeud.
Prérequis
Avant d'exécuter une opération de réplication, assurez-vous que les prérequis suivants sont satisfaits :
- Vérifiez que le serveur de réplication cible prend en charge la conservation. Les fonctions de règle de conservation sont prises en charge à partir de IBM Storage Protect 8.1.7.
- Vérifiez que l'ingestion de données est terminée sur le serveur de réplication source pour les noeuds ou les machines virtuelles contenant les données conservées.
- Vous pouvez définir des règles de conservation et des ensembles de conservation sur le serveur de réplication source ou cible. Toutefois, vous ne pouvez pas définir des règles de conservation et des ensembles de conservation pour les mêmes données sur les serveurs de réplication source et cible en même temps. Si un ensemble de conservation existe pour un noeud en cours de réplication sur un autre serveur, ce même noeud ne peut pas être membre d'un ensemble de conservation sur le serveur de réplication cible. De même, si un ensemble de conservation existe pour un noeud qui est un noeud cible pour la réplication depuis un autre serveur, le noeud source ne peut pas être membre d'un ensemble de conservation sur le serveur de réplication source. Le traitement de la réplication échoue tant que l'ensemble de conservation sur un serveur impliqué dans l'opération de réplication n'est pas arrivé à expiration ou n'a pas été supprimé.
- Si vous dispose d'ensembles de conservation sur un serveur de réplication source ou cible, vous ne pouvez pas inverser les rôles des serveurs de réplication ; en d'autres termes, vous ne pouvez pas désigner le serveur de réplication source comme serveur de réplication cible et vice versa. Si vous le faisiez, les données contenues dans les ensembles de conservation risqueraient d'être endommagées ou perdues.
- Si un noeud de votre ensemble de conservation est la cible d'une opération de réplication de noeud et que vous souhaitez créer un ensemble de conservation avec les données à répliquer, vous devez définir l'ensemble de conservation avec les valeurs de paramètre STARTTIME et STARTDATE qui précèdent le début de l'opération de réplication.
- Dans le Centre d'opérations, vous ne pouvez pas définir de règles de conservation pour protéger des noeuds sur un serveur de réplication si ces noeuds ont été répliqués à partir d'un autre serveur.
- Si vous répliquez des noeuds sur un serveur cible antérieur à la version 8.1.7, la conservation n'est pas prise en charge sur le serveur cible et vous ne pouvez pas ajouter les noeuds à une règle de conservation sur le serveur de réplication source.
- Si vous exécutez la commande REMOVE REPLNODE pour retirer un noeud de la réplication, les objets de données de sauvegarde répliqués précédemment qui sont à l'état CONSERVE sont susceptibles d'être supprimés du serveur cible en raison du traitement d'expiration, dans la mesure où ils ne font pas partie d'un ensemble de conservation sur le serveur cible. Pour éviter la suppression des données, assurez-vous que le processus d'expiration d'inventaire est arrêté et désactivé sur les serveurs cible concernés. Pour plus d'informations, voir REMOVE REPLNODE (Suppression d'un noeud client de la réplication).
Guide de bonnes pratiques en matière d'expiration et de suppression des données conservées
En règle générale, les objets de données arrivent à expiration quand ils ne sont plus conformes aux critères de conservation spécifiés dans les paramètres de règle pour la conservation des données sur le serveur. Pour plus d'informations, voir Concepts de règles.
Lors du processus d'expiration sur le serveur, les fichiers arrivés à expiration sont retirés de la base de données du serveur, puis supprimés de l'espace de stockage du serveur. Toutefois, les fichiers considérés comme arrivés à expiration selon les paramètres de règle sur la conservation des données, mais sont contenus dans un ensemble de conservation actif sont conservés et disponibles pour réplication sur des serveurs. L'expiration de ces données conservées peut être traitée en utilisant les méthodes suivantes :
- Si un objet de données conservé arrive à expiration ou est supprimé sur le serveur de réplication source, l'objet de données répliqué sur le serveur de réplication cible est supprimé durant l'opération de réplication suivante.
- Les données sur un serveur de réplication cible n'arrivent pas à expiration tant que tous les ensembles de conservation qui contiennent les données n'arrivent pas à expiration sur le serveur de réplication source. Lorsque l'ensemble de conservation arrive à expiration sur le serveur cible, seuls les objets de données conservés qu'il contient sont supprimés.
- Si vous définissez des règles différentes sur des serveurs comportant des ensembles de conservation, l'expiration est traitée comme suit :
- Si l'ensemble de conservation est défini sur le serveur de réplication source, les objets de données conservés sont répliqués et marqués comme INACTIF sur le serveur cible. Les données répliquées arrivent à expiration conformément aux propres paramètres de règle du serveur cible ou elles sont supprimées.
- Si l'ensemble de conservation est défini sur le serveur de réplication cible, les propres règles du serveur cible traitent l'expiration des données conservées. Si les données conservées appartiennent à un ensemble de conservation actif, elle sont conservées jusqu'à ce que ce dernier arrive à expiration.
Important: Lorsque vous utilisez des règles différentes, assurez-vous que vous êtes conscient de l'effet des règles sur les données conservées de sorte que les données n'expirent pas tant que vous ne souhaitez pas qu'elles expirent. Si vous activez des règles différentes pour vos ensembles de conservation sur les serveurs source et cible, les objets de sauvegarde répliqués qui sont à l'état CONSERVE mais qui ne figurent pas dans un ensemble de conservation sur le serveur cible sont supprimés conformément aux paramètres de règle.Pour définir des règles différentes, exécutez la commande SET DISSIMILARPOLICIES. Pour plus d'informations, voir SET DISSIMILARPOLICIES (Activation des règles sur le serveur de réplication cible pour gérer les données répliquées).
Scénario : Une règle de conservation et des ensembles de conservation sont définis sur le serveur de réplication source
Si la règle de conservation et l'ensemble de conservation sont créés sur le serveur de réplication source, les considérations suivantes s'appliquent :
- Les règles de conservation et les ensembles de conservation qui sont définis sur le serveur de réplication source ne sont pas répliqués sur le serveur cible. Seules les données des ensembles de conservation sont répliquées. Pour des informations sur la réplication des données client sur un autre serveur, voir Réplication des données client sur un autre serveur.
- Si vous répliquez un objet de données actif ou inactif et que cet objet passe ensuite à l'état CONSERVE, l'objet de données répliqué sur le serveur de réplication cible passe à l'état CONSERVE à la prochaine opération de réplication.
- Si un objet de données est à l'état CONSERVE sur le serveur de réplication source et n'a pas été répliqué avant de passer à cet état, l'objet de données est répliqué sur le serveur de réplication cible au cours de l'opération de réplication suivante et passe automatiquement à l'état CONSERVE.
Scénario : des règles de conservation et des ensembles de conservation sont définis sur le serveur de réplication cible
Si vous définissez une règle de conservation ou un ensemble de conservation sur le serveur de réplication cible, les considérations suivantes s'appliquent :
- Assurez-vous que des fichiers sont disponibles pour inclusion dans l'ensemble de conservation en exécutant la commande DEFINE COPYGROUP et en définissant le paramètre VEREXISTS sur une valeur supérieure ou égale à 3.
- Lorsqu'un fichier répliqué présent sur le serveur de réplication cible est susceptible d'être supprimé en raison d'un processus de suppression sur le serveur source, ce fichier répliqué passe à l'état CONSERVE s'il appartient à un ensemble de conservation actif sur le serveur de réplication cible.
- Lorsque les données présentes sur le serveur de réplication source arrivent à expiration, la relation entre les fichiers concernés sur les serveurs source et cible est retirée et les fichiers du serveur cible ne sont plus considérés comme des répliques.
- Lorsqu'un ensemble de conservation arrive à expiration sur le serveur cible, seuls les objets de données conservés qu'il contient sont supprimés.