client read time out on client and media server?
Both does the same function?
Please read through your previous posts again:
After you have read through each of the above posts, please answer this question:
Why do you have timeout settings on the client?
Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links
I have read the above post .Excellent.
Time out settings do not have any sense on client.It needs to be on media server and master.correct?
Nicolai only has 5 minutes, before he must go out. This is like the client connect timeout - if I do not pick up the phone within 5 minutes, Nicolai will hang up, and go out.
Here.Nicolai hanging up deoends on media server connect time out?
These timeout setting exist by default on all servers and clients when you look at Host Properties in the GUI.
They should simply be left alone unless database agents are used and evidence of client-intiated comms issues are seen.
The moment you go into Host Properties -> Clients -> Client-Name -> Timeouts, you will see two default settings. If you click OK or Apply (instead of Cancel), these settings are written to Client's bp.conf file.
bpconf will overcome media servers timeouts?
I see you found one of your other posts again: https://www-secure.symantec.com/connect/forums/details-media-server-and-clients
Thats good! Keep on reading.
Enough reading, enough applying the theory in practice will help you find the answers...
bpconf timeouts on clients will overcome media servers timeouts if set explocitely on clients?
Please can anybody reply to this?
I think Marianne's doing fine.
How's your reading coming along?
bit.ly/76LBN | APPLBN | 761LBN
I am officially giving up ...
There is just no point in answering the same questions over and over....
Please can anybody confirm this.
PLEASE READ through links in my post above.
The answer to your question is there. REALLY!
SCP classification pending.
i read.it is written that for database clients, client read time out value on client works.in that case will it overcome media server time out entry ?
Do you have database clients? Is this a "what if question" or do you actually have an issue?
I have data base clients.
Do you have issues with your database clients?
Yes.They are failing with error 13 after writing 25gb data.
Timeout questions have been answered in your other posts that we have provided links to.
Please start a new discussion for status 13 along with all relevant information:
1. NBU version on master, media server and client.
2. OS on master, media server and client
3. Details of data being backed up on the client. If database, the type of database and NBU policy type.
4. All text in Details tab of Activity Monitor.
5. bptm and bpbrm log files on media server (post files as File attachments)
6. log file on client - if filesystem, bpbkar log. If database, dbclient log (depending of type of database)
Please rename log files to reflect process name (e.g. bpbrm.txt) and attach to your new Status 13 post.
I just want to know if i increase time out in bp.conf file of my database clients,then will my media server read time out will not be consider then?
The answer is REALLY in the posts above.
Media server timeout is ALWAYS applied.
Client's bp.conf timeout entry should never be more than the timeout on the media server.
I have NEVER needed timeout on any client, neither have any of our many customers. Not even on database clients.
As per advice in the other posts, timeouts must NEVER be changed, unless you:
1) are experiencing an issue and you are told by Support or experienced/qualified person to change values.
2) are experiencing an issue and you find reference in a TN or manual that values should be changed
3) you are about to implement a new solution and you find reccommendation in NBU manual or TN that timeouts should be changed.
I have explained some time ago in one of your other posts how incorrect timeouts can even break scheduling.
So in any case client timeouts are of no use.
I have come to this conclusion.Thanks ALL and Marriane.