Prepare to deploy Backup and DR Service

Before you begin

It's a good idea to read Plan a Backup and DR deployment before you begin this section.

This page details the Google Cloud requirements that must be met before you enable Google Cloud Backup and DR Service which must be done in the Google Cloud console.

All of the tasks outlined in this page must be performed in the Google Cloud project where you are deploying your backup/recovery appliance. If this project is a shared VPC service project, then some tasks are performed in the VPC project and some in the workload project.

Note: VPC service controls cannot be enabled for Google Cloud Backup and DR Service. If VPC service controls is enabled for the peering connection, you need to disable it using the following command:

gcloud services vpc-peerings disable-vpc-service-controls --network=<vpc-network> --service=servicenetworking.googleapis.com

vpc-network is the network that allows the management console to communicate with all backup/recovery appliances when deploying the management console.

Allow trusted image projects

Permissions required for this task

This is an organization level policy that may not be set or even exist. To change this, your user needs to have the following permissions:

• orgpolicy.policies.create
• orgpolicy.policies.delete
• orgpolicy.policies.delete
• orgpolicy.policy.get
Example roles that have this permission include: Organization Policy Administrator

If you have enabled the constraint/compute.trustedImageProjects policy in the Organization policies, then the Google-managed source project for the images used to deploy the backup/recovery appliance is not allowed. You need to customize this organization policy in the projects where backup/recovery appliances are deployed to avoid getting a policy violation error during the deployment as detailed in the following instructions:

1. Go to the Organization policies page and select the project where you deploy your appliances.

   Go to Organization policies

2. In the policies list, click Define trusted image projects.

3. Click Edit to customize your existing trusted image constraints.

4. On the Edit page, select Customize.

5. Select from the following three possibilities:

   Existing inherited policy

   If there is an existing inherited policy, complete the following:

   1. Select the Policy enforcement as Merge with parent.

   2. Click Add rule.

   3. Select Custom from the Policy values drop-down list to set the constraint on specific image projects.

   4. Select Allow from the Policy type drop-down list to remove restrictions for the specified image projects.

   5. In the Custom values field, enter the custom value as projects/backupdr-images.

   6. Click Done.

   Existing Allow rule

   If there is an existing Allow rule, then complete the following steps:

   1. Leave the Policy enforcement to the default selected.

   2. Select the existing Allow rule.

      Caution: If a rule exists, use it. Do not try to add an additional rule.

   3. Click Add value to add additional image projects and enter the value as projects/backupdr-images.

   4. Click Done.

   No existing policy or rule

   If there is no existing rule, select Add rule and then complete the following steps:

   1. Leave the Policy enforcement to the default selected.

   2. Select Custom from the Policy values drop-down list to set the constraint on specific image projects.

   3. Select Allow from the Policy type drop-down list to remove restrictions for the specified image projects.

   4. In the Custom values field, enter the custom value as projects/backupdr-images.

   5. If you are setting project-level constraints, then they might conflict with the existing constraints set on your organization or folder.

   6. Click Add value to add additional image projects and click Done.

   7. Click Save.

6. Click Save to apply the constraint.

   For more information about creating organization policies, see Create and manage organization policies.

The deployment process

To launch the installation, Backup and DR Service creates a service account to run the installer. The service account requires privileges in the host project, the backup/recovery appliance service project, and the management console service project. For more information, see service accounts.

The service account used for installation becomes the service account of the backup/recovery appliance. After installation, the permissions of the service account are reduced to just the permissions required by the backup/recovery appliance.

The management console is deployed when you install the first backup/recovery appliance. You can deploy Backup and DR Service in a shared VPC or in a non-shared VPC.

Backup and DR Service in a non-shared VPC

When deploying the management console and the first backup/recovery appliance is in a single project with a non-shared VPC, then all three Backup and DR Service components are in the same project.

Note: CMEK must be disabled on the project where the backup/recovery appliance is deployed.

If the VPC is shared, see Backup and DR Service in a shared VPC.

Enable the required APIs for installation in a non-shared VPC

Before enabling the required APIs for installation in a non-shared VPC, review the Backup and DR Service deployment supported regions. See Supported regions.

To run the installer in a non-shared VPC, the following APIs must be enabled. To enable APIs, you need the role Service usage admin.

API	Service name
Compute Engine	compute.googleapis.com
Cloud Resource Manager	cloudresourcemanager.googleapis.com
Workflows ^1	workflows.googleapis.com
Cloud Key Management Service (KMS)	cloudkms.googleapis.com
Identity and Access Management IAM	iam.googleapis.com
Cloud Logging	logging.googleapis.com

¹ Workflow service is supported in the listed regions. If the Workflows service is not available in a region where the backup/recovery appliance is being deployed, then Backup and DR Service defaults to "us-central1" region. If you have an organization policy that is set to prevent creating resources in other regions, then you need to temporarily update your organization policy to allow creation of resources in "us-central1" region. You can restrict the "us-central1" region after the backup/recovery appliance deployment.

The user account requires these permissions in the non-shared VPC project

Preferred role	Permissions needed
resourcemanager.projectIamAdmin (Project IAM Admin)	resourcemanager.projects.getIamPolicy
	resourcemanager.projects.setIamPolicy
	resourcemanager.projects.get
	iam.serviceAccounts.delete
	iam.serviceAccounts.get
	workflows.workflows.delete
	workflows.executions.create
	workflows.executions.get
	workflows.operations.get
serviceusage.serviceUsageAdmin (Service Usage Admin)	serviceusage.services.list
iam.serviceAccountUser (Service Account User)	iam.serviceAccounts.actAs
iam.serviceAccountAdmin (Service Account Admin)	iam.serviceAccounts.create
	iam.serviceAccounts.delete
	iam.serviceAccounts.get
workflows.editor (Workflows Editor)	workflows.workflows.create
	workflows.workflows.delete
	workflows.executions.create
	workflows.executions.get
	workflows.operations.get
backupdr.admin (Backup and DR Admin)	backupdr.*
viewer (Basic)	Grants the permissions required to view most of Google Cloud resources.

Backup and DR in a shared VPC

When deploying the management console and the first backup/recovery appliance in a shared VPC project, you must configure these three projects in either the host project or in one or more service projects:

Before enabling the required APIs for installation in a shared VPC, review the Backup and DR deployment supported regions. See Supported regions.

Note: CMEK must be disabled on the project where any backup/recovery appliance is deployed.

• VPC owner project: This owns the selected VPC. The VPC owner is always the host project. The VPC owner project requires Private service access.

• Management console project: This is where the Backup and DR API is activated and where you access the management console to manage workloads.

• Backup/recovery appliance project: This is where the backup/recovery appliance is installed and usually where the protected resources reside.

In a shared VPC, these may be one, two, or three projects.

Type	VPC Owner	Management console	Backup/recovery appliance
HHH	Host project	Host project	Host project
HHS	Host project	Host project	Service project
HSH	Host project	Service project	Host project
HSS	Host project	Service project	Service project
HS2	Host project	Service project	A different service project

Descriptions of the deployment strategies

• HHH: Shared VPC. The VPC owner, the management console, and the backup/recovery appliance are all in the host project.

• HHS: Shared VPC. The VPC owner and the management console are in the host project, and the backup/recovery appliance is in a service project.

• HSH: Shared VPC. The VPC owner and the backup/recovery appliance are in the host project, and the management console is in a service project.

• HSS: Shared VPC. The VPC owner is in the host project, and the backup/recovery appliance and the management console are in one service project.

• HS2: Shared VPC. The VPC owner is in the host project, and the backup/recovery appliance and the management console are in two different service projects.

Enable these required APIs for installation in the host project

To run the installer, the following APIs must be enabled. To enable APIs, you need the role Service usage admin.

API	Service name
Compute Engine	compute.googleapis.com
Cloud Resource Manager	cloudresourcemanager.googleapis.com

Enable these required APIs for installation in the backup/recovery appliance project

API	Service name
Compute Engine	compute.googleapis.com
Cloud Resource Manager	cloudresourcemanager.googleapis.com
Workflows ^1	workflows.googleapis.com
Cloud Key Management Service (KMS)	cloudkms.googleapis.com
Identity and Access Management IAM	iam.googleapis.com
Cloud Logging	logging.googleapis.com

Note: The backup/recovery appliance requires access to the Google APIs. If the subnet network settings do not allow the VMs to access the Google APIs, then the backup/recovery appliance deployment fails. Make sure the subnet where you have deployed the backup/recovery appliance has access to Google APIs and services. Refer to Configure private Google access|VPC for additional information on how to configure this.

¹ Workflow service is supported in the listed regions. If the Workflows service is not available in a region where backup/recovery appliance is being deployed, then Backup and DR Service defaults to "us-central1" region. If you have an organization policy that is set to prevent creating resources in other regions, then you need to temporarily update your organization policy to allow creation of resources in "us-central1" region. You can restrict the "us-central1" region after the backup/recovery appliance deployment.

The user account requires these permissions in the VPC owner project

Note: The roles may grant more permissions than you need. For minimum required permissions, assign only those listed in the Permissions needed column.

Preferred Role	Permissions needed
resourcemanager.projectIamAdmin (Project IAM Admin)	resourcemanager.projects.getIamPolicy
	resourcemanager.projects.setIamPolicy
	resourcemanager.projects.get
	iam.serviceAccounts.delete
	iam.serviceAccounts.get
	workflows.workflows.delete
	workflows.executions.create
	workflows.executions.get
	workflows.operations.get
serviceusage.serviceUsageAdmin (Service Usage Admin)	serviceusage.services.list

The user account requires these permissions in the management console project

Note: The roles may grant more permissions than you need. For minimum required permissions, assign only those listed in the Permissions needed column.

The management console is deployed when you install the first backup/recovery appliance.

Preferred Role	Permissions needed
resourcemanager.projectIamAdmin (Project IAM Admin)	resourcemanager.projects.getIamPolicy
	resourcemanager.projects.setIamPolicy
	resourcemanager.projects.get
	iam.serviceAccounts.delete
	iam.serviceAccounts.get
	workflows.workflows.delete
	workflows.executions.create
	workflows.executions.get
	workflows.operations.get
backupdr.admin (Backup and DR Admin)	backupdr.*
viewer (Basic)	Grants the permissions required to view most of Google Cloud resources.

The user account requires these permissions in the backup/recovery appliance project

Note: The roles may grant more permissions than you need. For minimum required permissions, assign only those listed in the Permissions needed column.

Preferred Role	Permissions needed
resourcemanager.projectIamAdmin (Project IAM Admin)	resourcemanager.projects.getIamPolicy
	resourcemanager.projects.setIamPolicy
	resourcemanager.projects.get
iam.serviceAccountUser (Service Account User)	iam.serviceAccounts.actAs
iam.serviceAccountAdmin (Service Account Admin)	iam.serviceAccounts.create
	iam.serviceAccounts.delete
	iam.serviceAccounts.get
workflows.editor (Workflows Editor)	workflows.workflows.create
	workflows.workflows.delete
	workflows.executions.create
	workflows.executions.get
	workflows.operations.get
serviceusage.serviceUsageAdmin (Service Usage Admin)	serviceusage.services.list

In addition to the end user account permissions, other permissions are temporarily granted to the service account created on your behalf until the installation is complete.

Configure networks

If a VPC network has not already been created for your target project, you need one created before proceeding. See Create and modify Virtual Private Cloud (VPC) networks for details. You need a subnet in each region where you plan to deploy a backup/recovery appliance, and the should be assigned with the compute.networks.create permission create it.

Note: Backup and DR Service does not learn non-RFC 1918 subnet routes from your VPC by default. If you need to deploy a backup/recovery appliance into a non-RFC 1918 subnet, then you need to update the private service connection to Backup and DR Service in order to export any non-RFC 1918 routes.

Validate the private service connection

If the VPC network already exists then it is possible that a private service connection exists. If a private service connection does not exist, then you create one during deployment.

If a connection exists, then validate that the subnet range is large enough by completing the following:

1. Go to the VPC networks page in the Google Cloud console.
   Go to VPC networks

2. Select your VPC network to open the details page for that network.

3. Select Private service connection.

4. Under Allocated IP ranges for services, validate the subnets that have been allocated. There are four possibilities:

   • If the service networking API is not enabled, then do nothing on this panel. The Backup and DR Service activation process guides you through the process of enabling the API and allocating an IP address range. Consult with your network administrator whether they want to allocate an IP range or allow Google to automatically allocate a /20 IP range during service activation. See Configure private services access for details.

   • If no IP range is allocated, then one needs to be created during service activation. Consult with your network administrator whether they want to allocate an IP range or allow Google to automatically allocate a /20 one during service activation. See Configure private services access for details.

   • If there is at least one IP range allocated in the private service connection labeled servicenetworking-googleapis-com that has a /20 subnet—for example, 10.159.112.0/20—then no further action is required.

   • If the subnet mask for the allocated IP range in the private service connection labeled servicenetworking-googleapis-com is /23 or larger than the allocated range is large enough for Backup and DR Service. If the subnet IP range is too small, a new range that has a subnet mask of /20 should be allocated. If the private service access connection already exists, ensure that a /23 IP range is available in the private service connection labeled servicenetworking-googleapis-com. Consult with your network administrator. See Modify a private connection for details.

Create a Cloud Storage bucket

You need a Cloud Storage bucket if you want to protect databases and file systems using the Backup and DR agent, and then copy the backups to Cloud Storage for long term retention. This also applies for VMware VM backups created using VMware vSphere storage APIs data protection.

Permissions required for this task

To create a Cloud Storage bucket you need a role that contains the following permissions:

• storage.buckets.get
• storage.objects.create
• storage.objects.delete
• storage.objects.get
• storage.objects.list
• iam.serviceAccountKeys.create
Roles that have these permissions include Storage Admin and Editor.

Create a Cloud Storage bucket using the following instructions:

1. In the Google Cloud console, go to the Cloud Storage Buckets page.
   

   Go to Buckets

2. Click Create bucket.

3. Enter a name for the bucket.

4. Choose a region to store your data in and click Continue.

5. Choose a default storage class and click Continue. Use nearline when retention is 30 days or less or coldline when retention is 90 days or more. If retention is between 30 and 90 days then consider using coldline.

6. Leave Uniform access control selected and click Continue. Do not use fine-grained.

7. Leave Protection tools set to None and click Continue. Do not select other choices as they do not work with Backup and DR Service.

8. Click Create.

9. Validate that your service account has access to your bucket:

   1. Select your new bucket to display the bucket details.

   2. Go to Permissions.

   3. Under Principals, ensure your new service accounts are listed. If they are not then use the Add button to add both reader and writer service accounts as principals.

   Note: The service account attached to the appliance by default cannot access user-created buckets as the Backup and DR Cloud Storage Operator role is added with an IAM condition that only allows it to access buckets if the bucket that is created starts with the same name of the appliance. Due to this reason, you need to manually add the service account as a principal against each user-created bucket you wish to add to an OnVault pool.

What's next

• Deploy Backup and DR Service