Continuous replication is present in two Exchange 2007 features that use built-in asynchronous replication technology to create a copy of a storage group and maintain the copy's currency through log shipping and replay. Replication facilitates this by applying the log files of a production database to a copy of that database. The two features that contain this technology are local continuous replication (LCR) and cluster continuous replication (CCR).

• Local continuous replication   LCR lowers the total cost of ownership for Exchange 2007 by reducing the number of regular backups that are required for data protection. Although LCR does not eliminate the need to take backups (data backup are important to have if a disaster strikes), it does significantly reduce the need to take regular, daily full backups. LCR provides fast recovery with current data, as well as a single-server solution for transaction log copying and replaying.
  
• Cluster continuous replication   CCR combines automatic management of redundancy and application-level data replication. CCR is a solution that can be deployed without a single point of failure in a single data center or between two data centers. Transaction log replication is used to copy the databases and maintain the concurrency of the data among cluster nodes. The scheduled outage functionality in CCR is designed to make sure that all log data on the active node is successfully copied to the passive node. Therefore, scheduled outages do not result in loss of data, even though replication occurs asynchronously.
  

A single copy cluster is a clustered mailbox server that uses shared storage to allow multiple servers to manage a single copy of the storage groups. This is similar to clustering in previous versions of Exchange Server. However, there are some significant changes and improvements that have been made.

In a single copy cluster, an Exchange 2007 mailbox server uses its own network identity, not the identity of any node in the cluster. This network identity is referred to as a clustered mailbox server. If the node running a clustered mailbox server experiences problems, the clustered mailbox server goes offline for a brief period until another node takes control of the clustered mailbox server and brings it online. This process is known as failover. The storage hosting the clustered mailbox server's storage groups and databases is hosted on shared storage that is available to each possible host node of the clustered mailbox server. As the failover happens, the storage associated with the clustered mailbox is logically disconnected from the failed node and placed under the control of the new host node of the clustered mailbox server.