To move an aggregate composed of disks from one storage system (the source) to another (the target), you need to physically move disks, disk shelves, or entire loops or stacks. You might move an aggregate to move data to a new storage system model or remove data from an impaired storage system.
Before you begin
The
target storage system must meet the following requirements:
About this task
The procedure described here does not apply to aggregates composed of array LUNs.
If you are moving an aggregate composed of disks using Storage Encryption, you need to take some extra steps before and after moving the aggregate. If the physical security of the disks during the move is a concern and your key management server supports the creation of a trust relationship between two storage systems, then you should use that capability to retain secure encryption on the disks during the move. Otherwise, you must set the encryption key to a known value before moving the disks and give them a new authentication key after the disks are installed in the destination storage system. This is the method described in the steps below.
Steps
- Enter the following command at the source storage system to locate the disks that contain the aggregate: aggr status aggr_name -r
The locations of the data, parity, and dParity disks in the aggregate appear under the HA, SHELF, and BAY columns (dParity disks appear for RAID-DP aggregates only).
- If you are moving disks using Storage Encryption, reset their authentication key to their MSID (the default security ID set by the manufacturer) by entering the following command on the source storage system: disk encrypt rekey 0x0 disk_list
You can also use the wildcard character (*) to specify the disks to be rekeyed. For example, to rekey all disks in a specific shelf, you can specify adapter-name.shelI-ID.* as your disk list.
- Boot the source storage system into Maintenance mode.
- Take the aggregate offline: aggr offline aggr_name
The aggregate is taken offline and its hosted volumes are unmounted.
- Reboot into Normal mode.
- If disk ownership autoassignment is on, turn it off: options disk.auto_assign off
If the system is part of an HA pair, you must complete this step on each node.
- Remove the software ownership information from the disks to be moved by entering the following command for each disk: disk assign disk_name -s unowned -f
- Follow the instructions in the disk shelf hardware guide to remove the disks or shelves that you identified previously from the source storage system.
- If you turned off disk ownership autoassignment previously, turn it back on: options disk.auto_assign on
If the system is part of an HA pair, you must complete this step on each node.
- Install the disks or disk shelves in the target storage system.
- Assign the disks that you moved to the target storage system by entering the following command for each moved disk: disk assign disk_name
The newly relocated aggregate is offline and considered as a foreign aggregate. If the newly relocated aggregate has the same name as an existing aggregate on the target storage system, Data ONTAP renames it aggr_name(1), where aggr_name is the original name of the aggregate.
- Confirm that the newly relocated aggregate is complete: aggr status aggr_name
Attention: If the aggregate is incomplete (if it has a status of partial), add all missing disks before proceeding. Do not try to add missing disks after the aggregate comes online; doing so causes them to become hot spare disks. You can identify the disks currently used by the aggregate by using the aggr status -r command.
- If the storage system renamed the aggregate because of a name conflict, rename the aggregate: aggr rename aggr_name new_name
- Bring the aggregate online in the destination storage system: aggr online aggr_name
The aggregate comes online and is no longer considered to be a foreign aggregate.
- Confirm that the added aggregate came online: aggr status aggr_name
- If you moved disks using Storage Encryption, set them back to a secure encryption key.
If you... |
Then... |
Want all of the disks on your storage system to have the same authentication key and you have the authentication key for the other disks on the storage system |
Rekey the disks that were moved using the existing authentication key by entering the following command at the destination storage system prompt: disk encrypt rekey new_key_ID disk_list new_key_ID is the key ID for the existing authentication key on the destination storage system.
You can use the wildcard character (*) to specify the disks to be rekeyed. For example, to rekey all disks in a specific shelf, you can specify adapter-name.shelI-ID.* as your disk list.
|
Want all of the disks on your storage system to have the same authentication key and you do not have the authentication key for the other disks on the storage system |
Rekey all of the disks in the destination storage system by entering the following command at the destination storage system prompt: key_manager rekey -keytag key_tag You can allow Data ONTAP to generate a new authentication key automatically or provide your own by using the -manual parameter.
|
Do not need all of the disks on your storage system to have the same authentication key |
Rekey the disks that were moved: disk encrypt rekey new_key_ID disk_list new_key_ID is the key ID for a new authentication key on the destination storage system.
You can use the wildcard character (*) to specify the disks to be rekeyed. For example, to rekey all disks in a specific shelf, you can specify adapter-name.shelI-ID.* as your disk list.
|
After you finish
After you move the aggregate and bring it online in the destination storage system, you need to re-create the following configuration information for all volumes associated with the aggregate:
- Client connections (CIFS shares or NFS exports)
- Scheduled tasks (for example, deduplication or reallocation)
- Quotas
- Relationships between volumes (for example, SnapMirror or SnapVault)
- FlexCache volumes
- LUN connection information