Repostor Backups

Do you want to learn why Database backups are different from file backups? Click HERE to find out.

Do you want to learn why
Database backups
are different from file backups?
Click HERE to find out.

HDS True Copy

TrueCopy mirrors data volumes between two HDS VSP storage subsystems. The mirroring is synchronous, so the two subsystems need to be within Metropilitan distances. TrueCopy ensures that the data stays synchronised as the host will not consider an I/O to be complete until acknowledgement is received from the remote storage system.

Configuring TrueCopy

To configure TrueCopy you run through the following steps

HDS Universal Replicator

HDS Universal Replicator is an asynchronous remote mirroring product. Mirroring products require 2 sets of volumes, Primary Volumes in a local site and Secondary Volumes in a remote site. The data on the Secondary Volumes is generally used for disaster recovery purposes and so kept in step with the primary volumes. HDS Universal Replicator (HUR) is intended to be used when the local and remote sites are too far apart for the data to be absolutely identical, as this requires that application update activity at the local site is held until the update reached the remote site. Instead, I/Os are marked complete as soon as they reach the primary disks, then transferred seconds later to the remote site. This is called Asynchronous Mirroring. The trouble is that the I/Os to the remote site must be prresented in the same consistent order as they were at the primary site.
To achieve this, HUR uses a journalling system. Write I/Os to the primary disk subsystem are written to both the primary disk and a Master Journal volume where they are time stamped. These writes are then mirrored over the comms links to the remote site, to a Restore Journal disk, and then copied onto the Secondary Volumes in the correct order. The data on the Secondary Volumes will lag behind the Primaries by a few seconds, the exact RPO will depend on the speed of the links and the distance between sites.

The Secondary Volumes must first be populated by copying all the data over from the Primary Volumes, and the Secondary Volumes cannot be mounted to hosts to preserve the data integrity. Once the data is copied and mirroring commences, the pairs can be split and the Secondary Volumes write enabled so that the DR position can be tested. While a split is in progress, bit maps are maintained at both sites so that mirroring can be resumed again without needing a fresh copy of the data, just those changed blocks need to be copied.

HUR with TrueCopy and ShadowImage

True Copy (TC) can be combined with Universal Replicator (UR), the asynchronous solution, in the following configurations.

HUR would typically be used with TrueCopy in a 3 site configuration, where TrueCopy is used for synchronous mirroring between two quite local sites and HUR is used to mirror data to a third, very remote site.
This can work in a cascade configuration, whith a Truecopy P-VOL in the Primary site, mirrored to an S-Vol in the intermediate mirror site. This S-VOL also acts as a P-VOL for HUR, and is associated with a Master Journal. The Master Journal is replicated to a Restore Journal at a third, remote site, where the data is transferred to an S-VOL.
The other option is a multi-target configuration, where the P-Vol at the Primary Site is synchronously mirrored to an S-VOL at a secondary Site, and is also associated with a Master Journal. The Master Journal is replicated to a Restore Journal at a third, remote site, where the data is transferred to an S-VOL.

When HUR is used with ShadowImage, the Shadow Copy is usually create at the Remote site for testing. You can then suspend the mirroring, create the ShadowImage, then resume mirroring with very little loss in DR postion. You now have a complete and independent copy of the data at the remote site for testing.
The other use of ShadowImage, would be a local copy taken at the Primary site. This would typically be used for local backups. It should not affect the HUR process, unless you decide to copy the ShadowImage back onto the primary disk. This would cause an I/O surge that could overwhelm your journal disks.

HUR Volume States

The primary volumes are called P-VOLs and secondarys are called S-VOLs. The allowed status for a volume are

indicates unpaired volumes. Both primary and secondary are R/W enabled
means volumes are paired and the initial copy is complete. The pimary disk is R/W enabled while the secondary is read only (but S-VOL read is always disabled if the paircreate command was run with the -m noread option)
means volumes are paired but the operation, which can be copy, pairsplit, or resync, is not complete. The primary disk is R/W enabled while the secondary is read only
indicates that the volumes are in a paired state, but updates to the S-VOL data are suspended due to a user-requested pairsplit. The hardware keeps track of updates to the P-VOL so they can be applied to the S-VOL if the pair is re-established. If the pairsplit command used the write-enable option to enable writes to the S-VOL, then these updates are also tracked while the pair is split. The pimary disk is R/W enabled and the Secondary is either read only or read/write depending on the split parameter.
means that an error has happened and mirroring is suspended. When the error is corrected and mirroring re-snychronised, the entire P-VOL is copied over to the S-VOL. If there were no errors on the P-VOL, then it will be in R/W status.

HUR Functions

Creating a Mirrored Pair

You need to know the port, GID and LUN of the volumes that you wish to pair. Once you have that information, select your P-VOL and S-Vol using those numbers. Then select a Master Journal, Restore Journal and Mirror ID to associate with this pair. You then need to specify a consistency group number, and HDS recommends you make this the same as the journal number. Select your copy method, which will probably be ENTIRE if this is the first time. There are other parameters available, but you can take the defaults. Of course, you can run this process for several volumes at once.

You can use the GUI or the pairdisplay command to monitor the mirroring status of volumes, including progress of any volumes being mirrored or resynchronized. The -g group_name option is used to display all disks in a group and the -l option is used if only one of the sites is available

pairdisplay -g GRP

Splitting Pairs

Once mirroring is established and the pairs are in COPY or PAIR ststus, you can split a pair to give you a PIT copy of the P-VOL. If you then write-enable the S-VOL you can bring it online to a host for testing purposes. An effective way to utilise this is to take a ShadowImage copy of the S-VOL, then you can resume mirroring and still have a copy of the data for testing.
When a split command happens, the journalled write data is nolonger sent to the S-Vol and the volume status changes from PAIR to PSUS or SSUS as appropriate. However the pair relationship is maintained and updates from both sides are recorded for future resynchronisation.
If your volume is part of a mirrored group, then you need to split the whole group to get a consistency point between the disks in the group.

When you are ready, you can re-establish the secondary volume as a synchronised copy of the primary volume. This is done by merging the bit-maps that were maintained while the split was in operation, so that updated data on the S-VOL is back levelled from the P-VOL and also any updates made at the P-VOL are copied over too.
Again, if your volume is part of a mirrored group, then you need to resynchronise the whole group.

back to top

Remote Data Mirroring

Lascon latest major updates