Lorsque vous utilisez VEEAM, ou toute autre application de sauvegarde utilisant BOOST pour effectuer des sauvegardes, utilise la fonction Virtual Synthetics, elle crée de nouvelles sauvegardes à partir de celles existantes en associant des parties des sauvegardes précédentes sur le DD, puis ajoute les différences. Les sauvegardes précédentes utilisées pour la mise en point sont appelées « fichiers de base ».
La plupart des applications de sauvegarde lisent, mais ne modifient pas les fichiers de base utilisés pour la synthèse de nouvelles images de sauvegarde, mais VEEAM fonctionne différemment, lors de l’exécution de sauvegardes, elle remplace des parties des fichiers de base déjà sur le disque.
Lorsque la réplication de structure MTree sortante est configurée pour cette unité LSU/MTree VEEAM, il est possible qu’un fichier de sauvegarde en cours de réplication soit modifié par BOOST lors de la synthèse des nouveaux fichiers de sauvegarde. Si le DD source exécute DDOS 6.x et que la réplication de recettes est activée (option d’optimisation de la vitesse/des performances dans DDOS 6.x et versions ultérieures), cela peut entraîner l’arrivée de checksums incorrects sur le DD de destination, ce qui peut entraîner l’échec du système de fichiers (FS) à plusieurs reprises avec des messages tels que :
27 février 04 :05 :19 mtree-repl-dd.example.com ddfs[10654] : ERROR: MSG-INTRNL-00001 : FONCTIONNEMENT INATTENDU : ddr/repl/mrepl_replica.c : mrepl_finish_file_transfer_common : 3712: ! (orig_chksum == repl_chksum).
La façon dont VEEAM synthétise les nouvelles sauvegardes à partir de sauvegardes existantes, il peut y avoir des écrasements de certaines parties des fichiers en cours de réplication lorsqu’elles sont utilisées comme fichier de base pour la synthèse de nouvelles images de sauvegarde. Cela crée une confusion pour la réplication de recettes lorsque l’unité de stockage VEEAM est également configurée pour être utilisée dans le cadre de la réplication de structure MTree, ce qui peut entraîner un fonctionnement inattendu du DD cible.
Notez que ce défaut s’applique uniquement à l’extrémité de destination pour la réplication de structure MTree lorsque la source est :
- Exécution de DDOS 6.0.1.0 ou version antérieure (par exemple, tous les DDOS 6.0.0.x sont concernés)
- Exécution de DDOS 6.x antérieur à DDOS 6.0.2.0 ou 6.1.1.1
- Exécution de sauvegardes VEEAM sur une structure LSU/MTree, et cette même structure MTree est répliquée sur la cible à l’aide de la réplication de structure MTree
- Les sauvegardes BOOST avec les sauvegardes synthétiques virtuelles activées sont effectuées sur le même LSU/MTree
- Lorsque ce défaut se produit, cela peut entraîner l’indisponibilité de la structure MTree de destination répliquée avec plusieurs redémarrages de processus FS. Les personnes qui utilisent cette configuration ou qui envisagent de configurer leurs systèmes de cette manière sont invitées à utiliser la solution de contournement décrite ci-dessous ou à effectuer une mise à niveau vers la version corrigée de DDOS 6.0.2.0 ou 6.1.1.1 (ou toute version ultérieure).
Remarque : il est possible que la même chaîne de fonctionnement inattendu à l’extrémité de destination pour la réplication de structure MTree puisse se produire pour des problèmes autres que celui-ci, car l’erreur indique simplement qu’une somme de contrôle dans le snapshot de réplication de structure MTree ne correspondait pas. Pour toute question concernant le problème décrit ici ou la façon de contourner un problème, veuillez contacter votre fournisseur de support contractuel et référencer ce numéro
d’article de la base de connaissances 491049.
DD Engineering a identifié la cause première des PANIC FS sur le nœud de destination et a validé un correctif dans les versions suivantes :
- DDOS 6.0.2.0 et versions ultérieures
- DDOS 6.1.1.1 et versions ultérieures
Toute personne affectée par ce défaut ou envisage de configurer une configuration similaire est conseillée pour mettre à niveau le DD source vers les versions mentionnées au plus tôt.
Pour ceux qui ne souhaitent pas effectuer la mise à niveau ou ceux qui sont confrontés au problème avant que la version corrigée ne soit disponible, il existe une solution de contournement.
Il consiste à désactiver l’optimisation de la réplication de recettes sur le système DDOS 6.x source.
Cette optimisation n’est présente que dans DDOS 6.x et versions ultérieures. Le seul inconvénient de sa désactivation serait de réduire les vitesses de réplication pour être égales à celles obtenues sur DDOS 5.7.
Avant le déploiement, vous devez d’abord confirmer si cette solution de contournement s’applique à la configuration actuelle :
- Vérifiez si le DD source exécute DDOS 6.x avant la version qui a ce correctif (bug corrigé dans DDOS 6.0.2.0 et 6.1.1.1 et versions ultérieures)
- Assurez-vous que le DD configuré pour les sauvegardes VEEAM est également configuré pour la réplication de structure MTree pour l’objet LSU/MTree en tant que source (la vérification d’un ASUP récent serait le moyen le plus simple de confirmer), par exemple :
CTX: 20 Mode : source Destination : mtree://destination-dd.example.com/data/col1/destination_MTree Activé : oui
Si toutes ces conditions ci-dessus s’appliquent, ce système peut faire l’objet des défauts susmentionnés et entraîner le blocage du système de fichiers de réplication de destination.
Pour appliquer la solution de contournement, vous devez d’abord vous assurer qu’aucune réplication ou sauvegarde BOOST n’est en cours d’exécution, puis modifier les paramètres de registre, ce qui ne nécessite aucun arrêt de service. Avant de commencer ce processus, veuillez lire l’instruction CAUTION située sous la dernière étape de cette procédure.
- Assurez-vous que la réplication DD vers DD est désactivée sur le DD source exécutant DDOS 6.x :
# Réplication désactivez toutes les
- Assurez-vous également qu’il n’y a pas de sauvegardes BOOST en cours ou de boost MFR vers ou depuis le LSU/MTree VEEAM potentiellement incriminé avant d’appliquer le paramètre de registre. Si nécessaire, désactivez temporairement les sauvegardes et la réplication de fichier MFR vers ou depuis ce LSU :
# ddboost file-replication show active all
# ddboost file-replication show stats
- Cette modification du registre nécessite des privilèges de mode SE.
Remarque : Les commandes SE ont été obsolètes dans les versions DDOS 7.7.5.25, 7.10.1.15, 7.13.0.15, 6.2.1.110 et supérieures et sont accessibles uniquement par les employés Dell.
- À partir du mode SE, modifiez le paramètre de registre pour désactiver l’utilisation de la réplication de recettes :
# se sysparam set RECIPE_REPL_ENABLED=FALSE
- Vérifiez que le paramètre système a été correctement défini et s’affiche comme « FALSE » (désactivé)
# sysparam show RECIPE_REPL_ENABLED
Description du nom Remplacement par défaut actuel
------------------- ------------------------------------------------ ------- ------- --------
RECIPE_REPL_ENABLED Activer la réplication de recettes (s’applique à la source uniquement) RPC FAUX VRAI
------------------- ------------------------------------------------ ------- ------- --------
- Vous pouvez maintenant réactiver la réplication DD vers DD et reprendre les sauvegardes BOOST et BOOST MFR vers ou depuis le LSU :
# Réplication activer tout
ATTENTION : Si le traitement de la recette a été désactivé sur un système source Data Domain qui est également configuré en tant qu’extrémité de destination pour la réplication, le ou les systèmes sources de ces contextes devront également effectuer le processus ci-dessus (réplication de recettes désactivée).
En outre, notez qu’une fois la mise à niveau vers une version fixe (DDOS 6.0.2.0 ou 6.1.1.1), le paramètre doit être restauré afin que la réplication de recettes puisse être utilisée, la mise à niveau ne réinitialise pas la clé de registre. Après avoir terminé la mise à niveau, réactivez la réplication de la recette en vous connectant à DD, entrez en mode privilège SE et exécutez :
# réinitialisation sysparam RECIPE_REPL_ENABLED
Si vous n’êtes pas sûr du processus décrit ci-dessus, contactez votre fournisseur de support contractuel et faites référence à cet article
de la base de connaissances 491049 .
Il est toujours possible que les PANIC soient dus à un problème différent et que la solution de contournement appliquée ne fonctionne pas pendant que le fonctionnement inattendu du système de fichiers se poursuit sur le DD de destination.
Dans ce cas, il est recommandé que les DD source et cible soient mis à niveau vers le code sécurisé (versions DDOS mentionnées ci-dessus) et que le ou les contextes de réplication incriminés soient rompus (non configurés), les snapshots existants expirés et le ou les contextes de réplication ajoutés et réin initialisés. Étant donné qu’il s’agit d’un processus potentiellement fastidieux et que plusieurs contextes de réplication peuvent être à l’origine du problème, contactez votre fournisseur de support contractuel et faites référence à ce numéro d’article de la base de connaissances et à toutes les actions effectuées jusqu’à présent pour obtenir de l’aide.