SharePoint disaster recovery is a complex subject and one you should give some serious though.
There are several methods to backup your environment, and one would need a spreadsheet to identify the advantages and disadvantages of each method. I can only tell you that no backup method is perfect when you're talking about large volumes of SharePoint sites.
Before we can talk about the methods, there are much more important things to define like your RTO, RPO and RLO?
- RTO - Recovery Time Objective
- RPO - Recovery Point Objective
- RLO - Recovery Level Objective
Which all combined will mean that you will recover X many components of your farm, in Y hours and will loose the last Z hours of content changes.
Example: In the event of a disaster I want to get my content [SQL content DBs] available for users (RLO) in 2 hours (RTO) and don't mind loosing the last hour of content changes (RPO).
Other components of the farm can have diferent objectives, some of my clients don't backup some of the service applications, they've assumed that those will be rebuilt as part of the disaster recovery plan.
The more components you want to recover the more it will cost you to implement a disaster recovery plan. Reducing the time it will take you to get up and running will increase cost and reducing the amount of lost data will also increase cost.
If you want to backup everyting, are not prepared to loose anything and want to be up and running in no time, be prepared to spend some serious money. The kind of money that will make your CFO turn blue, then red, then green...
Let me ask you a few questions:
- Do you have a fully redundant farm: SQL cluster, multiple app servers and multiple WFEs?
- Do you plan on having a cold, warm or hot standby farm?
- Do you have any custom solutions installed on your servers?
- Do you have External BLOB Storage enabled?
And for the methods:
A SQL backup is good for content DBs but that's about it, if your content DBs change alot but your configurations don't, then a regular SQL backup (full / diff) of the content DBs combined with a farm backup (using PowerShell) will get you up and running.
Forget the windows backup for SharePoint farms, it's not even supported by Microsoft
PowerShell backups are a good option, the Backup-SPFarm command will let you choose either full or incremental backups, choose the components you want to backup and will let you choose if you want configuration only or both configurations and data.
System Center Data Protection Manager - All singing all dancing backup & restore solution!
Because you can specify the granularity of your backup using the PowerShell command, it's a much more versatile method.
Note that if you never touch your 14 hive (and you shouldn't) and all your custom solutions are deployed via solution packages, these will be stored in the configuration DB, so there is little need to backup the windows file system, if any.
On the other hand, restoring Search Service Applications and User Profile Service Applications is a nightmare on its own, and I'd define diferent RTOs for these.
For PowerShell backup see the command Backup-SPFarm: http://technet.microsoft.com/en-us/library/ff607881.aspx
Also see Backup-SPSite and Backup-SPConfigurationDatabase.
There is a lot to think about, and before you decide on how you want to backup your farm, decide what you want to backup, what you can afford to loose and how long your customers can have they're services unavailable and which services.
Make a good plan and that you can start thinking about methods. What I descrived above is a very brief idea of what you can and should do.
Last but not least, test your backups in your target recovery farm. Are your backups secured?
Are you able to use your backups to recover any data? Do you know how long it takes to restore your data if the backup took five days?
