Merge pull request #303310 from MicrosoftDocs/main

Auto Publish – main to live - 2025-07-25 11:00 UTC

Author: learn-build-service-prod[bot]

articles/backup/faq-backup-sql-server.yml

@@ -5,7 +5,7 @@ metadata:
   ms.reviewer: vijayts
   ms.topic: faq
   ms.service: azure-backup
-  ms.date: 06/24/2025
+  ms.date: 07/25/2025
   author: AbhishekMallick-MS
   ms.author: v-mallicka
 
@@ -43,22 +43,26 @@ sections:
           1. On the SQL Server instance, in the *C:\Program Files\Azure Workload Backup\bin* folder, create or edit the **ExtensionSettingsOverrides.json** file.
           1. In the **ExtensionSettingsOverrides.json** file, set `{"EnableAutoHealer": false}`.
           1. Save the changes and close the file.
-          1. On the SQL Server instance, open **Task Manage**, and then restart the **AzureWLBackupCoordinatorSvc** service.
+          1. On the **SQL Server instance**, open **Task Manager**, stop `AzureWLBackupPluginSvs` and `AzureWLBackupInquirySvc` services, and then restart the `AzureWLBackupCoordinatorSvc` service.
           
+             `AzureWLBackupPluginSvs` and `AzureWLBackupInquirySvc` services auto-start when new tasks arrive. Avoid restarting `AzureWLBackupCoordinatorSvc` during active backups; otherwise, it aborts them and might trigger full remedial backups.
+
       - question: |
           Can I control how many concurrent backups run on the SQL server?
         answer: |
           Yes. You can throttle the rate at which the backup policy runs to minimize the impact on a SQL Server instance. To change the setting:
           
           1. On the SQL Server instance, in the *C:\Program Files\Azure Workload Backup\bin* folder, create the *ExtensionSettingsOverrides.json* file.
-          2. In the **ExtensionSettingsOverrides.json** file, change the `DefaultBackupTasksThreshold` setting to a lower value (for example, 5). <br>
+          1. In the **ExtensionSettingsOverrides.json** file, change the `DefaultBackupTasksThreshold` setting to a lower value (for example, 5). <br>
             `{"DefaultBackupTasksThreshold": 5}`
           <br>
           The default value of DefaultBackupTasksThreshold is **20**.
           
-          3. Save your changes and close the file.
-          4. On the SQL Server instance, open **Task Manager**. Restart the **AzureWLBackupCoordinatorSvc** service.<br/> <br/>
-           While this method helps if the backup application is consuming a large quantity of resources, SQL Server [Resource Governor](/sql/relational-databases/resource-governor/resource-governor) is a more generic way to specify limits on the amount of CPU, physical IO, and memory that incoming application requests can use.
+          1. Save your changes and close the file.
+          1. On the **SQL Server instance**, open **Task Manager**, stop `AzureWLBackupPluginSvs` and `AzureWLBackupInquirySvc` services, and then restart the `AzureWLBackupCoordinatorSvc` service.
+          
+             `AzureWLBackupPluginSvs` and `AzureWLBackupInquirySvc` services auto-start when new tasks arrive. Avoid restarting `AzureWLBackupCoordinatorSvc` during active backups; otherwise, it aborts them and might trigger full remedial backups. For more generic control over CPU, I/O, and memory usage by backup applications, use **SQL Server Resource Governor**.
+
           
           > [!NOTE]
           > In the UX you can still go ahead and schedule as many backups at any given time. However they'll be processed in a sliding window of say, 5, according to the above example.

articles/backup/quick-backup-vm-portal.md

@@ -1,7 +1,7 @@
 ---
 title: Quickstart - Back up a VM with the Azure portal by using Azure Backup
 description: In this Quickstart, learn how to create a Recovery Services vault, enable protection on an Azure VM, and back up the VM,  with the Azure portal.
-ms.date: 01/30/2025
+ms.date: 07/25/2025
 ms.topic: quickstart
 ms.devlang: azurecli
 ms.custom: mvc, mode-ui, engagement-fy24
@@ -32,28 +32,31 @@ Sign in to the [Azure portal](https://portal.azure.com).
 
 To apply a backup policy to your Azure VMs, follow these steps:
 
-1. Go to **Backup center** and select **+Backup** from the **Overview** tab.
+1. Go to **Business Continuity Center** and select **+ Configure protection**.
 
-   ![Screenshot showing the Backup button.](./media/backup-azure-arm-vms-prepare/backup-button.png)
+   :::image type="content" source="./media/backup-azure-arm-vms-prepare/configure-protection.png" alt-text="Screenshot shows how to start configuring system backup." lightbox="./media/backup-azure-arm-vms-prepare/configure-protection.png":::
 
-1. On the **Start: Configure Backup** blade, select **Azure Virtual machines** as the **Datasource type** and select the vault you have created. Then select **Continue**.
+1. On the **Configure protection** pane, select **Resource managed by** as **Azure**, **Datasource type** as **Azure Virtual machines**, **Solution** as **Azure Backup**, and then select **Continue**.
 
-   ![Screenshot showing Backup and Backup Goal blades.](./media/backup-azure-arm-vms-prepare/select-backup-goal-1.png)
+   :::image type="content" source="./media/backup-azure-arm-vms-prepare/configure-system-protection.png" alt-text="Screenshot shows how to set the system backup." lightbox="./media/backup-azure-arm-vms-prepare/configure-system-protection.png":::  
 
-1. Assign a Backup policy.
 
-   - The default policy backs up the VM once a day. The daily backups are retained for _30 days_. Instant recovery snapshots are retained for two days.
+1. On the **Start: Configure Backup** pane, select **Azure Virtual machines** as the **Datasource type** and select the vault you have created. Then select **Continue**.
 
-      ![Screenshot showing the default backup policy.](./media/backup-azure-arm-vms-prepare/default-policy.png)
+   :::image type="content" source="./media/backup-azure-arm-vms-prepare/select-backup-goal-1.png" alt-text="Screenshot showing Backup and Backup Goal panes." lightbox="./media/backup-azure-arm-vms-prepare/select-backup-goal-1.png":::
 
-   - If you don't want to use the default policy, select **Create New**, and create a custom policy as described in the next procedure.
+1. On the **Configure backup** pane, select the **Policy sub type** as **Enhanced**, **Standard**.
 
-> [!Note]
-> With Enhanced policy, you can now back up Azure VMs multiple times a day that helps to perform hourly backups. [Learn more](backup-azure-vms-enhanced-policy.md).
+   - **Enhanced Backup policy**: [This policy](backup-azure-vms-enhanced-policy.md) allows multiple daily backups, enabling hourly backups. To enable Azure Backup on Azure VMs in Azure Extended Zones, you can only use the Enhanced policy.
+   - **Standard Backup policy**: [This policy](backup-instant-restore-capability.md) allows VM backup once a day. The daily backups are retained for 30 days. Instant recovery snapshots are retained for two days.
+
+   :::image type="content" source="./media/backup-azure-arm-vms-prepare/default-policy.png" alt-text="Screenshot showing the default backup policy." lightbox="./media/backup-azure-arm-vms-prepare/default-policy.png":::
+
+   If you don't want to use the default policy, select **Create New**, and create a custom policy as described in the next procedure.
 
 ## Select a VM to back up
 
-Create a simple scheduled daily backup to a Recovery Services vault.
+Create a scheduled daily backup to a Recovery Services vault.
 
 1. Under **Virtual Machines**, select **Add**.
 
@@ -159,25 +162,7 @@ Azure Backup backs up Azure VMs by installing an extension to the Azure VM agent
 
 When no longer needed, you can disable protection on the VM, remove the restore points and Recovery Services vault, then delete the resource group and associated VM resources
 
-If you're going to continue on to a Backup tutorial that explains how to restore data for your VM, skip the steps in this section and go to [Next steps](#next-steps).
-
-1. Select the **Backup** option for your VM.
-
-2. Choose **Stop backup**.
-
-    ![Screenshot showing to stop VM backup from the Azure portal.](./media/quick-backup-vm-portal/stop-backup.png)
-
-3. Select **Delete Backup Data** from the drop-down menu.
-
-4. In the **Type the name of the Backup item** dialog, enter your VM name, such as *myVM*. Select **Stop Backup**.
-
-    Once the VM backup has been stopped and recovery points removed, you can delete the resource group. If you used an existing VM, you may want to leave the resource group and VM in place.
-
-5. In the menu on the left, select **Resource groups**.
-6. From the list, choose your resource group. If you used the sample VM quickstart commands, the resource group is named *myResourceGroup*.
-7. Select **Delete resource group**. To confirm, enter the resource group name, then select **Delete**.
-
-    ![Screenshot showing to delete the resource group from the Azure portal.](./media/quick-backup-vm-portal/delete-resource-group-from-portal.png)
+Learn how to [stop protection and delete VM backups](backup-azure-manage-vms.md#stop-protection-and-delete-backup-data).
 
 ## Next steps
 

articles/data-factory/connector-lifecycle-overview.md

@@ -24,11 +24,11 @@ Connector upgrades are essential to evolve innovation in a fast manner, maintain
 
 - **New feature enhancements such as security, performance, etc.**  
 
-   While the service actively evolves to provide the most secure and reliable features in the connector, leveraging the connector lifecycle is an efficient approach to ensure that users can take full advantage of the new enhancements at their manageable pace without business interruption.
+   While the service actively evolves to provide the most secure and reliable features in the connector, applying the connector lifecycle is an efficient approach to ensure that users can take full advantage of the new enhancements at their manageable pace without business interruption.
 
 - **Protocol change introduced by external data source vendors leading to potential behavior changes**  
 
-   These changes aren't always exhaustively predictable and arise due to incompatibility brought by individual data source vendor itself. Given these uncertainties, versioning ensures that users can adopt the updated connector (e.g. version 2.0) while maintaining a fallback option in a period. This empowers users to well plan for a version upgrade to accommodate potential differences while providing users with a clear transition path.
+   These changes aren't always exhaustively predictable and arise due to incompatibility brought by individual data source vendor itself. Given these uncertainties, versioning ensures that users can adopt the updated connector (for example, version 2.0) while maintaining a fallback option in a period. This empowers users to well plan for a version upgrade to accommodate potential differences while providing users with a clear transition path.
 
 - **Fixing unintended behaviors**  
 
@@ -48,14 +48,14 @@ A connector lifecycle includes multiple stages with thorough and measurable asse
 | Public Preview      | This stage marks the initial release of a new connector version to all users publicly. During this phase, users are encouraged to try the latest connector version and provide feedback. For newly created connections, it defaults to the latest connector version. Users can switch back to the previous version. | 1 month or above*       |
 | General Availability  | Once a connector version meets the General Availability (GA) criteria, it's released to the public and is suitable for production workloads. To reach this stage, the new connector version must meet the requirements in terms of performance, reliability, and its capability to meet business needs. | 12 months or above*     |
 | End-of-Support (EOS) announced | When a connector version reaches its EOS, it won't receive any further updates or support. A six-month notice is announced before the EOS date of this version. This is documented together with the removal date. | 6 months before the end-of-support date* |
-| End-of-Support (EOS)  | Once the previously announced EOS date arrives, the connector version becomes officially unsupported. This implies that it won't receive any updates or bug fixes, and no official support will be provided. Users won't be able to create new workloads on a version that is under EOS stage. Using an unsupported connector version is at the user's own risk. The workload running on EOS version may not fail immediately, the service might expedite moving into the final stage at any time, at Microsoft's discretion due to outstanding security issues, or other factors. | /                        |
-| Version removed  | Once the connector version passes its EOS date, the service will remove all related components associated with this connector version. This implies that pipelines using this connector version will discontinue to execute. | 1-12 months after the end of support date* |
+| End-of-Support (EOS)  | Once the previously announced EOS date arrives, the connector version becomes officially unsupported. This implies that it won't receive any updates or bug fixes, and no official support will be provided. Users won't be able to create new workloads on a version that is under EOS stage. Using an unsupported connector version is at the user's own risk. The workload running on EOS version may not fail immediately. The service might expedite moving into the final stage at any time, at Microsoft's discretion due to outstanding security issues, or other factors. | /                        |
+| Version removed  | Once the connector version passes its EOS date, the service removes all related components associated with this connector version. This implies that pipelines using this connector version discontinues to execute. | 1-12 months after the end of support date* |
 
 *\* These timelines are provided as an example and might vary depending on various factors. Lifecycle timelines are subject to change at Microsoft discretion.*
 
 ## Understanding connector versions
 
-To manage connection updates effectively, it's important to understand versioning and how to interpret the change. Connectors in Azure Data Factory generally follow versioning Major.Minor (e.g., 1.2):
+To manage connection updates effectively, it's important to understand versioning and how to interpret the change. Connectors in Azure Data Factory generally follow versioning Major.Minor (for example, 1.2):
 
 - **Major updates (x.0):** These are significant changes that require review on the changes before upgrade.
 - **Minor updates (1.x):** These might introduce new features or fixes, but with minor changes to the existing behavior.
@@ -70,50 +70,6 @@ When a version reaches its end-of-support date, users are no longer allowed to c
 
 In addition to major and minor version updates, the service also delivers new features and bug fixes that are fully backward compatible with your existing setup. These changes don't require a version update to the connector. Depending on the nature of the change, users may either receive the improvements automatically or have the option to enable new features as needed. This approach ensures a seamless experience while maintaining stability and flexibility.
 
-## Automatic connector upgrade 
-
-In addition to providing [tools](connector-upgrade-advisor.md) and [best practices](connector-upgrade-guidance.md) to help users manually upgrade their connectors, the service now also provides a more streamlined upgrade process for some cases where applicable. This is designed to help users adopt the most reliable and supported connector versions with minimal disruption.
-
-The following section outlines the general approach that the service takes for automatic upgrades. While this provides a high-level overview, it's strongly recommended to review the documentation specific to each connector to understand which scenarios are supported and how the upgrade process applies to your workloads.
-
-In cases where certain scenarios running on the latest GA connector version are fully backward compatible with the previous version, the service will automatically upgrade existing workloads (such as Copy, Lookup, and Script activities) to a compatibility mode that preserves the behavior of the earlier version.
-
-These auto-upgraded workloads aren't affected by the announced removal date of the older version, giving users additional time to evaluate and transition to the latest GA version without facing immediate failures. 
-
-You can identify which activities have been automatically upgraded by inspecting the activity output, where relevant upgraded information is recorded.
-
-**Example:**
-
-Copy activity output 
-
-```json
-"source": {
-    "type": "AmazonS3",
-    "autoUpgrade": "true",
-} 
-
-"sink": {
-    "type": "AmazonS3",
-    "autoUpgrade": "true",
-}
-```
-
-> [!NOTE]
-> While compatibility mode offers flexibility, we strongly encourage users to upgrade to the latest GA version as soon as possible to benefit from ongoing improvements, optimizations, and full support. 
-
-You can find more details from the table below on the connector list that is planned for the automatic upgrade.  
-
-| Connector        | Scenario |
-|------------------|----------|
-| [Amazon Redshift](connector-amazon-redshift.md) | Scenario that doesn't rely on below capability in Amazon Redshift (version 1.0):<br><br>• Linked service that uses Azure integration runtime.<br>• Use [UNLOAD](connector-amazon-redshift.md#use-unload-to-copy-data-from-amazon-redshift).<br><br>Automatic upgrade is only applicable when the driver is installed in your machine that installs the self-hosted integration runtime.<br><br> For more information, go to [Install Amazon Redshift ODBC driver for the version 2.0](connector-amazon-redshift.md#install-amazon-redshift-odbc-driver-for-the-version-20).|
-| [Google BigQuery](connector-google-bigquery.md)  | Scenario that doesn't rely on below capability in Google BigQuery V1:<br><br>  • Use `trustedCertsPath`, `additionalProjects`, `requestgoogledrivescope` connection properties.<br>  • Set `useSystemTrustStore` connection property as `false`.<br>  • Use **STRUCT** and **ARRAY** data types. <br><br>If your pipeline runs on self-hosted integration runtime, it requires SHIR version 5.55 or above. |
-| [Hive](connector-hive.md) | Scenario that doesn't rely on below capability in Hive (version 1.0):<br><br>• Authentication types:<br>&nbsp;&nbsp;• Username<br>• Thrift transport protocol:<br>&nbsp;&nbsp;• HiveServer1<br>• Service discovery mode: True<br>• Use native query: True <br><br>If your pipeline runs on self-hosted integration runtime, it requires SHIR version 5.55 or above.|
-| [Impala](connector-impala.md) | Scenario that doesn't rely on below capability in Impala (version 1.0):<br><br>• Authentication types:<br>&nbsp;&nbsp;• SASL Username<br><br>If your pipeline runs on self-hosted integration runtime, it requires SHIR version 5.55 or above. |
-| [Spark](connector-spark.md) | Scenario that doesn't rely on below capability in Spark (version 1.0):<br><br>• Authentication types:<br>&nbsp;&nbsp;• Username<br>• Thrift transport protocol:<br>&nbsp;&nbsp;• SASL<br>&nbsp;&nbsp;• Binary<br>• Thrift transport protocol:<br>&nbsp;&nbsp;• SharkServer<br>&nbsp;&nbsp;• SharkServer2<br><br>If your pipeline runs on self-hosted integration runtime, it requires SHIR version 5.55 or above.|
-| [Teradata](connector-teradata.md)         | Scenario that doesn't rely on below capability in Teradata (version 1.0):<br><br>  • Set below value for **CharacterSet**:<br>&nbsp;&nbsp;• BIG5 (TCHBIG5_1R0)<br>&nbsp;&nbsp;• EUC (Unix compatible, KANJIEC_0U)<br>&nbsp;&nbsp;• GB (SCHGB2312_1T0)<br>&nbsp;&nbsp;• IBM Mainframe (KANJIEBCDIC5035_0I)<br>&nbsp;&nbsp;• NetworkKorean (HANGULKSC5601_2R4)<br>&nbsp;&nbsp;• Shift-JIS (Windows, DOS compatible, KANJISJIS_0S)|
-| [Vertica](connector-vertica.md) | Scenario that doesn't rely on below capability in Vertica (version 1.0):<br><br>• Linked service that uses Azure integration runtime.<br><br>Automatic upgrade is only applicable when the driver is installed in your machine that installs the self-hosted integration runtime (version 5.55 or above).<br><br> For more information, go to [Install Vertica ODBC driver for the version 2.0](connector-vertica.md#install-vertica-odbc-driver-for-the-version-20). |
-
-
 ## Related content
 
 - [Connector overview](connector-overview.md)