Real-Time Replication (Beta) Job Wizard for VMware: Retention

To allow replica rollback to a point in time your product keeps an I/O Journal of all I/O activities. This can be defined on the Retention page of the wizard by configuring the Recovery Point Objective (RPO) and I/O Journal settings as described in the sections below:

RPO

In the RPO section, configure the following parameters:

  • Recovery point objective: Set the target amount of time between recovery points creation (between 1 second and 60 minutes) for the creation of subsequent recovery points.

    Notes

    The RPO elements are:

    • Now - the current time. Current RPO is calculated on the target side (Journal Service) as time between the last source data capture and the previous source data capture

    • Last received time - the time when the last heartbeat was received by the Journal Service.

    • Last captured data time - the time when the last portion of source VM data was captured by the I/O Filter Daemon (a single instance of the I/O Filter software which is running on a specific ESXi host of the cluster).

    • Last recovery point time - the time when the last recovery point was created in the I/O Journal.

  • Fail VM replication if RPO exceeds: Optionally, select this option to fail and retry real-time replication job for VMware if the RPO exceeds a specified period of time. The set time cannot be lower than the selected Recovery point objective and cannot exceed 60 minutes.

    Failed VMs and VMs with missed RPO will appear in red on top of the list.

    Important

    Make sure the time on the source ESXi host(s) and the target Transporter VA is synchronized.

    Otherwise, the RPO value and/or recovery point date-time data may be incorrect. Also, the Real-Time Replication Failover Job Wizard for VMware process may yield the incorrect recovery points.

    If the job is not running (is created/stopped), the "No data" message will be displayed.

    If the job is running:

    • During initial and incremental replication, the "No data" message will be displayed.

      Notes

      • Initial replication - snapshot based full regular replication.

      • Incremental replication - snapshot based incremental regular replication.

    • During real-time replication process and when the RPO data is available, the current RPO will be displayed.

      Note

      Current RPO is calculated as time between the last source data capture and the previous source data capture.

Notes

The RPO data will be displayed as:

  • If time span <= 1 minute: "Xs".

  • If time span =< 1 hour and > 1 minute: "Xm Ys".

  • If time span =< 1 day and > 1 hour: "Xh Ym Zs".

I/O Journal

I/O Journal is a per disk set of records of I/O operations that keeps recovery points of a replica VM and can be used for failover to a point in time.

For every real-time replication run, a new Journal Extent is created in the I/O Journal. Each Journal Extent contains one or more Frames (internal logical parts of the Journal Extent containing up to 256 MB of data).

Configuration changes made to the source VM (if any) are checked every 15 minutes, and saved to the replica configuration journal. If no data changes on the Source VM are detected, the source I/O Filter Daemon will keep sending heartbeat messages to the target Journal Service.

Notes

If the connection from the source I/O Filter to the Journal Service (target) is lost:

  • I/O Filter keeps capturing the data on the source and caching/storing it locally.

  • I/O Filter keeps trying to re-connect to the Journal Service (target).

  • After the connection is restored, the data is sent to the Journal Service (target).

In the I/O Journal section, configure the following parameters:

  • Journal history limit: Optionally, select this option to set a limit for journal history, which is between 1 hour and 30 days.

  • Journal size limit: Set a limit for the journal size per disk between 1 GB and 20 TB.

    Note

    The journal size will be limited to the set value per VM. If the existing journal size is smaller than the limit specified in the job, it can be extended. Changing the existing journal to a smaller size is not applicable.

When the journal history limit is reached or when the I/O Journal has under 512 MB of free space, the following occurs:

  • If the replica I/O Journal contains multiple Journal Extents, the oldest Journal Extent is removed.

  • If the replica I/O Journal contains only one Journal Extent, its oldest Frame is applied to the replica. Afterwards, the oldest frame is overwritten by a new Frame.

  • If the replica I/O Journal contains only one Journal Extent with only one Frame, the Frame is not applied to the replica.

    Note

    For example, if the size of the single Journal Extent Frame (256 GB) is not reached within 1 hour (the specified journal history limit), the data allocated within this Frame will not be merged and the recovery points of a replica VM that were created according to the RPO setting will not be deleted.

    In this case, the data merge process to the replica will continue until the I/O Journal frame size (256 GB) is reached during the subsequent time frame.

    In case the size of the single Journal Extent Frame (256 GB) is reached within the next time frame, a new Frame will be generated and the recovery points created before the second Frame generation will be deleted.

For more information on the above terminology, see Installing the Journal Service.