Understanding Replication Concepts

Continuous Data Protection (CDP) refers to a technology that continuously captures or tracks data modifications by saving a copy of every change made to your data, capturing every version of the data that you save. It allows you to restore data to any point in time. It captures the changes to data and sends them to a separate journal.

CDP-based solutions can provide fine granularities of restorable objects ranging from crash-consistent images to logical objects such as files, mail boxes, messages, and database files and logs.

Traditional backups require a schedule and can only restore data to the point at which it was backed up. CDP does not need a schedule because all the data changes on the source LUN are tracked continuously and sent to a target LUN.

Oracle MaxRep for SAN replicates block-level differences rather than file-level differences. This means that if you change one byte of a 100 GB file, only the changed block is replicated.

CDP technology has the following attributes:

Data changes to a protected primary site are continuously captured or tracked.
All data changes are stored in a secondary Oracle FS System.
Data recovery takes much less time than tape backup or archives.

Disaster Recovery (DR) is the ability to continue work after a catastrophic problem in a critical technology of the company infrastructure. A DR solution using CDP technology replicates your data to a secondary site. In case of disaster, you can get immediate access to the data that was on the primary site up to the moment of the disaster.

Oracle MaxRep for SAN replicates drive level data in three stages:

Resyncing (Step 1): The original data at your source LUN is replicated to the target LUN.
Resyncing (Step 2): All data changes during Resyncing (Step I) are replicated to the target LUN.
Differential Sync: Differential Sync is a real-time process where any change in the source LUN is copied to the target LUN simultaneously.

In case of DR or backup, the restored data must be consistent with the original data. To ensure the consistency of backup data, consistent bookmarks are issued at the source LUN at periodic intervals of time or on demand.

There are three types of consistency:

Consistent: Also called crash consistent. Specifies that all point-in-time LUN information is available. Non-bookmark point-in-time recoveries are Consistent.
File System Consistent: Specifies that the file system has flushed its caches to disk at the time that the bookmark was issued. File system consistency uses host-based Oracle MaxRep agents.
Application Consistent: Specifies that all application data, possibly across multiple volumes and including cached data, is flushed to storage at that point in time and is available. Oracle MaxRep for SAN also provides application consistency through host-based Oracle MaxRep agents.

Only Oracle MaxRep agents that work with an application or file system create bookmarks.

The Retention logs, sometimes called the CDP logs, store information about data changes on a source LUN within a specified time period. This time frame is referred to as the retention window. Consistent points are stored as bookmarks in the retention window. The LUN can be rolled back to any of the application-consistent bookmarks in this retention window.

If application consistency is not needed, the LUN can be rolled back to any point in time of this retention window. Applications that are rolled back without using any bookmarks in this retention window are only crash consistent.

There are four types of retention policies associated with this retention window:

Time-Based

The data in the retention window will be overwritten after the specified time period.

Space-Based

The data in the retention window is overwritten after the space limit is reached within the retention drives.

Time and Space-Based

The data in the retention window will be overwritten either after the specified time or after the specified space is used, depending on what occurs first.

Sparse Retention

For long-term data retention purposes, the sparse policy is used. The sparse policy helps to save space on retention drives and increases the retention window.

Depending on the type of policy enforced, the retention window is maintained by preserving periodic bookmarks while discarding older data changes within the retention log files. Discarding older data makes room for new data changes.

A snapshot is an accessible replica of data from the primary Oracle FS System as it existed at a single point in time in the retention window. There are two types of snapshots: physical snapshots and virtual snapshots.

A physical snapshot is a full copy of the physical LUN. The size of the intended copy must be equal to or larger than the target LUN (in the replication pair).
Note: Mount the physical snapshot from the Oracle FS System where the physical LUN is located.
A virtual snapshot is a virtual LUN. A virtual snapshot is also known as a vsnap. Vsnaps require minimal system resources and load and unload quickly.
Note: Mount a virtual snapshot to the recovery host from the Replication Engine that is hosting the virtual snapshot.

Physical snapshots and virtual snapshots are accessed in one of the following modes:

Read‑Only: Read-only snapshots are for informational purposes and cannot accept or retain writes. The read‑only option is available for virtual snapshots only. Physical snapshots are always read‑write.
Read‑Write: Read-write virtual snapshots accepts and retains writes. This is done by maintaining an archive log on some part of the local drive as specified.
Read-Write-Journaled: For virtual snapshots, read‑write‑journaled mode allows you to roll back the virtual snapshot to a different point in time after you recover your data. The read‑write‑journaled option is available for virtual snapshots only. Physical snapshots are always read‑write.