Forum Discussion

agardner's avatar
agardner
Level 3
12 years ago
Solved

Netbackup Scheduling Question

Hello Symantec world. Much obliged for the many answers I've received thus far.

The SQL DBA that I'm working with and I hashed out another big question that I don't have the answer to.

Every night, our gajillion-dollar company backs up its production SQL databases. From what I understand, Netbackup does this by certain policies, but rather than set specific timeframes for backup completion, it dumps all of the information for the 100+ DB backups into a queue. Then, it allocates 10 or 15 threads and says, "Everybody get in line, 10 at a time, no pushing, no shoving, you'll finish when you finish."

What I need to know is how that queue is stored. Is there a backend database proprietary to Netbackup that we can query using SQL? 

We want to automate kicking off SQL backups that fail, but we need to know what is queued and hasn't run yet so that the automation doesn't think it is missing the backups that haven't been kicked off yet and try to kick those off prematurely.

Thanks in advance!

-SQL DB Headache

  • See :

    http://www.symantec.com/docs/HOWTO43727

    http://www.symantec.com/docs/HOWTO43728

    It the task of NBPEM - Policy Execution Manager. The job log is a intern tabel in memory.

    Best Regards

    Nicolai

  • See :

    http://www.symantec.com/docs/HOWTO43727

    http://www.symantec.com/docs/HOWTO43728

    It the task of NBPEM - Policy Execution Manager. The job log is a intern tabel in memory.

    Best Regards

    Nicolai

  • The links aren't populating. Is this a problem on Symantec side or my browser?

     

    ....guess I just had to wait. It's working for me too now. Thanks for letting me know.

  • Fantastic! Thank you very much! This will allow me to extract the information I need.

    If only it were possible via SQL...

  • Hey Ah45, thanks! We also use Control-M for automation, and Patrol generates tickets but that's not the issue. We are automating the kicking-off of missed SQL backups specifically, and we'll need to track a small amount of historical data, so a report of alerts won't be sufficient. At least it doesn't seem that way given the information/experience we've had so far.