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

  • 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 Google Cloud 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, and compute.subnetworks.get.

Limitations

  • Instance memory is not protected.

  • Crash consistency of backup data is guaranteed only for each disk individually.

  • 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.

    • Google Cloud instances and applications that comply with the restrictions for creating a Windows Volume Shadow Copy Service (VSS) snapshot. For details, see Google Cloud 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.
Temporary instance configuration

Enables you to specify the region, the zone, and the subnet where you want R‑Cloud to create a temporary instance during the backup. For AWS instances, you can also specify a security group. By default, the temporary instance is created in the source of the original instance. For details, see Configuring a temporary instance.

To access the Instances panel, in the navigation pane, click Instances 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 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

  1. 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.

  2. Click Configuration Configuration.

  3. 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

      1. 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 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.

      2. 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

      1. 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 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.

      2. 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.
  4. 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

  1. 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.

  2. Click Configuration Configuration.

  3. On the Exclude from Backup tab, select the disks that you want to exclude from the backup.

  4. Click Save.

Configuring a temporary instance

Prerequisites

  • Only if you are protecting Google Cloud instances and you plan to specify a different subnet for the temporary instance. 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 temporary instance for multiple instances. The selected instances must have the same values set for the location and the subnet. In the case of AWS instances, the same value must be set also for the security group.

Procedure

  1. In the Instances panel, select the instances for which you want to configure the temporary instance.

    Note  If you want to narrow down the list of displayed instances, use the filtering options as described in Filtering and sorting data.

  2. Click Configuration Configuration.

  3. On the Temporary Instance Configuration tab, select the following:

    1. From the Region drop-down menu, select the preferred region.

    2. From the Zone drop-down menu, select the preferred zone.

    3. From the Subnet drop-down menu, select the preferred subnet. By default, the temporary instance is created in the default subnet of the preferred region and zone.

    4. For AWS instances: Optionally, from the Security Group drop-down menu, select the preferred security group. By default, the temporary instance is created in the default security group of the preferred subnet.

  4. Click Save.