RTO was briefly mentioned earlier as the interval between when a system fails, and when it should come back online. A best practice is defining multiple RTOs when a critical system is in question. For example, you may have a shorter RTO for server failure or database corruption, but a much longer RTO to deal with natural disasters. You may define a four-hour return to service for anything but the worst disaster. Trying to design a short RTO for a true disaster can spiral costs out of control and may be practically impossible. In addition, it is likely that customers and partners will be more understanding of a 24-hour (or longer) outage due to a natural disaster.

There are exceptions to this, however. Large Internet companies like Amazon and Microsoft have failover datacenters that can provide seamless service switching in the event of a major disaster. But a small engineering firm may simply have backup tapes in a vault that must be restored in a new location on new hardware. The latter might take days to complete, but would be more in line with the risk. Once again, there is no perfect answer for what your RTO should be. Most return-to-service times are in the four-hour range for critical business systems and 24 hours and longer for generic business systems. While we would all like for service restoral times to be shorter, it is rarely practical or cost effective to provide them. The sweet spot for your service restoral should be directly based on the criticality of the service. If your company will go out of business if it is down for 24 hours, then you will require a much more complex system design and failover strategy.

The RPO defines your data loss threshold, measured in time. That is, how much data can you lose when SQL Server fails? Daily backups start becoming obsolete as soon as they begin. If a piece of data changes after it was backed up, you cannot restore that change until after the next backup cycle. If you must minimize the loss of any transactional data, then you must design and maintain for that minimal loss in SQL Server. You must leverage your transaction logs for restore points, and you will probably need to consider SQL Server mirroring or transaction log shipping to protect your content. RPO does not mean you have a minimal RTO. You may log ship all content off-site for protection, but it might take you hours or days to return that content to service. That may be perfectly acceptable for many businesses. Losing data may not be acceptable. Be very direct with the stakeholders about the expected RPO for your SharePoint Server 2007 design.