This page describes how to perform initial activation of Backup and DR Service and set up configurations for your project.
Components of the Backup and DR architecture
The Backup and DR Service architecture is delivered through the following components:
Management console: The management console serves as the management plane for your backup/recovery appliances. Each Backup and DR deployment includes a single management console managing any number of backup/recovery appliances. The management console is deployed in the backup administration project and is highly available within the deployed region, ensuring resilience against zonal outages.
Backup/recovery appliances: The backup/recovery appliance is the data mover that efficiently captures, moves, and manages the lifecycle of backup data within your enterprise. The backup/recovery appliances are deployed in the Workload entity for cloud workloads.
Backup and DR agents: The Backup and DR agent calls the application-native APIs to efficiently capture data from production applications in an incremental-forever fashion, and provides the application awareness at the time of recovery. The agent is installed on application hosts where applications to be protected reside. If you are only protecting the entire VM or a subset of its disks, then the Backup and DR agent is not required.
The management console is activated into a service producer vpc network. This service producer vpc communicates with your project using Private Google Access.
Implementation considerations
Following are some important considerations that affect how you deploy Backup and DR Service:
What are your organization's Recovery Time Objective (RTO) requirements? The RTO is the maximum amount of time that you can afford to be without your data. For example, if your RTO is 4 hours,then you need to be able to access your data within 4 hours of a disaster.
Do you need to centralize your backup management? You need to decide whether you want to manage your backups centrally or not.
- Centralized backup management means that you have a single management console to manage backups for all your workloads across all lines of business. This can be a more efficient way to manage backups, as you only need to manage a single management console.
- Decentralized backup management means that you have a separate management console for each line of business. The mode of operation varies from organization to organization.
What is your backup use case? Do you need backups for disaster recovery readiness in the event of a disaster in a production region, or is it enough to protect your data locally? If you need disaster recovery capability, you must consider cross-region backups. This means storing your backups in multiple locations, so that if one location is affected by a disaster, your data will still be accessible.
Workloads are in a single region
Your best backup strategy within a region depends upon your needs.
If you don't need disaster recovery (DR)
For fastest performance and lower cost, deploy the management console and the backup/recovery appliances in the same region where your workloads are running. Store your backup images in the same region as your workloads.
If you also want to have backup copies off-site, then you can either store backups in a different region or use dual-region or multi-region storage. Storing backups in a different region incurs network and storage charges.
If you need both backup and DR
For fastest performance and lower cost, deploy a management console in the same region as the production workload region and a second management console in the region that you can use for disaster recovery.
Deploy backup/recovery appliances in both the production workload region and the DR region to minimize recovery time objective (RTO). This ensures that a DR environment is fully pre-provisioned and available in the event of a disaster.
Store backup images in the production region and a copy in the disaster recovery DR region, or use dual-region or multi-region storage. The production region backup copy can meet routine backup needs with faster performance. Data copied to your DR region can be used to recover your workloads in case the production region is down.
Workloads are in multiple regions
Your best backup strategy across regions depends upon your needs.
If you don't need disaster recovery (DR)
For fastest performance and lower cost, deploy the management console in one of the regions where your workloads are running. This allows centralized management across all the workloads and regions.
Deploy one or more backup/recovery appliances in each region where the workloads are running. Store your backups in the same region as your workloads.
If you also want to have backup copies off-site, then you can either store backups in a different region or use dual-region or multi-region storage. Storing backups in a different region or multi-region incurs network and storage charges.
If you need both backup and DR
Deploy a management console in each of the production workload regions and another management console in the DR region.
Deploy backup/recovery appliances in both the production workload regions and the DR region to minimize recovery time objective (RTO). This ensures that a DR environment is fully pre-provisioned and available in the event of a disaster.
Store backups in the production workload region and a copy in the DR region, or use dual-region or multi-region storage. The production region backup copy can be used to meet backup needs.
A backup image in the DR can be used to recover workloads if the production region is down.
Set up Backup and DR Service in the Google Cloud console
Go to the Google Cloud console to activate the Backup and DR Service API and set up permissions for your account:
Activate Google Cloud Backup and DR
Backup/recovery appliance types
Backup and DR Service provides appliance types that are optimized for different workloads—Compute Engine VMs, VMware VMs, databases, and file systems. You can choose the appliance type that best meets your needs. It's important to select the best appliance type for your workloads. Once the backup/recovery appliance is in service, it runs continuously forever, always ready to run and re-run backup, restore, and other jobs at all times.
Backup and DR Service provides the following appliance types:
- Standard for Compute Engine VMs or SAP HANA databases: Select this option if you want to backup only Compute Engine instances or SAP HANA databases using Persistent Disk. By default, this appliance adds an e2-standard-4 machine type with a minimum Persistent Disk capacity of 10 GB. This appliance can manage up to 5,000 Compute Engine VMs.
- Standard for VMware VMs and other databases or resources: Select this option if you want standard configuration that supports optimal performance to backup databases, VMware VMs, and other resources. By default, this appliance adds an n2-standard-16 machine type. This adds 4 TB of balanced disk capacity as the minimum disk capacity. This appliance can manage up to 1,500 applications.
Basic for VMware VMs and other databases or resources: select this option if you want to have a basic configuration that supports moderate performance to backup databases, VMware VMs, and other resources. By default, this appliance adds an e2-standard-16 machine type. This appliance can manage up to 1,500 applications. You can choose any of the following disk types to store your data.
- Minimal capacity Persistent Disk: this option provides a minimum disk capacity of 10 GB. In this storage type, backups are stored as Persistent Disk snapshots and don't consume the local storage of the backup/recovery appliance.
- Standard Persistent Disk: select this storage type if you want to have efficient block storage. This is recommended for Google Cloud VMware Engine VMs, databases, or file system application with mid-high I/O, in addition to Compute Engine VMs. This adds 4 TB of Persistent Disk capacity as the minimum disk capacity.
- SSD Persistent Disk: select this storage type if you want to have fast block storage. This is recommended for Google Cloud VMware Engine, databases, or file systems application with very high I/O, in addition to Compute Engine VMs. This adds 4 TB of Persistent Disk capacity as the minimum disk capacity.
When you deploy an appliance, a service account is created automatically regardless of the appliance type. You can view the service account from the Service Account page.
The service account's name appears in the email address format my-service-account@my-project.iam.gserviceaccount.com, where appliance-name is the name of an appliance and projectid is the ID of your Google Cloud project.
Choose a storage type
The backup/recovery appliance stores backup data in the local appliance snapshot pool. You can copy it to object storage for long term retention. Google Cloud offers the following three types of local object storage:
Minimal capacity Persistent Disk: Backup images are stored as Persistent Disk snapshots that don't consume the local storage of the backup/recovery appliance.
Standard Persistent Disk: This storage type offers efficient block storage, starting with a 4TB Persistent Disk. This is recommended for VMware Engines and database or file system applications with mid- to high I/O.
SSD Persistent Disk: This storage type offers fast block storage, starting with a 4TB Persistent Disk. This is recommended for Google Cloud VMware Engine VMs and database or file system applications with very high I/O.
You can expand the capacity of your disk pools later.
You can move backups with long-term retention needs to Google Cloud Standard, Nearline, and Coldline storage depending on your expected need to access the data.
Recommended network topology for Backup and DR Service
Google Cloud recommends the use of Shared VPC while deploying Backup and DR Service. Shared VPC allows an organization to connect resources from multiple projects to a common VPC (VPC) network, so that they can communicate with each other securely and efficiently using internal IPs from that network. When you use Shared VPC, you designate a project as a host project and attach one or more other service projects to it. The VPC networks in the host project are called Shared VPC networks. Eligible resources from service projects can use subnets in the Shared VPC network.
Shared VPC lets organization administrators delegate administrative responsibilities, such as creating and managing instances, to service project administrators while maintaining centralized control over network resources like subnets, routes, and firewalls.
The management console is activated into a service producer VPC network VPC. This service producer VPC communicates with your project using Private Google Access. The primary purpose of this connection is for the management console and the backup/recovery appliances to exchange metadata. Backup traffic doesn't traverse this link. However, a management console needs to communicate with all of the backup/recovery appliances deployed in any network.
Shared VPC best practices
The following best practices are recommended:
Connecting to the management console: It's best to connect the service provider network to a Shared VPC within your network. All traffic from the management console flows through this VPC, and therefore, through the host project. Provisioning the connectivity to the Backup and DR Service through a Shared VPC also enables a seamless connection between projects where the workloads are running (service projects) and the Backup and DR Service.
Backup/recovery appliance appliance location: The backup/recovery appliances must be deployed in a subnet that has Private Google Access enabled for connectivity to the management console. There are two recommended strategies for selecting the projects for the backup/recovery appliances:
In the central host project: In this strategy, Backup and DR Service is treated as a central service from IT. The central backup team governs provisioning of the service. As such, all backup/recovery appliances are provisioned in the host project enabling central admins to consolidate all backup resources into a central project. This approach has the benefit of consolidating all backup-related resources and their billing into a single project.
In service projects: This strategy is suitable for more decentralized teams where service projects are created and their management is delegated to distributed teams. In this scenario, the recommended best practice is to provision VPC for downstream service projects. Backup/recovery appliance are installed in the service projects within these VPCs. This enables colocation of the workload and the backup/recovery appliance within a single project.
Private Google Access: It is a best practice to enable Private Google Access for each subnet where you install a backup/recovery appliance. This ensures the backup/recovery appliance can communicate with APIs, such as Compute Engine, Cloud Storage, and Cloud Logging, which is important for monitoring and alerting to work. To simplify and enhance connections to Google Cloud APIs, consider configuring DNS resolution for
private.googleapis.comas documented in the Summary of configuration options section. Also, configure the firewall rules from the backup/recovery appliances to allow connections to the CIDR range199.36.153.8/30on TCP port443.
Firewall configurations
The following required firewall rules for ingress into Backup and DR Service are automatically added.
| Purpose | Source | Target | Port (TCP) |
|---|---|---|---|
| Support traffic (support to appliance) | Host running SSH client | Backup/recovery appliance | 26 |
| iSCSI backup (host to appliance) | Host running Backup and DR agent | Backup/recovery appliance | 3260 |
| StreamSnap traffic (appliance to appliance) | Backup/recovery appliance | Backup/recovery appliance | 5107 |
| Backup/recovery appliance connectivity to management console | Backup/recovery appliance IP or subnet | *.backupdr.googleusercontent.com | 443 |
For more detail on how to configure this rule, see Prepare to deploy Backup and DR Service.
For any host that is running the Backup and DR agent, you must manually add the following TCP port to allow connectivity with an ingress firewall rule.
| Purpose | Source | Target | Port (TCP) |
|---|---|---|---|
| Agent traffic (appliance to host) | Backup/recovery appliance | Host running Backup and DR agent | 5106 |
For hosts using NFS for backup traffic, or for ESX hosts running in VMware Engine that are using NFS for mounts, you need to manually add the following TCP and UDP ports to allow connectivity with an ingress firewall rule.
| Purpose | Source | Target | Port (TCP/UDP) |
|---|---|---|---|
| NFS backup or mount | Host running Agent or ESXi host running mount | Backup/recovery appliance | 111, 756, 2049, 4001, 4045 |
For a list of the permissions used during this operation, see Backup and DR installation permissions reference.
Supported regions
The following section lists the management console and backup/recovery appliances supported regions.
Management console supported regions
While Backup and DR Service can be used to back up supported workloads in any Google Cloud region, the management console can be activated only in the following regions. Note that you cannot move the management console to a different region.
| Geographic Area | Region Name | Region Description | |
|---|---|---|---|
| Americas | |||
us-central1 |
Iowa |
 Low CO2
|
|
us-east1 |
South Carolina | ||
us-east4 |
Northern Virginia | ||
us-west1 |
Oregon |
Low CO2 |
|
us-west2 |
Los Angeles | ||
us-west4 |
Las Vegas | ||
southamerica-east1 |
São Paulo |
Low CO2
|
|
| Europe | |||
europe-west1 |
Belgium |
Low CO2
|
|
europe-west2 |
London |
Low CO2
|
|
europe-west3 |
Frankfurt |
Low CO2
|
|
europe-west4 |
Netherlands |
Low CO2
|
|
| Asia Pacific | |||
asia-east1 |
Taiwan | ||
asia-southeast1 |
Singapore | ||
australia-southeast1 |
Sydney | ||
| India | |||
asia-south1 |
Mumbai | ||
asia-south2 |
Delhi |
Backup/recovery appliance appliance supported regions
Backup and DR Service backup/recovery appliances can be deployed into any
Google Cloud zone.
Workflow service to perform the backup/recovery appliance deployment is supported in the
listed regions. If the Workflow service isn't
available in a region where your backup/recovery appliance is deployed, then the
Backup and DR Service defaults to running the workflow in the us-central1 region
(the appliance itself is still created in your selected region). If you have an
organization policy that is set to prevent creating resources in other regions,
then you must temporarily update your organization policy to allow creation of
resources in us-central1 region. You can restrict the us-central1 region
after deployment of the backup/recovery appliance.