cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4019
Views
10
Helpful
22
Replies

Problem running backup of UCCX 5.02/Archive error

jlakers72
Level 1
Level 1

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.

22 Replies 22

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.

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

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

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

mapping share drive with IP address has no problem. I can create file at the backup location as well.

Andy

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

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.

  1. Went to server and obtained the computer name, in this case it was "UNITY".
  2. Went back to IPCC and entered "UNITY" for the target location:  //UNITY/ipcc_backup
  3. Started the backup, held breath at 98%, and ta-da!

Hope it's that easy for the rest of you.

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