[cisco-voip] storing CDRs during SFTP outage (total time/space available) MCS vs VMWare

[Eric Pedersen]

My experience is that it will be fine as long as CUCM doesn't start deleting the CDR files off its disk. When I run "file list activelog /cm/cdr_repository/processed" it looks like it's keeping 30 days. We had our sftp server down for a while and CUCM picked up from where it left off when it became reachable again.

You could always set up a second repository then shut it off for a few days and see what happens when you turn it back on.

Eric

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Lelio Fulgenzi
Sent: 07 February 2013 3:04 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] storing CDRs during SFTP outage (total time/space available) MCS vs VMWare


Trying to figure out the amount of time I can go without an SFTP target with respect to CDRs. Currently our server team is not on-call for the server and I have to justify it if I want them on-call. My concern is not really the 5:01PM to 9:01AM issue, 16 hours we can deal with (unless of course, we need a restore done!), but what I am concerned is the 5:01PM on a Friday to a 9:01AM on a Tuesday of a long weekend. Not sure my system can handle holding on to 3 1/2 days of CDRs. This worry gets more so when you think about VMWare installations which I believe have smaller disk drive allocations.

Currently, a data sample for Friday 5PM to Tuesday 1PM is about 3,000 files and 40MB or so. (I chose to do 1 file every 5 minutes)

I'm thinking I should be OK. Are there any things I should look out for? Is this a BAD idea?

Lelio


---
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Cooking with unix is easy. You just sed it and forget it.
                              - LFJ (with apologies to Mr. Popeil)


The contents of this message may contain confidential and/or privileged
subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130207/41adc5b8/attachment.html>