28 Using N2W with GCP
N2W Backup & Recovery supports backup and recovery for Google Cloud Platform (GCP) Compute Engine virtual machines and Persistent Disks, including disaster recovery (DR) — copying snapshots to another region and/or another GCP project.
To get started with GCP in N2W:
Create a custom IAM role and a service account with the required permissions. See section 28.1.
Define a GCP Security Principal. See section 28.2.
Add a GCP account to N2W. See section 28.3.
Create a GCP policy. See section 28.4.
Configure GCP Disaster Recovery, if needed. See section 28.5.
Back up the policy. See section 28.6.
Recover a VM or disk. See sections 28.7 and 28.8.
28.1 Setting Up Your GCP Account
N2W Backup & Recovery needs a dedicated service account and a custom IAM role on your GCP project to perform backup and recovery operations.
In the Google Cloud Console, select the project N2W will protect. Go to APIs & Services > Library, and ensure the Compute Engine API, Identity and Access Management (IAM) API, and Cloud Resource Manager API are enabled. If any of your disks use customer-managed encryption keys (CMEK), also ensure the Cloud Key Management Service (KMS) API is enabled.
Create a custom IAM role scoped to your project. For the minimum required permissions, see https://n2ws.zendesk.com/hc/en-us/articles/38317199721501--5-0-0-Required-Minimum-GCP-permissions-for-N2W-operations. Save the permissions definition as a
.yamlfile, then create the role with:gcloud iam roles create n2wsBackupRecovery --project=PROJECT_ID --file=PATH_TO_YAML_FILEIn IAM & Admin > Service Accounts, select Create service account, and enter a name and description.
On the Grant this service account access to project step, select the custom role you created in step 2, and finish the wizard.
Open the new service account, select the Keys tab, and select Add key > Create new key, choosing the JSON format. Download the key file — you'll upload it when defining the GCP Security Principal. See section 28.2.
28.2 Defining a GCP Security Principal
Like Azure, N2W separates the GCP authentication credential (the Security Principal) from the GCP project you want to protect (the Account) — a single Security Principal's credentials can be used across every GCP project (Account) they have access to.
N2W supports two ways to authenticate a GCP Security Principal:
Service Account Key – Upload a JSON key file for the service account you created in section 28.1. This method is always available.
VM-Attached Service Account – Use the identity of the service account already attached to the virtual machine the N2W server itself runs on. This option only appears when your N2W server is installed on GCP.
To define a GCP Security Principal:
Log on to N2W using the root username and password used during the N2W configuration.
In the main navigation menu, select Security Principals.
Select [+] New GCP Security Principal.

Complete the New GCP Security Principal screen:
Name – Enter a name for the security principal.
User – Select your username in the list, or select [+] New to add a user. See section 18.
Type – Select Service Account Key or VM-Attached Service Account. This field only appears as a choice when both types are available to you; otherwise it's set automatically.
Key File – If you selected Service Account Key, upload the JSON key file for your service account.

Select Save. N2W validates the credentials against GCP (confirming the key resolves to a real, active service account) before saving the Security Principal.

28.3 Adding a GCP Account to N2W
In the main navigation menu, select Accounts.
In the [+] New menu, select GCP Account.

Complete the New GCP Account screen:
Name – Enter a name for the account.
User – Select your username in the list, or select [+] New to add a user. See section 18.
Security Principal – Select an existing security principal, or select [+] New to create one. See section 28.2.
Project ID – Select the GCP project to associate with this account. Only projects that your selected Security Principal's credentials can actually access are listed.

Select Save. The new account appears in the Accounts list as a GCP account.

Note: Check Account Permissions in the toolbar is currently not yet available for GCP accounts.
28.4 Creating a GCP Policy
To back up resources in GCP, create an N2W GCP policy.
In N2W, select the Policies tab.
In the [+] New menu, select GCP Policy.

In the New GCP Policy screen, complete the fields:
Name, User, Account — as with other cloud policies.
Backup Targets – Select the Compute Engine virtual machines and/or independent Persistent Disks to protect. For a VM target, choose which of its attached disks to include: all disks, or a specific selection.
Schedule – Select or create a backup schedule. See section 4.1.
Retention – Set the number of backup generations to keep, a time-based retention period, or both, for original and DR snapshots — at least one must be enabled. You can also configure Multiple Retentions to apply distinct Daily/Weekly/Monthly retention to specific backups. See section 4.2.9.
Auto-Remove Resource – Select to automatically remove a resource from the policy if it's deleted or no longer accessible in GCP.



Select Save.
Note: GCP policies do not currently support tag-based (label-based) target selection or an application-consistent (VSS-equivalent) backup mode — targets are selected explicitly in the policy.
Note: Hyperdisk volumes are not currently supported as backup targets and are not selectable in the Backup Targets list.
28.5 Configuring GCP DR
GCP policies support both cross-region and cross-project disaster recovery, copying disk snapshots to additional locations to protect against regional or project-level data loss.
In the DR tab of the policy, select Enable DR.
Complete DR Frequency and DR Timeout.
Select the DR target: Cross-Region and/or Cross-Project.
If you selected Cross-Region, select one or more target regions in the DR Regions list. Each target must be a single region (multi-region locations are not supported as DR targets).
If you selected Cross-Project, complete the following:
DR Account – Select the GCP account (project) to copy snapshots to. This must be a different account than the policy's own account.
DR Account Regions – Select the region or regions, within the DR account, to copy snapshots to.
Keep Original Snapshots – By default, the original snapshot is kept in its source location. If disabled, the source snapshot is removed once the DR copy completes.
Select Save.

Note: While DR lets you store snapshot copies in a different region or project, virtual machine recovery with N2W is currently available only to the policy's original project and zone, even when recovering from a DR copy. Recovering into a different project or region is currently available for standalone disks only — see section 28.7.
28.6 Backing Up a GCP Policy
If the policy has a schedule, it backs up automatically. To run a policy immediately, select the policy and select [Run ASAP] in the Policies view.
To view backup progress, select Backup Monitor and use the Cloud filter to display GCP policies. Backup status is shown in the Status column.

28.7 Recovering a GCP Virtual Machine
After a backup completes, you can recover it from the Backup Monitor.
In the Backup Monitor, select the backup, then select Recover.
Select the VM snapshot to recover from. If the policy has DR configured, use the Recover From option to choose a specific account and region to recover from — the original backup location, or a DR copy.

In the Basic Options, complete the recovery fields:
VM Name – Enter a name for the recovered instance.
Private IP – Optionally assign a specific private IP address. It must be available and within the target subnet's range.
Preserve Network Tags, Preserve Resource Manager Tags, Preserve Labels – Select which of the original VM's tags/labels to carry over to the recovered instance.
Select Recover.
Note: Recovering a VM is currently available only into the same project and zone it was originally backed up from. If you select a DR copy under Recover From, N2W uses that copy's snapshot data, but the recovered VM is still created at the original location, not at the DR copy's location. Recovering into a different project, zone, network, or machine type is currently available for standalone disks only — see section 28.8.
Note: Only one VM is recoverable per recovery operation.
28.8 Recovering a GCP Persistent Disk
In the Backup Monitor or Recovery view, select the disk snapshot to recover from. If the policy has DR configured, use Recover From to choose a specific account and region — the original backup location, or a DR copy.
Complete the recovery fields:
Disk Name, Zone, Disk Type, Size – Override any of these for the recovered disk, or keep the source values.
Preserve Tags, Preserve Labels – Select which of the original disk's tags/labels to carry over.
Target Account – To recover into a different GCP project than the source, select the target account (cross-project recovery).
Encryption – If the source disk used a customer-managed encryption key (CMEK), N2W attempts to reuse it on the recovered disk. If GCP rejects the key (for example, if it's no longer available in the target project), N2W automatically falls back to Google-managed encryption.
Select Recover.
28.9 GCP Disaster Recovery Monitoring
GCP backup and DR activity is included in the dashboard's Backups (DR) card alongside AWS and Azure, showing successful and failed DR operations across all three clouds in one place.
Not covered in this chapter, as these capabilities are not currently supported for GCP: a GCP-backed Storage Repository, GCP worker configuration, tag/label-based policy target selection, and cross-cloud recovery between GCP and AWS/Azure.
Last updated
Was this helpful?

