IBM flashcopy

随手记的一些东西.

1.fashcopy

2.fashcopySE

 

IBM FlashCopy

Both FlashCopy and FlashCopy SE can coexist on a DS8000

Standard FlashCopy uses a normal volume as target volume. This target volume has to

have the same size (or larger) as the source volume and that space is allocated in the

storage subsystem.

 

FlashCopy SE uses Space Efficient volumes as FlashCopy target volumes. A Space Efficient target volume has a virtual size,that is equal to or greater than the source volume size. However, space is not allocated for this volume when the volume is created and the FlashCopy initiated. Only when updates are made to the source volume, any original tracks of the source volume that will be modified are copied to the Space Efficient volume. Space in the repository is allocated for just these tracks (or for any write to the target itself).

 

FlashCopy

_ Incremental FlashCopy (refresh target volume)

_ Multiple Relationship FlashCopy

_ Consistency Group FlashCopy

_ Establish FlashCopy on existing Metro Mirror or Global Copy primary

_ Persistent FlashCopy

_ Remote FlashCopy

_ Reverse restore

 

 

FlashCopy SE

Multiple Relationship FlashCopy SE

Consistency Group FlashCopy SE

FlashCopy SE target as a Metro Mirror or Global Copy primary

Incremental FlashCopy

Remote FlashCopy SE

Persistent FlashCopy SE

Reverse restore and fast reverse restore of FlashCopy SE relations

 

 

 

Incremental FlashCopy (refresh target volume)

Refresh target volume provides the ability to refresh a LUN or volume involved in a

FlashCopy relationship. When a subsequent FlashCopy operation is initiated, only the tracks

changed on both the source and target need to be copied from the source to the target. The

direction of the refresh can also be reversed.

When using the Incremental FlashCopy option, this is what happens:

1. At first, you issue full FlashCopy with the change recording option. This option is for

creating change recording bitmaps in the storage unit. The change recording bitmaps are

used for recording the tracks which are changed on the source and target volumes after

the last FlashCopy.

2. After creating the change recording bitmaps, Copy Services records the information for

the updated tracks to the bitmaps. The FlashCopy relationship persists even if all of the

tracks have been copied from the source to the target.

3. The next time you issue Incremental FlashCopy, Copy Services checks the change

recording bitmaps and copies only the changed tracks to the target volumes. If some

tracks on the target volumes are updated, these

 

 

 

With Incremental FlashCopy, the initial FlashCopy — copy or nocopy — relationship between

a source and target volume is subject to the following (see Figure 8-3):

_ FlashCopy with nocopy option

If the original FlashCopy was established with the nocopy option, then the bitmap for the

target volume will be reset, and of course, the updates on the target volumes are

overwritten. However, using the incremental option will automatically convert this

relationship to a copy relationship, and the background copy will begin.

_ FlashCopy with copy option

If the original FlashCopy was established with the copy option (full volume copy), then the

updates that took place on the source volume since the last FlashCopy will be copied to

the target volume. Also, the updates done on the target volume will be overwritten with the

contents of the source volume.

When initializing a FlashCopy with Start Change Recording activated, a second and third

bitmap will be used to identify writes done to the source or the target volume (see Figure 8-4).

All three bitmaps are necessary for incremental FlashCopy:

_ Target bitmap: This bitmap keeps track of tracks not yet copied from source to target.

_ Source Change Recording bitmap: This bitmap keeps track of changes to the source.

_ Target Change Recording bitmap: This bitmap keeps track of changes to the target.

 

 

Reverse source-target relationship using reverseflash

The command reverseflash can be used to change the direction of a FlashCopy

relationship. The former source becomes target and the former target becomes source. The

data is copied from the target to the source.

Change recording is a prerequisite for reverse restore.

 

Reset target to contents of last consistency point using revertflash

The command revertflash can be used to reset the target volume to the contents of the last

consistency point. Like the commitflash command, this command is intended to be used in

asynchronous environments like Global Mirror environments. Before this command can be

issued, the relationship must be made revertible, either automatically as with Global Mirror, or

manually using the setrevertiblecommand.

 

Run background copy for persistent FlashCopy using rmflash

 

Additional background copies for persistent FlashCopy relationships can be created using the

rmflash command in combination with its -cp parameter.

 

 

 

 

Remove local FlashCopy using rmflash

The command rmflash can be used to remove a FlashCopy relationship. Unlike other

commands, it does not return an error if the request runs for a FlashCopy relationship that

does not exist.