Skip to main content
Question

Suddenly unable to back up MSSQL with this error 19:599.

  • October 28, 2024
  • 4 replies
  • 102 views

Veerasak
Byte
Forum|alt.badge.img+2

Help me !!

Suddenly, I can't back up data for my clients.

I have tried to check the connections and found that everything is normal. All ports can talk normally.

 

After that I uninstalled and reinstalled the agent but it still doesn't work.

 

 

 

Please advise me where else I need to check.

 

Description: Loss of control process SQLBackup.exe. Possible causes: 1. The control process has unexpectedly died. Check crash dump or core file. 2. The communication to the control process machine xxxxx might have gone down due to network errors. 3. If the machine xxxxx is a cluster, it may have failed over. 4. The machine xxxxx may have rebooted.

4 replies

Forum|alt.badge.img+7
  • Vaulter
  • 70 replies
  • October 28, 2024

hi @Veerasak

Please ensure service on client is up and running, there are no process crash on client for sqlbackup.exe (from Event veiwer--> applciation logs -- check for any faulting process )
Default Port 8400,8403 are open between commserver, client  and MA, av exclusion are inplace.
please review this kb article
https://kb.commvault.com/article/63604
 

look up for cvd.log , cvfwd.log , SQLbackup.log to check further more on the issue.

if still a problem support case may help for engineer to assist.



 


Veerasak
Byte
Forum|alt.badge.img+2
  • Author
  • Byte
  • 3 replies
  • October 29, 2024

Thank you @Sujay kumar 

 

I am sure that both Commserve , MA and the Client are service running normally.

And I can telnet Commserve between client with port 8400, 8403 normally.


Onno van den Berg
Commvault Certified Expert
Forum|alt.badge.img+19
  • Commvault Certified Expert
  • 1227 replies
  • October 29, 2024

Did you make any changes? What version are you running? Is it an AG config? If so, can the nodes communicate between each other on Commvault TCP ports. Are you using network topologies?


Damian Andre
Vaulter
Forum|alt.badge.img+23
  • Vaulter
  • 1287 replies
  • October 30, 2024

Two possibilities

  1. Communication
  2. Legitimate process crash

#2 is easy to check - go check the windows application log for any crashes. on the client machine

 

#1 If not a crash, It sounds like communication towards client is good, but it is being blocked on reverse. Just checking 8400 and 8403 is not accurate to depict if communication is good. Commvault uses random high ports for communication unless you are using a network topology or configuration to restrict the ports are used. I would implement a network configuration here and limit connectivity bi-bidirectionally for 8403 and see if that helps. Of course you should check comms from the client to MA/CS on 8403 assuming that will be your network/firewall port (it is by default 8403).

 

Probably going into way too much detail here, but if you want to thoroughly test reverse communication without network topologies:

  1. Access the registry of the CommServe, and head to:
    HKEY_LOCAL_MACHINE\SOFTWARE\CommVault Systems\Galaxy\Instance001\Runtime
  2. The high ports for the services the CommServe is using is stored here, for example: JobManager_v4
  3. The client should be able to telnet/cvping to the number (port) assigned to our example, JobManager_v4

    e.g JobManager is running on port 50148

     


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings