Veritas CloudPoint Administrator's Guide
- Getting started with CloudPoint
- Section I. Installing and configuring CloudPoint
- Preparing for installation
- About the deployment approach
- Deciding where to run CloudPoint
- 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
- Deploying CloudPoint in the AWS cloud
- Using plug-ins to discover assets
- Configuring off-host plug-ins
- AWS plug-in configuration notes
- Google Cloud Platform plug-in configuration notes
- Microsoft Azure plug-in configuration notes
- Dell EMC Unity array plug-in configuration notes
- Pure Storage FlashArray plug-in configuration notes
- HPE RMC plug-in configuration notes
- NetApp plug-in configuration notes
- Hitachi plug-in configuration notes
- InfiniBox plug-in configuration notes
- Configuring an off-host plug-in
- About CloudPoint plug-ins and assets discovery
- Configuring the on-host agents and plug-ins
- About agents
- Oracle plug-in configuration notes
- MongoDB plug-in configuration notes
- Microsoft SQL plug-in configuration notes
- About the installation and configuration process
- Preparing to install the Linux-based on-host agent
- Preparing to install the Windows-based on-host agent
- Downloading and installing the on-host agent
- Configuring the Linux-based on-host agent
- Configuring the Windows-based on-host agent
- Configuring the on-host plug-in
- Configuring VSS to store shadow copies on the originating drive
- Protecting assets with CloudPoint's agentless feature
- Preparing for installation
- Section II. Configuring users
- Section III. Protecting and managing data
- User interface basics
- Indexing and classifying your assets
- Protecting your assets with policies
- Tag-based asset protection
- Replicating snapshots for added protection
- About snapshot replication
- About cross-account snapshot replication in the AWS cloud
- Requirements for replicating snapshots
- Cross-account snapshot replication support matrix
- Cross-account snapshot replication limitations
- Configuring replication rules
- Editing a replication rule
- Deleting a replication rule
- Managing your assets
- Creating a snapshot manually
- Displaying asset snapshots
- Replicating a snapshot manually
- About snapshot restore
- About single file restore (granular restore)
- Single file restore requirements and limitations
- Restoring a snapshot
- Additional steps required after restoring disk-level snapshots
- Additional steps required after a SQL Server snapshot restore
- Additional steps required after an Oracle snapshot restore
- Additional steps required after a MongoDB snapshot restore
- Additional steps required after restoring an AWS RDS database instance
- Restoring individual files within a snapshot
- Deleting a snapshot
- Monitoring activities with notifications and the job log
- Protection and disaster recovery
- Section IV. Maintaining CloudPoint
- CloudPoint logging
- Troubleshooting CloudPoint
- Restarting CloudPoint
- Docker may fail to start due to a lack of space
- CloudPoint installation fails if rootfs is not mounted in a shared mode
- Some CloudPoint features do not appear in the user interface
- Off-host plug-in deletion does not automatically remove file system and application assets
- Disk-level snapshot restore fails if the original disk is detached from the instance
- Snapshot restore for encrypted AWS assets may fail
- Error while adding users to CloudPoint
- CloudPoint fails to revert restored snapshots if indexing, classification, or restore operations fail
- SQL snapshot or restore and SFR operations fail if the Windows instance loses connectivity with the CloudPoint host
- Troubleshooting CloudPoint logging
- Swagger UI-based authorization for CloudPoint REST API calls may fail
- Policy retention count is not honored for file system and application assets if there is an issue with the CloudPoint plug-in
- Working with your CloudPoint license
- Managing CloudPoint agents and plug-ins
- Upgrading CloudPoint
- Uninstalling CloudPoint
- Section V. Reference
About snapshot restore
The types of snapshots you can restore and where you can restore them varies depending on the asset type.
Table: Assets and supported restore options
Asset | Supported restore options |
|---|---|
Dell EMC Unity array | Restore a copy-on-write (COW) LUN snapshot to the same LUN with the option. |
HPE storage arrays | Restore a COW volume snapshot to the same volume with the option.
|
Pure Storage FlashArray | Restore a clone volume snapshot to the same volume with the option. |
NetApp storage arrays | Restore the LUN snapshot to the same LUN (SAN deployment) or restore the NetApp NFS shares (NAS deployment). |
Hitachi storage arrays | Restore the LDEV snapshot to the same LDEV with the option. |
InfiniBox storage arrays | Restore the SAN volume snapshot to the same volume with the option. |
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 CloudPoint 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 disk of supported storage arrays from 'Disk' section in CloudPoint dashboard, 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, CloudPoint 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
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.
If a region or zone is removed from the AWS or GCP plug-in configuration, then all the discovered assets from that region or zone are also removed from the CloudPoint assets database. If there are any active snapshots that are associated with the assets that get removed, then you may not be able perform any restore operations on those snapshots.
Once you add that zone back into the plug-in configuration, CloudPoint discovers all the assets again and you can resume the restore operations on the associated snapshots.