<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.2900.6058" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px">
<DIV> I have two Unity Connection clusters with mail stores around 6 gig and 8 gig. I have tried a lot of SFTP server solutions and so far the most consistent performing solution I have used is Globalscape EFT Server. </DIV>
<DIV> </DIV>
<DIV><A href="http://www.globalscape.com/gsftps/">http://www.globalscape.com/gsftps/</A></DIV>
<DIV> </DIV>
<DIV> It is not free but they are a member of the Cisco Technology Developer Program and have provided good support to us. I can attest to the need for a good current DRS backup. In January we ended up with database corruption on both the Pub and the Sub on one of our clusters and had to restore from a DRS backup. Very painful but at least we were able to restore service to 5000 users. Nothing drives home the need for backups like actually needing one!</DIV>
<DIV> </DIV>
<DIV>Steve</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR>>>> Pat Hayes <pat-cv@wcyv.com> 3/23/2011 9:41 AM >>><BR>To the original question of whether or not you can specify over the<BR>DRS recommended 15 gigs, yes, you can, but why would you want to? DRS<BR>being the only supported method of periodic backups, you are<BR>potentially putting your system at risk by going outside of that.<BR><BR>For problems backing up the mailbox store, I think there are two main<BR>ones - first, the SFTP server you use needs to support file uploads<BR>that large. Check the archives for details on some known problem<BR>servers. You can verify easily enough by trying to manually upload a<BR>large file to your server, if it is going to fail it usually fails<BR>around 1 or 2 gigs. Second, defect CSCtf40892 can cause your backup to<BR>stall out and fail, usually around the 3 gig mark. Check the bug for<BR>full details, but essentially everything 7.x prior to 7.1(5b)su3 and<BR>8.x prior to 8.5(1) is impacted. If you can get past those two issues,<BR>it should be smooth sailing :-)<BR><BR>On Tue, Mar 22, 2011 at 7:49 PM, Bill Simon <bills@psu.edu> wrote:<BR>> All,<BR>><BR>> We have a 10k user base and about 10GB mail store. Backups (DRS) seldom<BR>> worked on CUC 7.1. Just last weekend upgraded to 8.5 and backups are working<BR>> fine for this whole mail store. SFTP backups to a Linux server/OpenSSH.<BR>><BR>> Backups and increased scalability were the reasons we moved to 8.5. If<BR>> you've got a large system, consider moving to this version.<BR>><BR>><BR>> On 3/22/11 7:19 PM, Erick B. wrote:<BR>>><BR>>> Hmm... yea, on the 8.02 I have it always fails at just over a gig on<BR>>> both mailstores> 1 gig. The one mailstore we don't backup the<BR>>> messages in anymore however, just a lot of mailboxes for various<BR>>> sites.<BR>>><BR>>> I've worked with TAC on this in past, and they didn't suggest using<BR>>> more mailstores to help with the backup issue. We had tried a dozen or<BR>>> so different SFTP servers and all failed at a gig most of time, so we<BR>>> ruled out SFTP server as problem. Any mailstore less then a gig backs<BR>>> up fine.<BR>>><BR>>> I'll make some more mailstores to see what the limit is.<BR>>><BR>>> Also, can't move the system mailboxes off the default mailstore.<BR>>><BR>>><BR>>> On Tue, Mar 22, 2011 at 5:49 PM, Jobe Gates<jobe@gates-tribe.com> wrote:<BR>>>><BR>>>> Mine was up to 6GB's so yes it should go over 1. I thought 5 was the<BR>>>> limit on 7.x. Not sure about 8.<BR>>>><BR>>>><BR>>>> Thanks,<BR>>>> Jobe<BR>>>><BR>>>> On Mar 22, 2011, at 6:18 PM, "Erick B."<erickbee@gmail.com> wrote:<BR>>>><BR>>>>> I am having DRS fail at 1 gig, with mailstores over 1 gig in size.<BR>>>>> I've recently split a client into 5 mailstores now to get past the drs<BR>>>>> issue.<BR>>>>><BR>>>>><BR>>>>> this is with unity connection 8.02<BR>>>>><BR>>>>> so drs should be able to do larger then 1 gig? on the ones it fails on<BR>>>>> the drs backup process sits at 40% for awhile then fails....<BR>>>>><BR>>>>> Does anyone know if there is a limit to # of mailstores you can have?<BR>>>>><BR>>>>><BR>>>>> On Tue, Mar 22, 2011 at 3:54 PM, Jobe Gates<jobe@gates-tribe.com><BR>>>>> wrote:<BR>>>>>><BR>>>>>> I've had DRS problems with large stores. This was on 7.1 and there was<BR>>>>>> a known bug if you go over 10GB it would fail.<BR>>>>>><BR>>>>>> Thanks,<BR>>>>>> Jobe<BR>>>>>><BR>>>>>> On Mar 22, 2011, at 4:37 PM, Tanner Ezell<tanner.ezell@gmail.com><BR>>>>>> wrote:<BR>>>>>><BR>>>>>>> Certainly,<BR>>>>>>><BR>>>>>>> If you haven't already check out the design guide for CUC:<BR>>>>>>><BR>>>>>>><BR>>>>>>> <A href="http://www.cisco.com/en/US/docs/voice_ip_comm/connection/8x/design/guide/8xcucdgpdf.pdf">http://www.cisco.com/en/US/docs/voice_ip_comm/connection/8x/design/guide/8xcucdgpdf.pdf</A><BR>>>>>>><BR>>>>>>> Section 6 page 4 includes notes about scalability specifically the 2GB<BR>>>>>>> performance limitation I mentioned.<BR>>>>>>><BR>>>>>>> Regarding mail box size, I cannot speak to that I'm afraid. I have not<BR>>>>>>> been in a deployment that used such a large mail box.<BR>>>>>>><BR>>>>>>> Also, the CUC guide contains specific sections on scaling which will<BR>>>>>>> probably be on use to you.<BR>>>>>>><BR>>>>>>> Tanner<BR>>>>>>><BR>>>>>>> On Tue, Mar 22, 2011 at 1:29 PM, Anthony Holloway<BR>>>>>>> <avholloway+cisco-voip@gmail.com> wrote:<BR>>>>>>>><BR>>>>>>>> Thank you Tanner. This is for a 1,200 user deployment on a pair of<BR>>>>>>>> MCS-7835-I3's, with 300GB HDD space, and 4GB of memory.<BR>>>>>>>> Do you have a source for the 2GB per mailbox comment, or is that<BR>>>>>>>> coming from<BR>>>>>>>> experience?<BR>>>>>>>> Also, can you comment on the 15GB per mailbox store, as it pertains<BR>>>>>>>> to DRS<BR>>>>>>>> backing up at a rate of 3GB/hr?<BR>>>>>>>> Anthony<BR>>>>>>>><BR>>>>>>>> On Tue, Mar 22, 2011 at 3:05 PM, Tanner Ezell<tanner.ezell@gmail.com><BR>>>>>>>> wrote:<BR>>>>>>>>><BR>>>>>>>>> Mailbox sizes above 2GB are not recommend for performance reasons. I<BR>>>>>>>>> don't believe there is a hard limit on mailbox size.<BR>>>>>>>>><BR>>>>>>>>> Depending on how many users you are supporting and the hardware<BR>>>>>>>>> running the platform will really determine the best course of<BR>>>>>>>>> action.<BR>>>>>>>>> Anything less than a 50-100 users I wouldn't worry about, beyond<BR>>>>>>>>> that<BR>>>>>>>>> you need to take performance into consideration.<BR>>>>>>>>><BR>>>>>>>>> On Tue, Mar 22, 2011 at 10:03 AM, Anthony Holloway<BR>>>>>>>>> <avholloway+cisco-voip@gmail.com> wrote:<BR>>>>>>>>>><BR>>>>>>>>>> Unity Gurus,<BR>>>>>>>>>> I am reading up on the what's what with Mailbox Stores in CUC 8x,<BR>>>>>>>>>> and I<BR>>>>>>>>>> have<BR>>>>>>>>>> two questions:<BR>>>>>>>>>> 1. How closely should I stick to the 15GB per mailbox store for DRS<BR>>>>>>>>>> purposes?<BR>>>>>>>>>> 2. Ignoring DRS concerns, how large can a mailbox store be? All of<BR>>>>>>>>>> available<BR>>>>>>>>>> disk space?<BR>>>>>>>>>> In general, can you provide any real world considerations, tips, or<BR>>>>>>>>>> warnings<BR>>>>>>>>>> about going down this path?<BR>>>>>>>>>> Thanks.<BR>><BR>> _______________________________________________<BR>> cisco-voip mailing list<BR>> cisco-voip@puck.nether.net<BR>> <A href="https://puck.nether.net/mailman/listinfo/cisco">https://puck.nether.net/mailman/listinfo/cisco</A>-voip<BR>><BR><BR>_______________________________________________<BR>cisco-voip mailing list<BR>cisco-voip@puck.nether.net<BR><A href="https://puck.nether.net/mailman/listinfo/cisco">https://puck.nether.net/mailman/listinfo/cisco</A>-voip<BR><BR></DIV><font face="monospace">************************************<br>
This email may contain privileged and/or confidential information that is intended solely for the use of the addressee. If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information.<br>
There are risks associated with the use of electronic transmission. The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this transmission.<br>
************************************</font></BODY></HTML>