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
:guidance-profile "1889ea46-76de-460c-a27c-6667b60e201e";; testing March 2023 updated guidelines - Microsoft standard.
7
5
8
-
**A minimum total score of 80 is required.**
9
-
10
-
Select the total score link to review all feedback on brand, terms, spelling, grammar, readability, and inclusive language. *You should fix all spelling errors regardless of your total score.* This helps maintain customer trust in overall content quality.
6
+
:template-header;; This displays in the pull request results pane.
**A minimum total score of 80 is required. The total score is an average of the subscores.**
11
+
Select **Total score** to review the Acrolinx scorecard for your article. Try to increase your individual scores, ex. Correctness. Your article will be clearer and more consistent with Microsoft standards.
Copy file name to clipboardExpand all lines: azure-sql/database/automated-backups-overview.md
+6-4Lines changed: 6 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ description: Learn how Azure SQL Database automatically backs up all databases a
5
5
author: SudhirRaparla
6
6
ms.author: nvraparl
7
7
ms.reviewer: mathoma, wiassaf, danil
8
-
ms.date: 09/14/2022
8
+
ms.date: 09/12/2023
9
9
ms.service: sql-database
10
10
ms.subservice: backup-restore
11
11
ms.topic: conceptual
@@ -195,8 +195,6 @@ Azure SQL Database provides both short-term and long-term retention of backups.
195
195
196
196
For all new, restored, and copied databases, Azure SQL Database retains sufficient backups to allow PITR within the last 7 days by default. The service takes regular full, differential, and log backups to ensure that databases are restorable to any point in time within the retention period that's defined for the database.
197
197
198
-
Short-term back up retention of 1 to 35 days for Hyperscale databases is now in preview. To learn more, review [Managing backup retention in Hyperscale](hyperscale-automated-backups-overview.md#backup-retention).
199
-
200
198
Differential backups can be configured to occur either once in 12 hours or once in 24 hours. A 24-hour differential backup frequency might increase the time required to restore the database, compared to the 12-hour frequency. In the vCore model, the default frequency for differential backups is once in 12 hours. In the DTU model, the default frequency is once in 24 hours.
201
199
202
200
You can specify your backup storage redundancy option for STR when you create your database, and then change it at a later time. If you change your backup redundancy option after your database is created, new backups will use the new redundancy option. Backup copies made with the previous STR redundancy option are not moved or copied. They're left in the original storage account until the retention period expires, which can be 1 to 35 days.
@@ -210,14 +208,18 @@ If you delete a database, the system keeps backups in the same way that it would
210
208
211
209
### Long-term retention
212
210
213
-
For SQL Database, you can configure full LTR backups for up to 10 years in Azure Blob Storage. After the LTR policy is configured, full backups are automatically copied to a different storage container weekly.
211
+
For SQL Database, you can configure full long-term retention (LTR) backups for up to 10 years in Azure Blob Storage. After the LTR policy is configured, full backups are automatically copied to a different storage container weekly.
214
212
215
213
To meet various compliance requirements, you can select different retention periods for weekly, monthly, and/or yearly full backups. The frequency depends on the policy. For example, setting `W=0, M=1` would create an LTR copy monthly. For more information about LTR, see [Long-term retention](long-term-retention-overview.md).
216
214
217
215
Updating the backup storage redundancy for an existing database applies the change only to subsequent backups taken in the future and not for existing backups. All existing LTR backups for the database will continue to reside in the existing storage blob. New backups will be replicated based on the configured backup storage redundancy.
218
216
219
217
Storage consumption depends on the selected frequency and retention periods of LTR backups. You can use the [LTR pricing calculator](https://azure.microsoft.com/pricing/calculator/?service=sql-database) to estimate the cost of LTR storage.
220
218
219
+
When restoring a Hyperscale database from an LTR backup, the read scale property is disabled. To enable, read scale on the restored database, update the database after it has been created. You need to specify the target service level objective when restoring from an LTR backup.
220
+
221
+
Long-term retention can be enabled for Hyperscale databases created or migrated from other service tiers after June 2022. LTR support for all other Hyperscale databases will be added over the next several weeks. If you attempt to enable LTR for a Hyperscale database where it is not yet supported, you will receive the following error: "An error has occurred while enabling Long-term backup retention for this database. Please reach out to Microsoft support to enable long-term backup retention." In this case, reach out to Microsoft support and please create a support ticket to resolve this.
222
+
221
223
## Backup storage costs
222
224
223
225
The price for backup storage varies and depends on your [purchasing model (DTU or vCore)](purchasing-models.md), chosen backup storage redundancy option, and region. Backup storage is charged based on gigabytes consumed per month, at the same rate for all backups.
The following document includes links to Azure examples showing how to connect and query Azure SQL Database and Azure SQL Managed Instance. For some related recommendations for Transport Level Security, see [TLS considerations for database connectivity](#tls-considerations-for-database-connectivity).
20
20
@@ -54,7 +54,7 @@ Get the connection information you need to connect to the database in Azure SQL
54
54
55
55
1. Review the complete **ADO.NET** connection string.
56
56
57
-
:::image type="content" source="./media/connect-query-dotnet-core/adonet-connection-string2.png" alt-text="Screenshot showing the ADO.NET connection string.":::
57
+
:::image type="content" source="media/connect-query-dotnet-core/adonet-connection-string2.png" alt-text="Screenshot showing the ADO.NET connection string.":::
58
58
59
59
1. Copy the **ADO.NET** connection string if you intend to use it.
60
60
@@ -76,20 +76,20 @@ Non-Microsoft drivers might not use TLS by default. This can be a factor when co
76
76
77
77
## Libraries
78
78
79
-
You can use various libraries and frameworks to connect to Azure SQL Database or Azure SQL Managed Instance. Check out our [Get started tutorials](https://aka.ms/sqldev) to quickly get started with programming languages such as C#, Java, Node.js, PHP, and Python. Then build an app by using SQL Server on Linux or Windows, or a SQL Server container on Linux.
79
+
You can use various libraries and frameworks to connect to Azure SQL Database or Azure SQL Managed Instance. You can then build an app by using SQL Server on Linux or Windows, or a SQL Server container on Linux.
80
80
81
81
The following table lists connectivity libraries or *drivers* that client applications can use from a variety of languages to connect to and use SQL Server running on-premises or in the cloud. You can use them on Linux, Windows, or in containers, and use them to connect to Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse Analytics.
82
82
83
83
| Language | Platform | Additional resources | Download | Get started |
0 commit comments