8 Points to Consider Before You Implement SharePoint

If you're using virtualized servers for the SharePoint farm and those servers are on a single virtual server host, it doesn't make sense to break out the different SharePoint server roles on multiple servers, with the exception of separating the database server from the rest of the SharePoint server roles. (This should be done primarily for security reasons.) If you're running virtualized servers for your SharePoint farm and you need high availability and load balancing, make sure you don't have virtualized servers with the same roles running on the same host server. For example, if you want high availability and load balancing for your SharePoint web servers in a virtual environment, make sure that each virtual server is running on a different host. Placing two virtual servers on the same host won't increase fault tolerance because a hardware failure on the host server will cause both virtual servers to go down. In addition, placing two virtual servers on the same host will probably hurt rather than help performance. For comprehensive information about SharePoint farm design considerations, download the free book Planning and Architecture for Office SharePoint Server 2007.

7. Backups
If you're using a SQL Server backup agent, you can somewhat protect a SharePoint installation by either backing up the SQL Server database or dumping the SQL Server database to a file that later gets saved offline. You should backup all the other servers in your SharePoint farm as well. For larger environments that use a SAN, you can take snapshots of the SAN and save them to Just a Bunch of Disks (JBOD) to get around backup time constraints. However, online backups are vulnerable to virus outbreaks and other malware attacks that can potentially leave them useless, so it's important that you copy the snapshot backups to some type of offline media as well.

Most of the major backup software programs now support MOSS 2007-specific backup agents. The advantage of SharePoint-specific backup agents is they offer granular restore and are usually multiserver-farm-aware. Even if you're really good with SQL Server restores, granular restores without a SharePoint-specific backup agent can be tricky. Often I've found that restore requests aren't for the entire SharePoint site but rather for specific subsites or specific content on the portal. This is when these backup agents justify their cost. Although you're somewhat protected with MOSS 2007's Recycle Bin feature, I've run into situations when I still needed to perform a granular restore.

If you have mission-critical data stored on the portal, I suggest purchasing and using backup software that has a MOSS 2007-specific backup agent. I recommend that you either perform a full backup once a week with differential backups during the week or a full daily backup of your SharePoint portal.

8. Disaster Recovery
If you work for a publicly traded company that must be Sarbanes-Oxley (SOX) compliant, it's important to prove that you can recover from a disaster and prove how quickly you can recover. If you've had the unfortunate experience of recovering your SharePoint site after a major hardware failure or disaster, you know it can be challenging. Running a multiserver farm only complicates the restore process. Consider the steps to recover a simple two-server SharePoint farm:

1. Purchase new hardware.
2. Install Server 2008 or Windows 2003 on the database server.
3. Install the backup software.
4. Catalog the tape on the backup server.
5. Install the backup agent on the database server.
6. Restore the programs (including SQL Server) on the database server.
7. Restore the databases on the database server.
8. Install Server 2008 or Windows 2003 on the front-end server.
9. Install the backup agent on the front-end server.
10. Restore SharePoint on the front-end server.
11. 11. Test.

If your SharePoint farm is running virtualized servers, it greatly simplifies the process if you have the virtual server guest images backed up weekly with a traditional backup performed during the week. Consider the following steps using ESX Server as the virtualization platform:

1. Purchase new hardware.
2. Install ESX Server on the host server.
3. Install the backup software.
4. Catalog the tape on the backup server.
5. Install the backup agent on the ESX Server host.
6. Restore the SharePoint farm servers on the ESX Server host and start them.
7. If necessary, restore the latest full or differential backup on the servers. Optionally, restore the latest full or differential backup on the database server.
8. Test.

There are also two major advantages when using virtualization for disaster recovery: There's significantly less administrator involvement during the restore process, and restoring to different host hardware doesn't complicate the process. When using virtualization for disaster recovery, you should be able to reduce the recovery time by at least half compared to restoring the servers on bare-metal.

Take the Time
There are many factors to consider when implementing a SharePoint platform that's optimized for your company. Taking the time to address each factor will help ensure your portal performs well and is easily scalable.