I'm having a problem running a backup of UCCX, when attempting to run a backup at 98% this following error occurs:
ArchivingFailureEvent id=870, archiveId=CRS_1236362486731_, errorCode=ARCHIVE_CREATION_ERROR, statusMessage=tar failed with error code: 2, cmd: Tar.exe -c --atime-preserve -f "\\18.104.22.168\VOIP_BACKUP$\UCCX\Backup03-06-09#12-02.tar" \\STI\\Backup, refer to the MCVD logfiles for more details
com.cisco.archive.impl.ArchiveFailureException: ArchivingFailureEvent id=870, archiveId=CRS_1236362486731_, errorCode=ARCHIVE_CREATION_ERROR, statusMessage=tar failed with error code: 2, cmd: Tar.exe -c --atime-preserve -f "\\22.214.171.124\VOIP_BACKUP$\UCCX\Backup03-06-09#12-02.tar" \\STI\\Backup
Checked the JTapi version are consistent, cleared JAVA cache on the server & temp files. Checked file permissions on UNC share. Unable to find immediate resolution.
Looks like permissions to me! I know you said you'd checked, but have you actually tested it?
Try binding to the share as the user configured for the backup:
net use /d \\126.96.36.199\voip_backup$
net use \\188.8.131.52\voip_backup% /user:domain/username
Then enter the password when prompted.
Browse to the share
And create a file in the UCCX folder
It's failing after the backup has completed, and it just tries to dump everything already backed up to the remote location.
It may be the share permissions if you've checked the NTFS perms - by default new shares are read-only.
Please rate helpful posts...
You shouldn't make any changes to the Java version running on the CCX server. When you upgrade the OS or CCX software, Java will be upgraded for you. Changing it yourself will mean you are running a version of CCX and Java that possibly haven't been tested together.
Try the steps I posted.
Please rate helpful posts...
Just as an FYI i did have to change me java version. it "somehow" never upgraded when we patched it. but that why included the matrix from tac on Java ver.
try to take backup on the local directory and see if that completes.
make the backup storage location on the drive and then test with server admin credentials.
New install and I was able to do one backup on Tuesday night. Attempted to do a backup on Wed night and got this error. One .tar file is in the remote location folder...I have moved it out and attempted to run again and got the same error. Previous poster said to try to a local drive...there is no tape backup attached..is it possible to do the backup to a local folder?
Yes try the backup on a local directory, just make sure you have enough drive space!!
Also try deleting the contents of the C:\STI folder on the server. If you log a ticket with TAC they will clear the archive flags using the CET tool.
Can you explain how I can do a local backup. When I try to do c:\ in the network
location I get an error that it has to start with \\ ..
Backup locally works fine..remote location does not work..I can attach to the remote location. The Storage Location updates properly.
Assuming remote location is a windows box, you need to have the folder shared with correct permissions. Simple step is to verify if IPCC server can create files on the remote shared folder.
1. Say x.x.x.x is the remote location ip address
2. go to to the remote location and create a folder named ipccbackup under c drive.
3.right click and click properties.
4. Under sharing, select share this folder.
5. click permissions and set full control for user "Everyone", click apply and ok.
6. click ok.
7. come back to the ipcc server.
8. open run and type \\x.x.x.x\c$\ipccbackup
9.once the folder window opens, right click and create a new text document.
10. if it creates fine, shring and permissions are all set.
11. Set the new location \\x.x.x.x\c$\ipccbackup in the ipcc backup location.
12. try backup again and see if it works.
13. if it works, you have to remove user "Everyone" with full control and set the user account you want to try with full control priveleges.
hope this helps.
In my system we record every single call which makes my backup files around 50 GB each. I was having trouble getting the backup to complete when set to a remote storage location but it works fine backing up to the local drive. I ended up backing up locally and then wrote a batch file which runs every night and moves the backup files over to the remote storage location then deletes the local file to keep the local drive from filling up. Works great, but should be a last resort option.
My customer is having the same problem with UCCX 7.0(1)_Build168. Is this a Bug? he has setup a backup account with proper right, he can map the drive from the UCCX server and is able to create file?
Any one can shed some light?
I've recently seen issues where the share in question is part of a cluster based on Windows 2k8; maybe check that that isn't the case here?
It seems to be that the UCCX software resolves the name of the server to an IP, and then connects to the server at \\ipaddress\share ; as the share is linked to the hostname rather than an IP this second bit fails. See if you can map a drive to \\ip\share after pinging the hostname, if not this might be the same problem.
That sounds like a bug. I had the same problem on SR05. TAC sent me an ES patch which resolved the issue.
Open a TAC case and reference bug ID: CSCsl87631
I was having the same problem. However, I just had success and the idea came from reading some of the ideas in this thread...so thank you.
Hope it's that easy for the rest of you.
Their is a known bug when using the manual backup twice CSCsy04635 Backup fails with ARCHIVE_CREATION_ERROR. When this occurrs you more than likely will have to clear the locks from using the CET tool at the server - see the following technote
or restart the CCX engine/node manager if no locks are present.
One thing to keep in mind is the path of the destionation folder, actually use the full path, meaning the drive letter with $. The backup to a destionation folder can be picky and sometimes fails when this is not configured, i.e. \\destination server IP\C$\backup. In some cases if you are running low on disk space at the UCCX server the backup will not complete, you should have at least 22GB available for staging the backup as it can fail for this reason.
If those of you are recording all calls (which it is not intended for this purpose nor supported) you may see issues with this as well, try deleting the recordings.
As a good test to verify if it is a application issue or destination folder issue try backing up to the local directory, the path would be the same as above
\\destination server IP\C$\backup.