TECHNICAL WHITE PAPER

How It Works: Cloud-Native Protection for Azure

Bill Gurling
March 2021
RWP-0513
TABLE OF CONTENTS

3 INTRODUCTION 24 SUMMARY
3 Audience
25 GLOSSARY
3 Objectives
App Registration
3 Challenges
Azure Blob
4 The Rubrik Approach
Azure Kubernetes Service (AKS)
4 Key Features Azure Role (Role Definition)
Azure Subscription
6 ARCHITECTURE AND COMPONENTS
Azure Tenant
6 High Level Architecture
Azure Virtual Machine (VM)
7 Components
Customer Azure Tenant
7 How Cloud-Native Protection for Enterprise App Registration / Service Principal
Azure Works
Exocompute
7 Authorize
Locally Redundant Storage (LRS)
10 Configure
Logical Unit Number (LUN)
SLA Domains and Cloud-Native
Protection for Azure Managed Disk
11 Protect Managed Disk Snapshot
Subscription Level SLA Assignment Microsoft Azure
Tag Rules Resource Group
Direct SLA Domain Assignment Resource ID
Disk Exclusion Rubrik Azure Tenant
On Demand Snapshots Rubrik Polaris
App Consistency Service Level Agreement (SLA) Domain

Shared Access Signature (SAS) URI

17 HOW IT WORKS
Storage Account
17 Backup
Zone Redundant Storage (ZRS)
20 Restore

21 Export 28 APPENDIX A - AZURE TAGS

21 Managed Disk Exports

30 APPENDIX B - METADATA
22 Azure VM Exports

23 Replication 31 VERSION HISTORY

 INTRODUCTION
Welcome to How It Works: Cloud-Native Protection for Azure. The purpose of this document is to aid the reader in familiarizing
themselves with the features, architecture, and workflows of Rubrik’s Cloud-Native Protection for Microsoft Azure. Such
information will prove valuable while evaluating, designing, or implementing the technologies described herein.

AUDIENCE
This guide is for anyone who wants to better understand the capabilities of Cloud-Native Protection for Azure on Rubrik’s
Polaris platform and the technical architectures that underpin those capabilities. This includes architects, engineers, and
administrators responsible for Azure infrastructure and data protection operations as well as individuals with a vested interest
in security, compliance, or governance.

OBJECTIVES
The goal of this guide is to provide the reader with a clear and concise point of technical reference regarding architecture and
workflows utilized by Cloud-Native Protection for Azure on Rubrik Polaris. After reading this document, the reader should be
able to answer the following questions regarding Cloud-Native Protection for Azure:

• What does Cloud-Native Protection for Azure do?

• What problem(s) does the Cloud-Native Protection for Azure solve?

• How does one configure and utilize Cloud-Native Protection for Azure?

• How is Cloud-Native Protection for Azure architected? Why?

• How does Cloud-Native Protection for Azure operate?

• How does Cloud-Native Protection for Azure compare to alternate solutions?

CHALLENGES
Digital enterprises are increasingly using multiple private and public clouds to deploy applications, avoid vendor lock-in,
and exploit best-of-breed solutions. However, this fragments data within clouds, as well as across hybrid and multi-cloud
infrastructures, fracturing IT’s ability to protect, manage, and secure their data, operations, and business.

Public cloud providers themselves are responsible for the protection and availability of the cloud, however it is still the
customer’s responsibility to protect resources in the cloud. What this means, practically speaking, is that it is ultimately the
customer’s responsibility to protect their applications and data running in a public cloud, regardless of provider. The Shared
Responsibility Model published by Microsoft is a great point of reference for these concepts.

This leaves the customer at a critical decision point – How do I efficiently and reliably protect my assets that reside in the
cloud? While the question seems simple on its face, selecting the appropriate solution is actually quite difficult.

In hybrid or multi-cloud environments, customers might be inclined to lift and shift legacy tooling into the cloud. Unfortunately,
this approach often hampers the agility and elasticity that enterprises are seeking when adopting a cloud strategy.

The alternative, leveraging platform native tooling from the cloud provider themselves can be similarly flawed as this segments
data protection operations between public cloud providers as well as between public and on-premises environments. Such an
approach leads to significant headwinds in terms compliance, visibility, and operational efficiency.

The need for an alternate approach is clear.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 3

 THE RUBRIK APPROACH

Figure 1 - Rubrik Polaris Multi-cloud Protection

Rubrik’s goals are to collapse the footprint of legacy data protection solutions, simplify and automate backup and recovery
using policy-based protection, minimize data loss, and streamline operations. Cloud-Native Protection for Azure is a Software
as a Service (SaaS) based data protection platform that provides automated backup, recovery, and replication schedules
across regions and across clouds with a single global policy engine. This solution allows Rubrik customers to reap the benefits
of rapid innovation and reduced management complexity with data protection delivered as a service.

Protecting Azure workloads with Rubrik Polaris consists of 3 primary steps.

STEP DETAIL

Authorize Authorize Rubrik Polaris to access the Azure Subscription(s) that require protection via an OAuth
integrated workflow that aligns with Azure security best practices.

Configure Use a single, declarative SLA policy engine to automatically create and expire Azure managed disk
snapshots to suit backup and replication requirements.

Protect Assign SLA policies to the virtual machines and managed disks that require protection. Automatic
protection based on subscription membership, resource group membership, or tag values ensures
workloads are protected when they are provisioned. Recover managed disks or VMs rapidly through
the Polaris UI or API. Polaris acts as a single pane of glass for hybrid and multi-cloud deployments.

KEY FEATURES
The key features of Rubrik’s Cloud-Native Protection for Azure include:

• Unified data management across regions, subscriptions, tenants, private cloud, and public cloud platforms

• Automated global data protection via Polaris SLA Domains

• Rapid recovery for VMs and managed disks within or across regions

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 4

 UNIFIED DATA MANAGEMENT ACROSS SUBSCRIPTIONS AND CLOUD PLATFORMS

Single Point of Management and Automation via Rubrik Polaris – Rubrik’s Polaris SaaS platform is a single point of
management and automation for hybrid and multi-cloud environments. It requires no persistently running VMs or compute
in the customer’s Azure environment. Polaris provides customers with a simple, homogenous data management experience
across platforms that reduces the drag associated with legacy tooling and point solutions.

Consolidated Reporting – Easily track SLA Domain assignment, protection and recovery activity, and SLA policy compliance
across subscriptions, tenants, platforms, and clouds from a single, easy to use reporting engine.

AUTOMATED GLOBAL DATA PROTECTION VIA POLARIS SLA DOMAINS

SLA Domains – In the data protection world, Service Level Agreements (SLAs) define protection levels for workloads,
availability targets, and objectives that are crucial to a company. Collecting this information, implementing it, and staying
compliant with the SLA is usually a tedious and difficult process. Rubrik uses global SLA Domains, a declarative, policy-driven
framework, to make achieving your SLAs easier. When using an SLA Domain for Cloud-Native Protection for Azure, it is
comprised of three components:

• Snapshot Frequency

• Snapshot Retention

• Replica Region and Duration

Global Protection – Polaris SLA Domains can be assigned across object types even if those objects are spread across
clouds, subscriptions, or on-premises. This allows one set of policies to be used to manage data wherever it may be in the
environment.

Subscription and Resource Group Level Auto-Protection – Assign SLA Domains to entire Azure subscriptions or resource
groups and ensure that every VM provisioned to the protected regions receives the required level of data protection without
the need for explicit SLA assignment. Subscription and resource group level SLA Domain assignments can be overridden using
tag-based assignment or by directly assigning SLA Domains to VMs.

Tag-Based Auto-Protection – Allows for the assignment of SLA Domains to VMs or managed disks whenever a specific
tag key or key value pair is found on any VM or managed disk in any Azure subscription in scope. These tag rules allow
customers to leverage existing provisioning and governance logic to apply the appropriate SLA Domains across Azure tenants,
subscriptions, and regions without the need for manual intervention.

Application Consistent Backups – Customers can enable app consistent Azure VM snapshots via VSS or by leveraging pre/
post-snapshot scripts via a lightweight Rubrik service embedded in the VM. This service uses Rubrik’s Exocompute engine
built on top of Azure Kubernetes Service (AKS) to facilitate communication back to Polaris. This ephemeral compute engine
runs only when app consistent snapshots are being created in order to maintain cost efficiency.

SLA Driven Cross-Region Snapshot Replication – Allows a customer to define a target region and desired retention in an
SLA Domain. Polaris will replicate any snapshots created by that SLA Domain to the target region and expire them after the
specified retention period has elapsed.

RAPID RECOVERY FOR VMS, DISKS, AND FILES WITHIN OR ACROSS REGIONS

Azure Managed Disk Export – Create a new managed disk from the selected managed disk snapshot using either the original
snapshot in the source region or a replica in another region. This workflow allows the user to define the disk type, size, resource
group, region, and subscription. Tags that were on the source disk at the time of the snapshot can also be included or excluded
from the export process.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 5

 Azure Virtual Machine Restore – Select a point in time and automatically roll an Azure VM back to a known good point in time,
preserving its resourceId and private IP address. This operation ensures that disks are restored in a crash-consistent manner
to the desired point in time, attached to the right mount points, and with the original tags, if desired.

Azure Virtual Machine Export – Create a new Azure VM from the selected snapshot using either the original snapshot in the
source region or a replica in another region. This workflow allows the user to define the VM name, type, size, subscription,
resource group, region, VNet, subnet, and network security group. Tags that were on the source VM at the time of the snapshot
can also be included or excluded from the export process.

ARCHITECTURE AND COMPONENTS

HIGH LEVEL ARCHITECTURE

Cloud-Native Protection for Azure allows customers to take advantage of the power of Rubrik’s SLA policy engine via the
Polaris SaaS platform to protect workloads inside of their Azure subscriptions. This allows customers to experience the
power of Rubrik without the need to deploy, manage, or patch any long running compute instances in the customer’s Azure
environment, nor on-premises. In order to accomplish this, Polaris leverages the native snapshot and image creation APIs
provided by Azure to backup and recover Azure VMs and managed disks.

Figure 2 - High Level Architecture: Cloud-Native Protection for Azure

At a high level, the following workflow is used when protecting Azure Compute resources in a protected Azure subscription
using Rubrik Polaris.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 6

 1. Polaris authenticates into the customer’s Azure tenant using a service principal. This service principal is created by
Polaris when the customer enables Cloud-Native Protection for their Azure subscription(s). The role assigned to this
service principal grants it the necessary permissions to protect and restore VMs and managed disks in the customer’s
subscription(s). The credentials for the corresponding application object are stored in an encrypted format within a
customer specific database in Polaris.

2. If app-consistency is required, Rubrik’s Exocompute engine leverages Azure Kubernetes Service to communicate with
Rubrik’s in-VM service and quiesce applications as required.

3. Polaris calls the Azure compute and storage API endpoints in the customer’s Azure tenant(s) to create managed
disk snapshots in accordance with the frequency and retention defined in the SLA Domain policies assigned to the
customers VMs and managed disks in Polaris.

4. If app-consistency is required, Rubrik’s Exocompute engine leverages Azure Kubernetes Service to communicate with
Rubrik’s in-VM service and resume applications as required. If no additional work remains, Exocompute is terminated.

5. If replication is configured in the SLA Domain, the managed disk snapshots are copied to a storage account in the
remote Azure region defined as a replication target in the corresponding SLA Domain. They remain in the remote region
until the replication duration has elapsed, at which point they are expired.

6. Snapshot metadata is securely stored in Polaris.

COMPONENTS
The solution depicted in Figure 2 consists of many Azure and Rubrik components. Let’s discuss each in more detail as well
as describe its role within Cloud-Native Protection for Azure prior to delving deeper into the architectures and associated
workflows.

Cloud-Native Protection for Azure is configured and managed via Rubrik’s Polaris SaaS platform. When protecting Azure
assets, Polaris uses an app registration, a service principal, and a custom role to access the appropriate Azure subscription(s)
being protected within the customer’s Azure Active Directory (Azure AD) tenant. The service principal is assigned a role on
the protected subscriptions which grants Polaris the permissions required to protect Azure VMs and managed disks in the
customer’s environment. Polaris leverages the Azure storage and compute APIs to create managed disk snapshots and page
blobs in accordance with the SLA Domain policy applied. These snapshots are created, replicated, and expired automatically
by Polaris. Only metadata is sent to Polaris; the snapshots and storage accounts that contain customer data reside solely in the
customer owned Azure subscription(s).

HOW CLOUD-NATIVE PROTECTION FOR AZURE WORKS

As stated previously in this document, protecting Azure workloads with Rubrik Polaris consists of 3 primary steps:
Authorize, Configure, and Protect. This section of the document dives deeper into each of these steps both operationally
and architecturally. The reader should gain a basic familiarity of how Cloud-Native Protection for Azure on Rubrik Polaris is
architected, configured, and utilized.

AUTHORIZE

Authorizing Polaris to protect workloads in Azure is a very simple process. The customer clicks the Add Cloud Account button
in the Cloud Accounts section of Remote Settings in Polaris. The customer selects Azure, then VM Protection, and enters
the Azure AD Domain for the subscription(s) requiring protection. A wizard then walks the customer through selecting the
subscription(s) in scope for protection. The customer logs into their Azure Tenant with a user that has the ability to read,
create, and update app registrations, roles, and role assignments. Once authenticated, the customer selects the subscription(s)
and region(s) in scope for protection and clicks Submit. This action adds the selected subscription(s) to Cloud-Native
Protection for Azure in Polaris. Let’s explore how this workflow operates under the covers.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 7

 Figure 3 - Polaris Subscription Addition Workflow

In order to protect workloads running in Azure, Rubrik Polaris needs a means by which to interact with the customer’s Azure
subscription(s). Polaris leverages the native snapshotting and storage capabilities of Azure in order to backup, replicate, and
restore the assets it is protecting. These capabilities are available via the Azure Storage and Azure Compute APIs. Access
to these APIs is controlled by Azure AD. Azure AD itself is quite powerful and supports a variety of identities such as users,
groups, federated users and groups, as well as service principals. Permissions are delegated to or revoked from these identities
via roles, which define what actions a specific identity can and cannot take. The scope at which the role is assigned determines
which resources the identity can access. Common scopes for role assignment include subscriptions, and resource groups.
Rubrik Polaris leverages a service principal and a custom role assigned to the subscription(s) the customer chooses to protect
with Cloud-Native Protection in Azure. These objects and trusts are created when the customer’s subscription(s) are added to
Polaris and are assigned only the permissions necessary to protect the customer’s VMs and managed disks. The permissions
context of the user enabling protection is only used when initially adding subscriptions to Polaris. During this process, a global
admin is required to create the required service principals in the customer’s Azure AD tenant. All subsequent operations
(backup, restore, etc.) utilize the enterprise app registration and custom roles created therein.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 8

 The figure below depicts how the workflow interacts with a customer’s Azure subscription(s) from an Azure AD perspective.

Figure 4 - Polaris App Registration Workflow

There are two representations of applications in Azure AD: application objects, also known as app registrations, and service
principals, also referred to as enterprise app registrations. Application objects describe an application to Azure AD and can be
considered the definition of the application, allowing Azure to know how to issue tokens to the application based on the app
registration’s settings. This application object only exists in its home directory, even if it’s a multi-tenant application supporting
service principals in other directories. Service principals are what govern an application connecting to Azure AD and can
be considered the instance of the application in the customer’s directory. For any given application, it can have at most one
application object and one or more service principal objects representing instances of the application in every directory in
which it acts.

In the Cloud-Native Protection for Azure architecture depicted in Figure 4, a customer specific application object is created
in Rubrik’s directory. The customer specific application accesses the customer’s subscriptions by utilizing corresponding
service principles in the customer’s directories. These service principals are created when the customer initially adds their
subscriptions to Polaris for protection. The permissions delegated to this service principal are controlled via the custom
roles assigned to the service principal in each subscription. This architecture essentially builds a type of trust between the
customer’s Azure AD tenant(s) and Rubrik’s, allowing Polaris to interact with the Azure storage and compute APIs once it
authenticates into Rubrik’s tenant. A major benefit of this approach is that it does not require the customer to share long lived
Azure credentials with Rubrik when enabling Cloud-Native Protection for Azure.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 9

 Once this process is complete Polaris knows the necessary permissions are in place and has all the information needed to begin
protecting the Azure subscription(s). Examples of the custom roles created during this process are available for reference
on GitHub.

Another benefit of this method is that if these permissions need to be modified in the future, Polaris can prompt the user to
walk through updating the role via OAuth. The user simply initiates the workflow in Polaris, logs in, and authorizes the role
changes when prompted.

There are also alternative methods available to add subscriptions and tenants into Cloud-Native Protection for Azure. If one of
these approaches is necessary in your environment, please reach out to Rubrik support for enablement. These include:

• Addition of a subscription without leveraging OAuth and a cross-tenant app registration

• Manually entering the subscription details when adding a subscription

• Programatically creating and adding subscriptions to Cloud-Native Protection for Azure

CONFIGURE

SLA DOMAINS AND CLOUD-NATIVE PROTECTION FOR AZURE

Once an Azure subscription is added to Polaris, the next step is to create one or more SLA Domains in order to begin
protecting workloads in Azure. These SLA Domains can then be applied to Azure VMs and managed disks, at which time
Polaris will begin creating, replicating, and expiring managed disk snapshots to protect the relevant workloads in accordance
with the parameters defined in the assigned SLA Domain. SLA Domains are a powerful replacement to the job scheduling
approach used by many traditional data protection solutions largely due to their declarative nature which generally maps very
nicely to the RPOs and RTOs required by businesses.

Building an SLA Domain for use with Cloud-Native Protection for Azure is a straightforward and simple process that is outside
of the scope of this document. Please reference the Polaris User Guide for details on SLA Domain creation within Polaris. That
said, there are a few specific elements of SLA Domains relative to Cloud-Native Protection for Azure that will be highlighted.

When creating a SLA domain within Polaris, the customer can select an Azure Region that will be used for the replication of
any images and snapshots created via Cloud-Native Protection for Azure for this SLA Domain as well as the Retention for the
replicas in that region.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 10

 Figure 5 - SLA Domain with Azure Cross-Region Replication

At this point in time the Archiving portion of an SLA Domain does not apply to Cloud-Native Protection for Azure. The
customer can leave this parameter unconfigured in SLA Domains that will be utilized exclusively for protecting Azure
workloads. If the customer configures a parameter not applicable to Cloud-Native Protection for Azure, a warning will be
displayed when assigning that SLA Domain policy to incompatible assets.

PROTECT

SUBSCRIPTION LEVEL SLA ASSIGNMENT

Once the required Azure subscription(s) has been added to Polaris and the desired SLA Domains have been created, it’s
time to begin protecting workloads in Azure. Cloud-Native Protection for Azure has a few different options with regards to
assigning SLA Domains to Azure workloads and each of them provides a unique business benefit when employed properly.

Upon navigating to the Inventory screen in Polaris and selecting Azure, users are presented with an inventory of all Azure
VMs that Polaris is currently capable of protecting. Selecting the Subscriptions tab will present a view with a list of all Azure
subscriptions added to Polaris and some relevant information on each subscription.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 11

 Figure 6 - Cloud-Native Protection for Azure Inventory

From this view the customer can select one or more subscriptions using the corresponding checkboxes and use the Manage
Protection button to modify the SLA Domain assigned to that subscription. SLA Domains assigned at the subscription level
will automatically inherit down to all Azure VMs in all protected regions unless another SLA Domain is assigned via a tag rule
or directly to a VM itself. This is a useful technique to automatically protect all VMs provisioned into an Azure subscription with
the desired SLA Domain. As an example, one might assign a fairly lightweight SLA Domain to a developer subscription so that
all assets in that subscription are recoverable regardless of how they were provisioned.

SLA Domains with a yellow exclamation point over them in the SLA Domain selection window have some configuration that
is incompatible with Cloud-Native Protection for Azure for the subscription(s) that have been selected. Examples include an
archival configuration within the SLA Domain or replication configured to a non-Azure target. Hover over the warning icon to
receive a description of the warning.

Figure 7 - Cloud-Native SLA Assignment Warning

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 12

 In addition to assigning an SLA Domain to the subscription, this dialogue box also allows the customer to select Clear Existing
Assignment or Do Not Protect. Both of these configurations produce a similar result when utilized at the Azure subscription
level. The selected subscriptions and VMs within them would be unprotected unless an SLA Domain was assigned to them
using another means.

TAG RULES
Tag Rules are a powerful construct that allow Cloud-Native Protection for Azure to leverage existing business logic and
provisioning workflows to assign SLA Domains to the appropriate resources. This is accomplished by mapping an SLA Domain
to an Azure Tag or to an Azure Tag / Value Pair. These rules can be scoped across any number of Azure regions, subscriptions,
and tenants and are applied to either Azure VMs or managed disks. This is an extremely simple, powerful, and lightweight
mechanism for protecting Azure VMs and managed disks in large multi-subscription Azure environments.

When creating a tag rule, selecting (All tag values) in the value field will cause the rule to match either all VMs or managed
disks (depending on the previous selection) with the specified Tag Key regardless of the value. Similarly, selecting (No tag
value) will cause the rule to apply only when a matching Tag Key is found without a Tag Value.

Tag rules also require that the customer selects the SLA Domain to assign when the tag rule has a match. This SLA Domain
will be assigned to all matching objects, unless they have a specific SLA Domain assigned directly to them. Additionally, Polaris
will periodically poll the customer’s Azure subscription(s) and update the assigned SLA Domains in accordance with these
tag rules. This includes updated tag keys or values, newly provisioned Azure VMs or managed disks that match the rule, or
modifications to the tag rule itself.

Lastly, leveraging Do Not Protect within a tag rule can oftentimes be useful for excluding specific workloads from subscription
level Auto-Protection. For example, a tag rule matching rk_instance_class:TransientStormInstance with a Do Not Protect SLA
Domain selection will prevent Cloud-Native Protection for Azure from snapshotting the Storm instances that Rubrik uses for
jobs like CloudOn.

Since Azure resources can have multiple tags, Polaris may apply multiple tag rules to the same VM or managed disk. If the
tag rules specify different SLA Domains, Polaris selects one of them based upon the following order of precedence, highest
to lowest:

• Do Not Protect

• The SLA Domain with the most frequent snapshots

• The SLA Domain with the longest retention

DIRECT SLA DOMAIN ASSIGNMENT

Users can also directly assign SLA Domains to Azure VMs and managed disks from the Azure Inventory screen within Polaris.
The View dropdown can be used to flip between the Azure VM and managed disk inventory. The filter options on the left-hand
side of this view are particularly useful for tailoring the view to the desired resources, as is the VM search box at the top right of
the view. In order to determine the current SLA Domain assigned to an VM or disk, simply reference the SLA Domain column in
this view. The source of that SLA Domain can be viewed in the Assignment column of the same view.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 13

 Figure 8 - Direct SLA Assignment

Ticking the checkboxes next to the desired VMs or managed disks and clicking Manage Protection will bring up the SLA
Domain assignment dialogue box. This can also be accomplished by drilling down into an individual VM or managed disk and
clicking the same button. This view provides the option to select an existing SLA Domain as well as Clear existing assignment,
which will remove any existing SLAs directly assigned to the object, and Do Not Protect, which forces Polaris to stop
protecting the object.

The main difference between these two options is the fact that Clear existing assignment will allow SLA Domains assigned
at the subscription level or via tag rules to inherit down to the selected object. Do Not Protect, on the other hand, will force
Rubrik not to protect the object regardless of any subscription level assignments or tag rules that might be in play. In general,
direct SLA Domain assignment tends to be a last resort for overriding the SLA Domains inherited from subscription level SLA
Domain assignment or tag rules, as opposed to the primary means of assigning SLA Domains to Azure VMs or managed disks.

DISK EXCLUSION
Cloud-Native Protection for Azure on Polaris supports excluding disks from protection when Azure VM level backups are
performed. This can be a useful approach in cases such as database servers, where the application may be backed up
independent of the VM. In such cases, snapshotting the data disks on these VMs would offer little benefit and would result in
increased data protection costs.

To exclude specific disks attached to a VM from protection, the customer searches or navigates to the view for that VM, then
clicks the ellipsis next to the Take On Demand Snapshot button. In the context menu that appears, the customer selects
Exclude Disks. In the dialogue box that appears disks can be excluded and included in snapshots as needed. The boot disk of
an VM cannot be excluded.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 14

 Figure 9 - Disk Exclusion

ON DEMAND SNAPSHOTS
On Demand snapshots are snapshots that are manually created and differ from SLA Domain created snapshots in a few
significant ways. An On Demand snapshot is created when a user clicks the Take On Demand Snapshot button on the view
for an Azure VM or managed disk. An On Demand snapshot is not associated with an SLA, and thus, will be retained until it is
deleted. Because of this, customers have the capability to delete On Demand snapshots via the Polaris console by navigating
to the On Demand snapshot and selecting Delete from the menu that appears when clicking the ellipsis next to the time of
the corresponding snapshot. Only snapshots with a type of On Demand can be deleted by users. On Demand snapshots are
a useful tool when employed prior to making any change inside of a VM that cannot be easily recreated through other means.
Simply take an On Demand snapshot, perform the required task, and then delete the On Demand snapshot after confirming
the change is non-breaking. On Demand snapshots can also be used in conjunction with scripting to pause applications prior
to snapshotting a VM.

Figure 10 - On Demand Snapshot

APP CONSISTENCY
Cloud-Native Protection for Azure on Polaris allows customers to configure app consistency for the Azure snapshots it creates
when protecting Azure VMs. In depth detail on this process is available in the How It Works section on app consistent backups.
App consistency is achieved through a lightweight service that is installed inside of any Virtual Machines requiring app
consistent VM snapshots and leverages the Polaris Exocompute engine built on top of Azure Kubernetes Service to coordinate
communication between Polaris and these workloads. Exocompute must be configured for all subscriptions and regions where
app consistency is required. This is done in the Exocompute Settings tab of the Remote Settings console. The customer can
click Create Exocompute Setting and select the appropriate Azure tenant. Polaris will prompt the customer to authenticate
and will automatically update the permissions assigned to Polaris’ Service Principal if necessary.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 15

 Once permissions are in place, the customer is prompted to select regions within the protected subscription(s) that are in
scope for app-consistency. Only regions that support AKS will be displayed in this view. For each region that is in scope, the
customer will specify a VNet and subnets for AKS to run in. This subnet must have internet access in order for Exocompute to
communicate with Polaris and certain container registries. This subnet also must allow Exocompute to communicate with each
of the VMs it facilitates app consistency for on TCP 12800 and 12801.

Figure 11 - Excompute Configuration

Once exocompute is configured for the required subscriptions and regions, customers can configure app consistency on the
desired VMs. First, The customer downloads and installs the Rubrik Backup Service (RBS) on each of the desired VMs. Next,
the RBS services in these VMs are registered with Polaris. Then, the customer configures App Consistency (VSS) and/or pre/
post-scripts as required in either shell script or batch.

Figure 12 - Configuring App Consistency

When registering RBS with Polaris, an Exocompute cluster is provisioned to verify connectivity between RBS, Exocompute,
and Polaris.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 16

 Figure 13 - RBS Connectivity Check

Once RBS is successfully registered, the customer can enable app consistency and specify the desired pre/post-scripts on the
VM as required. Subsequent snapshots will provide app consistency as defined.

HOW IT WORKS

BACKUP
Once subscriptions are added and SLA Domains are assigned, Polaris will begin protecting workloads in Azure. The Polaris
job framework will begin automatically scheduling and snapshotting disks and VMs in accordance with the SLA Domains
that have been created and assigned without needing to schedule any jobs. Polaris handles batching all snapshot jobs so as
not to overrun the API limits on Azure with one big batch of snapshot or replication activities. By default, Polaris will run a
maximum of 20 snapshot jobs in parallel. Let’s dig into the specifics of snapshotting managed disk, followed by that of Azure
VM snapshots.

MANAGED DISK SNAPSHOTS

When backing up individual managed disks, a Microsoft.Compute/snapshots/write API call is made to the Azure API with the
ResourceId of the source disk and the required tag values as parameters. Polaris will apply some Polaris specific tags to the
newly created snapshots. Azure Storage Service Encryption is enabled by default for all managed disk snapshots. Managed
disk snapshots are incremental, crash-consistent, and are stored on Zone Redundant Storage (ZRS) where supported. In
regions where ZRS storage is unavailable, Locally Redundant Storage (LRS) is used instead.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 17

 Figure 14 - managed disk snapshot

These snapshots are stored in a Rubrik created resource group named RubrikBackups-RG-DontDelete. Polaris also locks
these snapshots inside of the customer’s Azure environment so that they cannot be deleted accidentally. An example of one of
these locks is depicted in Figure 12.

Figure 15 - Azure Managed Disk Snapshot Lock

AZURE VM SNAPSHOTS

Polaris Azure VM Snapshots are stored as managed disk snapshots inside of Azure. Polaris uses the Microsoft.Compute/
snapshots/write API to create snapshots of all non-excluded managed disks. When using this method, the managed disk
snapshots created will be individually crash-consistent. In other words, there is no guarantee that each disk’s snapshot will
be crash-consistent to the exact same point in time as the snapshots of the other disks attached to the source VM when the
image was created. Let’s take a look at the specifics of this approach.

When creating a snapshot, a Microsoft.Compute/snapshots/write API call is made to the Azure API with the ResourceId of
the source disk(s) and the required tag values as parameters. Polaris will apply some Polaris specific tags to the newly created
snapshots. Azure Storage Service Encryption is enabled by default for all managed disk snapshots. Managed disk snapshots
are incremental, crash-consistent, and are stored on ZRS where supported. In regions where ZRS storage is unavailable, LRS is
used instead.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 18

 Figure 16 - Azure VM Snapshot

These snapshots are stored in a Rubrik created resource group named RubrikBackups-RG-DontDelete. Polaris also locks
these snapshots inside of the customer’s Azure environment so that they cannot be deleted accidentally. An example of one of
these locks is depicted in Figure 15.

APP CONSISTENCY

Snapshots created on VMs with RBS installed, app consistency enabled and configured will leverage Exocompute worker(s) to
facilitate the creation of app consistent snapshots. During this process, Polaris communicates with Rubrik’s in-VM service and
quiesce applications as required prior to beginning the VM snapshot. Rubrik does this by first invoking the pre-script and then
triggers the VSS Quiesce. Once ready, the snapshot is created. Next Rubrik resumes normal application activity by triggering
VSS Thaw and then the Post-script.

Note: In case of retries, the Post-script might be executed multiple times. So, the post-script needs to be idempotent

Figure 17 - App Consistent Snapshot

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 19

 RESTORE
In order to restore a VM protected by Cloud-Native Protection for Azure the customer simply navigates to the VM they want to
restore, selects the appropriate snapshot, and then chooses Restore from the context menu for that snapshot. This operation
essentially rolls the currently running VM back to the point in time of the selected snapshot while allowing the restored VM to
retain its resource id and private IP address. This is accomplished by stopping the running VM and replacing the disks on the
VM with disks created from the snapshot being restored. This restore process is intelligent and will account for replication, disk
exclusion, and tag recovery.

If the snapshot being restored was replicated to a remote region and the snapshots within the local region are unavailable,
Polaris will copy the necessary snapshots from the remote region to the source region in order to utilize them for the restore.

Once Polaris has identified that the required snapshots and image are available it will launch the required managed disks from
their corresponding managed disk snapshots in preparation for the rollback. Disks that were excluded from protection have no
corresponding snapshots and thus will not be recreated.

Once the disks required for the restore are available, Polaris shuts down the VM being restored. Polaris then detaches all
managed disks from the existing VM as soon as it reaches a stopped state. Once the detached disks show as available they
are tagged with Rubrik metadata. The detached disks are not deleted automatically. Once the restore is complete and the
customer has validated the results, the customer typically deletes the detached disks. However, if customer requirements
dictate retaining them for some period of time, the recommended approach would be to snapshot the disk and retain that
rather than the disk itself. This significantly reduces the cost of storing the data.

At this stage of the process Polaris attaches the previously created disk(s) to the original Logical Unit Number(s) (LUNs) on the
VM being restored. Once the newly attached disks are in the attached state, the restore process starts the VM and waits until
it is in the running state. Polaris then tags the restored VM and disks with the appropriate tags. If the customer has chosen to
restore tags, this includes the tags that were on the VM at the time of the snapshot being restored.

Figure 18 - Azure VM Restore

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 20

 EXPORT
When running an export of an Azure VM or managed disk via Cloud-Native Protection for Azure on Polaris the customer
creates a new VM or managed disk from the snapshot being exported. This process is initiated by choosing Export in the
context menu for the snapshot the customer wants to export.

In the dialogue box that appears the customer is able to specify the export parameters for the object being exported. Both
Azure VMs and managed disks can be exported from either the local snapshot or a Rubrik snapshot replica in a remote region
(if one exists) and can be exported to any region supported by Polaris. Cross-region exports are a useful tool for test/dev and
disaster recovery scenarios. Both object types allow the customer to define the name of the exported object, subscription,
resource group, region, availability zone, as well as whether or not the tags at the time of the snapshot should be applied to the
export. The following sections explore each operation in more detail.

MANAGED DISK EXPORTS

Managed disk exports allow the customer to create a new managed disk from a snapshot of their choosing. In addition to the
parameters above, customers can also specify the disk type (standard, premium, ssd, ultra ssd, etc.), the disk size, and whether
or not the new disk should replace the existing source disk.

Polaris copies any required managed disk snapshot(s) from a remote region if the snapshot(s) required for the export are not
currently available in the target export region. This can happen in a few scenarios:

• An export of source region snapshot to a remote region

• An export of a replica region snapshot to any region other than the replica region

• An export of a missing source region snapshot to any region other than the replica region

• An export of a missing replica region snapshot to any region other than the source region

During this phase, the required snapshot is copied to the export target region. Once the required disk snapshot is available in
the specified region Polaris will launch a new managed disk from the corresponding snapshot and tag it with the appropriate
tags. If export tags was selected, the tags from the original disk will be included as well.

At this stage of the process, if the customer has selected the option to Replace the existing disk where attached, Polaris stops
the VM where the source disk is attached and polls it until it is in a stopped state. After which, the original source disk for the
snapshot being exported will be detached (but not deleted) from its VM and the newly exported disk will be attached in its
place. Lastly, Polaris restarts the VM and polls for it to be in a running state and tags the detached disk.

Upon completion the exported disk is now available in the desired region. If Replace the existing disk where attached option
was selected the newly exported disk will be attached in place of the existing source disk and the existing source disk will
be detached and ready for use or deletion. The diagram below depicts this process when exporting a disk and replacing an
existing data disk attachment.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 21

 Figure 19 - Managed disk export with replace attachment

AZURE VM EXPORTS

Azure VM exports allow the customer to create a new Azure VM from a selected snapshot. In addition to the previously
mentioned parameters, customers can also specify the VM size, type, vnet, subnet, and network security group to apply to
the new VM.

As with managed disk exports, Azure VM exports will only copy snapshots from a remote region if the snapshots being used
for the export are not currently in the target region for the export. This can happen in a few scenarios:

• An export of source region snapshot to a remote region

• An export of a replica region snapshot to any region other than the replica region

• An export of a missing source region snapshot or image to any region other than the replica region

• An export of a missing replica region snapshot or image to any region other than the source region

If necessary, the required snapshots are copied to the export target region. Once the required assets are available in the export
region, Polaris will create the required disk(s) from the corresponding snapshot(s). Once complete, Polaris will create a NIC
in the specified export subnet. Lastly, a new VM is created using the disk(s) and NIC created during the previous phases. If
the customer selected export tags when exporting the VM, the tags from the source VM at time of snapshot are copied to
the exported VM. The Rubrik specific tags are always applied regardless of selection. The new VM is polled until it shows
as running.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 22

 Figure 20 - Azure VM Export

REPLICATION
When replicating snapshots across regions, Cloud-Native Protection for Azure utilizes the Get Page Ranges and Put Pages
from URL APIs to incrementally copy snapshot data across Azure regions while minimizing cost. Disk snapshots in the target
region are stored on LRS storage within General Purpose v1 (GPv1) storage accounts as snapshots of page blobs. Each
page blob corresponds to a managed disk in the source region and each page blob snapshot corresponds to a managed
disk snapshot in the source region. This approach provides multi region availability for workloads protected by Cloud-
Native Protection for Azure while minimizing data storage costs. Replication runs every 30 minutes and consists of the
following process.

First, Polaris retrieves SAS Uniform Resource Identifiers (URIs) for the managed disk(s) in scope for replication. These URIs
can be utilized to read pages directly from the source managed disk snapshot(s) for a period of time. Polaris then uses the Get
Page Ranges API to get a list of page ranges that have changed or cleared since the last snapshot. This approach yields a result
for Azure managed disks that is similar to that of VMware’s Change Block Tracking (CBT) capability.

This list of changed pages is then used in conjunction with the Put Page from URL API to copy the changed pages from the
source managed disk snapshot to the target page blob in the replica region. Once the copy is complete, Polaris creates a
snapshot of the page blob. This snapshot is identical to the snapshot of the managed disk in the source region and can be used
to restore or export the source managed disk as required.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 23

 Figure 21 - Azure Snapshot Cross-Region Replication

SUMMARY
This concludes the How it Works: Cloud-Native Protection for Azure on Rubrik Polaris. The guide explained the architecture
and the value proposition of Cloud-Native Protection for Azure as well as educated the reader on the nuances of each major
workflow within the product. Additionally, the guide equipped the reader with some common techniques and best practices
for using the product efficiently from both an operations and cost perspective allowing them to fully understand and unlock
the potential of Cloud-Native Protection for Azure.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 24

 GLOSSARY
APP REGISTRATION
App Registrations are also known as application objects, these describe an application to Azure AD and can be considered
the definition of the application, allowing Azure AD to know how to issue tokens to the application based on its settings. The
application object will only exist in its home directory, even if it’s a multi-tenant application supporting service principals in
other directories.

AZURE BLOB
Azure Storage offers three types of blob storage: Block Blobs, Append Blobs and page blobs. Block blobs are composed of
blocks and are ideal for storing text or binary files, and for uploading large files efficiently. Append blobs are also made up of
blocks, but they are optimized for append operations, making them ideal for logging scenarios. Page blobs are made up of 512-
byte pages up to 8 TB in total size and are designed for frequent random read/write operations. Page blobs are the foundation
of Azure IaaS Disks.

AZURE KUBERNETES SERVICE (AKS)

Azurec Kubernetes Service is a managed service that makes it easy for Azure customers to run Kubernetes on Azure without
needing to stand up or maintain their own Kubernetes control plane. Rubrik’s Exocompute engine uses AKS whenever local
compute is required in the customer’s Azure environment to perform a task. In terms of Cloud-Native Protection for Azure,
Exocompute is utilized to facilitate the creation of app consistent VM snapshots.

AZURE ROLE (ROLE DEFINITION)

A role definition is a collection of permissions. It’s typically just called a role. A role definition lists the operations that can be
performed, such as read, write, and delete. Roles can be high-level, like owner, or specific, like virtual machine reader.

AZURE SUBSCRIPTION
An Azure Subscription is a logical container for the resources a customer provisions in Azure. Each Azure resource is associated
with only one subscription, although they can be further organized into resource groups within a subscription. Creating a
subscription is the first step in adopting Azure. Subscriptions can be used as a permissions boundary within Azure by assigning
a role to a service principal (such as a user or a group) on the subscription. This grants the selected principal the permissions
described in the role across all resources in the subscription.

AZURE TENANT
A dedicated and trusted instance of Azure AD. An Azure AD tenant is automatically created when a customer’s organization
first signs up for a Microsoft cloud service subscription like Microsoft Azure, Microsoft Intune, or Office 365. An Azure tenant
represents a single organization and can contain one or more Azure subscriptions.

AZURE VIRTUAL MACHINE (VM)

An Azure VM is essentially a virtual server running in Azure. The VM size and type dictate the CPU, RAM, and other
performance characteristics of the VM. VMs run in a subnet within virtual networks known as VNet. Azure VMs use block
storage devices called managed disks.

CUSTOMER AZURE TENANT

The customer owned Azure tenant houses subscriptions and the resources protected by Cloud-Native Protection for Azure.
Polaris uses an app registration in a Rubrik owned Azure tenant that is trusted by the customer’s Azure tenant in order to make
the API calls necessary to protect VMs and managed disks. The snapshots created by this process continue to reside in the
customer owned Azure subscription, only metadata is stored in Polaris.

ENTERPRISE APP REGISTRATION / SERVICE PRINCIPAL

An Enterprise App Registration is a service principal within a customer’s Azure AD tenant used to govern how Polaris
connects to Azure AD in the customer’s environment. This service principal can be considered the instance of the Polaris in the
customer’s directory. It’s permissions are dictated by role assignments at the subscription level.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 25

 EXOCOMPUTE
Exocompute extends Polaris to support a “bring-your-own-compute” approach to protecting Azure VMs and managed disks.
Exocompute is a framework for running containers in the customer’s environment with a bidirectional communication path
between the containers and Polaris. This framework abstracts away the underlying cloud’s container service and allows Cloud-
Native Protection to support and workloads across cloud platforms.

LOCALLY REDUNDANT STORAGE (LRS)

Azure Storage always stores multiple copies of customer data so that it is protected from planned and unplanned events,
including transient hardware failures, network or power outages, and massive natural disasters. Redundancy ensures that a
customer’s storage account meets the Service-Level Agreement (SLA) for Azure Storage even in the face of failures. Locally
redundant storage (LRS) replicates customer data three times within a single physical location in the primary region. LRS
provides at least 99.999999999% (11 nines) durability of objects over a given year.

LOGICAL UNIT NUMBER (LUN)

A logical unit number (LUN) is a unique identifier for designating an individual or collection of physical or virtual storage
devices that execute input/output (I/O) commands with a host computer. This value is used in Azure to identify the data disks
connected to a VM and therefore must be unique for each data disk attached to a VM.

MANAGED DISK
Azure managed disks are block-level storage volumes that are managed by Azure and used with Azure Virtual Machines.
Managed disks are like a physical disk in an on-premises server but virtualized. With managed disks, all customers have to do
is specify the disk size, the disk type, and provision the disk. Once a customer provisions the disk, Azure handles the rest. The
available types of disks are ultra disks, premium solid-state drives (SSD), standard SSDs, and standard hard disk drives (HDD).

MANAGED DISK SNAPSHOT

A managed disk snapshot is a read-only crash-consistent full copy of a managed disk that is stored as a standard managed
disk by default. With snapshots, customers can back up their managed disks at any point in time. These snapshots exist
independent of the source disk and can be used to create new managed disks. These snapshots are incremental in nature and
are billed based on the used size. For example, if a customer creates a snapshot of a managed disk with a provisioned capacity
of 64 GiB and actual used data size of 10 GiB, that snapshot is billed only for the used data size of 10 GiB.

MICROSOFT AZURE
Azure is a cloud computing service created by Microsoft for building, testing, deploying, and managing applications and
services through Microsoft-managed data centers. It provides software as a service (SaaS), platform as a service (PaaS) and
infrastructure as a service (IaaS) and supports many different programming languages, tools, and frameworks, including both
Microsoft-specific and third-party software and systems.

RESOURCE GROUP
A container that holds related resources for an Azure solution. The resource group includes those resources that you want to
manage as a group. You decide which resources belong in a resource group based on what makes the most sense for your
organization.

RESOURCE ID
This is the fully qualified ID of a resource in Azure. It includes the resource name, type, and location in the format /
subscriptions/{guid}/resourceGroups/{resource-group-name}/{resource-provider-namespace}/{resource-type}/
{resource-name}

RUBRIK AZURE TENANT

A tenant represents an organization in Azure Active Directory. It’s a dedicated Azure AD service instance that an organization
receives and owns when it signs up for a Microsoft cloud service such as Azure, Microsoft Intune, or Office 365. Each Azure AD
tenant is distinct and separate from other Azure AD tenants.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 26

 RUBRIK POLARIS
Polaris is Rubrik’s SaaS platform which aggregates metadata related to data protection activities across hybrid and multi-
cloud environments. The end result is a robust framework consisting of metadata from several data sources, often referred to
as a unified system of record. Rubrik Polaris enables customers to exploit the business value hidden in this dataset leveraging
AI and ML driven tools within Polaris.

Full details on the capabilities of Polaris are outside the scope of this document but they include: centralized management for
Rubrik CDM clusters, ransomware detection and rollback via Polaris Radar, data classification and compliance via Polaris Sonar,
as well as Cloud-Native Protection for public cloud workloads, the topic of this document.

A Polaris tenant is a microservices application built on top of a Kubernetes engine and is comprised of, but limited to the
following services:

• HTML 5 User Interface

• API Services

• User identity and access services

• Distributed task/job schedulers

• Reporting services

• Gateway services for interacting with customer endpoints (CDM Clusters, Public Clouds, etc.)

• Compute engine management services

• Database services

• Logging and Metrics services

Ultimately, none of this detail typically matters to Polaris customers. The application is provisioned and managed by Rubrik
with delivery to the end-user via a web based SaaS portal.

SERVICE LEVEL AGREEMENT (SLA) DOMAIN

Rubrik SLA Domains are data protection policies built within Polaris and then assigned to assets requiring protection. SLA
Domains are comprised of these three components when utilized by Cloud-Native Protection for Azure:

• Snapshot Frequency

• Snapshot Retention

• Replica Region and Duration

SHARED ACCESS SIGNATURE (SAS) URI

A shared access signature (SAS) provides secure delegated access to resources in a storage account without compromising
the security of the data. With a SAS, customers have granular control over how a client can access data. Customers can control
what resources the client may access, what permissions they have on those resources, and how long the SAS is valid, among
other parameters. SAS Uniform Resource Identifiers (URIs) are also known as ad hoc SAS. When a customer creates an ad hoc
SAS, the start time, expiry time, and permissions for the SAS are all specified in the SAS URI.

STORAGE ACCOUNT
An Azure storage account contains all of Azure Storage data objects: blobs, files, queues, tables, and disks. The storage
account provides a unique namespace for Azure Storage data that is accessible from anywhere in the world over HTTP or
HTTPS. Data in Azure storage accounts is durable and highly available, secure, and massively scalable.

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 27

 ZONE REDUNDANT STORAGE (ZRS)
Azure Storage always stores multiple copies of customer data so that it is protected from planned and unplanned events,
including transient hardware failures, network or power outages, and massive natural disasters. Redundancy ensures that a
customer’s storage account meets the Service-Level Agreement (SLA) for Azure Storage even in the face of failures. Zone
redundant storage (ZRS) copies data synchronously across three Azure availability zones in the storage account’s region.

APPENDIX A - AZURE TAGS

INDIVIDUAL MANAGED DISK SNAPSHOT TAGS:

TAG KEY TAG VALUE

rk_snapshot_date Date on which snapshot was taken

rk_source_disk_id Polaris UUID of source managed disk

rk_source_disk_name Resource group name::Azure name of source managed disk

rk_taskchain_id Polaris UUID for source task chain

VM BACKUP MANAGED DISK SNAPSHOT TAGS:

TAG KEY TAG VALUE

rk_snapshot_date Date on which snapshot was taken

rk_source_vm_id Polaris UUID of source VM

rk_source_disk_id Polaris UUID of source managed disk

rk_source_disk_name Resource group name::Azure name of source managed disk

rk_taskchain_id Polaris UUID for source task chain

RESTORE VM, DETACHED DISK TAGS:

TAG KEY TAG VALUE

rk_detached_by azure-native-restore-vm::detach-disks/UUID of the Polaris source snapshot

rk_detached_from Source VM resource group name, Source VM name and LUN

rk_detached_time The UTC time when the disk was detached

RESTORED VM AND MANAGED DISK TAGS:

TAG KEY TAG VALUE

rk_restore_timestamp The UTC time when the restore was initiated (VM only)

rk_source_snapshot_id The UUID of the source snapshot

rk_taskchain_id Polaris UUID for source task chain0

rk_user The Polaris user ID that executed this restore

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 28

 TAG KEY TAG VALUE

rk_source_disk_name Azure name of source managed disk (disk only)

rk_source_vm_name Azure name of the source VM (disk only)

EXPORTED VM AND MANAGED DISK TAGS:

TAG KEY TAG VALUE

rk_export_source_region The region of the source snapshot

rk_source_snapshot_id The UUID of the source snapshot

rk_source_vm_name The Azure name of the source VM for this export

rk_taskchain_id Polaris UUID for source task chain

rk_user The Polaris user ID that executed this export

rk_source_disk_name Azure name of source managed disk (disk only)

EXPORT DISK, DETACHED DISK TAGS:

TAG KEY TAG VALUE

rk_detached_by azure-native-export-disk-snapshot::detach-disk
plus the Resource ID of the snapshot used for the export

rk_detached_from VM resource group name, Azure VM name and LUN from which managed disk was detached

rk_detached_time The UTC time when the disk was detached

EXPORTED DISK TAGS:

TAG KEY TAG VALUE

rk_export_source_region The region of the source snapshot

rk_source_disk_name Azure name of source managed disk

rk_source_snapshot_id The UUID of the source snapshot

rk_taskchain_id Polaris UUID for source task chain

rk_user The Polaris user ID that executed this export

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 29

 APPENDIX B - METADATA
METADATA USE CASE

Tenant ID
Azure Domain Name
OAuth - Creating a custom role to protect
Service Principal ID
Azure subscription(s)
Regions
Subscriptions

Role Definition ID
Role Assignment Name
Role lifecycle management and mappings
Role Display Name
Role Scope

Azure VM Properties (protected subscriptions and regions only):

Name
Size
VNet
Subnet
Create managed disk snapshots per
OS Type
SLA Domain
UUID
Tags
Region
Availability Zone
Azure Disk Encryption (ADE) Enabled/Disabled

Azure Managed Disk Properties (protected subscriptions and regions only):

Name
Size
Storage Tier
Performance
Create managed disk snapshots per
OS Type
SLA Domain
UUID
Tags
Region
Availability Zone
Azure Disk Encryption (ADE) Enabled/Disabled

Resource Group Properties (protected subscriptions and regions only):

Enable SLA Domain assignment at the
Name
resource group level
Region

Snapshot Properties (Polaris managed only):

Name
Delete Lock Name
Tags
Snapshot Tier Snapshot management, restore, export
Snapshot Size
ADE Key Vault ID/URL
ADE KEK Secret URL
ADE KEK Vault ID

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 30

 METADATA USE CASE

Storage Account Properties (Polaris managed only):

Replication Target Storage Account Name(s)
Blob Container Names
Cross-region snapshot replication
Page Blob Names
Timestamps of Page Blob Snapshots
Region

VERSION HISTORY
Version Date Summary of Changes

1.0 May 2020 Initial Release

1.1 Mar 2021 Adds App Consistency

Rubrik, the Multi-Cloud Data Control™ Company, enables enterprises to maximize value from data
Global HQ that is increasingly fragmented across data centers and clouds. Rubrik delivers a single, policy-driven
1001 Page Mill Rd., Building 2 1-844-4RUBRIK platform for data recovery, governance, compliance, and cloud mobility. For more information, visit
Palo Alto, CA 94304 inquiries@rubrik.com www.rubrik.com and follow @rubrikInc on Twitter. © 2021 Rubrik. Rubrik is a registered trademark of
United States www.rubrik.com Rubrik, Inc. Other marks may be trademarks of their respective owners.

20210414_v1

TECHNICAL WHITE PAPER | HOW IT WORKS: CLOUD-NATIVE PROTECTION FOR AZURE 31