RHEL v6x Master Server NBU v184.108.40.206, Win2008 R2 Std Media servers also v220.127.116.11, Sharepoint 2007 and 2010 farms
I was asked some Sharepoint Policy questions that I could not answer with much detail. I have read and studied the Sharepoint Policy configuration guide multiple times. Here are some of the questions I was asked about:
Are you telling me that a Sharepoint Farm requires four policies? File backup, Sharepoint Full, Sharepoint GRT and MSSQL? The Windows File backup should backup everything except MSSQL.
My lame answer: The Sharepoint configuration is not recognized as a standard file system, i.e. C:\, D:\... but rather as Microsoft Sharepoint Resources:\ and the standard File level backup won't properly protect the resource.
Ok, You are backing up Microsoft Sharepoint Resources:\* to me that means you are getting everything. Why then do you need a Sharepoint GRT policy.
You can only restore Sharepoint as a full restore from the Sharepoint Full Policy: Microsoft Sharepoint Resources:\* you can not break down the restores to be able to recover, for instance, a single sharepoint file or link. There is a checkbox in the Policy for GRT. We do not check the box for a Full backup. The GRT Policy has these important differences: The resource selection is Microsoft Sharepoint Resources:\ALLWebs and we do check the GRT box. Also in order to do a GRT backup / restore a Sharepoint Full backup is required and the restores require an NFS client.
I could not explain any of the "inner" workings of the policy. I made a guess on the GRT backup that the Policy opens the Sharepoint DB and somehow connects pointers to the objects to add to the backup so that for a GRT restore it would know where each object (file) was in the DB. I don't know if the objects are stored in the DB as BLOBs or otherwise how any of this policy works. As you can read the best I could do was to discuss the configuration of the Sharepoint Policies but nothing else. We have had a miserable time getting regular successful Sharepoint backups and Restores which is why I'm on the line with this. At this point I believe the problem is either with frailties in Netbackup for Sharepoint or that our Sharepoint installations have configuration issues. We are considering alternate products to do the backup/restore: Idera, Docave, MS DPM. Can you folks help me out here?
Sharepoint takes A LOT of configuration. GRT adds even more. The main difference between a sharepoint backup with GRT and with out GRT is that GRT allow you to be able to restore at a granular level. You can drill all the way down to a specific file . In addition , when using GRT you can only backup to disk. This requires a good amount of storage. Here is a configuration checklist I have created :
SharePoint Configuration Check List
1. NetBackup Client version should be the same as the Master Server, and should be installed on all servers in the SharePoint farm, even SQL backend. For SharePoint 2010 SP 1 or GRT you must be on 18.104.22.168 or higher.
2. The NetBackup Client service should be started by a Domain Account. (MUST be in format“domain\user”)
(additional services are needed for GRT, please see GRT Section)
3. The domain account in Step 2 must have the following privileges and permissions:
a. "Replace a process level token" and "Debug Programs" (Administrator Tools - Local Security Policy - Local Policies - User Rights Assignment) for all servers in the SharePoint farm, backend SQL included.
b. Local Administrator rights on all servers in the SharePoint farm.
c. Within SharePoint Central Administrator, the Domain Account is specified as a SharePoint Farm
d. The System Administrator role on the SQL Server for the SharePoint databases.
4. At a minimum, you must have at least .NET Framework 3.5 installed on all servers in the SharePoint Farm.
5. Ports 13782 (bpcd) and 13724 (vnetd) between all Servers in the SharePoint farm and between the Media Server and Master. The ports must be opened bi-directionally.
6. Under Host Properties - Clients on the Master server, under the Windows Client - SharePoint section, make sure that the Domain Account from step 2 is specified there, with the syntax as follows: DOMAIN\Username (not just the Username). Do this for every client/server member of the SharePoint farm.
7. Create a "beds" directory under <install path>\NetBackup\logs\ on each of the SharePoint farm servers (SQL included)
8. Under Host Properties - Master Server, there is a Distributed Applications section. For the first field, put in the name of the Front end server in the SharePoint policy, and in the 2nd field, the name of the SQL server hosting the SharePoint databases.
9. From the Front End web server specified in the policy, Right click on the NetBackup Backup, Archive, and Restore (BAR) GUI and select "Run as Administrator" . You should be able to see Microsoft SharePoint Resources objects there. If you do not see objects, check the farm topology and make sure you have not missed any of the steps on that server.
7. In the first policy (non-granular), the client selection is a Front End Web server for the SharePoint portal. The backup selection for your first policy should be: "Microsoft SharePoint Resources:\"
8. Make sure you do not have the "Enable Granular Recovery" box checked.
9. In the client selction, the frontend server should be specified.
10. You may now test you SharePoint Backup.
Addition steps for SharePoint GRT
For setting up GRT backups of SharePoint, the Media server (if it is a Windows box) and the SQL server need to be running Windows 2003 R2 (or greater) with the following hotfix applied: http://support.microsoft.com/kb/947186.
- In addition The Media server doing the backup/restore operations MUST have NFS Server components installed and running, as outlined in the SharePoint Administration Guide for NetBackup.
- The Frontend and Backend servers must have Client for NFS
See Tech Note for details on NFS - http://www.symantec.com/docs/TECH76684.
-The backups can only be Full backups, and must be taken to a disk storage unit, not tape. Be sure that the policy reflects this as well as having the "Enable Granular Recovery" box checked. Please see the following tech note which lists what type of disk storage types are support for GRT - http://www.symantec.com/docs/TECH187917
- Since GRT only supports Disk, backups can be staged off to tape media at a later time, but the initial backup must be to disk. If you stage the backup image to tape, you must duplicate the image back to disk before a restore can be attempted. For best performance, Symantec recommends that the disk storage unit being used as a target for GRT backups be located locally on the media server as direct SCSI or SAN attached disks. The use of disk storage units that write to network based file systems ( NFS or CIFS ) is not recommended. Performance degradation or read errors may result when the media server presents the backup image via NFS to the client or proxy client if the NFS exported image itself is residing on a network file system ( NFS or CIFS ).
- In addition to the Netbackup Client service, the Netbackup Legacy Client Service and Legacy Network services should be service should be started by a Domain Account. Please refer to #2 and #3 above.
- For GRT Restores, you must run the BAR from the Front end server.
- In addition to 13782 (bpcd) , 13724 (vnetd) the 111 ( portmap) , and 7394 (nbfsd ) need to be open.
In a disaster recovery situation ( where you loose the OS) you will need to restore from 2 polices. First you would need to recover the OS from a MS Windows policy, then recover the sharepoint data from a Sharepoint policy. Starting in 7.5.x , there is an option for VM-ware with sarepoint protection. There is info regarding this in the VM Sysadmin guide and the Sharepoint Admin guide.
Thank you Dyneshia. Although this is all good information it is not what I was asking for. You are telling me how to configure Netbackup for Sharepoint backup/restore, a reciepe but not how it works. I have all of this information and feel I have a fairly good handle on correctly configuring Netbackup, Media Servers, Sharepoint Clients and the like. What I was asking was for the underlying processes that the policy and Sharepoint are doing/using. Yes, I know what is expected of GRT but how does it work - my comments on my guesses as to BLOBs and pointers - why the backup opens a DB server and Front End server? What is it about Microsoft Sharepoint Resources:\ that makes that a target for a backup rather than the drive volumes: C:\, D:\ and so on? What are the Sharepoint "files" that makes them "not" files that can be backed up with ordinary file level backup but instead "resources". This is the kinds of questions I'm being asked to answer.