Planning instance protection
Before performing a backup, get familiar with the prerequisites, limitations, considerations, and recommendations that are general for all data protection environments and those that are specific for your data protection environment needs.
Preparing your data protection environment
Prerequisites
-
The data movers must have access to the instances that you want to protect and to the targets that store the protected data. To ensure this, configure instance backup options so that the data mover uses the appropriate subnet. For instructions, see Configuring a data mover.
Tip You can check under which subnet the instance and the target are accessible in your cloud provider management console.
-
For AWS: Before backing up an instance, make sure the following prerequisites are met in the location of the instance:
-
In a VPC without public IPs or in subnets without public IPs, you must create the following VPC endpoints:
-
Interface endpoints: Amazon EC2 (
ec2
), AWS Security Token Service (sts
), Amazon SQS (sqs
), and Amazon SNS (sns
) -
Gateway endpoint for Amazon S3
For details on how to enable Amazon VPC endpoints, see AWS documentation.
-
-
The security group that the instance belongs to must have an inbound firewall rule for port 443 (HTTPS), source IP 0.0.0.0/0 and an outbound firewall rule for port 443 (HTTPS), destination IP 0.0.0.0/0.
For instructions on how to configure and apply the network firewall rule, see AWS documentation.
-
-
For Google Cloud:
-
The HYCU Managed Service Account (HMSA) must have the Compute Admin, Service Account User, and Storage Admin roles granted on the projects with the instances that you plan to protect. For instructions on how to grant permissions to service accounts, see Google Cloud documentation.
-
Cloud Resource Manager API, Compute Engine API, Cloud Identity and Access Management API, Cloud Billing API, and Cloud Storage API must be enabled on the projects that contain the instances that you want to protect. For instructions on how to enable APIs, see Google Cloud documentation.
-
Only if you plan to back up and restore instances that use Shared VPC networks. Your user account or the HYCU Managed Service Account (HMSA) must be granted the following permissions in the Shared VPC host project:
compute.firewalls.list
,compute.networks.list
,compute.networks.get
,compute.subnetworks.list
,compute.subnetworks.use
, andcompute.subnetworks.get
.
-
Limitations
-
Instance memory is not protected.
-
Crash consistency of backup data is guaranteed only for each disk individually.
-
For Azure: Protecting Windows instances that have storage spaces configured is not supported.
-
For Google Cloud: Local SSDs are not protected.
Considerations
-
Keep in mind that the role you have assigned determines what kind of actions you can perform. For details on roles, see Managing roles.
-
Backup data (including copies of backup data and data archives) that R‑Cloud creates is crash‑consistent, but it may not always be application‑consistent. If pre‑snapshot scripts are not provided, the application consistency of backup data is limited to the following:
-
Applications that store their data on a single disk.
-
AWS instances and applications that comply with the prerequisites for creating a Windows Volume Shadow Copy Service (VSS) snapshot. For more information about Windows VSS snapshot prerequisites, see Backing up instances.
-
Azure and Google Cloud instances and applications that comply with the restrictions for creating a Windows Volume Shadow Copy Service (VSS) snapshot. For details, see the relevant cloud provider documentation.
-
-
For Google Cloud: R‑Cloud uses an external IP address to access Google Cloud APIs if Private Google Access is disabled on subnets. If your data protection environment requires the use of an internal IP address, make sure Private Google Access is enabled on subnets. For details, see Google Cloud documentation.
Recommendation
Only if you delete an instance from Google Cloud. If an instance that you delete from Google Cloud still has at least one valid restore point available in R‑Cloud, it is considered protected and its status is Protected deleted. If you create a new instance with the same name, project, and zone in Google Cloud, R‑Cloud will recognize this instance as the old one during instance synchronization and change its status from Protected deleted to Protected. Using the restore points of such an instance for a restore could result in data corruption. Therefore, it is recommended that you create the new instance with a different name, project, or zone, or that you mark the restore points of the old instance as expired before performing a restore. For details on marking restore points as expired, see Expiring backups manually.
Configuring instance backup options
Before you start protecting instances, you can adjust instance protection to the needs of your data protection environment by configuring backup options. You can configure backup options for a single instance or for multiple instances at the same time.
Backup options
Backup option | Description |
---|---|
Pre/post Scripts |
Enables you to specify the pre-snapshot and post-snapshot scripts to perform necessary actions before and/or after the snapshot of an instance is created. For example, if the instance hosts a database management system, you may want to put the database offline before the snapshot is created to ensure an application-consistent backup and bring the database back online when the snapshot creation completes. For details, see Setting pre/post scripts. |
Exclude from Backup |
Enables you to specify any disk to be excluded from the instance backup. For details, see Excluding disks from the backup. Important This backup option can be configured only for a single instance. |
Data Movers |
Enables you to specify where you want R‑Cloud to create a data mover during the backup. By default, the data mover is created in the source of the original instance. For details, see Configuring a data mover. |

To access the Instances panel, in the navigation pane, click Instances.
Setting pre/post scripts
Prerequisites
-
Access to the instance file system must be enabled. For instructions, see Enabling access to data.
-
A script must be available in an accessible folder.
-
The user account must have permissions to run a script on the instance with the assigned credentials.
Consideration
The scripts are run from the home directory of the user account that R‑Cloud uses for running the scripts.
Depending on the operating system on the instance, the following user accounts are used:
-
For AWS and Azure instances: The user account that is assigned to the instance in R‑Cloud through a credential group.
-
For Google Cloud instances running Linux:
- The instance has no credential group assigned in R‑Cloud: The HYCU Managed Service Account (HMSA).
-
The instance has a credential group assigned: The user account specified in the credential group.
-
For Google Cloud instances running Windows: The user account that is assigned to the instance in R‑Cloud by means of a credential group.
Procedure
-
In the Instances panel, select the instances for which you want to set pre/post scripts.
Note If you want to narrow down the list of displayed instances, use the filtering options as described in Filtering and sorting data.
-
Click
Configuration.
-
Depending on whether you want to set a pre/post-snapshot script for a single instance or multiple instances, on the Pre/Post Scripts tab, do the following:
-
For a single instance:
Field Instructions Pre-snapshot Script Enter the path to the script that R‑Cloud should run before it creates a snapshot of the instance. For example:
-
Windows:
%USERPROFILE%\quiesce_db.bat
-
Linux:
bash /home/<UserName>/freeze_db.sh
Post-snapshot Script Enter the path to the script that R‑Cloud should run after it creates a snapshot of the instance. For example:
-
Windows:
%USERPROFILE%\resume_db.bat
-
Linux:
bash /home/<UserName>/thaw_db.sh
-
-
For multiple instances:
Field Instructions Pre-snapshot Script -
Specify the path to the script that R-Cloud should run before it creates the snapshots of the instances. To do so, choose one of the following:
-
If you want to use a new script, select
Add New, enter the path to the script, and then click Save.
The following are examples of the scripts:
-
Windows:
%USERPROFILE%\quiesce_db.bat
-
Linux:
bash /home/<UserName>/freeze_db.sh
-
-
If any of the selected instances already have a pre-snapshot script set and you want to use the same script for all other selected instances, select the preferred script.
-
-
Only if any of the selected instances already have a pre-snapshot script set. Select the Override these instances check box if you want the specified script to be used for all the selected instances.
Post-snapshot Script -
Specify the path to the script that R-Cloud should run after it creates the snapshots of the instances. To do so, choose one of the following:
-
If you want to use a new script, select
Add New, enter the path to the script, and then click Save.
The following are examples of the scripts:
-
Windows:
%USERPROFILE%\resume_db.bat
-
Linux:
bash /home/<UserName>/thaw_db.sh
-
-
If any of the selected instances already have a post-snapshot script set and you want to use the same script for all other selected instances, select the preferred script.
-
-
Only if any of the selected instances already have a post-snapshot script set. Select the Override these instances check box if you want the specified script to be used for all the selected instances.
-
-
- Click Save.
Excluding disks from the backup
Consideration
If you exclude the boot disk from the backup, you cannot restore the entire instance, but only its disks.
Procedure
-
In the Instances panel, select the instance for which you want to exclude disks from the backup.
Note If you want to narrow down the list of displayed instances, use the filtering options as described in Filtering and sorting data.
-
Click
Configuration.
-
On the Exclude from Backup tab, select the disks that you want to exclude from the backup.
-
Click Save.
Configuring a data mover
Prerequisites
-
Only if you are protecting Google Cloud instances and you plan to specify a different subnet for the data mover. If you plan to use pre-snapshot and post-snapshot scripts, or back up instances for which the restore of individual files is allowed, VPC Network Peering must be configured. For details on how to configure VPC Network Peering, see Google Cloud documentation.
-
Only if you plan to configure the data mover for multiple instances. The selected instances must have the same values set for the location, the network, the subnet, and the security group.
Procedure
-
In the Instances panel, select the instances for which you want to configure the data mover.
Note If you want to narrow down the list of displayed instances, use the filtering options as described in Filtering and sorting data.
-
Click
Configuration.
-
On the Data Movers tab, select the following:
-
For AWS and Google Cloud instances: From the Zone drop-down menu, select the preferred zone.
-
For Azure instances: From the Network drop-down menu, select the preferred network.
-
From the Subnet drop-down menu, select the preferred subnet. By default, the data mover is created in the default subnet of the preferred zone for AWS and Google Cloud instances and in the first subnet provided by the Azure API for Azure instances.
-
For AWS instances: Optionally, from the Security Group drop-down menu, select the preferred security group. By default, the data mover is created in the default security group of the preferred subnet.
-
- Click Save.