About snapshot restore
The types of snapshots you can restore and where you can restore them varies depending on the asset type.
When you restore a snapshot, keep in mind the following:
You can restore an encrypted snapshot. To enable the restoring of encrypted snapshots, add a Key Management Service (KMS) policy, and grant the NetBackup user access to KMS keys so that they can restore encrypted snapshots.
If you are restoring a replicated host snapshot to a location that is different from the source region, then the restore might fail as the key is not available at the target location.
As a prerequisite, create a key-pair with the same name as the source of the snapshot, or import the key-pair from the source to the target region.
Then, after the restore is successful, change the security groups of the instance from the network settings for the instance.
When you have created a snapshot of a supported storage array disk which has a file system created and mounted on it, you must first stop any application that is using the file system and then unmount the file system and perform restore.
For AWS/Azure/GCP cloud disk/volume snapshots, you must first detach the disk from the instance and then restore the snapshot to original location.
(Applicable to AWS only) When you restore a host-level application snapshot, the name of the new virtual machine that is created is the same as the name of the host-level snapshot that corresponds to the application snapshot.
For example, when you create an application snapshot named
OracleAppSnap, NetBackup automatically creates a corresponding host-level snapshot for it namedOracleAppSnap-<number>. For example, the snapshot name may resembleOracleAppSnap-15.Now, when you restore the application snapshot (
OracleAppSnap), the name of the new VM isOracleAppSnap-<number> (timestamp).Using the example cited earlier, the new VM name may resemble
OracleAppSnap-15 (restored Nov 20 2018 09:24).Note that the VM name includes "Oracle-AppSnap-15" which is the name of the host-level snapshot.
(Applicable to AWS only) When you restore a disk-level application snapshot or a disk snapshot, the new disk that is created does not bear any name. The disk name appears blank.
You have to manually assign a name to the disk to be able to identify and use it after the restore.
When you restore a snapshot of a Windows instance, you can log in to the newly restored instance using original instance's username/password/pem file.
By default, AWS disables generating a random encrypted password after launching the instance from AMI. You must set Ec2SetPassword to
Enabledinconfig.xmlto generate new password every time. For more information on how to set the password, see the following link.https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2config-service.html#UsingConfigXML_WinAMI
With CloudPoint 9.0, a restore of any Amazon EC2 instances created before June 2019 will not have a product billing code due to an AWS limitation.
The volume type of newly created volumes for replicated snapshots is according to the region's default volume type.
If volume type is not specified, the following default values are used:
Table: Default volume types
Region | Default volume type |
|---|---|
us-east-1, eu-west-1, eu-central-1, us-west-1, us-west-2 ap-northeast-1, ap-northeast-2, ap-southeast-1, ap-southeast-2, ap-south-1 sa-east-1, us-gov-west-1, cn-north-1 | standard |
All other regions | gp2 |
If you are performing a disk-level snapshot restore to the same location, then verify that the original disk is attached to the instance, before you trigger a restore.
If the existing original disk is detached from the instance, then the restore operation might fail.
See Disk-level snapshot restore fails if the original disk is detached from the instance.
You can perform only one restore operation on a snapshot at any given time. If multiple operations are submitted on the same asset, then only the first operation is triggered and the remaining operations will fail.
This is applicable for all CloudPoint operations in general. CloudPoint does not support running multiple jobs on the same asset simultaneously.
If you intend to restore multiple file systems or databases on the same instance, then Veritas recommends that you perform these operations one after the other, in a sequential manner.
Running multiple restore operations in parallel can lead to an inconsistency at the instance level and the operations might fail eventually. Multiple restore jobs that need access to any shared asset between them are not allowed. Assets that participate in the restore job are locked and any other job requiring such locked assets will fail.