Veritas NetBackup™ CloudPoint Install and Upgrade Guide
- Section I. CloudPoint installation and configuration
- Preparing for CloudPoint installation
- About the deployment approach
- Deciding where to run CloudPoint
- About deploying CloudPoint in the cloud
- Meeting system requirements
- CloudPoint host sizing recommendations
- Creating an instance or preparing the physical host to install CloudPoint
- Installing Docker
- Creating and mounting a volume to store CloudPoint data
- Verifying that specific ports are open on the instance or physical host
- Deploying CloudPoint using the Docker image
- CloudPoint cloud plug-ins
- CloudPoint storage array plug-ins
- How to configure the CloudPoint storage array plug-ins?
- NetApp plug-in configuration notes
- Nutanix Files plug-in configuration notes
- Dell EMC Unity array plug-in configuration parameters
- Pure Storage FlashArray plug-in configuration notes
- HPE RMC plug-in configuration notes
- Hitachi plug-in configuration notes
- InfiniBox plug-in configuration notes
- Dell EMC PowerScale (Isilon) plug-in configuration notes
- Qumulo plug-in configuration notes
- CloudPoint application agents and plug-ins
- Microsoft SQL plug-in configuration notes
- Oracle plug-in configuration notes
- MongoDB plug-in configuration notes
- About the installation and configuration process
- Preparing to install the Linux-based agent
- Preparing to install the Windows-based agent
- Downloading and installing the CloudPoint agent
- Registering the Linux-based agent
- Registering the Windows-based agent
- Configuring the CloudPoint application plug-in
- Configuring VSS to store shadow copies on the originating drive
- Creating a NetBackup protection plan for cloud assets
- Subscribing cloud assets to a NetBackup protection plan
- About snapshot restore
- Restore requirements and limitations for Microsoft SQL Server
- Restore requirements and limitations for Oracle
- Restore requirements and limitations for MongoDB
- Steps required before restoring SQL AG databases
- Recovering a SQL database to the same location
- Recovering a SQL database to an alternate location
- Additional steps required after a SQL Server snapshot restore
- Additional steps required after restoring SQL AG databases
- SQL snapshot or restore and granular restore operations fail if the Windows instance loses connectivity with the CloudPoint host
- Disk-level snapshot restore fails if the original disk is detached from the instance
- Additional steps required after a MongoDB snapshot restore
- Additional steps required after an Oracle snapshot restore
- Additional steps required after restoring an AWS RDS database instance
- Protecting assets with CloudPoint's agentless feature
- Volume Encryption in NetBackup
- Preparing for CloudPoint installation
- Section II. CloudPoint maintenance
- CloudPoint logging
- Troubleshooting CloudPoint
- Restarting CloudPoint
- Troubleshooting CloudPoint logging
- CloudPoint agent fails to connect to the CloudPoint server if the agent host is restarted abruptly
- CloudPoint agent registration on Windows hosts may time out or fail
- Disaster recovery when DR package is lost or passphrase is lost
- Agentless log file name changed
- Upgrading CloudPoint
- Uninstalling CloudPoint
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.