Disaster Recovery Terminology

Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

 

Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3

Make sure that you are familiar with the following terms. You can find additional terms that are specific to Microsoft Exchange in the Exchange Server 2007 Glossary.

  • (ESE) Database
    An Extensible Storage Engine (ESE) database used by Exchange.
  • (ESE) Logs
    The logs used by ESE to provide atomicity, consistency, isolation, and durability (ACID) characteristics.
  • (Remote) copy
    A storage group or database copy that is maintained by another server in the cluster.
  • active copy
    The master, mountable copy for the storage group. This copy represents current content of the other copies of the same storage group.
  • back up
    (verb) To create a copy of a database or other system component by preserving the actual files that make up that component. These files are typically stored in a different location, such as on specialized storage media.
  • backup
    (noun) The file or other media, typically compressed, that stores files that have been backed up.
  • backup job
    The act of backing up a set of files at the same time.
  • boot partition
    The hard disk partition where the Windows Server 2003 operating system is installed. This partition contains the %systemroot% folder and the %programfiles% folder.
  • checkpoint file
    A file that tracks the progress of transaction logging. The checkpoint file has a pointer to the oldest log file that contains data that has not yet been written to the database. The name of the checkpoint file is Enn.chk, where Enn is the log file prefix of the storage group.
  • clean shutdown
    Whenever a database is shut down, a flag in the database header keeps track of whether the database did the required maintenance to put the database in a consistent state. A database that was shut down in a consistent state is referred to as being shutdown clean.
  • clone
    A Volume Shadow Copy Service (VSS) concept where a complete copy is created of a set of files. The content of files reflects a particular point in time.
  • consistent state
    If the database is in a consistent state, the database can be remounted without any kind of transaction log replay. The database successfully detached from the log file stream when it was shut down. Such a database can be mounted and attached again to the log stream without requiring additional transaction log replay. Changing a database from an inconsistent state to a consistent state generally involves two processes: Restoring the database from a backup that was completed while the database was online, and replaying the transaction log files into the restored database.
  • continuous replication
    An asynchronous replication-like technology that creates a copy of a storage group and maintains its currency through change propagation. This feature includes local continuous replication and clustered continuous replication.
  • copy
    A replica of one or more files. In the context of disaster recovery, the term copy applies to a storage group.
  • database
    In the context of disaster recovery, database is a generic term that refers to either a mailbox store or a public folder store. An Exchange database is composed of both information in memory and the database files on the disk. If the information in memory is lost before it is written to the database files on the disk, it can be replayed from the transaction log files.
  • dirty shutdown
    When a database is shut down before you have performed required maintenance, it is put into an inconsistent state. This kind of shutdown is flagged as a dirty shutdown. This term means that some transaction log files must be replayed before the database can be considered consistent. You cannot mount a database that was shut down in this state until the transaction logs have been replayed and the database has correctly detached from the current log stream.
  • Extensible Storage Engine (ESE)
    The database engine that Exchange uses. ESE is a multi-user Indexed Sequential Access Method (ISAM) table manager with full data manipulation language (DML) and data definition language (DDL) capabilities. Applications such as Exchange use ESE to store records and create indexes.
  • full computer backup set
    You create a full computer backup set when you back up your Windows Server 2003 operating system files, including the System State data and all the applications that you have installed on the server. You must back up these files as part of the same backup job.
  • hard recovery
    Hard recovery is the process that changes a restored database back to a consistent state by playing transactions into the database from transaction log files. To initiate hard recovery, you select the Last Backup Set check box in Backup when you restore your last database, or you can uses the eseutil /cc command. The hard recovery process uses a RESTORE.env file that is generated during the recovery process to determine how to restore the database files and what transaction log files must be replayed from the temp directory that the backup was restored to. After the databases are copied to their original location, and the transaction log files from the temp directory are replayed into them, hard recovery continues to replay any additional transaction log files that it finds in the transaction log file path specified for the storage group of the restored database. The soft recovery process also replays any additional transaction log files that it finds.
  • healthy copy
    A state of a storage group copy that indicates that logs are being applied to reflect changes into the storage group. A copy that is fully seeded, has a valid, non-corrupted log stream, and can have successful log replay operations performed.
  • inconsistent state
    If the database is in an inconsistent state, which is referred to as a dirty shutdown, it cannot be remounted. A database in an inconsistent state has not been detached from the transaction log stream, and it can be mounted only after the appropriate transaction log replay has been performed. After the replay, the database is detached from the log stream and left in a consistent and mountable state.
  • Local copy
    A copy that is maintained by the same server as the production storage group.
  • mailbox store
    A database for storing mailboxes in Exchange. Exchange mailbox stores contain data that is private to a user, and they also contain mailbox folders generated when a new mailbox is created for a user.
  • mounted drive
    A mounted drive is a drive that is mapped to an empty folder on a volume that uses the NTFS file system. Mounted drives function like other drives function, but they are assigned drive paths instead of drive letters. You can use a mounted drive to add another drive to a computer with all 26 possible drive letters already used, or to extend the size of a volume without having to re-create the volume on a larger disk.
  • offline backup
    A backup made while the Exchange services are stopped. When you perform an offline backup, users do not have access to their mailboxes.
  • online backup
    A backup made while the Exchange services are running.
  • physical corruption
    The data content of a file that does not read or correctly validate.
  • point-in-time copy
    A particular version of a copy created by a VSS snapshot or clone operation for the purposes of verification or data access.
  • public folder store
    The part of the Exchange store that maintains information in public folders.
  • recovery
    When it refers to Exchange databases, recovery means to replay transaction log files into a restored database. This action brings the database up-to-date. There are two distinct forms of recovery: soft recovery and hard recovery.
  • replay
    A process in which Exchange examines the transaction log files for a storage group to identify transactions that have been logged, but they have not been incorporated into the databases of that storage group. This process, also known as playing back log files, brings the databases up-to-date with the transaction log files. The operation of applying log files to a database to advance its content to a different state.
  • resource groups
    In a cluster, resource groups are collections of resources that are managed as a single unit. During failover, the whole resource group is moved from the failed node to an available node.
  • restore
    To return the original files that were previously preserved in a backup to their location on a server.
  • seed
    The baseline content of a storage group used to start replay processing.
  • snapshot
    A VSS concept where a copy on a write version of a set of files is created. The content of files reflects a particular point in time.
  • soft recovery
    An automatic transaction log file replay process that occurs when a database is remounted after an unexpected stop.

    The soft recovery process only replays logs from the transaction log file path specified for the storage group that contains the affected databases. Affected databases are described as having been shut down in a dirty state. Soft recovery uses the checkpoint file to determine which transaction log file to start with when it sequentially replays transactions into databases. This process makes the databases up-to-date with all recorded transactions.

  • storage group
    An Exchange concept that identifies a set of databases.
  • system partition
    The disk partition from which your computer starts. This partition contains files in the root directory such as NTLDR and BOOT.ini.
  • transaction log files
    Files that contain a record of the changes that were made to an Exchange database. All changes to the database are recorded in the transaction log files before they are written into the database files. If a database shuts down unexpectedly, unfinished transactions can be restored by replaying the transaction log files into the database.
  • Volume Shadow Copy Service
    The Volume Shadow Copy Service (VSS) is a service in Windows Server 2003 and Windows Server 2008. It is a framework that facilitates communication between applications such as Exchange 2007, storage subsystems, and storage management applications (including backup applications) in order to define, persist, and exploit point-in-time copies of storage data.
  • VSS
    See Volume Shadow Copy Service.
  • Windows backup set
    The most basic collection of files and folders that is required to preserve a backup of the Windows Server 2003 operating system. This collection includes all the files and folders that Windows created in both the boot and system partitions. The collection also includes the System State data that are preserved together with the Windows Server 2003 operating system files and folders in the same backup.