Though almost everything in SharePoint is stored in the SQL Sever database NOT everything is. In case of massive failure you may need to rebuild the farm, which is best done with Farm backup done on STSADM.EXE batch file on one of the WFE servers. But for lost content SQL Server backups every night.
How often to do full backups with STSADM, well monthly or weekly depending on churn. If your organization is creating lots and lots of new site collections weekly would be better, if you have tight control on creating new site collections monthly should be good. You need to ask yourself how often the entire farm is changing, and schedule your farm backups for that.
But don't listen to me, here is an excellent blog entry:
Dave Wollerman's SharePoint Blog
SharePoint Disaster Recovery Tips Using SharePoint and SQL Backups
There are a number of companies out there that utilize SQL transaction log backups for their SharePoint solution. This of course is fine and supported by Microsoft, but if there is a complete disaster then the SharePoint administrator will have to piece everything back together. My recommendation is to run the SharePoint full backup option in conjunction with the SQL Transaction log backups.
SharePoint backup / restore (either through the central administration web site or using STSADM utility) will put the farm back together in case of a diaster. SharePoint restore from a SharePoint backup will require the administrator to run through the configuration wizard to build out a new central administration. Once central administration is available, SharePoint restore can run to put all the pieces back together. The SharePoint restore will build out all the IIS virtual server, application pools, web applications, shared service provider, content indexes, and all the links in between.
Once everything is pieced back together SQL backups and be restored over the existing databases that were restored from the SharePoint restore process. Plus the transactions logs can be replayed up to the point of the last transaction log backup.
Now I know your going to say that it sucks because you have to backup in 2 places. Yes this is true, but you only really have to run the SharePoint backup when there is a change to the farm. Changes would included adding a new web application, shared service provider, etc. Also keep in mind that if you will want to backup any changes to the IIS virtual server in case there was host headers and SSL on the site. Plus you will want to make sure you have a backup of any custom solutions and such.
No comments:
Post a Comment