You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/app-service/tutorial-connect-app-access-sql-database-as-user-dotnet.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -130,7 +130,7 @@ Currently, your Azure app connects to SQL Database uses SQL authentication (user
130
130
131
131
The app registration in Microsoft Entra ID now has the required permissions to connect to SQL Database by impersonating the signed-in user. Next, you configure your App Service app to give you a usable access token.
132
132
133
-
In the Cloud Shell, run the following commands on the app to add the `scope` parameter to the authentication setting `identityProviders.azureActiveDirectory.login.loginParameters`.
133
+
In the Cloud Shell, run the following commands on the app to add the `scope` parameter to the authentication setting `identityProviders.azureActiveDirectory.login.loginParameters`. It uses [jq] for JSON processing, which is installed already in the Cloud Shell.
134
134
135
135
```azurecli-interactive
136
136
authSettings=$(az webapp auth show --resource-group <group-name> --name <app-name>)
Copy file name to clipboardExpand all lines: articles/cloud-services/cloud-services-guestos-msrc-releases.md
+47-3Lines changed: 47 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,16 +7,60 @@ author: jejackson
7
7
ms.assetid: d0a272a9-ed01-4f4c-a0b3-bd5e841bdd77
8
8
ms.service: cloud-services
9
9
ms.topic: article
10
-
ms.date: 04/10/2024
10
+
ms.date: 05/03/2024
11
11
ms.author: jejackson
12
12
ms.custom: compute-evergreen
13
13
---
14
14
15
15
# Azure Guest OS
16
16
The following tables show the Microsoft Security Response Center (MSRC) updates applied to the Azure Guest OS. Search this article to determine if a particular update applies to the Guest OS you are using. Updates always carry forward for the particular [family][family-explain] they were introduced in.
17
17
18
-
>[!NOTE]
19
-
>The April Guest OS is currently being rolled out to Cloud Service VMs that are configured for automatic updates. When the rollout is complete, this version will be made available for manual updates through the Azure portal and configuration files. The following patches are included in the March Guest OS. This list is subject to change.
18
+
## May 2024 Guest OS
19
+
20
+
| Product Category | Parent KB Article | Vulnerability Description | Guest OS | Date First Introduced |
21
+
| --- | --- | --- | --- | --- |
22
+
| Rel 24-05 |[5036626]| .NET Framework 3.5 Security and Quality Rollup |[2.151]| May 14, 2024 |
Copy file name to clipboardExpand all lines: articles/storage/file-sync/file-sync-disaster-recovery-best-practices.md
+14-14Lines changed: 14 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,14 @@
1
1
---
2
2
title: Best practices for disaster recovery with Azure File Sync
3
-
description: Learn about best practices for disaster recovery with Azure File Sync, including high availability, data protection, and data redundancy.
3
+
description: Learn about best practices for disaster recovery with Azure File Sync, including high availability, data protection/backup, and data redundancy.
4
4
author: khdownie
5
5
ms.service: azure-file-storage
6
6
ms.topic: how-to
7
-
ms.date: 04/18/2023
7
+
ms.date: 06/04/2024
8
8
ms.author: kendownie
9
9
---
10
10
11
-
# Best practices for disaster recovery with Azure File Sync
11
+
# Disaster recovery best practices with Azure File Sync
12
12
13
13
For Azure File Sync, there are three main areas to consider for disaster recovery: high availability, data protection/backup, and data redundancy. This article covers each area and helps you decide what configuration to use for your own disaster recovery solution.
14
14
@@ -31,11 +31,11 @@ There are two different strategies you can use to achieve high availability for
31
31
32
32
For a failover cluster, you don't need to take any special steps to use Azure File Sync. For a standby server, you should make the following configurations:
33
33
34
-
Have a secondary server with different server endpoints that sync to the same sync group as your primary server but don't enable end-user access to the server. This allows all files to sync from the primary server to the standby server. You can consider enabling namespace-only tiering so that only the namespace is downloaded initially. If your primary server fails, you can use DFS-N to quickly reconfigure end-user access to your standby server.
34
+
Have a secondary server with different server endpoints that sync to the same sync group as your primary server, but don't enable end-user access to the server. This allows all files to sync from the primary server to the standby server. You can consider enabling namespace-only tiering so that only the namespace is downloaded initially. If your primary server fails, you can use DFS-N to quickly reconfigure end-user access to your standby server.
35
35
36
36
## Data protection/backup
37
37
38
-
Protecting your actual data is a key component of a disaster recovery solution. There are two main ways to do this with your Azure file shares: you can either back up your data in the cloud or on-premises. We highly recommend you back up your data in the cloud because your cloud endpoint will contain a full copy of your data, while server endpoints might only contain a subset of your data.
38
+
Protecting your data is a key component of a disaster recovery solution. There are two main ways to do this with your Azure file shares: you can either back up your data in the cloud or on-premises. We highly recommend you back up your data in the cloud because your cloud endpoint will contain a full copy of your data, while server endpoints might only contain a subset of your data.
39
39
40
40
### Back up your data in the cloud
41
41
@@ -49,13 +49,13 @@ For more information, see [About Azure file share backup](../../backup/azure-fil
49
49
50
50
### Back up your data on-premises
51
51
52
-
If you enable cloud tiering, don't implement an on-premises backup solution. With cloud tiering enabled, only a subset of your data will be stored locally on your server, the rest of your data is stored in your cloud endpoint. Depending on what backup solution you use for a local backup, tiered files will either be:
52
+
If you enable cloud tiering, don't implement an on-premises backup solution. With cloud tiering enabled, only a subset of your data will be stored locally on your server, and the rest of your data is stored in your cloud endpoint. Depending on what backup solution you use for a local backup, tiered files will either be:
53
53
54
54
- skipped and not backed up (due to their `FILE_ATTRIBUTE_RECALL_ONDATA_ACCESS` attribute), or
55
-
-they will be backed up only as a tiered file and might not be accessible upon restore due to changes in the live share, or
56
-
-they will be recalled to your disk, which will result in high egress charges.
55
+
- backed up only as a tiered file and might not be accessible upon restore due to changes in the live share, or
56
+
- recalled to your disk, which will result in high egress charges.
57
57
58
-
If you decide to use an on-premises backup solution, you should perform backups on a server in the sync group with cloud tiering disabled. When performing a restore, use the volume-level or file-level restore options. Files restored using the file-level restore option will sync to all endpoints in the sync group and existing files will be replaced with the version restored from backup. Volume-level restores won't replace newer file versions in the cloud endpoint or other server endpoints.
58
+
If you decide to use an on-premises backup solution, you should perform backups on a server in the sync group with cloud tiering disabled. When performing a restore, use the volume-level or file-level restore options. Files restored using the file-level restore option will sync to all endpoints in the sync group, and existing files will be replaced with the version restored from backup. Volume-level restores won't replace newer file versions in the cloud endpoint or other server endpoints.
59
59
60
60
[Volume Shadow Copy Service (VSS) snapshots](file-sync-deployment-guide.md#optional-self-service-restore-through-previous-versions-and-vss-volume-shadow-copy-service) (including the **Previous Versions** tab) are supported on volumes with cloud tiering enabled. This allows you to perform self-service restores instead of relying on an admin to perform restores for you. However, you must enable previous version compatibility through PowerShell, which will increase your snapshot storage costs. VSS snapshots don't protect against disasters on the server endpoint itself, so they should only be used alongside cloud-side backups. For details, see [Self Service restore through Previous Versions and VSS](file-sync-deployment-guide.md#optional-self-service-restore-through-previous-versions-and-vss-volume-shadow-copy-service).
61
61
@@ -64,9 +64,9 @@ If you decide to use an on-premises backup solution, you should perform backups
64
64
To ensure a robust disaster recovery solution, add some form of data redundancy to your infrastructure. There are four redundancy offerings for Azure Files: [Locally-redundant storage (LRS)](../files/files-redundancy.md#locally-redundant-storage), [zone-redundant storage (ZRS)](../files/files-redundancy.md#zone-redundant-storage), [geo-redundant storage (GRS)](../files/files-redundancy.md#geo-redundant-storage), and [geo-zone-redundant storage (GZRS)](../files/files-redundancy.md#geo-zone-redundant-storage).
65
65
66
66
-[Locally-redundant storage (LRS)](../files/files-redundancy.md#locally-redundant-storage): With LRS, every file is stored three times within an Azure storage cluster. This protects against loss of data due to hardware faults, such as a bad disk drive. However, if a disaster such as fire or flooding occurs within the data center, all replicas of a storage account using LRS may be lost or unrecoverable.
67
-
-[Zone-redundant storage (ZRS)](../files/files-redundancy.md#zone-redundant-storage): With ZRS, three copies of each file stored, however these copies are physically isolated in three distinct storage clusters in different Azure *availability zones*. Availability zones are unique physical locations within an Azure region. Each zone is made up of one or more data centers equipped with independent power, cooling, and networking. A write to storage is not accepted until it is written to the storage clusters in all three availability zones.
68
-
-[Geo-redundant storage (GRS)](../files/files-redundancy.md#geo-redundant-storage): With GRS, you have two regions, a primary and secondary region. Files are stored three times within an Azure storage cluster in the primary region. Writes are asynchronously replicated to a Microsoft-defined secondary region. GRS provides six copies of your data spread between two Azure regions.
69
-
-[Geo-zone-redundant storage (GZRS)](../files/files-redundancy.md#geo-zone-redundant-storage): You can think of GZRS as if it were like ZRS but with geo-redundancy. With GZRS, files are stored three times across three distinct storage clusters in the primary region. All writes are then asynchronously replicated to a Microsoft-defined secondary region.
67
+
-[Zone-redundant storage (ZRS)](../files/files-redundancy.md#zone-redundant-storage): With ZRS, three copies of each file stored, however these copies are physically isolated in three distinct storage clusters in different Azure *availability zones*. Availability zones are unique physical locations within an Azure region. Each zone is made up of one or more data centers equipped with independent power, cooling, and networking. A write to storage isn't accepted until it's written to the storage clusters in all three availability zones.
68
+
-[Geo-redundant storage (GRS)](../files/files-redundancy.md#geo-redundant-storage): With GRS, you have two regions: a primary and secondary region. Files are stored three times within an Azure storage cluster in the primary region. Writes are asynchronously replicated to a Microsoft-defined secondary region. GRS provides six copies of your data spread between two Azure regions.
69
+
-[Geo-zone-redundant storage (GZRS)](../files/files-redundancy.md#geo-zone-redundant-storage): Think of GZRS as ZRS but with geo-redundancy. With GZRS, files are stored three times across three distinct storage clusters in the primary region. All writes are then asynchronously replicated to a Microsoft-defined secondary region.
70
70
71
71
For a robust disaster recovery solution, most customers should consider ZRS. ZRS adds the least amount of extra cost for its added data redundancy benefits and is also the most seamless in the event of an outage. If your organization's policy or regulatory requirements require geo-redundancy for your data, consider either GRS or GZRS.
72
72
@@ -77,10 +77,10 @@ If your storage account is configured with either GRS or GZRS replication, Micro
77
77
Although you can manually request a failover of your Storage Sync Service to your GRS or GZRS paired region, we don't recommend doing this outside of large-scale regional outages because the process isn't seamless and might incur extra cost. To initiate the process, open a support ticket and request that both your Azure storage accounts that contain your Azure file share and your Storage Sync Service be failed over.
78
78
79
79
> [!WARNING]
80
-
> You must contact support to request your Storage Sync Service be failed over if you are initiating this process manually. Attempting to create a new Storage Sync Service using the same server endpoints in the secondary region might result in extra data staying in your storage account because the previous installation of Azure File Sync won't be cleaned up.
80
+
> You must contact support to request your Storage Sync Service be failed over if you're initiating this process manually. Attempting to create a new Storage Sync Service using the same server endpoints in the secondary region might result in extra data staying in your storage account because the previous installation of Azure File Sync won't be cleaned up.
81
81
82
82
Once a failover occurs, server endpoints will switch over to sync with the cloud endpoint in the secondary region automatically. However, the server endpoints must reconcile with the cloud endpoints. This might result in file conflicts, as the data in the secondary region might not be caught up to the primary.
83
83
84
-
## Next steps
84
+
## Next step
85
85
86
86
[Learn about Azure file share backup](../../backup/azure-file-share-backup-overview.md?toc=/azure/storage/file-sync/toc.json)
0 commit comments