American Megatrends ManageTrends 2.7, User Manual

Page: 294 / 367

StorTrends® 1300 User’s Guide (StorTrends iTX version 2.7) 276
Journal Assisted Replication
With respect to management, JAR is same as Snap Assisted Replication. JAR too
supports Failover, Fail back and Rollback etc. In JAR, it replicates the IO from the
Journal File instead of Snapshot. As mentioned earlier, IOs are logged into journal with a
snapshot event as base. It means, all IOs that happened between two snapshots are logged
sequentially into Journal File with leading and trailing snap event. Hence replicating all
IOs from between such two snap event has similar effect of replicating data between two
snapshots of a volume. JAR is preferred over SAR when Recovery Point Objective (RPO)
has to be very minimal. JAR also provides another benefit with compare to SAR. In JAR,
remote volume can be in-sync with Primary volume. SAR always relies on volume’s
snapshot in order to replicate data. Unless snapshots are created continuously, SAR
replication cannot happen. Hence, the remote volume always at least lags to Primary
volume by a time last snapshot is created in Primary Volume. In JAR, since replication
happened by the same order at which IOs happened to Primary volume, even the last IO
replicated to Secondary is valid. JAR does not need a closing snapshot in secondary in
order to access Secondary volume.
Create Journal Assisted Replication (JAR)
In order to create JAR, Journal File must have been already created. All the volumes (and
only those volumes) used to create Journal File should be used to create JAR. Thus
Consistency Group is not broken. Select ‘Replication\Asynchronous’ note to proceed to
Replication Wizard