Restores from ops center failing with status 2850

Do all of your clients and media servers have the OpsCenter server added as a valid server in their servers list?

I have seen something very similar with an error message that meant nothing but once i worked through the logs it was simply an access denied which if i remember correctly was either the client or the media server telling the OpsCenter server that it had no right to request such a restore.

I do not currently have the ops center server listed in the configs for any media servers or clients.  It's currently only in the master server's bp.conf.  So I need the 'OPS_CENTER_SERVER_NAME' in bp.conf for media servers and possibly clients as well?

No, you need it as a SERVER entry as its going entry

I added the server entries and it had no change.  I'm fairly confident that isn't the problem since the restore is starting and always stopping at exactly 1924538880 bytes for a file.  If the restore does not contain a file that is over 1924538880 bytes it completes without issue.  This only started occuring after upgrading from 7.5.0.3 to 7.6.0.2.  This backup is new enough that it was backed up using the 7.6.0.2 client so I don't think it is an issue of restoring a 7.5.0.3 backup to a 7.6.0.2 client.  Maybe there is an issue with the version of tar that comes in 7.6.0.2 with files over this particular file size?  I've found no other evidence of that online though.

Adding some additonal info

I can restore to the media server itself that is performing the restore just fine using ops center however restoring to the client the restore stops when the file hits the previous mentioned file size.

I performed a stack trace on the tar on the client and found this that may help point somewhere.

write(2, "Unexpected EOF on archive file", 30) = 30

I also tried to see if there was a difference in invoking tar between a restore from Ops Center vs the Java Admin client.  The only difference I can see really is en_US.UTF-8 vs en_US for some of the parameters.

tar -x -v -Y -p -P -I 1409770926 -U 0 -E /usr/openv/netbackup/.rename.28586    -Q -J clnt_lc_messages=en_US.UTF-8 -J clnt_lc_time=en_US.UTF-8 -J clnt_lc_ctype=en_US.UTF-8 -J clnt_lc_collate=en_US.UTF-8 -J clnt_lc_numeric=en_US.UTF-8 -J restoreid=91571.001 -J job_total=1 -J client=restore-client -J requesting_client=masterserver -J browse_client=backup-client -J backup_time=1409749211                                                                                              -f - -J verbose=5 -J disallow_server_file_writes=0
tar -x -v -Y -p -P -I 1409771509 -U 0 -E /usr/openv/netbackup/.rename.30040 -j -Q -J clnt_lc_messages=en_US       -J clnt_lc_time=en_US       -J clnt_lc_ctype=en_US       -J clnt_lc_collate=en_US       -J clnt_lc_numeric=en_US       -J restoreid=91572.001 -J job_total=1 -J client=restore-client -J requesting_client=masterserver -J browse_client=backup-client -J backup_time=1409749211 -L /usr/openv/netbackup/logs/user_ops/root/logs/jbp-24274409771508901319000000409-DvKORJ.log -f - -J verbose=5 -J disallow_server_file_writes=0

Eliminate OpsCenter from the picture and restore using the Admin Console. Then you'll know where the problem lies, client or OpsCenter config.

I've already done that and the problem is definitely with restores from Ops Center.  I have no idea why a restore from ops center would fail at the exact same number of bytes on a file if a file is larger than 1.8gig though.

2 months later and no solution as yet.

It seems as if you have discovered a bug with OpsCenter.

Hopefully you have logged a Support call with Symantec by now?

I meant to reply back to this thread I think.  I did log a support ticket and was told that there is a known bug with restoring large files from Ops Center.  I think the tech article I was given the link to said files larger than 1GB though the problem for me seemed to be files over 1.8GB not 1GB.  I was assured it was the same problem.

Unfortunately I was told this would not be fixed until 7.6.0.4 which is still not out and there were no plans for an EEB to fix this problem.  I will be deploying 7.6.0.4 as soon as it comes out and pray that it doesn't cause any other severe problems.

Was it this one?

Restores initiated via OpsCenter Simplified File Restore (SFR) do not correctly restore files larger than 1 GB.
 http://symantec.com/docs/TECH222720

The Etrack listed in this doc IS resolved in 7.6.0.4 (and we should probably update the TechNote).