03-06-2009 10:06 AM - edited 03-14-2019 03:46 AM
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 "\\129.207.7.10\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 "\\129.207.7.10\VOIP_BACKUP$\UCCX\Backup03-06-09#12-02.tar" \\STI\\Backup
at com.cisco.archive.impl.BackupArchiveImpl.waitForArchiveResult(BackupArchiveImpl.java:494)
at com.cisco.archive.impl.BackupArchiveImpl.processArchive(BackupArchiveImpl.java:412)
at com.cisco.archive.impl.ArchiveImpl$3.run(ArchiveImpl.java:382)
at com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.runCommand(ExecutorStubImpl.java:690)
at com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.run(ExecutorStubImpl.java:486)
at com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.run(ExecutorStubImpl.java:762)
at com.cisco.executor.impl.ThreadStubImpl$RequestImpl.run(ThreadStubImpl.java:563)
at com.cisco.util.ThreadPoolFactory$ThreadImpl.run(ThreadPoolFactory.java:853)
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.
02-11-2010 10:18 AM
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.
02-11-2010 10:25 AM
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.
05-16-2010 05:09 PM
Hi Guys,
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?
Andy
05-17-2010 09:39 AM
Hi
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.
Aaron
05-17-2010 03:10 PM
mapping share drive with IP address has no problem. I can create file at the backup location as well.
Andy
05-19-2010 12:18 PM
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
08-20-2010 04:53 PM
Hello all,
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.
08-24-2010 04:49 AM
Hi Everyone,
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
http://www.cisco.com/en/US/products/sw/custcosw/ps1846/products_tech_note09186a0080ab4b8e.shtml
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.
Regards,
Joe
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide