NetWorker : Maintenance et dépannage de la base de données des supports

• Échec du démarrage des services.
• Échec du workflow quotidien de sauvegarde du serveur de protection> du serveur .
• Informations incomplètes ou trompeuses relatives aux savesets ou clients renvoyés par la commande mminfo ou lors de l’interrogation ou de la consultation des savesets dans NetWorker Management Console (NMC) ou l’administration de NetWorker Web User Interface (NWUI).
• Problèmes de sauvegarde, de restauration ou de clonage liés à l’incapacité à localiser les savesets, clients ou volumes.
• Erreurs dans le journal du processus du serveur ou les consoles liées à la base de données des supports :

nsrmmdbd WiSS code assertion error (st_nextrec: rec loop detected)
nsrmmdbd error, ss_clone_ensure_clone_eligibility: assertion, invalid parameters or code segment
nsrmmdbd XCHK ssid:saveset_short_ssid host:saveset_hostname name:saveset_name has a fragment with an invalid volid:saveset_volid
nsrmmdbd NSR warning WiSS code assertion error (ST_readvdir: directory read failed)
nsrmmdbd NSR critical Unexpected error reading long record directory: an invalid slot number
nsrmmdbd NSR warning partial record error, ssid: saveset_short_ssid saveset_long_ssid flags:0x00010101 size:0 files:0 tm:datetime cloneid
nsrmmdbd NSR notice media db must be scavenged
nsrmmdbd NSR critical media db scavenge failed
nsrmmdbd NSR warning Cannot scavenge path_to_mmvolume6 (Permission denied) - recover from backup media
nsrmmdbd NSR warning Cannot scavenge path_to_mmvolume6 (unknown error code) - recover from backup media
nsrmmdbd MDB warning can't fetch save set <saveset ID>
nsrmmdbd MDB warning Unable to fetch child save set <saveset ID> for cover set <saveset ID>

• Perte soudaine de nombreux savesets de la base de données des supports ou augmentation soudaine de l’espace disponible de stockage sur disque.
• Le logiciel ne parvient pas à faire expirer ou à supprimer les savesets, ce qui entraîne une consommation rapide du stockage.

Comme toute base de données, la base de données des supports peut être endommagée à des degrés divers lorsqu’il existe une inférence avec son fonctionnement normal, par exemple. 

• Arrêt inattendu du processus nsrmmdbd (vidage mémoire, plantage du système, redémarrage ou perte d’alimentation).
• Transaction interrompue (interférence des logiciels de sécurité externes ou épuisement de l’espace disque).
• Problème interne logique (bug de code ou conditions non gérées).
• Interférence directe avec les fichiers de la base de données des médias ou les fichiers de saveset sur le stockage géré par NetWorker.

La base de données des supports est mieux protégée contre les dommages en appliquant les pratiques générales suivantes :

• Si possible, utilisez une partition de disque locale distincte pour le dossier nsr/mm, ce qui permet d’éviter des conditions telles que l’épuisement de l’espace disque par d’autres processus. Cette partition doit faire au moins 3 fois la taille de la base de données des médias ; à l’heure actuelle, une grande base de données de médias serait de 10 Go ; Par conséquent, 100 Go devraient suffire pour n’importe quelle installation. 
• Assurez-vous que le workflow de sauvegarde du serveur est exécuté quotidiennement afin que les sauvegardes de la base de données des supports et des ressources critiques de reprise après sinistre (le Bootstrap) soient disponibles en cas de sinistre.
• Vérifiez régulièrement l’emplacement des démarrages à l’aide de la commande mminfo -B .
• N’autorisez jamais un autre NetWorker Server à accéder simultanément aux volumes de stockage du serveur NetWorker, car cela peut entraîner une perte de données.
• Si un logiciel antivirus est installé sur le serveur NetWorker, créez des exclusions pour le répertoire /nsr afin d’empêcher le logiciel antivirus d’analyser, de modifier ou de supprimer les fichiers NetWorker. 
• Évitez de supprimer manuellement des fichiers du stockage NetWorker pour tenter de libérer de l’espace. NetWorker dispose de routines de récupération d’espace qui s’exécutent quotidiennement, et le support doit être contacté si ces tâches sont considérées comme défaillantes.
• En règle générale, pour la planification de zone de données, conservez les données du même type dans les mêmes pools pour faciliter la maintenance en cas de besoin, comme les savesets vProxy, les savesets de système de fichiers et les savesets de base de données Oracle dans des pools distincts.
• N’ignorez pas les messages liés aux erreurs de la base de données des supports. Contactez le support en cas d’inquiétudes.

Tenez compte de la relation entre la base de données des supports et le stockage de NetWorker, et protégez les volumes à l’aide de l’indicateur Scan Needed : 

• NetWorker exécute le processus d’expiration quotidiennement dans le cadre du workflow de sauvegarde du serveur. Cette tâche calcule les rétentions et les dépendances, puis fait expirer les savesets qui ont dépassé leur période de rétention et qui n’ont pas de dépendants non expirés. Une fois cette opération terminée, NetWorker tente de supprimer tous les savesets de volume de disque arrivés à expiration. Ensuite, l’opération de récupération d’espace s’exécute pour chaque volume, en supprimant les fichiers de saveset des supports de disque qui ne disposent pas d’entrées correspondantes dans la base de données des médias. Cela signifie que si la base de données des supports est corrompue ou si vous restaurez la base de données à un point antérieur dans le temps, les données valides peuvent être supprimées.
• Si vous pensez qu’il y a un problème avec des volumes de disque, pour vous assurer que les données valides ne sont pas supprimées, assurez-vous que le volume est démonté et marqué comme Analyse nécessaire. Cela s’applique également aux volumes après une restauration à un point antérieur dans le temps (où des savesets valides peuvent exister sur le disque créé après le point de restauration, et n’ont donc aucune entrée dans la base de données restaurée). 
• Scan Needed permet la sauvegarde, la restauration et/ou le clonage normaux, mais empêche l’expiration ou la suppression normale. Par conséquent, assurez-vous qu’il est utilisé uniquement pour protéger les volumes perçus comme étant en danger et supprimé lors du retour aux opérations normales. Les volumes doivent être démontés pour pouvoir définir ou supprimer cette balise. Il est courant que les volumes soient marqués comme « scan needed » après la reprise après sinistre du NetWorker Server (nsrdr), afin d’éviter toute perte de données indésirable dans un scénario de reprise après sinistre.

Il existe plusieurs façons de vérifier et de corriger les problèmes liés à la base de données des supports. Avant de tenter l’une de ces procédures, afin d’évaluer les impacts, créez des rapports avant et après pour voir si les savesets, volumes, clients ou autres ont été supprimés.
Sur la ligne de commande, dans un répertoire vers les sorties hôtes, exécutez les commandes suivantes pour comparer les propriétés de la base de données des médias avant et après la procédure :

• mminfo -C mminfo-C_pre.mmi
• mminfo -X mminfo-X_pre.mmi
• mminfo -ar « volid,type,location,pool,volume,state,volflags,written,savesets » -q family=disk -xc, > mminfo-vol_pre.mmi

Une fois la maintenance terminée, réexécutez-les dans un fichier distinct (par exemple *_post.mmi) et comparez les valeurs.

nsrim - Protection quotidienne des serveurs

Le workflow de sauvegarde du serveur de protection > du serveur s’exécute chaque jour, et avec lui l’action d’expiration. L’action Expiration exécute nsrim, qui est l’utilitaire de maintenance natif de NetWorker. Cette opération peut également être exécutée directement, mais peut prendre de quelques minutes à plusieurs heures, en fonction de la charge du serveur et de la taille de la base de données des médias :
À moins que ce processus ne s’exécute quotidiennement, il est peu probable que cela change quoi que ce soit. Vérifiez le journal du processus pour l’achèvement quotidien de nsrim .

Redémarrage du service

Le redémarrage des services NetWorker force diverses vérifications de démarrage qui peuvent révéler des problèmes dans les messages d’erreur du journal des processus, et éventuellement les corriger. Avant d’interrompre les services, si des problèmes de base de données semblent graves, assurez-vous qu’il y a suffisamment d’espace libre disponible et que les emplacements des données d’amorçage sont connus (mminfo -B output). Idéalement, exécutez d’abord nsrmmdbasm -s nsr/mm/mmvolrel_path > mm.xdr pour tenter d’extraire une copie de la base de données des supports actuelle. Avant de redémarrer les services, créez une copie du dossier mmvolrel, car il peut être nécessaire ultérieurement à des fins d’analyse ou de récupération.

Exportation et réimportation de la base de données des supports

Ce processus évite une reprise après sinistre complète en extrayant uniquement les enregistrements viables de la base de données des médias et en les réimportant vers le serveur sans arrêter les services. Toutefois, cette opération ne doit être effectuée que lorsque le serveur est inactif et ne doit jamais être tentée lorsque des tâches sont en cours d’exécution. Utilisez le chemin complet à la place de mmvolrel (qui peut varier en fonction de l’installation ou du système d’exploitation)

1. Avant de commencer, marquez tous les volumes de disque comme Analyse nécessaire après le démontage. Si la gestion automatique des médias est définie pour les périphériques hébergeant des volumes de disque, vous devez d’abord désactiver cette option. Les volumes de bande n’ont pas besoin de cette étape. 
2. Exécutez les commandes mminfo décrites dans le préambule pour préparer vos rapports préliminaires.
3. Vérifiez la taille du dossier et de l’enregistrement mmvolrel de la base de données des supports
4. Assurez-vous qu’aucun des processus nsrck, nsrim, nsrmmdbasm n’esten cours d’exécution ; S’il existe des fichiers volumineux, anciens ou qui n’ont pas été récemment modifiés dans le dossier parent MM, tels que mm[alphanumerics], déplacez-les ou supprimez-les s’ils ne sont verrouillés par aucun processus.
5. Exécutez la commande pour extraire la base de données des supports : nsrmmdbasm -s mmvolrel > mm.xdr
6. Comparez la taille du nouveau fichier à la taille du dossier mmvolrel - si elle doit être de taille similaire. S’il est minuscule (4 octets ou quelques Ko), la commande a échoué. S’il est beaucoup plus petit, des enregistrements corrompus ont peut-être été supprimés dans le cadre du processus.
7. Préparez le serveur à restaurer sa base de données des supports en définissant le champ d’état du serveur sur la reprise après sinistre dans NMC/NWUI ou à l’aide de nwadmin.
8. Effectuez une restauration directement à partir de la base de données des médias Extrayez le fichier à l’aide de la commande nsrmmdbasm : nsrmmdbasm -r -2 < mm.xdr
9. Une fois l’opération terminée, exécutez la même commande mminfo que celle décrite dans le préambule et comparez les valeurs écrites et celles du saveset par volume, en vous assurant que tous les volumes sont présents. De même, les valeurs mminfo -C doivent être identiques.
10. En cas de disparités, prenez-en note et réfléchissez attentivement à la procédure à suivre, puis contactez le support si vous n’êtes pas sûr des résultats que vous voyez :
    • Pour les volumes qui semblent sains, vous pouvez supprimer la balise Scan Needed et monter les volumes, car il ne devrait y avoir aucun risque de suppression de saveset si aucun saveset ne semble avoir été supprimé du volume si les savesets et les valeurs écrites sont cohérents. 
    • Les volumes qui affichent moins de savesets ou un total d’écritures inférieur doivent laisser l’indicateur Scan Needed en place et exécuter scanneur : scanner -i devicename pour réintroduire les fichiers trouvés sur le volume qui n’ont plus d’enregistrements. Une fois l’analyse terminée pour chaque volume, vérifiez à nouveau le nombre de savesets et supprimez l’indicateur Scan Needed. Remontez le volume une fois que vous êtes sûr que le scanner a remplacé les savesets censés être manquants.

nsrdr

La reprise après sinistre complète effectuée par nsrdr restaure non seulement la base de données des supports, mais également d’autres éléments du serveur tels que la base de données des ressources et la base de données des tâches. Consultez le Guide des bonnes pratiques de disponibilité et de reprise après sinistre du serveur correspondant à votre version avant d’essayer de poursuivre.
Cette commande s’attend à ce que les nœuds de stockage soient en ligne et joignables afin de terminer.