Skip to main content
Solved

Sharepoint Farm Disaster recovery: Backup


Forum|alt.badge.img+8

Currently we are protecting a customer’s Sharepoint farm using SQL agent on the SQL server; and File system agent on rest of the servers; we cant get hypervisor access hence used the file system agent.  We tested the recovery and restored all the servers and used SQL database restore to restore the databases.  However, the search functionality does not work on the recovered environment.  

 

 

We are thinking of using the Sharepoint Farm backup; the documentation says to install Sharepoint agent; so as I understand 

>  Install Sharepoint Agent on all the servers in the farm 

> Because SQL agent is already installed on SQL server do I need to install Sharepoint agent as well on it ; also do I need to stop SQL backups and Sharepoint backups would protect the same set of data again

> Create a sudo-client and select all these as member servers 

> Expand sudo-client and create user-defined sub-client and on the content tab include web-front-end data > Perform backup 

> Use Sharepoint Farm backup set to back up all the components: I presume it would show up correctly on the Sharepoint server once the agent is installed 

 

Also, why is it recommended to use 

“SharePoint Farm (database) backup with SQL agent content database backup using either the block level option”

rather than normal SQL VDI based backups 


 

When recovering 

  • Recover all the servers using the file system agent as we cant get access to hypervisor
  • Restore Sharepoint Data using the Sharepoint Farm backup on the restored servers 
  • Restore web-front end and registry setting using Sharepoint sudo-client 

 

 

 

 

 

Best answer by Scott Reynolds

@Theseeker

For your second question answer is no. The SQL Agent will detect when the database is being protected by the SharePoint IDA and it will skip it. You will see this in the SQL jobs on the status tab with a message that it is being protected by SP.

Also this is only for content DBs other will still be protected via SQL Agent.

 

If you are concerned about File System agent protecting these database files you can add filters for *.MDF and *.LDF to make sure FS ignores the SQL database files on backup

View original
Did this answer your question?
If you have a question or comment, please create a topic

3 replies

Forum|alt.badge.img+15
  • Vaulter
  • 630 replies
  • May 9, 2022

Good morning.  The SharePoint agent only gets installed on the SharePoint servers, the SQL agent on the database servers.  The Sharepoint Farm agent captures data that just backing up the SP content databases using the SQL agent will not capture.  As seen in this link:

https://documentation.commvault.com/11.24/essential/105771_full_system_recovery_of_sharepoint_server_agent.html

The Sharepoint Farm client is used “to back up and recover web applications, content databases, and web front end data, such as the SharePoint hive, IIS settings, and the SharePoint registry entries.”

it goes on further to point out:


“Backing up the database server does not back up Web Front End data such as the SharePoint hive, IIS settings, and the SharePoint registry entries. To back up these components, you can perform a disaster recovery of the farm client.”

 

As for your question “Also, why is it recommended to use "SharePoint Farm (database) backup with SQL agent content database backup using either the block level option"  ratherthan normal SQLVDI based backups”

I assume you are referring to this doc:

https://documentation.commvault.com/11.24/expert/17932_document_sharepoint_server_agent.html

“You can use the Farm backups to create recovery points. These recovery points can be used with the offline mining to restore the specific documents that you want”

Using block-level or Intellisnap gives you the ability to mine the database offline for granular item recover
 


Forum|alt.badge.img+8
  • Author
  • Byte
  • 39 replies
  • May 10, 2022

 

As the existing servers have File system agents and SQL agent installed; when I create a sudo client (I am using Commvault Java console rather than the web based UI); no servers are listed here.  So I think I will first have to install the Sharepoint agent on all the farm members as per the document 

https://documentation.commvault.com/11.24/expert/17832_farm_sharepoint_server_agent.htm

 

  1.  Once the agent is installed; I can use that sub-client on sharepoint agent to protect the following

 

“After installing the SharePoint Server Agent, the farm backup set is added by default to the SharePoint client.” to protect farm objects, web applications, service applications, and SQL content databases.”  

  1.  I then use this sudo client to protect other items like : “  http://docs.commvault.com/commvault/v11/article?p=17873.htm
    You can use a pseudo client to back up and recover web applications, content databases, and web front end data like SharePoint hive, IIS settings and SharePoint registry entries.

so both 1 and 2 are required for a DR situation.  The current SQL level backups that we have wherein all the databases are protected via the Commvault SQL agent; will I have to make any changes there because the Sharepoint agent would be protecting the same set of content databases and has a backup schedule already(15 minute transactional logs; daily differential and weekly full) ; I do not want to protect the same data 3 times; once via the file system agent; then the SQL agent backing up databases and 3 Sharepoint agent again backing up content databases  

 

 

 

 

 


Forum|alt.badge.img+14

@Theseeker

For your second question answer is no. The SQL Agent will detect when the database is being protected by the SharePoint IDA and it will skip it. You will see this in the SQL jobs on the status tab with a message that it is being protected by SP.

Also this is only for content DBs other will still be protected via SQL Agent.

 

If you are concerned about File System agent protecting these database files you can add filters for *.MDF and *.LDF to make sure FS ignores the SQL database files on backup


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