CUCM disaster recovery problems

[Josh Howard]

We had a power outage issue and afterwards our cucm server wouldn't reboot.  So we ran the recovery disk and it booted back up and all seems to be functioning perfectly except the backups have stopped working.  The weekly backup on Friday didn't work anymore.  So we started over.  Downloaded and installed the newest version of FreeFTPd.  When we try to add new backup device it fails everytime.  Below is the log from Freeftpd...

03-13-2013 12:18:13 IP 172.21.224.50 SFTP connection attempt

03-13-2013 12:18:18 IP 172.21.224.50 SFTP BBGAdmin connected

03-13-2013 12:18:22 IP 172.21.224.50 SFTP BBGAdmin is changing dir to / (F:\CUCM Backups\BBGAdmin\)

03-13-2013 12:18:27 IP 172.21.224.50 SFTP BBGAdmin is listing / (F:\CUCM Backups\BBGAdmin\dUmmI_Drf)

03-13-2013 12:18:31 IP 172.21.224.50 SFTP BBGAdmin disconnected

03-13-2013 12:18:13 IP 172.21.224.50 SFTP connection attempt

03-13-2013 12:18:18 IP 172.21.224.50 SFTP BBGAdmin connected

03-13-2013 12:18:22 IP 172.21.224.50 SFTP BBGAdmin is changing dir to / (F:\CUCM Backups\BBGAdmin\)

03-13-2013 12:18:27 IP 172.21.224.50 SFTP BBGAdmin is listing / (F:\CUCM Backups\BBGAdmin\dUmmI_Drf)

03-13-2013 12:18:31 IP 172.21.224.50 SFTP BBGAdmin disconnected

I tried two different user names just to make sure.  Has anyone ran across this problem before?  What could have happened on the cucm server after the recovery disc was used that could have caused this.  Look forward to answering any questions I can and appreciate any and all advice you may provide me.

Thanks,
Josh

[Rob Huffman]

Hi Josh,

What is the exact CUCM version?

Cheers!

Rob

"Hours are like diamonds, don't let them waste
Time waits for no one, no favors has he" 

- Stones

[Josh Howard]

7.1.5.31900-3

Thanks

[Rob Huffman]

Hi Josh,

I thought it might be a bug, but I cannot identify any. Sorry

my friend.

Any error on the DRS page itself? DRF master/local re-started?

Cheers!

Rob

"Hours are like diamonds, don't let them waste
Time waits for no one, no favors has he" 

- Stones

[Josh Howard]

Rob,

The error that I get when trying to add the backup device is...

"Update failed : Unable to access SFTP server or SFTP server too slow to respond.Please make sure the login credentials and path are correct."

I have restarted both the DRF master/local services and it still hasn't worked.

Thanks,
Josh

[yahsiel2004]

Josh,
Have you verified the directory that the sftp user is trying to access?

Regards,

Yosh

[Josh Howard]

Yosh,

I have used WinSCP to test Freeftpd with.  The login information works and can write and delete from the directory we use for backups.  So the freeftpd is working, just not with the cucm server currently.

Thanks,

Josh

[Aaron Harrison]

Hi Josh

Have you pulled the DRF logs from the CUCM server? You can see the connection on the SFTP side works OK, so you need too see what failure occurs at the client end.

Aaron

[Josh Howard]

Aaron,

I will work on getting the logs next. 

Another update so far if this helps anyone, is I can manual connect and copy files using "file get tftp Ringlist.xml", entered in all the usual information that I would use to setup the backup device and it works.  Unfortunately I still can't add a backup device.

I'll get those logs next as soon as I can.

Thanks for your post,

Josh

[Josh Howard]

Aaron,

I've added the log to my attachments.

Thanks,

Josh

[Josh Howard]

I've also setup Core FTP on a different computer and tested it. I get the same results. I can transfer using winscp as a client off one server. I can use the "file get tftp" command from the cisco server to transfer files and it works. I simply can't get a backup device added. I'm curious what /common/drf/dUmmI_Drf is. That seems to be where the error occurs in the log.

[Jean-Christophe Majchrzak]

I've experienced DRS problems with the latest 1.0.12 version of FreeFTPd. Not like yours, but it fails on TFTP backup with the same kind of message "server too slow to respond".

Using FreeFTPd Version 1.0.11 works perfectly.

JC.

[Josh Howard]

Thought I would report our solution.  I went thru the whole TAC process and after alot of work they had to remotely connect and check the database.  It was corrupt and I believe it was /common/drf was no longer there.  They said we'd have to rebuild the server.  That didn't sound to fun so what we actually did was upgrade to version 8 and it rebuilt that directory during the upgrade.  Problem solved.