Skip to content

Update backup storage redundancy information #10359

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ZaeemKhaliq wants to merge 1 commit into
base: live
Choose a base branch
from
Open

Update backup storage redundancy information #10359

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion azure-sql/database/active-geo-replication-overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -116,7 +116,7 @@ If you decide to create the geo-secondary with a different configuration, you sh
> - If the geo-secondary is at a lower compute size than the primary. Look for the `HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO` wait type in [sys.dm_exec_requests](/sql/relational-databases/system-dynamic-management-views/sys-dm-exec-requests-transact-sql) and [sys.dm_os_wait_stats](/sql/relational-databases/system-dynamic-management-views/sys-dm-os-wait-stats-transact-sql) database views.
> - Throttling can also occur for reasons unrelated to compute size, for example in heavy workloads for bulk insert, `SELECT INTO`, and index builds. For more information on wait types for different kinds of log I/O throttling, see [Transaction log rate governance](resource-limits-logical-server.md#transaction-log-rate-governance).

By default, backup storage redundancy of the geo-secondary is same as for the primary database. You can choose to configure a geo-secondary with a different backup storage redundancy. Backups are always taken on the primary database. If the secondary is configured with a different backup storage redundancy, then after a geo-failover, when the geo-secondary is promoted to the primary, new backups will be stored and billed according to the type of storage (RA-GRS, ZRS, LRS) selected on the new primary (previous secondary).
By default, backup storage redundancy of the geo-secondary is same as for the primary database. You can choose to configure a geo-secondary with a different backup storage redundancy. Backups are always taken on the primary database in **General Purpose** service tier (In **Business Critical** tier, they are now taken on [secondary replicas](https://learn.microsoft.com/en-us/azure/azure-sql/database/automated-backups-overview?view=azuresql#automatic-backups-on-secondary-replicas)). If the secondary is configured with a different backup storage redundancy, then after a geo-failover, when the geo-secondary is promoted to the primary, new backups will be stored and billed according to the type of storage (RA-GRS, ZRS, LRS) selected on the new primary (previous secondary).

## Save on costs with the standby replica

Expand Down