26 Using N2WS with Azure
Manage the backup and recovery of your Azure resources.
Following are the steps for setup, backup, and recovery of Azure VMs, Disks, and SQL Servers:
Before starting, configure N2WS Backup & Recovery according to section 2.
After the final configuration screen, prepare your Azure Subscription by adding the required permissions and custom IAM role in Azure. See section 26.1.
Enable Azure Cloud as one of your UI defaults in N2WS Server Settings > General Settings > User UI Default.
Register the CPM app in Azure. See section 26.2.
Create an N2WS account user as usual and configure resource limitations for Azure as described in section 18.3.
Assign a custom role to your app. See section 26.3.
In N2WS, add an Azure account with the custom N2WS role. See section 26.4.
Create a Storage Account Repository for your data objects. See section 26.5.
Create an Azure policy in N2WS with Azure backup targets. See section 26.6.
Configure Azure Disaster Recovery. See section 26.7.
Back up the policy. See section 26.8.
Recover from a backup, including file-level recovery. See section 26.9.
26.1 Setting Up Your Azure Subscription
N2WS Backup and Recovery needs the following permissions to perform backup and recovery actions.
For the minimal permissions for Azure, see https://support.n2ws.com/portal/en/kb/articles/minimal-azure-permissions-roles-for-n2ws-operations
Add your subscription ID value to the
subscriptionsattribute in the minimal permissions JSON.
4. Complete the form as follows using N2WSBackupRecoveryRole as the Custom role name, and then select the JSON file saved in step 1. 5. Create the role with the new JSON file.
26.2 Registering Your Azure App
In the Azure portal Dashboard section, go to the App registrations service.
In the Name box, type CPM-on-Azure and select Register.
3. Select the app. 4. Save the Application (client) ID and Directory (tenant) ID for use when adding the Azure account to N2WS.
26.3 Assigning the Custom Role to your App
In Azure, go to the Subscription service and select your subscription.
Select Access control (IAM).
Select Add and then select Add role assignment.
In the Role list, select your custom role.
In the Select list, select the app that you created.
Select Save.
In the Role assignments tab, verify that the custom role is assigned.
26.4 Adding an Azure Account to N2WS
Log on to N2WS using the root username and password used during the N2WS configuration.
Select the Accounts tab.
Complete the New Azure Account screen using the App registration view information in the Azure portal as needed.
Name - Copy from your App registration name.
Directory (tenant) ID – Copy from your App registration.
Application (client) ID – Copy from your App registration.
Client Secret – Copy from your App registration Certificates & secrets in the App registration view, or set a new secret.
Scan Resources - Select to include the current account in tag scans performed by the system. The scan will cover all VMs and disks in all locations.
5. Select Save. The new account appears in the Accounts list as an Azure Cloud account.
26.5 The Storage Account Repository
Storage Account repositories are where backups of SQL servers are stored. Storage Account repositories can also be used to store disk snapshots via Lifecycle policy or serve as cross-cloud storage for AWS volume snapshots via a Lifecycle policy. For more details, see section 21.
A single Azure Storage Account container can have multiple repositories.
26.5.1 Configuring an Azure Storage Repository
In N2WS, select the Storage Repositories tab.
In the Storage Repositories screen, complete the following fields, and select Save when complete.
Name - Type a unique name for the new repository, which will also be used as a folder name in the Azure Storage Repository container. Only alphanumeric characters and the underscore are allowed.
Description - Optional brief description of the contents of the repository.
User – Select the user in the list.
Account - Select the account that has access to the Storage Repository.
Subscriptions – Select the subscription that owns the Storage Repository.
Resource Group – Select the Storage Repository's resource group.
Location – Select the Storage Repository’s location.
Storage Account Name – Select the name of the Storage Account from the list.
Immutable backups - Select to protect data stored in the repository from accidental deletion or alteration. When enabled, the N2WS server puts a Lease on every object stored in the Storage Repository. A leased object cannot be deleted or modified until the Lease is cancelled. You can specify the string that will be used as the Lease (in a UUID format), or let N2WS create one for you.
26.5.2 Deleting a Storage Repository
You can delete all snapshots copied to a specific Storage Repository.
Deleting a repository is not possible when the repository is used by a policy. You must change the policy's repository to a different one before you can delete the Target repository.
Select the Storage Repositories tab.
Select the repository to delete.
26.6 Creating an Azure Policy
To back up resources in Azure, create an N2WS Azure policy.
In N2WS, select the Policies tab.
In the New Azure Policy screen, complete the fields:
Name – Enter a name for the policy.
Enabled – Clear to disable the policy.
Subscription – Select from the list.
Auto Target Removal – Select Yes to automatically remove a non-existing target from the policy.
4. Select the Backup Targets tab. 5. For each resource type to back up, in the Add Backup Targets menu, select a target. The applicable screen opens.
For Virtual Machines, see section ‎26.6.2.
For SQL Servers and their databases, see section ‎26.6.1.
For Azure disks, see section ‎26.6.3.
6. Before completing a policy with SQL Server backup targets, select a Target repository for the policy in the Storage Repository tab, and then select Save.
7. In the Backup Targets tab, review the selected targets, and then select Save.
26.6.1 Adding an SQL Server Target
An SQL Server backup is performed by a worker. The worker parameters for each SQL Server target are configured in the Policy SQL Server and Database Configuration screen, as shown in step 3 below.
Backups are always full to enable fast restores.
Backups are kept in an Azure Repository.
The default behavior for workers has changed in 4.3.0. The worker used for SQL Backup & Recover now uses a private IP instead of a public IP. To change:
1. Connect to your N2WS Backup and Recovery Instance with SSH Client.
2. Type sudo su.
3. Add the following lines to /cpmdata/conf/cpmserver.cfg:
[azure_worker]
assign_public_ip_to_public_sql_server_workers=True
4. Run service apache2 restart
5. Choose the worker’s Vnet and subnet as the SQL Server.
Following are possible backup configurations for an SQL Server target:
Back up all databases
Include or Exclude only pre-selected databases in the backup process
Before selecting individual SQL Servers, it is required to filter by the Location of the target resources using the list in the upper left corner. Filtering by Resource Group is optional.
To add an SQL Server target:
In the Add Backup Targets menu, select SQL Servers. The Add SQL Servers table opens.
2. When finished selecting targets, select Add selected. The Backup Targets tab lists the selected targets.
4. In the Which Databases list, choose whether to back up All Databases on this server, or select databases, and then choose Include Selected or Exclude Selected.
5. For each database, change Private DNS Zone, SSH Key, Virtual Network, Subnet, Security Group, and Network Access as needed, and then select Apply.
6. In the Storage Repository tab, select the Target repository for the SQL Server backup, and then select Save.
26.6.2 Adding an Azure Virtual Machine
Before selecting individual Virtual Machine targets, it is required to filter by the Location of the target resources using the list in the upper left corner. Filtering by Resource Group is optional.
On the Add Backup Targets menu, select Virtual Machines. The Add Virtual Machines table opens.
2. Select the virtual machines for backup, and then select Add selected. The Backup Targets tab lists the selected targets.
4. In the Which Disks list, select the disks to Include or Exclude in the backup. Change additional information as needed, and then select Apply.
26.6.3 Adding an Azure Disk Backup Target
To define backup success, retries, and failures for alerting:
In the Add Backup Targets menu, select Disks.
26.6.4 Setting Backup Success and Retry Policy
To define backup success, retries, and failures for alerting:
Select the relevant policy.
In the More Options tab, complete the backup, retry, and alert options as described in section ‎4.2.4.
26.6.5 Enabling Immutable Backups
Enabling Immutable Backups will prevent the unauthorized deletion of Azure VM and disk snapshots. When a policy is enabled for Immutable Backups, a ‘Delete’ lock type is assigned to a disk snapshot until the lock is removed. The lock is removed by N2WS before Cleanup or by user-initiated deletion.
To enable immutable backups:
Select the relevant policy.
In the More Options tab, select Enable Immutable Backups.
To view the Lock Type in Azure:
On the Azure console, go to the Snapshot page and select Locks.
26.7 Configuring Azure DR
The DR operation copies managed disk snapshots to selected locations.
In the DR tab, select Enable DR.
Complete DR Frequency and DR Timeout.
In the Target Locations list, select the DR target locations.
26.7.1 Setting a Tag for Managed Disks with Disk Access
Azure can manage private access disks using a Disk Access resource, which is based on subscription and location. For disk targets using private access, provide a tag with the ID of the Disk Access resource on the selected DR locations.
To provide a Disk Access ID, add a tag to the resource as follows:
Key: ‘cpm_dr_disk_access’ or ‘cpm_dr_disk_access:<LOCATION>’; Value: ‘<Disk Access ID>’
If disks are attached to a Virtual Machine target and same Disk Access is used for all backed up disks, it is sufficient to add the tag to the Virtual Machine and not each disk.
If a single DR location is selected, there is no need for ‘:
<LOCATION>’ in the tag key.
26.8 Backing Up an Azure Policy
If the policy has a schedule, the policy will backup automatically according to the schedule.
26.9 Recovering from an Azure Backup
To recover from a Wasabi Repository, see section ‎27.3.
To orchestrate recovery scenarios with Azure targets, see section ‎24.
After creating a backup, you can recover it from the Backup Monitor.
In the VM recovery Basic Options, there are Azure options for replicating data to additional locations
to protect against potential data loss and data unavailability:
Availability Zone – A redundant data center (different building, different servers, different power, etc.) within a geographical area that is managed by Azure.
Availability Set – A redundant data center (different building, different servers, different power, etc.) that can be launched and fully configured by the customer and managed by the customer.
No Redundancy Infrastructure Required – By selecting this option, the customer can choose not to replicate its data to an additional (redundant) location in another zone or set. By choosing this option, the customer would save some money, but in rare cases (usually 11 9s of durability and 99.9% of availability), the customer can experience some degree of data loss and availability.
In the Disk Recovery screen, you may be presented with an option to change the encryption when recovering certain disks.
26.9.1 Recovering a VM and Disks
To recover a VM and/or attached disks:
b. In the Availability Type list, select one of the following:
No Infrastructure Redundancy Required – Select to not replicate data at a redundant location in another zone or set.
Availability Zone – Select a zone in the Availability Zone list.
Availability Set – Select a set in the Availability Set list.
c. In the Private IP Address box, assign an available IP address or switch the Custom toggle key to Auto assigned.
d. The default Preserve Tags action during recovery is Preserve Original for the virtual machine. To manage tags, see section ‎‎10.3. e. In the Disks tab, enter a new Name for each disk. Similar names will cause the recovery to fail.
f. Select Recover Virtual Machine.
3. To recover only Disks attached to the VM, select Recover Disks Only. a. In the Disks tab, enter a new Name for each disk. Similar names will cause the recovery to fail. b. See Note in section 26.5 about changing the Encryption Set for certain disks. c. Change other settings as needed. d. Select Recover Disk.
26.9.2 Recovering a VM with Virtual Machine Scale Set
Following are the basic steps in recovering a VM with a Virtual Machine Scale set:
In AWS, create a backup and recover disks.
In Azure, create and configure a VM, and then attach the recovered disks.
To recover a VM with a Virtual Machine Scale Set:
Select a successful backup, and then select Recovery.
Select the VM, and choose Recovery only Disks.
Select the disks to recover, and then select Recover Disk.
After the disks are successfully recovered, go to the Azure portal, and locate the recovered root disk.
Select "+ Create VM".
Configure the VM:
In Availability Options, select Virtual Machine Scale Set, and then proceed with the setup.
In the Disks tab, make sure to attach the existing recovered disks.
26.9.3 Recovering Independent Disks
To recover from backups with independent disks:
In the Independent Disks tab:
Enter a new Name for each disk to recover as similar names will cause failure.
See section 26.10 about changing the Encryption Set for certain disks.
The default Preserve Tags action during recovery is Preserve Original for the independent disks associated with the virtual machine. To manage tags, see section ‎‎10.3.
Change other settings as needed.
Select Recover Disk.
26.9.4 DR Recovery
When recovering from a backup that includes DR (DR is in Completed state), the same Recover screen opens but with the addition of the Restore to Location drop-down list.
Default location is Origin, which will recover all the objects from the original backup. It will perform the same recovery as a policy with no DR.
When choosing one of the other regions, the objects are listed and are recovered in the selected location.
26.9.5 Recovering an SQL Server and Databases
You can recover an SQL Server and some of or all its databases or just the SQL databases.
To recover an SQL Server with some or all its databases:
3. In the Server Admin Login and Password boxes, provide the credentials to use in the recovered SQL Server.
4. The default Preserve Tags action during recovery is Preserve Original for the servers. To manage tags, see section ‎‎10.3.
5. In the Network tab:
a. Select the Minimum TLS Version in the list.
b. Select Firewall Rules and Virtual Network Rules, or select Deny Pubic Network Access.
6. In the SQL Databases tab, select the databases to recover.
The default Preserve Tags action during recovery is Preserve Original for the database. To manage tags, see section ‎‎10.3.
7. In the Worker Options tab, set values to enable communication between the Worker and the SQL Server.
7. Select Recover SQL Server.
To recover SQL Databases only:
In the SQL Databases tab, enter a new Name for each database. Similar names will cause the recovery to fail.
The default Preserve Tags action during recovery is Preserve Original for the database. To manage tags, see section ‎‎10.3.
Change other settings as needed.
Select Recover SQL Database.
26.9.6 File-level Recovery from a Snapshot of an Azure Disk or Virtual Machine
When you back up an Azure Virtual Machine or disks, you can recover individual files from the backup without having to recover the entire Virtual Machine or all disks.
To recover individual files from a snapshot of an Azure disk or Virtual Machine:
Complete the steps required to configure a worker to be launched in the account, subscription, and location of the source snapshot. See section 22.
To explore files from an entire virtual machine, go to the Virtual Machine tab, select the virtual machine, and then select Explore Disks Files.
To explore files from one or more disks belonging to a virtual machine, go to the Virtual Machine tab, select the virtual machine, then select Recover Disks Only. Select one or more disks, and then select Explore Disks.
To explore files from an independent disk, go to the Independent Disks tab, select the disk, and then select Explore Disks.
If multiple backups of the chosen target exist, you will be prompted to select the number of different backups to explore. Select the desired number, and then select Start Session.
26.10 Cross-Cloud Recovery of AWS Volume from S3 to Azure
N2WS allows recovering an AWS volume backup to Azure.
Limitations:
Cross-cloud recovery is supported only for Instance Volume backups copied to S3.
From the UI, such recovery can only be initiated for one volume at a time chosen from the Volume Recovery from Instance screen.
OS\root disk functionality doesn’t migrate from AWS to S3. If N2WS recovers an AWS root volume to Azure, an Azure VM can’t be spined up from that disk.
To recover a volume from S3 to Azure:
In the Backup Monitor, select an Instance backup that was copied to S3, and then select Recover.
In the Recover screen, select the instance from which the volume is to be recovered.
In the Restore from list, choose the repository to which the volume was copied.
In the Restore to Account list, choose the Azure account to restore to.
In the Subscription list, choose the subscription to restore to.
Select Recover volumes only.
7. In the Volume Recovery from Instance screen, select one volume to recover.
8. In the Disk Name box, type the name of the disk to be recovered in Azure.
9. In the Resource Group list, choose the resource group to which the disk will be recovered.
10. Optionally, choose an Availability Zone to recover to and the Encryption Set to use on the recovered disk.
11. Select Recover Volume.
26.11 Using Lifecycle Management to Lower Cost of Managed Disk Snapshots
Snapshots of Azure Managed Disks can be stored in a Storage Repository at a lower cost.
N2WS allows creation of lifecycle policies. In lifecycle policies, older snapshots are automatically moved from high-cost to low-cost storage tiers. The snapshots can be stored in any Storage Repository supported by your N2WS license:
AWS Storage (S3) Repository
Azure Storage Repository
Wasabi Repository
26.11.1 Limitations
Life-cycle policy applies only to Managed Disk snapshots, whether they are backed up as independent disks, or as part of a virtual machine backup. If a policy contains resources other than virtual machine or Disks, these resources will not be affected by the lifecycle policy.
Backups copied to Storage Repository cannot be moved to the Freezer.
To use the Lifecycle Policy functionality, the
cpmdatapolicy must be enabled. See section ‎4.2.1 for details on enabling thecpmdatapolicy.Due to the incremental nature of the snapshots, only one backup of a policy can be copied to Storage Repository at any given time. A backup will not be copied to the repository if the previous backup in the same policy is still being copied. Recovery from the repository is always possible unless the backup itself is being cleaned up.
Lifecycle operations, such as Snapshot Copy and Cleanup, are performed by Workers. For Copy operations, the worker is always launched in the account, subscription, and location of the disk whose snapshot is being copied. A Worker configuration must be created for every such combination. To speed up the operations, N2WS will attempt to launch 2 workers per policy. Your Virtual machine quotas must be large enough to allow launching the required number of workers. For more information about workers, see section 26.12.
Copy and Restore of data to/from a repository outside of the Azure cloud, such as AWS Storage (S3) Repository, or Wasabi Repository, may incur additional network charges.
26.11.2 Enabling and configuring Lifecycle rules for an Azure Policy
In the N2WS left panel, select the Policies tab.
Select the Lifecycle Management tab.
Turn on the Use Storage Repository toggle switch.
Choose the interval between backups that are to be moved to the Storage Repository. For example, to move a weekly backup of a policy that runs daily backups, choose 7.
Choose whether to delete the original Disk Snapshots after they are copied to the Storage Repository.
When enabled, snapshots are deleted regardless of whether the copy to Storage Repository operation succeeded or failed.
7. Select the retention settings for the snapshots in the repository. Retention can be specified in terms of the number of backups (generations), backup age, or a combination of the two. If generations and age are enabled, a backup will be deleted only if both criteria have been met.
26.11.3 Recovering from Storage Repository
You can recover a backup from Storage Repository to the original location or to a different one.
To recover a backup from Storage Repository:
Make sure a Worker Configuration exists for the location where the resource is to be recovered. See section 26.12 for more information.
In the Restore from drop-down list of the Recover screen, select the name of the Storage Repository to recover from.
In the Restore to Location drop-down list, select the Location to restore to.
Select the resource to recover (either a Virtual Machine or a Disk) from the list and select Recover. If you wish to recover only selected disks from a Virtual machine backup, select the Virtual machine, select Recover Disks Only, and then select the desired disks.
In the dialog, complete the relevant recovery parameters. See section 26.9.1 for more details.
In the Recovery From Repository Options tab, choose a Storage Account that will be used to store temporary data during the recovery process.
Select Recover Virtual Machine / Recover Disks to start the recovery process.
You can follow the process in the Recovery Monitor.
26.12 Configuring Azure Workers
Workers are used by N2WS for Lifecycle operations, such as copying Azure Disk Snapshots to a Repository, as well as for Cleanup and Recovery of these snapshots. A Worker Configuration specifies the parameters required for launching a worker instance for a specific combination of account/subscription/location. Whenever a worker is required, N2WS will look for a Worker Configuration according to the operation’s account, subscription, and location.
26.12.1 Worker Parameters
To configure Azure worker parameters:
Select the Worker Configuration tab.
In the User, Account, Subscription, and Location lists, choose the values you are creating the configuration for. The configuration will be applied to all workers launched in the selected location, account, and subscription.
Select a Resource Group where the worker will be created.
Choose an SSH Key to be associated with the worker. If you leave the default, don’t use key pair as you will not be able to use key-based authentication for SSH connections to this worker.
Select a Virtual Network from the list. The selected network must allow workers to access the subnet where N2WS is running as well as the Azure Blob services and the repository.
Select a Subnet from the list.
Select a Security Group to be applied to the workers.
In the Network Access list, select a network access method. Direct network access or indirect access via an HTTP proxy is required:
Direct - Select a Direct connection if no HTTP proxy is required.
via HTTP proxy -
–If an HTTP proxy is required, select, and fill in the proxy values.
Select Save.
Test the new worker. See section ‎22.3.
To edit or delete a worker configuration:
In the Worker Configuration tab, select a worker.
Last updated
Was this helpful?
