Today is the final straw! A blog post is born…
I’m sat remotely looking at another deployed production SharePoint environment that is not being properly backed up.
For sure, backup your SharePoint configuration/service application databases and your content databases but please also make sure you’re backing up your SQL Server system databases!
They don’t need to be on a daily (or more frequent) schedule like your SharePoint databases but do backup system, msdb and model (if you have altered it perhaps to define the default settings for new content databases).
the bottom line is that good system database backups can help you (in many circumstances) meet tight recovery time objectives (RTOs) if your SQL Server back-end becomes goobered, without these backups it maybe necessary to rebuild SQL Servers in situations where a restoration would have put things right.
Why? They’re all needed for optimal SQL Server operations and, in the case of master, they’re needed for your instance to start period. Master holds most of the configuration data for the instance (database info, logins, AlwaysOn configuration info, etc.) and without a restorable backup if your SQL Server becomes corrupted (it does happen!) or needs to be re-deployed for some reason then you will have to manually recreate all of the configuration settings made to the point of recovery. Not ideal, especially if your configuration was not fully scripted and documented!
More preparation equals less perspiration.
Here’s a convenient Technet article letting you know what needs to be done with links to how to do it!
more to follow…