It's critical to develop and document a tested back-up schedule and disaster recovery plan which will replicate both the database content of SharePoint, as well as the web server(s) settings and customizations. In spite of SharePoint's database-centric content storage system, most deployments contain a healthy number of enhancements and customizations to their SharePoint instance inextricably linked to the state of their web server(s). Failing to replicate and store back-ups of the web server(s) themselves will likely dramatically increase recovery and restoration downtime.
Since data loss disasters come in multiple levels of severity, it's important to have recovery procedures that address each. I suggest a 3-tiered approach:
-
Entire server farm restoration process (complete web server and database loss).
-
Web application, site, and site collection restoration process (database content loss).
-
Individual content object restoration process (recycle bin).
If possible, backing up the entire web server(s) with an image of the box (or VM) is ideal, at an interval appropriate for your system's size and rate of change. I also suggest creating an image of the box immediately before applying any patches/updates. In addition to imaging the entire SharePoint web server(s), I also backup the servers' individual 12 hive directories (C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12) and Inetpub directories (C:\Inetpub). These directories hold most of the pertinent files involved in SharePoint customizations and configuration, and provide another layer of security in the case the server images are lost or damaged. The following is a list of potential SharePoint settings and configurations maintained within the web server(s):
-
Application Pool settings, including service accounts (all accounts that run as Web applications, including the crawler account and the search account).
-
Secure Sockets Layer (SSL) certificates
-
Alternate access mapping settings
-
Farm-level search settings
-
Activated features
-
12 hive - (C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12)
-
GAC – global assembly cache; a protected operating system location where .NET framework code assemblies are installed to provide full system access (C:\WINNT\assembly)
In addition, it is generally a good idea to maintain a complete and up-to-date list of SharePoint databases and the web application(s)/site collection(s) they map to. SharePoint databases should be backed up appropriately based on the frequency of content changes within your system, generally a daily incremental and weekly full SQL back-up schedule is a good starting point. The weekly (or daily) database back-ups should be stored somewhere off-site in the event recovery from a catastrophic loss (i.e. your office or datacenter burns down).
Ensuring your recycle bin settings are correctly configured will often save you major headaches when users (inevitably) accidentally delete content. Navigate to Central Admin > Application Management > Web Application General Settings and scroll down to the bottom of the page to find the recycle bin settings for the current selected web application (change selection at the top of the page). By default, SharePoint activates web application recycle bins and stores deleted content in it for 30 days, after which the deleted content is moved to the 2nd stage recycle bin (the site collection level recycle bin) where it is stored indefinitely unless the 2nd stage space quota is reached. The space quota is set by default to 50% of the total space allocated to the web application itself.
An important point to note about recycle bins (so important I'm putting it in bold): Site and site collection deletion is not managed through the Recycle Bins – content contained within deleted sites/site collections will be permanently lost. (One reason I don't allocate full permissions to sites as part of my governance policy.)
I hope these points of preponderance provide you with some inspiration and/or guidance when devising your own SharePoint back-up schedule and recovery procedure because (at the risk of sounding super-cliche) - when it comes to SharePoint - failing to plan is planning to fail.