Ce document décrit une raison pour laquelle le serveur de Cisco Customer Response Solutions (CRS) (3.x et plus tôt) échoue sauvegarde et fournit une solution dans un environnement exprès de Cisco IP Contact Center (IPCC).
Remarque: Pour dépanner le problème lié de sauvegarde au Cisco Unified Contact Center Express 7.x, référez-vous à la question de sauvegarder d'Unified Contact Center Express.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Cisco CallManager
Cisco CRS
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
Version 3.3(3) et antérieures de Cisco CallManager
Version 3.x et antérieures de Cisco CRS
Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Bien que n'importe quel serveur dans la batterie de Cisco CallManager puisse être le serveur de sauvegarde, l'il est recommandé que le serveur de base de données de Publisher soit le serveur de sauvegarde. Un serveur de sauvegarde est prié dans une batterie de Cisco CallManager.
Un serveur de point d'émission de données (ou la cible de sauvegarde) contient les données à sauvegarder pour le Cisco CallManager ou le Cisco Customer Response Solutions (CRS). Une batterie de Cisco CallManager peut contenir zéro, un ou plusieurs serveurs de point d'émission de données. Vous indiquez un serveur en tant que serveur de point d'émission de données (cible de sauvegarde). Le fichier de consignation de journal de sauvegarde, stiBackup.log, se trouve dans le répertoire suivant : Fichiers de C:\Program Files\Common \ Cisco \ logs.
La figure 1 explique la topologie. Le serveur de sauvegarde est le CallManager et la cible de sauvegarde est un serveur CRS.
Figure 1 — Une configuration simple - Serveur de sauvegarde (CallManager) et cible de sauvegarde (CRS)
Tandis que vous sauvegardez le serveur CRS, le service de sauvegarde STI échoue avec l'échec de connexion pour l'utilisateur ou l'erreur fatale - base de données de l'erreur lors de la recherche de SQL, car la figure 2 affiche.
Figure 2 — Erreur fatale - Base de données de l'erreur lors de la recherche de SQL
Afin de prendre en charge la sauvegarde, le service de sauvegarde STI doit être installé sur le serveur de sauvegarde et la cible. L'installation crée automatiquement le compte de BackAdmin. Ce supports de compte le service de sauvegarde sur un Cisco CallManager. Vous devez utiliser le même mot de passe pour ce compte sur le serveur de sauvegarde et la cible. Sans ces compte et mot de passe sur le serveur de sauvegarde et la cible, la sauvegarde échoue.
Quand ce problème se pose, le serveur CRS (sauvegarde) ne fait pas installer le service de sauvegarde STI. Afin de résoudre ce problème, installer le service de sauvegarde STI sur la cible de sauvegarde (CRS) et générer le même mot de passe pour le compte de BackAdmin que le mot de passe utilisé pour le compte de BackAdmin sur le CallManager.
La sauvegarde manuelle échoue à 98% avec le message d'erreur d'Archive_CREATION_ERROR.
Cette erreur se produit parce que le serveur CRS ne pouvait pas accéder à l'emplacement de sauvegarde et écrire le fichier de .tar dans le répertoire de sauvegarde. Changez l'emplacement de mémoire au serveur local afin de résoudre ce problème.