HP StorageWorks Storage Mirroring Recover Scripting Guide (T5437-96022, November 2010)

Inserting tasks during replication
Task command processing is a Storage Mirroring Recover feature that allows you to
insert and run tasks at various points during the replication of data. Because the tasks
are user-defined, you can achieve a wide variety of goals with this feature. For example,
you might insert a task to create a snapshot or run a backup on the target after a certain
segment of data from the source has been applied on the target. This allows you to
coordinate a point-in-time backup with real-time replication.
Task command processing can be enabled from the Management Console, but it can
only be initiated through a scripting command.
If you disable this option on a source server, you can still submit tasks to be processed
on a target, although task command processing must be enabled on the target.
Because Storage Mirroring Recover replication follows the same write sequence within
and across multiple files, it provides complete data integrity at all times. At any given
moment, the target represents a single point in time from the source, which makes the
target crash consistent. But for some applications, crash consistency may not be
adequate. You may require that the source data be in a quiescent (latent) state, similar to
an application checkpoint. You need to be able to identify when the application is stable,
which is usually when all of the data has been written to disk. This can be triggered by
stopping the service. With task command processing, you can stop the source service
just long enough to identify that stopped point in time as a stable state, insert a task at
that point into the Storage Mirroring Recover replication queue to trigger a backup or
snapshot on the target, and then restart the service. Here is how the process would work.
1. Storage Mirroring Recover and an application are both running on the source. Only
Storage Mirroring Recover is running on the target.
2. The application data is changing on the source and Storage Mirroring Recover is
capturing those data changes and transmitting them to the target.
3. A script is launched (either manually or perhaps scheduled by the Windows
Scheduler) that stops the application service on the source, pauses to give the
service time to shutdown and write the data to disk, initiates a Storage Mirroring
Recover task command, and then restarts the application service on the source.
4. The Storage Mirroring Recover task command is transmitted, inline with the source
replication data, to the target.
5. The data is applied on the target as it is received. Since the task command was
inserted inline, the replication data from the source is applied to the target first.
When the target gets to the Storage Mirroring Recover task command, the target
data will be in the exact same state as the source data when the source application
service was stopped. Since this was a stable point on the source, it is also a stable
point on the target.