Skip to content

Commit e103ef5

Browse files
author
Jill Grant
authored
Merge pull request #262717 from whhender/microsoft-purview-reliability
Initial reliability pass
2 parents 3958d3b + 45cf8c0 commit e103ef5

File tree

3 files changed

+118
-3
lines changed

3 files changed

+118
-3
lines changed

articles/reliability/TOC.yml

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -323,7 +323,9 @@
323323
- name: Microsoft Defender for Cloud DevOps security
324324
href: reliability-defender-devops.md
325325
- name: Microsoft Fabric
326-
href: reliability-fabric.md
326+
href: reliability-fabric.md
327+
- name: Microsoft Purview
328+
href: reliability-microsoft-purview.md
327329
- name: Azure Service Manager retirement
328330
items:
329331
- name: Overview

articles/reliability/reliability-guidance-overview.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -118,8 +118,8 @@ For a more detailed overview of reliability principles in Azure, see [Reliabilit
118118
|Azure Storage Mover|[Reliability in Azure Storage Mover](./reliability-azure-storage-mover.md)|[Reliability in Azure Storage Mover](./reliability-azure-storage-mover.md)|
119119
|Azure VMware Solution|| [Azure VMware disaster recovery for virtual machines](../azure-vmware/disaster-recovery-for-virtual-machines.md?toc=/azure/reliability/toc.json&bc=/azure/reliability/breadcrumb/toc.json) |
120120
|Microsoft Defender for Cloud DevOps security|[Reliability in Microsoft Defender for Cloud DevOps security](./reliability-defender-devops.md)|[Reliability in Microsoft Defender for Cloud DevOps security](./reliability-defender-devops.md)|
121-
|Microsoft Fabric|[Microsoft Fabric](reliability-fabric.md) |[Microsoft Fabric](reliability-fabric.md)
122-
121+
|Microsoft Fabric|[Microsoft Fabric](reliability-fabric.md) |[Microsoft Fabric](reliability-fabric.md)|
122+
|Microsoft Purview|[Reliability for Microsoft Purview](reliability-fabric.md) |[Disaster recovery for Microsoft Purview](/purview/concept-best-practices-migration#implementation-steps)|
123123

124124
## Azure Service Manager Retirement
125125

Lines changed: 113 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,113 @@
1+
---
2+
title: Reliability in Microsoft Purview for governance experiences
3+
description: Find out about reliability in Microsoft Purview for governance experiences
4+
author: whhender
5+
ms.author: whhender
6+
ms.topic: reliability-article
7+
ms.custom: subject-reliability, references_regions
8+
ms.service: purview
9+
ms.date: 01/08/2024
10+
---
11+
12+
# Reliability in Microsoft Purview
13+
14+
This article describes reliability support in Microsoft Purview for governance experiences, and covers both regional resiliency with [availability zones](#availability-zone-support) and [disaster recovery and business continuity](#disaster-recovery-and-business-continuity). For a more detailed overview of reliability principles in Azure, see [Azure reliability](/azure/well-architected/reliability/).
15+
16+
## Availability zone support
17+
18+
[!INCLUDE [next step](includes/reliability-availability-zone-description-include.md)]
19+
20+
Microsoft Purview makes commercially reasonable efforts to support zone-redundant availability zones, where resources automatically replicate across zones, without any need for you to set up or configure.
21+
22+
### Prerequisites
23+
24+
- Microsoft Purview governance experience currently provides partial availablility-zone support in [a limited number of regions](#supported-regions). This partial availability-zone support covers experiences (and/or certain functionalities within an experience).
25+
- Zone availability might or might not be available for Microsoft Purview governance experiences or features/functionalities that are in preview.
26+
27+
### Supported regions
28+
29+
Microsoft Purview makes commercially reasonable efforts to provide availability zone support in various regions as follows:
30+
31+
| Region | Data Map | Scan | Policy | Insights |
32+
| --- | --- | --- | --- | --- |
33+
|Norway East|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg"::: |:::image type="icon" source="media/yes-icon.svg":::|
34+
|East US 2 EUAP||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
35+
|Central US||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
36+
|West Central US|||||
37+
|Southeast Asia||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
38+
|East US||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
39+
|Australia East|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg"::: |:::image type="icon" source="media/yes-icon.svg":::|
40+
|West US 2||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
41+
|Canada Central|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg"::: |:::image type="icon" source="media/yes-icon.svg":::|
42+
|Central India||:::image type="icon" source="media/yes-icon.svg":::|||
43+
|East US 2||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
44+
|France Central||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
45+
|Germany West Central||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
46+
|Japan East||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
47+
|Korea Central||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
48+
|West US 3||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
49+
|North Europe||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
50+
|South Africa North||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
51+
|Sweden Central|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg"::: |:::image type="icon" source="media/yes-icon.svg":::|
52+
|Switzerland North||:::image type="icon" source="media/yes-icon.svg":::|||
53+
|UAE North|||||
54+
|USGov Virginia|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg"::: |:::image type="icon" source="media/yes-icon.svg":::|
55+
|South Central US||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
56+
|Brazil South||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
57+
|UK South|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg"::: |:::image type="icon" source="media/yes-icon.svg":::|
58+
|Canada East|||||
59+
|Qatar Central||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
60+
|China North 3|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg"::: |:::image type="icon" source="media/yes-icon.svg":::|
61+
|West Europe||:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|:::image type="icon" source="media/yes-icon.svg":::|
62+
63+
## Disaster recovery and business continuity
64+
65+
[!INCLUDE [next step](includes/reliability-disaster-recovery-description-include.md)]
66+
67+
There's some key information to consider upfront:
68+
69+
- It isn't advisable to back up "scanned" assets' details. You should only back up the curated data such as mapping of classifications and glossaries on assets. The only case when you need to back up assets' details is when you have custom assets via custom `typeDef`.
70+
71+
- The backed-up asset count should be fewer than 100,000 assets. The main driver is that you have to use the search query API to get the assets, which have limitation of 100,000 assets returned. However, if you're able to segment the search query to get smaller number of assets per API call, it's possible to back up more than 100,000 assets.
72+
73+
- The goal is to perform one time migration. If you wish to continuously "sync" assets between two accounts, there are other steps that won't be covered in detail by this article. You have to use [Microsoft Purview's Event Hubs to subscribe and create entities to another account](/purview/manage-kafka-dotnet). However, Event Hubs only has Atlas information. Microsoft Purview has added other capabilities such as **glossaries** and **contacts** which won't be available via Event Hubs.
74+
75+
### Identify key requirements
76+
77+
Most of enterprise organizations have critical requirement for Microsoft Purview for capabilities such as Backup, Business Continuity, and Disaster Recovery (BCDR). To get into more details of this requirement, you need to differentiate between Backup, High Availability (HA), and Disaster recovery (DR).
78+
79+
While they're similar, HA keeps the service operational if there was a hardware fault, for example, but it wouldn't protect you if someone accidentally or deliberately deleted all the records in your database. For that, you might need to restore the service from a backup.
80+
81+
### Backup
82+
83+
You might need to create regular backups from a Microsoft Purview account and use a backup in case a piece of data or configuration is accidentally or deliberately deleted from the Microsoft Purview account by the users.
84+
85+
The backup should allow saving a point in time copy of the following configurations from the Microsoft Purview account:
86+
87+
- Account information (for example, Friendly name)
88+
- Collection structure and role assignments
89+
- Custom Scan rule sets, classifications, and classification rules
90+
- Registered data sources
91+
- Scan information
92+
- Create and maintain key vaults connections
93+
- Key vault connections and Credentials and relations with current scans
94+
- Registered SHIRs
95+
- Glossary terms templates
96+
- Glossary terms
97+
- Manual asset updates (including classification and glossary assignments)
98+
- ADF and Synapse connections and lineage
99+
100+
Backup strategy is determined by restore strategy, or more specifically how long it will take to restore things when a disaster occurs. To answer that, you might need to engage with the affected stakeholders (the business owners) and understand what the required recovery objectives are.
101+
102+
There are three main requirements to take into consideration:
103+
104+
- **Recover Time Objective (RTO)** – Defines the maximum allowable downtime following a disaster for which ideally the system should be back operational.
105+
- **Recovery Point Objective (RPO)** – Defines the acceptable amount of data loss that is ok following a disaster. Normally RPO is expressed as a timeframe in hours or minutes.
106+
- **Recovery Level Object (RLO)** – Defines the granularity of the data being restored. It could be a SQL server, a set of databases, tables, records, etc.
107+
108+
To implement disaster recovery for Microsoft Purview, see the [Microsoft Purview disaster recovery documentation.](/purview/concept-best-practices-migration#implementation-steps)
109+
110+
## Next steps
111+
112+
> [!div class="nextstepaction"]
113+
> [Resiliency in Azure](/azure/well-architected/reliability/)

0 commit comments

Comments
 (0)