Well, since I started this thread and nobody responded I thought that I would share some of the things that I have found out about doing SharePoint backups.

The backup and restore of a SharePoint Farm can actually be done once all of the configuration items have been set up properly. 

• For one thing ALL of the SharePoint servers and back-end SQL servers need to be running the same version of the NetBackup client as the NBU master/media servers (in my case, this was version 6.5.4).  Originally, we had version 6.5 loaded on the clients and we were not able to perform a Farm-level backup.  Once we got the SharePoint servers upgraded to the correct version of NBU, it worked fine.
• Next, be sure to follow the steps in http://support.veritas.com/docs/335997 .  It's a wonderful step by step guide to doing the configurations.
• The Farm-level backup will allow you to restore anything down to the content-db level.  If you want anything more granular than that you will need to use GRT.  The documentation for the SharePoint agent doesn't really tell you that you need GRT for doing an individual site restore for example. 

So, my next step will be to get the GRT working.  This requires the media server to be running one of the following so that NFS will be set up:

1. UNIX/Linux
2. Windows 2003 R2
3. Windows 2008

Also, the back-end SQL servers need parts of NFS so they need to be running either Windows 2003 R2 or Windows 2008.

We will likely be running Windows 2008....but we haven't done that yet, so we're still doing basic backup and restore testing for SharePoint at higher levels.

Tha'ts it for now....I'll put more out here later.  If anyone has anything else, please add to this thread.

There is a limitation in current GRT implementation - it does not support granular recovery of WebParts.
We have a customer who has applied about 5 EEB applied to 6.5.5 just to make it work. So, don't consider this functionality as working out-of-box.
BTW, GRT does work with W2K3 (non-R2) at a media server without any problems.

Mouse, what's a "web part"?  I'm not clear on all of the SharePoint terms here.  Do you have any info on individual site restores?

Also, when you say that "GRT does work with W2K3 (non-R2) at a media server", do you mean that you can get the NFS pieces working on there?

Now, having pasted all that, I'm happy to tell you that this will change in 6.5.6 and there's likely to be a TechFile for 6.5.5 coming very soon as well.  (When I get some links, I'll be sure to post them!)  In the mean time, as Mouse said, EEBs ARE available if you open a support case if/when you start experiencing issues.

So, after several successful SharePoint Farm-level backups, we decided to try out some restores.

Restores of individual content databases are easy to do.  Even doing redirected restores of content databases.

Right now, though, we are having issues with doing restores of SharePoint Web-Apps.  When we try to initiate a restore by checking off a given Web-App and then try to start the restore, we end up with nothing.  No job starts on the NetBackup master and there are some errors in the Event viewer on the SharePoint Front-end Web Server.  That error looks like the following:

Faulting application SPSRecoveryAsst.exe, version 6.5.2009.430, faulting module MSVCR71.dll, version 7.10.3052.4, fault address 0x0001569b.

I have opened a case on this, but I am awaiting a fix for this issue.

I will post more here when I get this issue resolved. 

It may be obvious to most, but since there is a way to manage an exclude list from the NBU master for a Windows client, I thought that might be the way to do it for SharePoint. 

WRONG!!

The ONLY way to manage any kind of excludes for a SharePoint backup is from the front-end web server through the BAR GUI.

Furthermore, even if you build an exclude list for SharePoint from the front-end web server, you may still encounter an error 71 on the backup due to a bug. 

If you encounter the error 71, the way around it is to explicitly list only those SharePoint items that you want to have backed up.

Well, I finally got an answer back from Symantec support on the issue of SPSRecoveryAsst failing when attempting to restore a web application.  It turns out that this is a bug that has been fixed in NetBackup 7.0.1 and will be backported to 6.5.5 only!

This doesn't do me much good since we have a large environment that was just updated to 6.5.4.

So, if you want full functionality for doing restores of SharePoint 2007, you should be at the latest version of NetBackup and use GRT.

An interesting point was raised by Symantec when they told us not to mix SQL agent backups with SharePoint object backups.  Just what do you do with the SQL transaction logs? 

According to Symantec, an incremental backup of a web application is supposed to truncate the transaction logs of the associated content databases.  However, our testing has shown this to not be the case.

If an incremental backup of a web application and its associated content DB's do not truncate the logs, that would mean that you should do a separate SQL backup of the transaction logs at some point and use that backup to truncate the logs. 

If you don't do something like that, then you run the risk of filling up your disk and all of the problems that will cause.

It turns out that NBU version 6.5.4 will not do anything about SQL log truncation when performing a differential backup of a web application and the associated content db's.  According to Symantec, you should back these up separately with a SQL backup.

This goes against what they said originally....but it will take care of the T-logs and their truncation.

Now, as to whether you can play the T-logs against a restored content database, that's a different question.  But, according to Symantec, it should be possible.  (I'm leaving that test for another day.)

It turns out that NBU version 6.5.4 will not do anything about SQL log truncation when performing a differential backup of a web application and the associated content db's.  According to Symantec, you should back these up separately with a SQL backup.

This goes against what they said originally....but it will take care of the T-logs and their truncation.

Now, as to whether you can play the T-logs against a restored content database, that's a different question.  But, according to Symantec, it should be possible.  (I'm leaving that test for another day.)

According to Symantec, if you are going to do GRT backups, you cannot use dedupe storage devices (like Data Domain) as a disk storage unit for SharePoint backup policies.  We were told that this is not supported.  Although there is nothing in the documentation that states that fact.

We may test this just to see what happens.

Using 6.5.4 we discovered that you cannot restore a web application from a non-GRT backup.  We were not able to test whether or not you could do a restore from a GRT backup until we upgraded to 7.0.1. (For clarification, our environment was not set up to take advantage of GRT until we upgraded to 7.0.1.  6.5.4 CAN do GRT, it's just that our environment wasn't configured to do the NFS piece which is required for GRT.)

As of 7.0.1, you still cannot restore a web app from a non-GRT backup.  However, using a GRT backup WILL allow you to do a successful restore.

The NBU SharePoint Admin guide says that you can do a restore of a web application from a non-GRT backup, but the condition (bug?) that prevented this in 6.5.4 must still exist in 7.0.1.