Administrator Guide

a modified snapshot cannot be reverted. If you want a virtual snapshot to provide the capability to revert the contents of the
source volume or snapshot to when the snapshot was created, create a snapshot for this purpose and archive it so you do not
change the contents.
For snapshots, the reset snapshot feature is supported for all snapshots in a tree hierarchy. However, a snapshot can only be
reset to the immediate parent volume or snapshot from which it was created.
About copying volumes
For virtual storage, this feature enables you to copy a virtual base volume or snapshot to a new virtual volume.
The volume copy feature enables you to copy a base volume and snapshot to a new volume. This feature creates a complete
“physical” copy of a base volume or virtual snapshot within a storage system. It is an exact copy of the source as it existed at
the time the copy operation was initiated, consumes the same amount of space as the source, and is independent from an I/O
perspective. In contrast, the snapshot feature creates a point-in-time logical copy of a volume, which remains dependent on the
source volume.
The volume copy feature provides the following benefits:
● Additional data protection: An independent copy of a volume provides additional data protection against a complete source
volume failure. If the source volume fails, the copy can be used to restore the volume to the point in time when the copy was
created.
● Non-disruptive use of production data: With an independent copy of the volume, resource contention and the potential
performance impact on production volumes is mitigated. Data blocks between the source and the copied volumes are
independent, versus shared with snapshots, so that I/O is to each set of blocks respectively. Application I/O transactions are
not competing with each other when accessing the same data blocks.
For more information about creating a copy of a virtual base volume or snapshot, see Copying a volume or snapshot.
About reconstruction
If one or more disks fail in a disk group and spares of the appropriate size (same or larger) and type (same as the failed disks)
are available, the storage system automatically uses the spares to reconstruct the disk group. Disk group reconstruction does
not require I/O to be stopped, so volumes can continue to be used while reconstruction is in progress.
If no spares are available, reconstruction does not start automatically. The copyback process starts when the failed disk is
replaced. If you have configured the dynamic spares feature through the CLI, reconstruction will automatically start for disk
groups. With dynamic spares enabled, if a disk fails and you replace it with a compatible disk, the storage system rescans the
bus, finds the new disk, automatically designates it a spare, and starts reconstructing the disk group. See About spares.
For virtual storage, reconstruction of all disk groups uses a quick-rebuild feature. For more information on quick rebuild, see
About quick rebuild.
When a disk fails, its fault LED illuminates amber. When a spare is used as a reconstruction target, its activity LED blinks green.
During reconstruction, the fault LED and activity LEDs for all disks in the disk group blink. For descriptions of LED states, see
the Deployment Guide.
NOTE:
Reconstruction can take hours or days to complete, depending on the disk group RAID level and size, disk speed,
utility priority, host I/O activity, and other processes running on the storage system.
At any time after disk failure, you can remove the failed disk and replace it with a new disk of the same type in the same slot.
The following steps describe the drive failure process that occurs when a drive fails in a disk group:
1. A drive fails.
2. An available compatible spare drive joins the disk group.
3. Reconstruction starts and the disk group status is VRSC/RCON.
4. The failed drive replaced by a new drive.
5. A copyback operation from the spare drive to the new drive begins. The status of the disk group is CPYBK.
6. When the copyback operation completes, the original spare drive exits the disk group and it becomes a spare drive again.
A drive may go missing from a slot because of accidental removal or bus/slot issues prevent it from being detected. The
following steps describe the drive failure process that occurs when a drive goes missing from a slot:
1. A drive goes missing from a slot.
2. An available compatible spare drive joins the disk group.
3. Reconstruction starts and the disk group status is VRSC/RCON.
28
Getting started