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

Recovering from offline VDisks using the CLI

|
|
|
|
|
|
|

What to check after running the system recovery

70
Storwize V7000: Troubleshooting, Recovery, and Maintenance Guide
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
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.
Differences to be aware of 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.
Before using the volumes, perform the following tasks:
v Start the host systems.
v Manual actions might be necessary on the hosts to trigger them to rescan for
devices. You can perform this task by disconnecting and reconnecting the Fibre
Channel cables to each host bus adapter (HBA) port.
v Verify that all mapped volumes can be accessed by the hosts.
v Run file system consistency checks.
®
function mappings and Metro Mirror or Global