What BCV and 2-Way-Mirror are and how to use them

> BCV is not RAID-1, right?

Correct, RAID1, RAID5, etc are methods for providing basic protection for a data volume by spreading elements of the data over multiple physical disks.

BCV (Business Continuity Volume) is a method for making a byte for byte copy of a running data volume that can be mounted on another host and used independently of the source volume.

A BCV is a specific implementation of a "Local Copy". A long time ago the implementation of BCV was bound up with mirroring protection; this is no longer the case although the terminology is often still mixed. Nowadays the local mirror can be a complete standalone copy of the original on its own disk, a clone, or it can be a snap copy only recording differences as changes are made to the source and the copy (target) volume.

Typical uses of local snap and clone copies are to make copies of real databases for application testing or for off-line backup.

For application testing with real world data a local copy is made and mounted on a test host during testing, after testing the content of the copy is refreshed from the real database ready for the next series of tests. A modern Symmetrix array will make the refresh appear instantaneous. The actual refresh is incremental, only changed areas of the volume will be updated.

For backup a mirror copy of the production system is made and the backup is made from the copy later at some appropriate time. If a backup is made directly from a production system it can slow the production system for hours. The mirror takes a moment to refresh and the production system can continue its work unimpeded. The backup made from the mirror disks can also be faster than a standard production backup because the mirror volumes are not impeded by having to support production.

Gold Copy I: For creating a repeatable testing environment a mirror copy (gold copy) could be made of a production database at a given point in time. Subsequently a work copy of the gold copy could be made to run testing and, at the end of each test session the test copy could be refreshed from the "gold" copy so that tests always begin from the same logical point in time.

Gold Copy II: before making changes/updates to a system make a local “Gold” copy. If the system fails after the update for any reason, simply restore the original state of the system back from the gold copy.

Typically clones are to be preferred if the copy will be used intensively as the clone is independent of the source volume.

Snaps make use of the real source volume to provide data that are not changed and their use has a performance impact on the source and copy volumes. The benefit of the snap is that it saves disk space.

> What happens if a source device fails? Does BCV automatically replace anyhow the broken STD with itself? If not, what do we need to do with the BCV to replace the broken STD with it? Or do we need to restore a BCV onto another STD in order to get a properly functioning STD?

Typically the source device is protected by its own RAID protection, and the local copy will not be required to provide low level protection against disk failure.

On the other hand, local mirrors are important as a rapid recovery mechanism for logical problems that may occur in an application’s data.

If you make a local copy say four times a day and keep all four copies available in the array then, if an event occurs in the application say due to a programming or other data corruption, then you will have four backups that can be almost instantly brought on line to roll the system back to a previous point in time.

> Could you bring any handy examples of using BCV?

See examples above.

> 2-Way-Mirror is RAID-1 in terms of EMC? How data on a 2-Way-Mirror is redistributed across physical drives?

Yes a 2-Way Mirror is another way of saying RAID1. When say a 10GB volume is created a 10GB volume is created on one disk and another 10GB from another disk is linked to it to provide the full RAID1 protected volume.

> Couldn't it happen that one physical drive stores blocks from both parts of our mirror (the same blocks needed to provide data redundancy)?

No - The software in the array ensures that the different copies of the data land on different physical volumes.

Can we use 2-Way-Mirrors and BCVs in a completely thin provisioned environment? Does Enginuity have mechanisms ensuring that mirrored blocks of our hypothetical 2-Way-Mir+TDEV and BCV+TDEV do not reside on the same physical drive? If so, how it can be useful and what are the steps of creating such devices?

In a modern Symmetrix system and certainly in the Thin environment forget about BCVs, the Local Mirrors are simply thin volumes (TDEVs) used as local mirror devices, you don't need to think about 2-way-mirrors and BCVs, etc.

The primary volumes and the local mirror volumes are protected by the underlying RAID protection in the Thin Pool, R1, R5, and R6. The device level protection is determined by the RAID type chosen for the TDATs, the Data Devices on which the Thin Pools are created.

As with creation of thick devices the array itself ensures that provisioning rules for creation of TDATs are obeyed and that the data elements of a given device cannot be created on the same physical disk. 

Regards,

Andy