Re: "Drive is not responding. Backup set aborted." - Veritas Backup Exec

This is a discussion on Re: "Drive is not responding. Backup set aborted." - Veritas Backup Exec ; Bob, I can see why the thread stopped with you. After reading the statement, "Last time I checked, tcp/ip wasn't using the OSI model", I thought, "this guy should go work for Veritas' technical support team." Bob, maybe you should ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: "Drive is not responding. Backup set aborted."

  1. Re: "Drive is not responding. Backup set aborted."


    Bob,

    I can see why the thread stopped with you. After reading the statement,
    "Last time I checked, tcp/ip wasn't using the OSI model", I thought, "this
    guy should go work for Veritas' technical support team."

    Bob, maybe you should learn a little more about the subject, before you attempt
    to help someone. You are just spouting off little incoherent tidbits of
    information you obviously don't know too much about.

    Here's a couple links to some information that may help you learn errors
    in your comment:
    http://www.compucom.com/trg/trg3h.html
    http://www.google.com/search?q=What+...I+Model&num=10
    http://ipprimer.windsorcs.com/section.cfm?SectionID=4
    http://www.cisco.com/univercd/cc/td/...tm#xtocid19394

    Good luck.
    Mike

    "Bob Fisher" wrote:
    >Last time I checked, tcp/ip wasn't using the OSI model.
    >
    >Backup exec probably (i haven't checked) uses tcp/ip, in which case flow
    >control is built in, but if they're using udp then the application is
    >responsible.
    >
    >In any case, we're discussing a 3 party communication, and that puts the
    >responsibility squarely on Veritas.
    >
    >As for over taxing the network, the only data pump in the whole picture

    is
    >(possibly) the agent, so any responsibility for flooding the network would
    >be there. Exchange merely responds to request for data. If properly written,
    >I could be using a ppp connection (as long as I didn't care if it finished).
    >
    >Add to this the fact that everything worked just fine until the latest
    >version of Backup Exec!, even with service pack 6.
    >
    >"Manny" wrote in message
    >news:383b72db@hronntp01....
    >>
    >> Bob,
    >> Your point is not altogether invalid, but do you really think
    >> veritas writes their backup app with flow control in mind?
    >> Or maybe they leave it to the OS and just request the data from
    >> the OS? Where does the Agent Accelerator reside in the OSI model?
    >> Is it in the Application layer? Maybe.
    >> Bruce may well be onto something there. I had a client
    >> experiencing the exact same problem and upgrading the NIC card
    >> drivers did the trick in their case.
    >> Not the easiest problem to troubleshoot.
    >> Good luck Mike.
    >>
    >> "Bob Fisher" wrote:
    >> >not likely, unless you're saying veritas doesn't know how to write a

    >network
    >> >app that does flow control.
    >> >
    >> >"bruce baker" wrote in message
    >> >news:383b40fe@hronntp01....
    >> >>
    >> >> Bob replace your nic its not handling the bandwith requested.
    >> >> It could be the backup server or the remote servers nic.
    >> >> Network trouble shooting is such fun.!!!
    >> >>
    >> >> "Bob Fisher" wrote:
    >> >> >I did, and the problem continued....
    >> >> >I found that disabling the Accelerator Agent stopped the problems.
    >> >> >It takes twice as long to backup exchange, but it works now.
    >> >> >"Denise Moreno" wrote in message
    >> >> >news:3839836c@hronntp01....
    >> >> >>
    >> >> >> Did you apply the hotfix patch after upgrading to 2575 build??
    >> >> >> "Mike Hare" wrote:
    >> >> >> >
    >> >> >> >Up until today I have been running SP4 on my backup server.
    >> >> >> >I just went to SP5 along with the upgrade to build 2575. I am
    >> >> >> > tempted to start over and install Backup Exec 7.2. I never had
    >> >> >> >this problem untill after 7.3.
    >> >> >> >
    >> >> >> >
    >> >> >> >
    >> >> >> >"Ed Jones" wrote:
    >> >> >> >
    >> >> >> >>
    >> >> >> >>Im getting the same problem since the first 7.3 2575, I did my

    >whole
    >> >> >backup
    >> >> >> >>server over(format c) and installed 7.3 2570 and still have the
    >> >problem,
    >> >> >> >>this machine is NT SP6, i begining to think the problem may be

    SP6
    >> >> >(microsoft
    >> >> >> >>has a winsock fix for this service pack could be the problem?)
    >> >> >> >>
    >> >> >> >>
    >> >> >> >>"Mike Hare" wrote:
    >> >> >> >>>
    >> >> >> >>>For about the past year, our backups have been running perfectly.
    >> >But
    >> >> >> about
    >> >> >> >>>a month after upgrading to 7.3, I have been having backups on

    my
    >> >remote
    >> >> >> >>servers
    >> >> >> >>>(Via a T1 connection) fail with the message "Drive is not
    >> >responding.
    >> >> >> Backup
    >> >> >> >>>set aborted.", on drive volumes as well as Exchange Server

    >stores.
    >> >> It
    >> >> >> has
    >> >> >> >>>gotten worse, to the point that I can no longer backup any remote
    >> >> >servers.
    >> >> >> >>>I just upgraded to the Nov 15 release of build 2575. The backup
    >> >server
    >> >> >> >is
    >> >> >> >>>Windows NT Workstation 4.0 SP5 with 128 Megs ram, and an

    >autoloader
    >> >> >tape
    >> >> >> >>>drive--this server is solely dedicated to Backup Exec and does
    >> >nothing
    >> >> >> >else.
    >> >> >> >>>So far, I have not been able to find any network issues that

    >would
    >> >> >cause
    >> >> >> >>>this. It did not start right after my first 7.3 upgrade, so I

    am
    >> not
    >> >> >sure
    >> >> >> >>>if the 7.3 version is the cause. Also, since I used the new Nov

    >> 15
    >> >> >release
    >> >> >> >>>of build 2575, should I still install the post2574 patch?
    >> >> >> >>
    >> >> >> >
    >> >> >>
    >> >> >
    >> >> >
    >> >>
    >> >
    >> >

    >>

    >
    >



  2. Re: "Drive is not responding. Backup set aborted."

    I'm sorry...tcp/ip and UDP are protocols that are not based on OSI, although
    loose associations can be made. Note that even your sources aren't
    consistent (compucom puts telnet at the application layer, google puts it at
    the session layer). There are no real presentation or session layers in a
    tcp/ip network, and even the lower levels are a bit tough to work out. TCP
    and UDP really stop at the transport layer. Below tcp, the network is
    inherently "unreliable", which means that any failure in a network card to
    keep up with the dataflow will be handled nicely by the transport layer, and
    any failings would be expected to show up as a system level error.

    The dataflow is exchange<->agent<->network<->server<->tape. Of these, delays
    on the network are to be expected, but the real determinant is the tape
    speed..

    Presumably, the agent<->server connection uses some sort of flow control
    over and above that available on the network, since the server must
    ultimately write to tape, which may impose all sorts of delays, including
    sitting for extended periods while switching to the next volume. The agent
    must also negotiate a transfer of data from exchange server.

    While the network card certainly has a role in all this, that shouldn't
    result in anything more than collisions or retransmissions at the tcp level.

    I've never actually checked to see what was being used between the server
    software and the agent/exchange. I suspect that it's RPC over named pipes
    when talking directly to exchange (although I really haven't checked), but
    that the agent sets up something else.

    The particular point, though, was that the network card is below the point
    in the network stack that adds reliability (in the OSI sense), and since it
    works in all other situations is not likely (my words) to be the problem.
    "Mike" wrote in message news:3846a97b@hronntp01....
    >
    > Bob,
    >
    > I can see why the thread stopped with you. After reading the statement,
    > "Last time I checked, tcp/ip wasn't using the OSI model", I thought, "this
    > guy should go work for Veritas' technical support team."
    >
    > Bob, maybe you should learn a little more about the subject, before you

    attempt
    > to help someone. You are just spouting off little incoherent tidbits of
    > information you obviously don't know too much about.
    >
    > Here's a couple links to some information that may help you learn errors
    > in your comment:
    > http://www.compucom.com/trg/trg3h.html
    > http://www.google.com/search?q=What+...I+Model&num=10
    > http://ipprimer.windsorcs.com/section.cfm?SectionID=4
    >

    http://www.cisco.com/univercd/cc/td/...int.htm#xtocid
    19394
    >
    > Good luck.
    > Mike
    >
    > "Bob Fisher" wrote:
    > >Last time I checked, tcp/ip wasn't using the OSI model.
    > >
    > >Backup exec probably (i haven't checked) uses tcp/ip, in which case flow
    > >control is built in, but if they're using udp then the application is
    > >responsible.
    > >
    > >In any case, we're discussing a 3 party communication, and that puts the
    > >responsibility squarely on Veritas.
    > >
    > >As for over taxing the network, the only data pump in the whole picture

    > is
    > >(possibly) the agent, so any responsibility for flooding the network

    would
    > >be there. Exchange merely responds to request for data. If properly

    written,
    > >I could be using a ppp connection (as long as I didn't care if it

    finished).
    > >
    > >Add to this the fact that everything worked just fine until the latest
    > >version of Backup Exec!, even with service pack 6.
    > >
    > >"Manny" wrote in message
    > >news:383b72db@hronntp01....
    > >>
    > >> Bob,
    > >> Your point is not altogether invalid, but do you really think
    > >> veritas writes their backup app with flow control in mind?
    > >> Or maybe they leave it to the OS and just request the data from
    > >> the OS? Where does the Agent Accelerator reside in the OSI model?
    > >> Is it in the Application layer? Maybe.
    > >> Bruce may well be onto something there. I had a client
    > >> experiencing the exact same problem and upgrading the NIC card
    > >> drivers did the trick in their case.
    > >> Not the easiest problem to troubleshoot.
    > >> Good luck Mike.
    > >>
    > >> "Bob Fisher" wrote:
    > >> >not likely, unless you're saying veritas doesn't know how to write a

    > >network
    > >> >app that does flow control.
    > >> >
    > >> >"bruce baker" wrote in message
    > >> >news:383b40fe@hronntp01....
    > >> >>
    > >> >> Bob replace your nic its not handling the bandwith requested.
    > >> >> It could be the backup server or the remote servers nic.
    > >> >> Network trouble shooting is such fun.!!!
    > >> >>
    > >> >> "Bob Fisher" wrote:
    > >> >> >I did, and the problem continued....
    > >> >> >I found that disabling the Accelerator Agent stopped the problems.
    > >> >> >It takes twice as long to backup exchange, but it works now.
    > >> >> >"Denise Moreno" wrote in message
    > >> >> >news:3839836c@hronntp01....
    > >> >> >>
    > >> >> >> Did you apply the hotfix patch after upgrading to 2575 build??
    > >> >> >> "Mike Hare" wrote:
    > >> >> >> >
    > >> >> >> >Up until today I have been running SP4 on my backup server.
    > >> >> >> >I just went to SP5 along with the upgrade to build 2575. I am
    > >> >> >> > tempted to start over and install Backup Exec 7.2. I never had
    > >> >> >> >this problem untill after 7.3.
    > >> >> >> >
    > >> >> >> >
    > >> >> >> >
    > >> >> >> >"Ed Jones" wrote:
    > >> >> >> >
    > >> >> >> >>
    > >> >> >> >>Im getting the same problem since the first 7.3 2575, I did my

    > >whole
    > >> >> >backup
    > >> >> >> >>server over(format c) and installed 7.3 2570 and still have the
    > >> >problem,
    > >> >> >> >>this machine is NT SP6, i begining to think the problem may be

    > SP6
    > >> >> >(microsoft
    > >> >> >> >>has a winsock fix for this service pack could be the problem?)
    > >> >> >> >>
    > >> >> >> >>
    > >> >> >> >>"Mike Hare" wrote:
    > >> >> >> >>>
    > >> >> >> >>>For about the past year, our backups have been running

    perfectly.
    > >> >But
    > >> >> >> about
    > >> >> >> >>>a month after upgrading to 7.3, I have been having backups on

    > my
    > >> >remote
    > >> >> >> >>servers
    > >> >> >> >>>(Via a T1 connection) fail with the message "Drive is not
    > >> >responding.
    > >> >> >> Backup
    > >> >> >> >>>set aborted.", on drive volumes as well as Exchange Server

    > >stores.
    > >> >> It
    > >> >> >> has
    > >> >> >> >>>gotten worse, to the point that I can no longer backup any

    remote
    > >> >> >servers.
    > >> >> >> >>>I just upgraded to the Nov 15 release of build 2575. The

    backup
    > >> >server
    > >> >> >> >is
    > >> >> >> >>>Windows NT Workstation 4.0 SP5 with 128 Megs ram, and an

    > >autoloader
    > >> >> >tape
    > >> >> >> >>>drive--this server is solely dedicated to Backup Exec and does
    > >> >nothing
    > >> >> >> >else.
    > >> >> >> >>>So far, I have not been able to find any network issues that

    > >would
    > >> >> >cause
    > >> >> >> >>>this. It did not start right after my first 7.3 upgrade, so I

    > am
    > >> not
    > >> >> >sure
    > >> >> >> >>>if the 7.3 version is the cause. Also, since I used the new

    Nov
    > >> 15
    > >> >> >release
    > >> >> >> >>>of build 2575, should I still install the post2574 patch?
    > >> >> >> >>
    > >> >> >> >
    > >> >> >>
    > >> >> >
    > >> >> >
    > >> >>
    > >> >
    > >> >
    > >>

    > >
    > >

    >




+ Reply to Thread