# GCP GCE

Storware Backup & Recovery supports the Google Compute Engine platform by using a VM called “Proxy VM”. The node invokes commands on the GCP to snapshot and attach temporary disks of a specific VM to itself (Proxy VM). The proxy VM is able to read the data from the attached disk snapshots and forward them to the backup provider.

This means that you need to create a Compute Instance (Proxy VM) in each zone from which you want to secure instances.

The Storware Backup & Recovery Server can be deployed anywhere, but keep in mind that Nodes need to be able to call the server over HTTP(S) on the port you have specified.

The GCP backup strategies allows you to exclude drives from the backup that you don’t need.

All backup destinations can be used, but keep in mind that you may be charged for transferring data between regions, zones, and external backup providers.

Storware Backup & Recovery Node has access to instances only in the **projects where service account has access to**.

Storware Backup & Recovery Node requires the **organization ID** and **service account key** to connect to the GCP account.

## Typical use scenarios <a href="#typical-use-cases" id="typical-use-cases"></a>

There are several scenarios for GCP which may be suitable for your case:

* **Backup GCE to GCS** - in this case after dumping backup, Storware Backup & Recovery can push them to the GCS bucket.
* **Backup GCE to your local backup provider** - if you already have a central enterprise backup solution, you may want to use it as a backup provider for GCE instances running in GCP.
* **Backup GCE to your other cloud provider** - If you're using multiple clouds, you also may consider storing data in S3 or Azure backup providers.

{% hint style="info" %}
**Note**: In all cases, depending on your target, you may be charged for data transfers.
{% endhint %}

## Setup considerations <a href="#setup-considerations" id="setup-considerations"></a>

It is assumed that you have working experience with GCE to be able to deploy Storware Backup & Recovery components. You also need to have an IAM user with permissions that allow you to deploy an instance and generate service account access key for Storware Backup & Recovery.

Remember to use **CentOS 8** as a base image - both for the Server and Nodes. For a typical installation, we recommend 2 virtual processors and 8 GB of RAM. This means that **e2-standard-2** should cover general use cases.

Both Storware Backup & Recovery components are assumed to be deployed without HA (more precisely, all the nodes or server will probably be in separate zones, and only need to communicate over HTTP). There is no requirement for multi-zone deployment for now. While the Node is stateless and can be lost without data loss, the Server needs DB to be protected. Storware Backup & Recovery provides a built-in automatic DB backup mechanism, which can be used to protect backup metadata. Please refer to the [Disaster recovery](https://docs.storware.eu/backup-and-recovery-7.3/troubleshooting/disaster-recovery) section for more details.

You add GCP as a Hypervisor Manager. You need to provide the organization ID and service account keys of a user that has required permissions.

## Permissions

Cloud Resource Manager needs to be enabled in project where proxy vms are located.

Here are the IAM permissions that Storware Backup & Recovery needs to have for backup/restore operations.

```
compute.disks.create
compute.disks.createSnapshot
compute.disks.delete
compute.disks.get
compute.disks.list
compute.disks.use
compute.disks.useReadOnly
compute.diskTypes.list
compute.globalOperations.get
compute.instances.attachDisk
compute.instances.create
compute.instances.delete
compute.instances.detachDisk
compute.instances.get
compute.instances.list
compute.instances.setMetadata
compute.instances.setServiceAccount
compute.instances.setTags
compute.machineTypes.list
compute.projects.get
compute.regions.list
compute.snapshots.create
compute.snapshots.delete
compute.snapshots.get
compute.snapshots.list
compute.snapshots.setLabels
compute.snapshots.useReadOnly
compute.subnetworks.list
compute.subnetworks.use
compute.subnetworks.useExternalIp
compute.zoneOperations.get
compute.zones.list
iam.serviceAccounts.actAs
resourcemanager.projects.get
```

## Adding a hypervisor manager

To properly configure your GCP account, go to Storware Backup & Recovery WebUI -> Virtual Environments -> Infrastructure -> add hypervisor manager

Enter parameters such as:

* Organization ID
* Service Account Key

![](https://content.gitbook.com/content/aAlfZI37JR0ShCZIy4qK/blobs/NzveZ2W4IsGPL65P4gKS/protecting-virtual-environments_cloud_gcp-gce.png)

{% hint style="info" %}
**Note**: If you want to backup instances in projects without organization provide 0 as the Organization ID.
{% endhint %}

## Multi-zone configuration

To secure instances from multiple zones, You need to register additional Nodes. For every zone you want to backup instances from, You need to create separate Node Configuration. Each Node Configuration needs to be assigned to correct Hypervisor Cluster (which reflects compute zone from GCP).

First Synchronization Task needs only one Node. After first scan, You can assign Node Configurations to Hypervisor Clusters, and run Synchronization Task once again to fetch all instances from other zones.

To assign Node Configurations to Hypervisor Cluster you need to go to Clusters list in Infrastructure tab. Then click on selected Cluster to choose Node Configuration.

{% hint style="info" %}
**Note**: For backup and restore between zones nodes and node configurations should have access to the same backup destination.
{% endhint %}

## Backup strategies

GCP supports two backup and restore strategies:

1. Disk attachment (full)
2. Disk attachment with changed block tracking (full/incremental)

In both cases, volume snapshots are kept in GCP only until the Storware Backup & Recovery Export task is completed.

## Restore

Storware Backup & Recovery supports:

* restoring instances to different projects
* restoring instances to different regions and zones
* restoring instances to different machine types (that are available in selected regions)
* restoring instances to different subnetworks (that are available in selected project)
* restoring disks to different disk types

{% hint style="info" %}
**Note**: Storware Backup & Recovery do not support backup/restore of VM with disk encrypted with an imported key. Currently, only VMs with key generated by GCP are supported.
{% endhint %}
