Dissociation de la réplication

Un package de réplication peut être converti en projet inscriptible local exploitable comme n'importe quel autre projet local (c'est-à-dire sans les restrictions de gestion appliquées aux packages de réplication) en dissociant la connexion de réplication. Une fois cette opération effectuée, ce package ne peut plus recevoir de mises à jour de réplication. Les mises à jour ultérieures du même projet à partir de la source doivent donc envoyer une mises à jour complète accompagnée d'une nouvelle action (et dans un nouveau package). Les mises à jour de réplication ultérieures échouent car le package correspondant n'existe plus sur la cible.

Cette option est utile essentiellement lors de l'emploi de la réplication pour migrer des données entre les appareils ou dans d'autres scénarios qui n'impliquent pas de réplication des données reçues vers la source dans le cadre d'un plan de récupération après sinistre classique.

Pour dissocier la réplication dans la BUI, accédez au package de réplication (voir ci-dessus) et cliquez sur l'onglet Réplication puis sur le bouton . La boîte de dialogue qui s'affiche alors permet à l'administrateur d'indiquer le nom du nouveau projet local.

Pour dissocier la réplication dans la CLI, accédez au package de réplication (voir ci-dessus) et exécutez la commande sever. Cette commande sélectionne un argument facultatif indiquant le nom du nouveau projet local. Si aucun argument n'est indiqué, le nom d'origine est utilisé.

Tous les partages locaux étant exportés, tous les partages d'un package sont exportés lorsque celui-ci est dissocié, qu'ils l'aient déjà été ou non (voir ci-dessus). S'il existe des conflits de point de montage entre les systèmes de fichiers répliqués et les autres systèmes de fichiers, l'opération de dissociation échoue. Il faut résoudre ces conflits avant l'inversion en reconfigurant les points de montage des partages concernés.