Common SharePoint File system customisations you will want to backup
- IIS site configuration
- Assemblies deployed to the GAC
- Site Definitions
- Any master pages, images, CSS files or page layouts that are not stored in your content DBs
- iFilters and corresponding registry modifications
- Third party solutions (again, these often include assemblies deployed to the GAC)
- Resource files (.resx)
But back to our precious SharePoint farm configuration – what can we do to protect it? In MOSS, SQL database mirroring is an option that can certainly increase availability of the database, but ultimately you must ensure that you have a fall back in the form of thorough documentation. Luckily, Microsoft provide a handy list of settings that you should document on Technet. Essentially, these can be found by clicking through central administration:
MOSS Farm configuration settings you should document:
- Application pool settings, including service accounts (all accounts that run as Web applications, including the crawler account and the search account).
- Alternate access mapping settings.
- Farm-level search settings.
- External service connection settings.
- Workflow management settings.
- E-mail settings.
- A/V settings.
- Usage analysis processing settings.
- Diagnostic logging settings.
- Content deployment settings.
- Timer job settings.
- HTML viewer settings.
- Recycle Bin settings and other Web application general settings.
- Administrator-deployed form templates.
- Default quota templates.
- Database names and locations.
- Web application names and databases. Be sure to document the content database names associated with each Web application.
- Crawler impact rules.
- Activated features.
- Blocked file types.
- Farm solutions (e.g. WSP files) that have been deployed (thanks to one of my readers for this one).
OK, so what about SharePoint 2010? I’ve already mentioned that the configuration DB cannot be restored due to it containing environment specific settings and potential synchronisation issues. Whilst that is true, Microsoft have mitigated this limitation by providing us with a “Configuration Only” backup option. This capability is great news given that being able to restore the configuration directly is the equivalent of restoring the database itself. What’s even better is that the configuration backup can be used to restore farm settings to another environment – which will prove incredibly useful for those wishing to create consistent pre-production environments.
For those using PowerShell, a farm configuration backup can be taken by running the following script: