When I run a backup and include the messages, the backup fails. Withouth selecting messages (database, etc.) the backup completes no problem. I've got a TAC case open now, but I've spent the last few days with him trying to install different SFTP servers on a windows box to get this to work (he feels it's a problem with my SFTP server) -- but all my other stuff backs up fine (CUCM, etc.)
Does anyone have a recommendation for a windows SFTP client or any ideas why my messages backup keeps failing? The size is large -- seems to fail at 1GB or 3.4GB --
Speaking from the UC side... I would suggest providing the DRS traces to TAC. Perform your backup with messages, note the time then from CLI gather the following directories:
file get activelog platform/drf/log
file get activelog platform/drf/trace
If you have timestamps of when things fail, those logs may help you understand what may be going on. Also, getting a network capture from the CLI of UC may be a good idea as well.
utils network capture file
Ctrl-c will stop the capture. You can collect the capture from RTMT
Hope that helps,
So, I have 2 thoughts for you. The first is that you may be starting outgrow a single mailstore. The DB is presized for 40 messages per user for up to 10,000 users or about 1.25GB. When companies start to set up multiple mailstores, there are some backup considerations. Primarily, DRS has to be able to backup an entire mailstore and cluster data in one session. In some cases, folks will create multiple mailstores and do multiple backups - 1 per mailstore. You may or may not be in this boat but it's worth discussing with TAC for sure.
Secondly, a recommendation on SFTP server - solid, no issues, recommend it to every client - CopSSH.
Please rate helpful posts!
Did anyone find a resolution to this problem. I'm running UC 7.1.2 and am running into the same issue. I'm using freeftpd and there are no problems with my other backups (CUCM, ER) using DRS.
I have the same issue on the Publisher of a cluster running 7.1(3b)SU2. The subscriber backs up without issue. Only the Publisher has problems and always fails at about 50% of the message store. I have a TAC case open but very little info coming out so far that would be of value. I'll update if I get something solid. If you are running a cluster, give the backup a shot on the Subscriber (if you haven't already) and if that works - at least you'll get the message store backed up as the data is replicated anyway.
Please rate helpful posts!
You just click the number of stars you want to give as a rating - 5 being the highest. Once you vote, you can't change it so give what you feel is applicable. You can rate a single post or every post, it's up to you.
To expand on the topic real quick - go ahead and back up both but do the following:
1) Create a separate backup path for each server on your SFTP server.
2) Backup the Pub to its SFTP path and select everything BUT the message store.
3) Backup the Sub as well to its own SFTP path BUT backup everything (doesn't hurt to have full backup of both even though it's a cluster with DB replication).
4) You'll have to reconfigure the DRS settings to implement the new backup path and such but this should work for you.
5) I set this up on my own prior to opening a TAC case and they validated that this is the best way to go about backing up the system given the issue with the Publisher.
Please rate helpful posts!
Hey everyone - sorry I forgot to update the post. TAC recommended a new FTP/SFTP client.... said it was free, but it wasn't -- still well worth it.
We use Titan FTP Server now -- works great.
The problem was a reliability issue with large file sizes. Our database is huge (big compared to some anyhow -- 12 to 15 GB)
Since changing to Titan we've never had a problem.
That's good in your case but in other cases, this is not the problem however TAC seems pretty tied to it. I always recommend CopSSH which is Open SSHd for Windows. There are no file size issues and all other UC products back up fine. However, I have used Titan for another customer that wasn't comfortable using a free product and they have had good success with it as well. It's not free but it works well.
Thanks for the update.
I'm having the same issue, i'm using CUCM ver 6.1.3, IPCC Enterprise ver 7.2 and Unity ver 8,
CUCM and IPCC both backup ok every night no problems, but Unity fails backing up messages at status 40, it works somrtimes on auto or manual backup but most times it fails, i have tried different physical machines and different sftp software like FreeFTP, CoreFTP and TitanFTP and all suffer from same failures.......
First - are you using UNITY or Unity Connection? I'm assuming Connection since you're on this thread ... but need to confirm. Big difference in backup tools there.
Second - if you are using Unity Connection, is the environment a standalone install or a cluster?
am using unity connection and in a HA cluster.
Using sftpd which was doing fine until my last backup prior to loading all voicemails, same messages part goes up to 40 and throws an error.
Doesn't matter if Pub or Sub, both does the same thing. I'd really like to have a good complete backup at this point, since working a ton of users and config, I won't want to lose.
Also i believe the max size for the db is set to around 15gigs, while I'm around 3gig right now o na single db.
See if you aren't hitting these bugs as well....
DRS defects (Here are the 2 issues with OpenSSH based SFTP servers): CSCtf40892 CCMDB component backup fails when cdr repository is large - Root cause was found to be re-keying after landmark transfer sizes failing between CUCM/CUC maverick client and OpenSSH 4.7 or higher SFTP server. CSCth63717 Unity Connection DRS backups of UnityMbxDb1 fails w/ large mail stores (Similar to the above defect as it a OS platform issue, but with the Maverick client on the system). Fixed in 7.1(5)ES24 and the latest is ES25
I have the exact same problem with Unity Connection, did you manage to resolve this? Would appreciate any guidance in this area. Have just created an addtional message store and was planning to migrate some users into it.