cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2024
Views
10
Helpful
6
Replies

CUCM 12.5.1 DRS backup failure at TCT component

Bob Fitzgerald
Level 4
Level 4

Hello all!

Our customer is having an issue where the CUCM backup is failing when it gets to the TCT component on their second Sub.  The backups are scheduled locally on the CUCM, and saved to their PCD as the SFTP.  There is enough space on the PCD for the backups.  Manual backups fail as well.  The backup just stalls at the TCT component on the second Sub every time.

-  I verified with them that the Trace Collection Service settings were at Default.

- I have had them download the Trace Collection Service logs from the second Sub and delete them after download.  No change in issue.

- I have had them restart the Trace Collection Service and Trace Collection Servlet on the second Sub.  No change in issue.

- They will be rebooting the server tonight.

 

When they click on the step that failed it says "Unable to read log file".  Not sure what else I can have them try if the server reboot doesn't have any effect.  Any guidance would be greatly appreciated.

Thanks!

1 Accepted Solution

Accepted Solutions

Hi all,

 

Thank you for the helpful suggestions.  Ultimately it was disk space issue apparently.  Not on the PCD, which is something I had them check initially.  When they connected to the Sub upon which the backup was failing via SSH and got status through the CLI they saw a write error stating the system was out of disk space.  I guess 8GB is too small for backing things up even when the backup is stored somewhere else?  They added space to the VM, rebooted and ran the backup again.  Backup successful this time.

 

Thanks again!

View solution in original post

6 Replies 6

I doubt that PCD SFTP service is intended for DRS backups. Have you tried with any other SFTP server software? For example Solar Winds SFTP, it’s a free app you can download and install on a Windows server.



Response Signature


PCD is intended  to use for DRS backups. Logs file gives  more information but in your case its  "Unable to read log file". @Roger Kallberg mentioned you can try a different sftp and see it it works.

 

Below document describes how to use Prime Collaboration Deployment (PCD) as a Secure File Transfer Protocol (SFTP) server in order to provide a remote server option for tasks such as upgrades, backups and restores.

https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/prime-collaboration/215541-use-prime-collaboration-deployment-as-a.html

 

 

 



Response Signature


Well I learned something new today. Thanks @Nithin Eluvathingal 



Response Signature


Ratheesh Kumar
VIP Alumni
VIP Alumni

Hi there

 

Maybe you could be hitting a bug, in the other way. CUCM 12.5 has issues while restoring the TCT components with HCS. I guess opening a TAC will be your best bet.

 

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvw28754

 

Symptom:
DRS restore fails on HCM-F 12.5.x versions for Platform and TCT components. The restore fails with below errors -
Traceback (most recent call last):
File "/common/drf/scripts/platform/platform_do_restore.py", line 17, in
import dbllib
ImportError: No module named dbllib

 

Hope this Helps

Cheers
Rath!

***Please rate helpful posts and if applicable mark "Accept as a Solution"***

 

 

 

 

Tested your scenario on my lab using CUCM  version 12.5.1SU3 and  PCD 12.5.1 and both publisher and subscriber backup worked. 

 

The Bug id @Ratheesh Kumar mentioned is for restore Scenario and for HCS.Since your back fails only on subscriber, is there a firewall between subscriber and publisher ? Have you checked the DB, is it authenticated properly and all tables are  synced ?what's you PCD version ?

 

If  you feel everything okay at your end  contact TAC. 



Response Signature


Hi all,

 

Thank you for the helpful suggestions.  Ultimately it was disk space issue apparently.  Not on the PCD, which is something I had them check initially.  When they connected to the Sub upon which the backup was failing via SSH and got status through the CLI they saw a write error stating the system was out of disk space.  I guess 8GB is too small for backing things up even when the backup is stored somewhere else?  They added space to the VM, rebooted and ran the backup again.  Backup successful this time.

 

Thanks again!