annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 
cancel
Annonces
Webinar IPV6 et Multicast Octobre
79
Visites
0
Compliment
9
Réponses
Translator
Community Manager

Sauvegardes CUCM non terminées - bloqué à l’étape finale « Copie du fichier TAR de sauvegarde sur un support d’archivage »

Salut, j’ai la configuration suivante

CUCM PUB + SUB Version du système: 11.5.1.15900-18

Chaque fois qu’une sauvegarde est tentée (qu’elle soit planifiée ou manuelle), lorsque tous les composants sont sauvegardés et que chacun d’entre eux affiche « 100% SUCCESS », le processus reste bloqué dans CUCM PUB avec ce message de progression: « Copie du fichier TAR de sauvegarde sur un support d’archivage »

Les traces des services DRF Master & Local recueillies via RTMT n’ont montré aucun message d’erreur clair pouvant être potentiellement lié.

Le processus de sauvegarde continue de rester bloqué à sa dernière étape avec ce message de progression: « Copie du fichier TAR de sauvegarde sur un support d’archivage » à l’infini, jusqu’à ce que nous redémarrions manuellement les services DRF.

Ce que j’ai fait jusqu’à présent sans aucun résultat positif:

- redémarrage du service Tomcat sur les deux nœuds

- redémarrage du service DRF Master + service local DRF sur CUCM PUB

- redémarrage du service local DRF sur CUCM SUB

- vérifié aucun certificat ipsec & tomcat / trust expiré sur CUCM PUB & SUB

- supprimé les anciens fichiers de sauvegarde du serveur SFTP

- essayé un autre serveur de destination et un autre emplacement de sauvegarde différents - mêmes résultats

- essayé deux applications logicielles SFTP différentes: freeFTPd & WinSCP - mêmes résultats (aucun délai d’expiration de connexion configuré sur aucune d’entre elles)

- dbreplication vérifiée entre CUCM PUB & SUB - tout bon

Quelqu’un a-t-il une idée de la façon de résoudre ce problème?

Merci

1 SOLUTION APPROUVÉE

Solutions approuvées
Translator
Community Manager

Salut à tous, j’ai fini par ouvrir le cas TAC.

Le problème était que je frappais le bogue CSCuu46430 lié au processus DRF créant des journaux sans les purger, ne se terminant pas correctement.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuu46430/?rfs=iqvred

Le fait est que la seule façon de supprimer manuellement ces journaux est d’avoir un accès root au système d’exploitation CUCM, donc TAC doit être impliqué - aucune chance de le faire par vous-même.

J’espère que cette information sera précieuse pour quelqu’un un jour.

Merci à tous pour votre aide !!!

Voir la solution dans l'envoi d'origine

9 RÉPONSES 9
Translator
Community Manager

Pouvez-vous essayer différentes applications SFTP et voir le comportement ?

Salut Nithin, merci pour votre réponse,

Oui, j’ai déjà essayé freeFTPd & WinSCP avec le même résultat.

Un autre conseil ?

Merci

Freeftpd n’est pas recommandé et il a de nombreux problèmes connus.

Essayez un autre serveur SFTP.

Existe-t-il un pare-feu entre la cible de sauvegarde et CUCM ?

Salut Nithin,

Freeftpd n’a été utilisé qu’à des fins de test et le comportement était exactement le même qu’auparavant avec le serveur WinSCP principal déjà en place.

Il n’y a pas de pare-feu entre les serveurs de sauvegarde essayés jusqu’à présent et les serveurs CUCM. Aucune erreur de connexion repérée sur les journaux.

IMHO DRF Master ou le service d’agent local dans le PUB se suspend juste au moment où la sauvegarde est terminée et je ne peux pas savoir pourquoi.

Il y a un bug pour exactement le même problème que nous sommes confrontés, mais nous avons essayé plusieurs fois la solution de contournement suggérée sans résultat: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsq50512

merci

Cet ID de bogue est lié à une ancienne version.

Je suggère de communiquer avec l’ATC.

Translator
Community Manager

Modifiez le répertoire de chemin d’accès et vérifiez.

Pls rate si c’est « Utile ». Si cela a répondu à votre question, veuillez cliquer sur « Accepter comme solution ».

Je l’ai déjà fait en essayant avec deux serveurs cibles et emplacements différents
avec des chemins différents, aucun résultat
Translator
Community Manager

DRS est plutôt pointilleux sur les chiffrements et les algorithmes d’échange de clés. Tout ce qui a une sshd_config peut généralement être fait fonctionner en ajoutant ces commandes.

KexAlgorithms +diffie-hellman-group1-sha1
KexAlgorithms +diffie-hellman-group-exchange-sha1

Chiffrements +aes128-cbc
Chiffrements +3des-cbc

Certains serveurs plus récents n’aiment pas le chiffrement 3des, vous devrez donc peut-être le laisser tomber si votre serveur ssh groks dessus. Un certain nombre de versions plus récentes de Windows vous permettent d’ajouter « Serveur OpenSSH » en tant que composant facultatif, et j’ai réussi à l’utiliser comme cible DRS. J’ai également eu du succès en utilisant le composant serveur OpenSSH de Cygwin.

Translator
Community Manager

Salut à tous, j’ai fini par ouvrir le cas TAC.

Le problème était que je frappais le bogue CSCuu46430 lié au processus DRF créant des journaux sans les purger, ne se terminant pas correctement.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuu46430/?rfs=iqvred

Le fait est que la seule façon de supprimer manuellement ces journaux est d’avoir un accès root au système d’exploitation CUCM, donc TAC doit être impliqué - aucune chance de le faire par vous-même.

J’espère que cette information sera précieuse pour quelqu’un un jour.

Merci à tous pour votre aide !!!

Voir la solution dans l'envoi d'origine