Recovering From Offline Vdisks Using The Cli; What To Check After Running The System Recovery - IBM Storwize V7000 Unified Series Problem Determination Manual

Recovering from offline VDisks using the CLI

|
|
|
|
|
|
|

What to check after running the system recovery

If the recovery completes with offline volumes, go to "Recovering from offline
VDisks using the CLI."
After performing the storage system recovery procedure, contact IBM support for
assistance with recovering the file modules, so access to the file systems can be
restored.
If a recovery procedure (T3 procedure) completes with offline volumes, you can
use the command-line interface (CLI) to access the volumes.
If you have performed the recovery procedure, and it has completed successfully
but there are offline volumes, you can perform the following steps to bring the
volumes back online. Any volumes that are offline and are not thin-provisioned
volumes are offline because of the loss of write-cache data during the event that
led both nodes to lose their hardened data. These volumes might need additional
recovery steps after the volume is brought back online.
Note: If you encounter errors in the error log after running the recovery procedure
that are related to offline arrays, use the fix procedures to resolve the offline array
errors before fixing the offline volume (VDisk) errors.
Perform the following steps to recover an offline volume after the recovery
procedure has completed:
1. Delete all IBM FlashCopy function mappings and Metro Mirror or Global
Mirror relationships that use the offline volumes.
2. Run the recovervdisk or recovervdiskbysystem command.
You can recover individual volumes by using the recovervdisk command. You
can recover all the volumes in a clustered system by using the
recovervdiskbysystem command.
3. Recreate all FlashCopy mappings and Metro Mirror or Global Mirror
relationships that use the volumes.
Several tasks must be performed before you use the volumes.
Be aware of the following differences regarding the recovered configuration:
v FlashCopy mappings are restored as "idle_or_copied" with 0% progress. Both
volumes must have been restored to their original I/O groups.
v The management ID is different. Any scripts or associated programs that refer to
the system-management ID of the clustered system must be changed.
v Any FlashCopy mappings that were not in the "idle_or_copied" state with 100%
progress at the point of disaster have inconsistent data on their target disks.
These mappings must be restarted.
v Intersystem remote copy partnerships and relationships are not restored and
must be re-created manually.
v Consistency groups are not restored and must be re-created manually.
v Intrasystem remote copy relationships are restored if all dependencies were
successfully restored to their original I/O groups.
v The system time zone might not have been restored.
v The GPFS cluster quorum state held on the control enclosure might not have
been restored.
Chapter 5. Control enclosure
245