Restoring P-VOLs from a snapshot

The operation of restoring the copy-source volume data from the copy-destination volume data is called snapshot restore.

When restore is started and snapshotStatus becomes Restoring, the data in the restore-destination volume will virtually reflect the data in the restore-source volume, even if the restore copy is not yet complete, and the restored data can be accessed immediately.

When restore starts, access to the restore-source volume is suppressed. When the restore is complete, the restore-source volume will transition to the Prepared state. The volume that has transitioned to the Prepared state can take the next snapshot without the need to perform preparation for taking a snapshot.

You can restore a volume only when snapshotStatus of the copy-destination (restore-source) volume is "Normal".
You cannot restore a volume if a snapshot has been taken by using the copy-destination (restore-source) volume as the copy-source volume in a cascade configuration.
If the copy-source (restore-destination) volume is a snapshot in a cascade configuration, a volume can be restored only when snapshotStatus of the copy-source (restore-destination) volume is "Normal".
When the copy-source volume is shared, if there is already a snapshot whose snapshotStatus is "Restoring" under the copy-source (restore-destination) volume, a new restore operation cannot be started.

Note:

When a restore operation is performed, the data in the restore-source volume is written to the restore-destination volume. Because the data in the restore-destination volume before the data in the restore-source volume is written is copied to the storage pool here, the storage pool usage will increase. If data in snapshot volumes is lost during restore due to the storage pool being full, data in the restore-destination volume will also become unavailable.
When restoring a volume, do so when IOPS to the restore-destination volume is low.

If the data in the restore-destination volume is updated by a write I/O, differential data copy will run. Furthermore, copying data from the restore-source volume to the restore-destination volume by restore will also run. These copy operations increase the load in the storage node and deteriorate not only the IOPS performance of write I/O but also the IOPS performance of read I/O.
If more failures than the redundant configuration allows occur during restoration, restoration processing might be unsuccessful. However, processing automatically restarts after the node is restored. In such cases, obtain the volume information, and then verify the progress of the restoration from snapshotStatus. If snapshotStatus is "Restoring", restoration is in progress. Wait until the processing finishes. If snapshotStatus is "Prepared", restoration has completed.

CAUTION:

If a failure occurs in the storage cluster (for example, as a result of stoppage of power to the storage cluster) while restoring is being performed and the write back mode with cache protection is disabled, data on the snapshot volume might be lost. When the write back mode with cache protection is enabled, data on the snapshot volume is protected. However, if a failure occurs in the storage cluster while failures exceeding the storage controller redundancy are occurring, the data on the snapshot volume is not protected even if the write back mode with cache protection is enabled.
(Virtual machine) If the storage cluster becomes abnormal during restoration due to failures exceeding redundancy (for example, a network switch failure, power failure, or an unintentional operation to shut down the storage node storage nodes on multiple storage nodes), data in snapshot volumes will be lost and the data on the restoration-destination volume will become unavailable. Before performing restoration, back up data on the restoration-destination volume to another normal volume via hosts or other means, and record information of the restoration-destination volume by performing the operations described in Obtaining information about individual volumes.
(Bare metal) If the storage cluster becomes abnormal during restoration due to failures exceeding redundancy (for example, a network switch failure, power failure, or an unintentional operation to shut down storage nodes), data in snapshot volumes will be lost and the data on the restoration-destination volume will become unavailable. Before performing restoration, back up data on the restoration-destination volume to another normal volume via hosts or other means, and record information of the restoration-destination volume by performing the operations described in Obtaining information about individual volumes.
(Cloud) If the storage cluster becomes abnormal during restoration due to failures exceeding redundancy (for example, a failure or an unintentional shut-down operation of the EC2 instances on multiple storage nodes), data of the snapshot volume will be lost and the data on the restoration-destination volume will become unavailable. Before performing restoration, back up data on the restoration-destination volume to another normal volume via hosts or other means, and record information of the restoration-destination volume by performing the operations described in Obtaining information about individual volumes.
To keep the data consistent, stop the host I/O operations until a snapshot has been restored. If the volume is for the OS system disk, restore a snapshot from the restore-source volume (S-VOL) after shutting down the OS. For a data disk volume, restore a snapshot after unmounting the disk. In this case, the fsfreeze command cannot be used. After a snapshot restoration is completed, mount the file system, and then resume the host I/O operations. The steps for stopping the host I/O operations depend on the OS. Perform the process according to the steps for the OS you are using.

Required role: VpsStorage

Obtain a list of S-VOL information by specifying the restore-destination volume, and verify that there is no volume with snapshotStatus of "Restoring".

REST API: GET /v1/objects/volumes/<id>/snapshot-volumes

CLI: snapshot_volume_list

After verification, go to the next step.
Restore the intended P-VOL with data in snapshot volumes.

Run either of the following commands with the restore-source volume (S-VOL) ID specified.

If you use the CLI, you can specify a name instead of the ID of the volume.

REST API: POST /v1/objects/volumes/actions/restore-snapshot/invoke

CLI: volume_restore_snapshot

Verify the job ID which is displayed after the command is run.

You can check the progress of the restoration by obtaining the volume information, snapshotProgressRate [%]. For how to obtain the volume information, see Obtaining information about individual volumes in this manual. For the volume ID, specify the ID of the restore-source volume.
Verify the state of the job.

Run either of the following commands with the job ID specified.

REST API: GET /v1/objects/jobs/<jobId>

CLI: job_show

If the job state is "Succeeded", the job is completed.
Obtain information about restore-source volumes (S-VOLs) to verify that the snapshotStatus has changed to "Prepared".

REST API: GET /v1/objects/volumes/<id>

CLI: volume_show

After performing step 3, it might take approximately one minute for the snapshotStatus to change. When you want to verify that the snapshotStatus has changed, wait for approximately one minute before verification.