text: Figure 11-14 A reverse FlashCopy example for data restoration 
  
  This example assumes that a simple FlashCopy mapping was created between the “source” 
  volume and “target” volume, and no background copy is set. 
  
  When the FlashCopy mapping starts (Date of Copy1), if source volume is changed (write 
  operations on grain “A”), the modified grains are first copied to target, the bitmap table is 
  updated, and the source grain is modified (from “A” to “G”). 
  
  At a time (“Corruption Date”), data is modified on another grain (grain “D” below), so it is first 
  written on the target volume and the bitmap table is updated. Unfortunately, the new data is 
  corrupted on source volume. 
  
  The storage administrator can then use the Reverse FlashCopy feature by completing these 
  steps: 
  
  1. Creating a mapping from target to source (if not created). Because FlashCopy recognizes 
  that the target volume of this new mapping is a source in another mapping, it does not 
  create another bitmap table. It uses the bitmap table instead, with its updated bits. 
  
  2. Start the new mapping. Because of the bitmap table,*only the modified grains are copied*. 
  
  After the restoration is complete, at the “Restored State” time, source volume data is similar to 
  what it was before the Corruption Date. The copy can resume with the restored data (Date of 
  Copy2) and, for example, data on the source volume can be modified (“D” grain is changed in 
  “H” grain in the example below). In this last case, because “D” grain was copied, it is not 
  copied again on target volume. 