Current architecture: Database Server: two physical servers connected via FC to a SAN Web Front Ends: two physical servers Network Load Balanced, only one of which hosts SharePoint webapp pools including the Central Administration Site. The other physical server has two virtual machines on it, each of which hosts another web front end. I’m being given nothing else but a stand-alone server to create a backup server in another part of the world that we can run everything on in t event the building the current servers run in gets destroyed. I was thinking of installing another web front end on the other/backup server (in a different region entirely) and adding it to the existing farm. So the web app pools would be hosted there, but the database would not be, and neither would the Central Administration site. BUT, I could install a database server on the backup server and restore the backups to it, then install the Central Administration site on the backup server as well and point the MOSS/SharePoint installation at the new database server. Thoughts? Problems? I realize it’s not pretty, I wanted to have another SAN and use virtualization replicating to a backup server off site, but this is all they are willing to give me.

Your disaster recovery plan would entirely depend on your SLA. What kind of data loss can your company live with. If absolute ZERO data loss is required, then you have to do replication or log shipping, but given that you've only been given a single server for disaster recovery, my guess is "Last Night's Backup" is probably your SLA. What I would recommend is that you configure that single server as a single server solution running SQL, CA and WFE all on the same box. Then use your nightly backups, restored to that server, as your fail over. Once you prove it out, it'll be in place and you'll simply have to restore your last database backup to be back up and running. I trust that answers your question... Thanks C http://www.cjvandyk.com/blog

I’m being given nothing else but a stand-alone server to create a backup server in another part of the world that we can run everything on in t event the building the current servers run in gets destroyed. SharePoint farm servers distributed over a long distance WAN link ("stretched farms") are not generally a good idea - you should really have a 1GB/s link between all farm servers with <1ms latency. Generally it is advised to have a backup "farm" rather than adding a distant server to your current farm. You could then either configure SQL log shipping, or simply restore DB backups in the event of disaster if some downtime is acceptable. I think this is what Cornelius is suggesting. Obviously availability is not data protection - you need to have a backup plan (e.g. backup tapes, off-site backups etc) in addition to your DR server. Technet provides some decent information on this at http://technet.microsoft.com/en-us/library/cc748824.aspx#Section4 HTH.Benjamin Athawes Twitter SharePoint Blog

SharePoint farm servers distributed over a long distance WAN link ("stretched farms") are not generally a good idea - But considering that it's my only real option since that's all I'm being given, it should work better than nothing. Our end users are all over the world anyway, and this stand alone backup server would only serve to support critical SharePoint tools in the event the primary servers in the "farm" are down.

Your disaster recovery plan would entirely depend on your SLA. So my plan makes sense then? I figure on a high level overview, this would be the plan: 1) Install MOSS 2007 on that server/join it to the existing SharePoint farm. 2) Install SQL Database Server on that server and restore backups to it. 3) Install the Central Administration application pool on that server so I can log into it in a disaster and point the SharePoint/MOSS 2007 installation to the backup database server. I figure the existing farm where I’m located now is already pointing to the primary database server, and since I can only host Central Administration on one server at a time, I might as well host it on the backup server so that I can get into it and point SharePoint to the new SQL Server rather than the one that was destroyed in whatever disaster might have happened.

What about Network Load Balancing. Do I need to do any configuration for this server to process requests as another web front end?

Here are a few potential issues that I thought of with adding the remote server to your farm (from http://mossblogger.blogspot.com/2010/07/sharepoint-disaster-recovery-on-budget.html): Stretched farms are only a realistic scenario where they are in close proximity with high speed links. That means less then 1ms latency and 1GB/s bandwidth. The SharePoint configuration and central administration content databases contain computer-specific information meaning that the restoration environment must contain the same topology and server roles - which would not be possible on a single server. Aggregate capacity requirements need to be met on the single DR server for the duration of the servers use. This means whatever resources were used on the "live" farm servers need to be available on the standby. Amongst others this includes CPU cycles, RAM, disk capacity, disk IO requirements, and network bandwidth. Point 2 is probably the most important - restoring the configuration and central administration database is not supported given that you are restoring to a completely different topology (standalone vs. 2 DB servers and 3 WFE servers). Basically, my guess would be that you will spend more time attempting to restore everything to the single remote server (without taking into account the added pressure you will have to restore in a DR scenario) than simply having a secondary DR farm in the first place. My recommendation would be: Create a separate DR farm on your standalone server and apply all Windows, SQL, WSS and MOSS updates to match that of the live environment as closely as possible. Deploy all SharePoint customisations to the DR farm Create and configure all Web applications to the DR farm, restoring all content databases from the live farm. Test it! I hope that makes sense. Benjamin Athawes Twitter SharePoint Blog

What about Network Load Balancing. Do I need to do any configuration for this server to process requests as another web front end? User requests wont be sent to your DR server unless you modify the relevant DNS entries. That means that you public DNS record(s) need to be changed to point to your DR server which could take time to propagate. I am assuming here that you mean that the DR server should only serve content in the event of disaster. If you are suggesting the server be load balanced with the rest of your farm servers (at the other location) you will have serious performance issues (potentially to the point that the site(s) are unusable) as detailed in my previous response. Like I say, I suggest you set up a separate DR farm and test outside of a DR scenario. HTH.Benjamin Athawes Twitter SharePoint Blog

Here are a few potential issues that I thought of with adding the remote server to your farm (from http://mossblogger.blogspot.com/2010/07/sharepoint-disaster-recovery-on-budget.html): Stretched farms are only a realistic scenario where they are in close proximity with high speed links. That means less then 1ms latency and 1GB/s bandwidth. The SharePoint configuration and central administration content databases contain computer-specific information meaning that the restoration environment must contain the same topology and server roles - which would not be possible on a single server. Aggregate capacity requirements need to be met on the single DR server for the duration of the servers use. This means whatever resources were used on the "live" farm servers need to be available on the standby. Amongst others this includes CPU cycles, RAM, disk capacity, disk IO requirements, and network bandwidth. Point 2 is probably the most important - restoring the configuration and central administration database is not supported given that you are restoring to a completely different topology (standalone vs. 2 DB servers and 3 WFE servers). Basically, my guess would be that you will spend more time attempting to restore everything to the single remote server (without taking into account the added pressure you will have to restore in a DR scenario) than simply having a secondary DR farm in the first place. My recommendation would be: Create a separate DR farm on your standalone server and apply all Windows, SQL, WSS and MOSS updates to match that of the live environment as closely as possible. Deploy all SharePoint customisations to the DR farm Create and configure all Web applications to the DR farm, restoring all content databases from the live farm. Test it! I hope that makes sense. Benjamin Athawes Twitter SharePoint Blog Thanks Benjamin. So it sounds like you're saying I should just do a brand new installation of SharePoint on the stand alone/backup server, moving any custom web parts to the new installation, and attach the content databases from the primary farm to the DR "farm"? My only concern with this is how this would all be done. Will attaching the primary farms conent databases to the DR farm provide the same URL as the primary farm when users go to the SharePoint site? This seems a bit more complicated and out of my comfort zone than adding another server to the farm and I'm not entirely sure what all the steps involved are.

What about Network Load Balancing. Do I need to do any configuration for this server to process requests as another web front end? User requests wont be sent to your DR server unless you modify the relevant DNS entries. That means that you public DNS record(s) need to be changed to point to your DR server which could take time to propagate. I am assuming here that you mean that the DR server should only serve content in the event of disaster. If you are suggesting the server be load balanced with the rest of your farm servers (at the other location) you will have serious performance issues (potentially to the point that the site(s) are unusable) as detailed in my previous response. Like I say, I suggest you set up a separate DR farm and test outside of a DR scenario. HTH. Benjamin Athawes Twitter SharePoint Blog Yes, I really only need it to server content in the event of a disaster, so I really don't need NLB. Since that is the case, as long as I get the server running, I should be OK?

I think you have understood correctly. Remember one key point - your DR farm needs to have the same patches as your live farm - e.g. Windows updates, WSS, MOSS and any accompanying hotfixes. You should hopefully be able to mitigate your concerns around restoration by testing the DR farm. You can test your DR farm by doing a dummy DR scenario, i.e: Take your most recent content database backups Restore them to SQL server on the DR server Take your most recent 12 hive backups (if you have any custom style sheets, images etc.) Restore the 12 hive customisations to the DR server Re-create each Web application on the DR farm with the same URL that you use on the live server (URLs can be configured in Alternate Access Mappings). Re-direct your client to the DR server (e.g. by using a modified hosts file) Test! Of course you will likely run into problems - but the beauty of this is that you can test outside of a DR scenario. We try to do this at least once every year to ensure we have a robust recovery strategy. HTH! Benjamin Athawes Twitter SharePoint Blog

Based on my impression that a few hours downtime (or however long it takes you to recover your farm to the DR server and for DNS to propagate) is probably ok, you should be fine.Benjamin Athawes Twitter SharePoint Blog

Based on my impression that a few hours downtime (or however long it takes you to recover your farm to the DR server and for DNS to propagate) is probably ok, you should be fine. Benjamin Athawes Twitter SharePoint Blog They gave me a requirement of 4 hours max downtime. Sucks. This is gonna be more involved than I expected.