Azure SQL Database의 비즈니스 연속성 개요Overview of business continuity with Azure SQL Database

이 개요에서는 Azure SQL Database에서 비즈니스 연속성 및 재해 복구를 위해 제공하는 기능에 대해 설명합니다.This overview describes the capabilities that Azure SQL Database provides for business continuity and disaster recovery. 데이터 손실을 유발하거나 데이터베이스 및 응용 프로그램을 사용할 수 없게 만들 수 있는 중단 이벤트에서의 복구와 관련된 옵션, 권장 사항 및 자습서에 대해 알아봅니다.Learn about options, recommendations, and tutorials for recovering from disruptive events that could cause data loss or cause your database and application to become unavailable. 사용자 또는 응용 프로그램 오류가 데이터 무결성에 영향을 주거나, Azure 지역에 가동 중단이 발생하거나, 응용 프로그램에 유지 관리가 필요할 때 수행할 작업을 알아봅니다.Learn what to do when a user or application error affects data integrity, an Azure region has an outage, or your application requires maintenance.

비즈니스 연속성을 제공하는 데 사용할 수 있는 SQL Database 기능SQL Database features that you can use to provide business continuity

SQL Database는 자동화된 백업 및 선택적 데이터베이스 복제를 비롯한 여러 가지 비즈니스 연속성 기능을 제공합니다.SQL Database provides several business continuity features, including automated backups and optional database replication. 이러한 기능은 최근 트랜잭션에 대한 ERT(예상 복구 시간) 및 잠재적 데이터 손실에 대해 각기 다른 특성을 갖습니다.Each has different characteristics for estimated recovery time (ERT) and potential data loss for recent transactions. 이러한 옵션을 이해하면 적절한 옵션을 선택할 수 있습니다. 대부분의 시나리오에서 이러한 옵션을 함께 사용할 수 있습니다.Once you understand these options, you can choose among them - and, in most scenarios, use them together for different scenarios. 비즈니스 연속성 계획을 개발할 때는 중단 이벤트 후 응용 프로그램이 완벽하게 복구되기까지 허용되는 최대 시간(RTO(복구 시간 목표))을 이해해야 합니다.As you develop your business continuity plan, you need to understand the maximum acceptable time before the application fully recovers after the disruptive event - this is your recovery time objective (RTO). 중단 이벤트 후 복구될 때 응용 프로그램이 손실을 허용할 수 있는 최신 데이터 업데이트의 최대 크기(시간 간격)(RPO(복구 지점 목표))도 이해해야 합니다.You also need to understand the maximum amount of recent data updates (time interval) the application can tolerate losing when recovering after the disruptive event - this is your recovery point objective (RPO).

다음 테이블에서 세 가지 가장 일반적인 시나리오에 대한 ERT 및 RPO를 비교합니다.The following table compares the ERT and RPO for the three most common scenarios.

기능Capability 기본 계층Basic tier 표준 계층Standard tier 프리미엄 계층Premium tier
백업에서 특정 시점 복원Point in Time Restore from backup 7일 이내의 모든 복원 지점Any restore point within 7 days 35일 이내의 모든 복원 지점Any restore point within 35 days 35일 이내의 모든 복원 지점Any restore point within 35 days
지리적으로 복제된 백업에서 지역 복원Geo-restore from geo-replicated backups ERT < 12시간, RPO < 1시간ERT < 12h, RPO < 1h ERT < 12시간, RPO < 1시간ERT < 12h, RPO < 1h ERT < 12시간, RPO < 1시간ERT < 12h, RPO < 1h
Azure Backup 자격 증명 모음에서 복원Restore from Azure Backup Vault ERT < 12시간, RPO < 1주ERT < 12h, RPO < 1 wk ERT < 12시간, RPO < 1주ERT < 12h, RPO < 1 wk ERT < 12시간, RPO < 1주ERT < 12h, RPO < 1 wk
활성 지역 복제Active geo-replication ERT < 30초, RPO < 5초ERT < 30s, RPO < 5s ERT < 30초, RPO < 5초ERT < 30s, RPO < 5s ERT < 30초, RPO < 5초ERT < 30s, RPO < 5s

데이터베이스 백업을 사용하여 데이터베이스 복구Use database backups to recover a database

SQL Database는 데이터 손실로부터 비즈니스를 보호하기 위해 매주 전체 데이터베이스 백업과 매시간 차등 데이터베이스 백업, 그리고 5~10분 간격으로 트랜잭션 로그 백업을 모두 자동으로 수행합니다.SQL Database automatically performs a combination of full database backups weekly, differential database backups hourly, and transaction log backups every five - ten minutes to protect your business from data loss. 이러한 백업은 표준 및 프리미엄 서비스 계층의 데이터베이스에 대해서는 35일 동안, 기본 서비스 계층의 데이터베이스에 대해서는 7일 동안 지역 중복 저장소에 저장됩니다.These backups are stored in geo-redundant storage for 35 days for databases in the Standard and Premium service tiers and 7 days for databases in the Basic service tier. 자세한 내용은 서비스 계층을 참조하세요.For more information, see service tiers. 서비스 계층에 대한 보존 기간이 비즈니스 요구 사항에 맞지 않으면 서비스 계층을 변경하여 보존 기간을 늘릴 수 있습니다.If the retention period for your service tier does not meet your business requirements, you can increase the retention period by changing the service tier. 데이터 센터 가동 중단으로부터 보호하기 위해 전체 및 차등 데이터베이스 백업도 쌍을 이루는 데이터 센터로 복제됩니다.The full and differential database backups are also replicated to a paired data center for protection against a data center outage. 자세한 내용은 자동 데이터베이스 백업을 참조하세요.For more information, see automatic database backups.

기본 보존 기간이 응용 프로그램에 대해 충분하지 않을 경우에 데이터베이스 장기 보존 정책을 구성하여 확장할 수 있습니다.If the built-in retention period is not sufficient for your application, you can extend it by configuring a database long-term retention policy. 자세한 내용은 장기 보존을 참조하세요.For more information, see long-term retention.

이러한 자동 데이터베이스 백업을 사용하여 다양한 중단 이벤트에서 데이터 센터 내로 및 다른 데이터 센터로 데이터베이스를 복구할 수 있습니다.You can use these automatic database backups to recover a database from various disruptive events, both within your data center and to another data center. 자동 데이터베이스 백업을 사용할 경우 예상 복구 시간은 동일한 지역에서 동시에 복구되는 총 데이터베이스 수, 데이터베이스 크기, 트랜잭션 로그 크기 및 네트워크 대역폭에 따라 좌우됩니다.Using automatic database backups, the estimated time of recovery depends on several factors including the total number of databases recovering in the same region at the same time, the database size, the transaction log size, and network bandwidth. 복구 시간은 일반적으로 12시간 미만입니다.The recovery time is usually less than 12 hours. 다른 데이터 영역을 복구할 때 잠재적인 데이터 손실은 시간별 차등 데이터베이스 백업의 지역 중복 저장소별로 1시간으로 제한됩니다.When recovering to another data region, the potential data loss is limited to 1 hour by the geo-redundant storage of hourly differential database backups.

중요

자동화된 백업을 사용하여 복구하려면 SQL Server 참여자 역할의 구성원이거나 구독 소유자여야 합니다. RBAC: 기본 제공 역할을 참조하세요.To recover using automated backups, you must be a member of the SQL Server Contributor role or the subscription owner - see RBAC: Built-in roles. Azure 포털, PowerShell 또는 REST API를 사용하여 복구할 수 있습니다.You can recover using the Azure portal, PowerShell, or the REST API. Transact-SQL은 사용할 수 없습니다.You cannot use Transact-SQL.

다음 조건의 응용 프로그램의 경우, 자동화된 백업을 비즈니스 연속성 및 복구 메커니즘으로 사용합니다.Use automated backups as your business continuity and recovery mechanism if your application:

  • 중요 업무용으로 간주되지 않습니다.Is not considered mission critical.
  • 연계된 SLA가 없으므로 24시간 이상의 가동 중지가 발생해도 재무적 책임이 없습니다.Doesn't have a binding SLA - a downtime of 24 hours or longer does not result in financial liability.
  • 데이터 변경(시간당 낮은 트랜잭션) 속도가 느리고, 최대 1시간의 데이터 변경 내용 손실은 비교적 허용 가능한 데이터 손실에 해당합니다.Has a low rate of data change (low transactions per hour) and losing up to an hour of change is an acceptable data loss.
  • 비용에 민감합니다.Is cost sensitive.

빠른 복구가 필요한 경우 활성 지역 복제(다음에 설명)를 사용합니다.If you need faster recovery, use active geo-replication (discussed next). 35일이 지난 기간에서 데이터를 복구해야 하는 경우 장기 백업 보존을 사용합니다.If you need to be able to recover data from a period older than 35 days, use long-term backup retention.

활성 지역 복제 및 자동 장애 조치 그룹(미리 보기 상태)을 사용하여 복구 시간을 줄이고 복구와 연결된 데이터 손실을 제한합니다.Use active geo-replication and auto-failover groups (in-preview) to reduce recovery time and limit data loss associated with a recovery

업무 중단이 발생할 경우 데이터베이스 복구를 위해 데이터베이스 백업을 사용하는 것 외에도 활성 지역 복제를 사용하여 선택한 지역에서 최대 4개의 읽기 가능한 보조 데이터베이스가 유지되도록 데이터베이스를 구성할 수 있습니다.In addition to using database backups for database recovery if a business disruption occurs, you can use active geo-replication to configure a database to have up to four readable secondary databases in the regions of your choice. 이러한 보조 데이터베이스는 비동기 복제 메커니즘을 사용하여 주 데이터베이스와 동기화된 상태를 유지합니다.These secondary databases are kept synchronized with the primary database using an asynchronous replication mechanism. 이 기능은 데이터 센터 가동 중단 발생 시 또는 응용 프로그램 업그레이드 기간에 업무 중단을 방지하기 위해 사용됩니다.This feature is used to protect against business disruption if a data center outage occurs or during an application upgrade. 지리적으로 분산된 사용자에게 읽기 전용 쿼리에 대한 향상된 쿼리 성능을 제공하기 위해 활성 지역 복제를 사용할 수도 있습니다.Active geo-replication can also be used to provide better query performance for read-only queries to geographically dispersed users.

자동화된 투명 장애 조치를 사용하려면 SQL Database의 자동 장애 조치 그룹 기능(미리 보기 상태)을 사용하여 지역에서 복제된 데이터베이스를 그룹으로 구성해야 합니다.To enable automated and transparent failover you should organize your geo-replicated databases into groups using the auto-failover group feature of SQL Database (in-preview).

주 데이터베이스가 예기치 않게 오프라인 상태가 되거나 유지 관리 작업을 위해 오프라인 상태로 전환해야 할 경우 보조 데이터베이스를 빠르게 주 데이터베이스로 승격하고(장애 조치(faiilover)라고도 함) 승격된 주 데이터베이스에 연결하도록 응용 프로그램을 구성할 수 있습니다.If the primary database goes offline unexpectedly or you need to take it offline for maintenance activities, you can quickly promote a secondary to become the primary (also called a failover) and configure applications to connect to the promoted primary. 응용 프로그램이 장애 조치(failover) 그룹 수신기를 사용하여 데이터베이스에 연결하는 경우 장애 조치(failover) 후 SQL 연결 문자열 구성을 변경할 필요가 없습니다.If your application is connecting to the databases using the failover group listener, you don’t need to change the SQL connection string configuration after failover. 계획된 장애 조치를 사용할 경우 데이터는 손실되지 않습니다.With a planned failover, there is no data loss. 계획되지 않은 장애 조치를 사용하는 경우 비동기 복제의 특성으로 인해 아주 최근에 발생한 트랜잭션에 대해 약간의 데이터 손실이 발생합니다.With an unplanned failover, there may be some small amount of data loss for very recent transactions due to the nature of asynchronous replication. 자동 장애 조치 그룹(미리 보기 상태)을 사용하여 잠재적 데이터 손실을 최소화하도록 장애 조치 정책을 사용자 지정할 수 있습니다.Using auto-failover groups (in-preview), you can customize the failover policy to minimize the potential data loss. 장애 조치(failover) 후, 계획에 따라 또는 데이터 센터가 다시 온라인 상태가 될 때 장애 복구(failback)를 수행할 수 있습니다.After a failover, you can later failback - either according to a plan or when the data center comes back online. 모든 경우에 사용자는 적은 양의 가동 중지 시간을 경험하며 다시 연결해야 합니다.In all cases, users experience a small amount of downtime and need to reconnect.

중요

활성 지역 복제 및 자동 장애 조치 그룹(미리 보기 상태)을 사용하려면 SQL Server에서 구독 소유자이거나 관리 권한을 보유해야 합니다.To use active geo-replication and auto-failover groups (in-preview), you must either be the subscription owner or have administrative permissions in SQL Server. 구독에 대한 권한을 통해 Azure Portal, PowerShell 또는 REST API를 사용하거나, Azure 구독 사용 권한을 사용하거나, SQL Server 사용 권한이 있는 Transact-SQL을 사용하여 구성하고 장애 조치할 수 있습니다.You can configure and fail over using the Azure portal, PowerShell, or the REST API using Azure subscription permissions or using Transact-SQL with SQL Server permissions.

응용 프로그램이 다음 조건에 맞는 경우 활성 지역 복제 및 자동 장애 조치 그룹(미리 보기 상태)을 사용합니다.Use active geo-replication and auto-failover groups (in preview) if your application meets any of these criteria:

  • 중요 업무용입니다.Is mission critical.
  • 24시간 이상의 가동 중지 시간을 허용하지 않는 SLA(서비스 수준 약정)가 있습니다.Has a service level agreement (SLA) that does not allow for 24 hours or more of downtime.
  • 가동 중지는 재무적 책임을 유발할 수 있습니다.Downtime may result in financial liability.
  • 데이터 변경 속도가 높고 1시간에 해당하는 데이터 손실은 허용할 수 없는 수준입니다.Has a high rate of data change is high and losing an hour of data is not acceptable.
  • 활성 지역 복제를 사용할 때 발생하는 추가적인 비용이 잠재적인 재무적 책임과 연계된 비즈니스 손실보다 낮습니다.The additional cost of active geo-replication is lower than the potential financial liability and associated loss of business.

>

사용자 또는 응용 프로그램 오류 발생 이후 데이터베이스 복구Recover a database after a user or application error

어느 누구도 완벽하지는 않습니다.No one is perfect! 사용자가 실수로 데이터를 삭제할 수도 있고, 의도치 않게 중요한 테이블을 삭제할 수도 있고, 전체 데이터베이스를 삭제할 수도 있습니다.A user might accidentally delete some data, inadvertently drop an important table, or even drop an entire database. 또는 응용 프로그램에서 결함으로 인해 잘못된 데이터를 적절한 데이터에 덮어쓸 수도 있습니다.Or, an application might accidentally overwrite good data with bad data due to an application defect.

이러한 시나리오에서 복구 옵션은 다음과 같습니다.In this scenario, these are your recovery options.

지정 시간 복원 수행Perform a point-in-time restore

자동화된 백업을 사용하여 데이터베이스 복사본을 알려진 적절한 지정 시간(데이터베이스 보존 기간 내에 포함되는 시간)으로 복구할 수 있습니다.You can use the automated backups to recover a copy of your database to a known good point in time, provided that time is within the database retention period. 데이터베이스가 복원된 후에 원본 데이터베이스를 복원된 데이터베이스로 바꾸거나 복원된 데이터에서 필요한 데이터를 원본 데이터베이스로 복사할 수 있습니다.After the database is restored, you can either replace the original database with the restored database or copy the needed data from the restored data into the original database. 데이터베이스가 활성 지역 복제를 사용하는 경우 복원된 복사본에서 필수 데이터를 원본 데이터베이스로 복사하는 것이 좋습니다.If the database uses active geo-replication, we recommend copying the required data from the restored copy into the original database. 원본 데이터베이스를 복원된 데이터베이스로 바꾸는 경우 활성 지역 복제를 다시 구성하고 다시 동기화해야 합니다(데이터베이스 크기가 클 경우 시간이 오래 걸릴 수 있음).If you replace the original database with the restored database, you need to reconfigure and resynchronize active geo-replication (which can take quite some time for a large database). 이 경우 데이터베이스를 사용 가능한 마지막 시점으로 복원하지만 지역 보조 복제본에 대한 지정 시간 복원은 현재 지원되지 않습니다.While this restores a database to the last available point in time, restoring the geo-secondary to any point in time is not currently supported.

Azure 포털 또는 PowerShell을 사용하여 데이터베이스를 지정 시간으로 복원하기 위한 자세한 단계 및 내용은 지정 시간 복원을 참조하세요.For more information and for detailed steps for restoring a database to a point in time using the Azure portal or using PowerShell, see point-in-time restore. Transact-SQL을 사용하여 복구할 수는 없습니다.You cannot recover using Transact-SQL.

삭제된 데이터베이스 복원Restore a deleted database

데이터베이스가 삭제되었으나 논리 서버는 삭제되지 않은 경우 삭제된 데이터베이스를 삭제된 시점으로 복원할 수 있습니다.If the database is deleted but the logical server has not been deleted, you can restore the deleted database to the point at which it was deleted. 이렇게 하면 삭제된 동일한 논리적 SQL Server로 데이터베이스 백업이 복원됩니다.This restores a database backup to the same logical SQL server from which it was deleted. 원래 이름을 사용하여 복원하거나 새 이름 또는 복원된 데이터베이스를 입력할 수 있습니다.You can restore it using the original name or provide a new name or the restored database.

Azure 포털 또는 PowerShell을 사용하여 삭제된 데이터베이스를 복원하는 자세한 단계 및 정보는 삭제된 데이터베이스 복원을 참조하세요.For more information and for detailed steps for restoring a deleted database using the Azure portal or using PowerShell, see restore a deleted database. Transact-SQL을 사용하여 복원할 수는 없습니다.You cannot restore using Transact-SQL.

중요

논리 서버가 삭제되면 삭제된 데이터베이스를 복구할 수 없습니다.If the logical server is deleted, you cannot recover a deleted database.

Azure Backup 자격 증명 모음에서 복원Restore from Azure Backup Vault

자동화된 백업에 대한 현재 보존 기간 외에 데이터 손실이 발생하고 장기 보존을 위해 데이터베이스를 구성하는 경우 Azure Backup Vault의 주간 백업에서 새 데이터베이스로 복원할 수 있습니다.If the data loss occurred outside the current retention period for automated backups and your database is configured for long-term retention, you can restore from a weekly backup in Azure Backup Vault to a new database. 이 시점에서 원본 데이터베이스를 복원된 데이터베이스로 바꾸거나 복원된 데이터베이스에서 필요한 데이터를 원본 데이터베이스로 복사할 수 있습니다.At this point, you can either replace the original database with the restored database or copy the needed data from the restored database into the original database. 이전 버전의 주요 응용 프로그램 업그레이드하기 전에 데이터베이스를 검색해야 할 경우 감사자 또는 법적 순서의 요청을 충족한다면 Azure Backup Vault에 저장된 전체 백업을 사용하여 데이터베이스를 만들 수 있습니다.If you need to retrieve an old version of your database prior to a major application upgrade, satisfy a request from auditors or a legal order, you can create a database using a full backup saved in the Azure Backup Vault. 자세한 내용은 장기 보존을 참조하세요.For more information, see Long-term retention.

Azure 지역 데이터 센터 가동 중단 상태에서 다른 지역으로 데이터베이스 복구Recover a database to another region from an Azure regional data center outage

드문 경우지만 Azure 데이터 센터에서 가동 중단이 발생할 수 있습니다.Although rare, an Azure data center can have an outage. 가동 중단이 발생하면 몇 분 내지 몇 시간 동안 지속될 수 있는 업무 중단이 발생합니다.When an outage occurs, it causes a business disruption that might only last a few minutes or might last for hours.

  • 한 가지 방법은 데이터 센터 가동 중단이 끝날 때 데이터베이스가 다시 온라인 상태가 될 때까지 기다리는 것입니다.One option is to wait for your database to come back online when the data center outage is over. 이러한 방법은 데이터베이스의 오프라인 유지가 가능한 응용 프로그램에 적합합니다.This works for applications that can afford to have the database offline. 예를 들어 지속적으로 작업할 필요가 없는 개발 프로젝트 또는 무료 평가판이 있습니다.For example, a development project or free trial you don't need to work on constantly. 데이터 센터가 가동 중단되면 중단이 얼마나 지속될지 알 수 없으므로 이 옵션은 잠시 데이터베이스가 필요 없어도 되는 경우에만 적합합니다.When a data center has an outage, you do not know how long the outage might last, so this option only works if you don't need your database for a while.
  • 또 다른 방법은 활성 지역 복제를 사용 중인 경우 다른 데이터 영역으로 장애 조치하거나 지역 중복 데이터베이스 백업(지역 복원)을 사용하여 데이터베이스를 복구하는 것입니다.Another option is to either fail over to another data region if you are using active geo-replication or the recover a database using geo-redundant database backups (geo-restore). 백업에서 데이터베이스를 복구하는 데는 몇 시간이 걸리지만 장애 조치는 몇 초면 끝납니다.Failover takes only a few seconds while database recovery from backups takes hours.

작업을 수행하는 시기, 복구하는 데 걸리는 시간 및 발생하는 데이터 손실의 양은 응용 프로그램에서 비즈니스 연속성 기능을 어떤 방법으로 사용할 것인지에 따라 달라집니다.When you take action, how long it takes you to recover, and how much data loss you incur depends upon how you decide to use these business continuity features in your application. 실제로 응용 프로그램 요구 사항에 따라 데이터베이스 백업 및 활성 지역 복제를 함께 사용하도록 선택할 수 있습니다.Indeed, you may choose to use a combination of database backups and active geo-replication depending upon your application requirements. 이러한 비즈니스 지속성 기능을 사용하는 독립 실행형 데이터베이스 및 탄력적 풀에 대한 응용 프로그램 디자인 고려 사항에 대한 자세한 내용은 클라우드 재해 복구를 위해 응용 프로그램 디자인탄력적 풀 재해 복구 전략을 참조하세요.For a discussion of application design considerations for stand-alone databases and for elastic pools using these business continuity features, see Design an application for cloud disaster recovery and Elastic Pool disaster recovery strategies.

다음 섹션에서는 데이터베이스 백업 또는 활성 지역 복제를 사용하는 복구 단계를 대략적으로 설명합니다.The following sections provide an overview of the steps to recover using either database backups or active geo-replication. 계획 요구 사항, 복구 후 단계 및 가동 중단을 시뮬레이션하여 재해 복구 훈련을 수행하는 방법을 포함하는 자세한 단계는 중단 상태에서 SQL Database 복구를 참조하세요.For detailed steps including planning requirements, post recovery steps, and information about how to simulate an outage to perform a disaster recovery drill, see Recover a SQL Database from an outage.

가동 중단에 대비Prepare for an outage

어떤 비즈니스 연속성 기능을 사용하든 관계없이 다음 작업을 수행해야 합니다.Regardless of the business continuity feature you use, you must:

  • 서버 수준 방화벽 규칙, 로그인 및 master 데이터베이스 수준 사용 권한을 포함하는 대상 서버를 식별하고 준비합니다.Identify and prepare the target server, including server-level firewall rules, logins, and master database level permissions.
  • 클라이언트 및 클라이언트 응용 프로그램을 새 서버로 리디렉션하는 방법을 결정합니다.Determine how to redirect clients and client applications to the new server
  • 감사 설정 및 경고와 같은 다른 종속성을 문서화합니다.Document other dependencies, such as auditing settings and alerts

적절한 준비 없이 장애 조치나 데이터베이스 복구 이후에 응용 프로그램을 온라인 상태로 전환하면 추가 시간이 소요되고, 바쁜 업무 중 문제 해결이 필요할 수도 있어 비효율적입니다.If you do not prepare properly, bringing your applications online after a failover or a database recovery takes additional time and likely also require troubleshooting at a time of stress - a bad combination.

지역에서 복제된 보조 데이터베이스로 장애 조치Fail over to a geo-replicated secondary database

활성 지역 복제 및 자동 장애 조치 그룹(미리 보기 상태)을 복구 메커니즘으로 사용할 경우 자동 장애 조치 정책을 구성하거나 수동 장애 조치를 사용할 수 있습니다.If you are using active geo-replication and auto-failover groups (in-preview) as your recovery mechanism, you can configure an automatic failover policy or use manual failover. 일단 장애 조치가 시작되면 보조 데이터베이스는 새로운 주 데이터베이스로 승격되며, 새 트랜잭션을 기록하고 쿼리에 응답할 준비를 갖춥니다. 이때 최소한의 데이터 손실이 있을 수 있으나 아직 복제되지 않습니다.Once initiated, the failover causes the secondary to become the new primary and ready to record new transactions and respond to queries - with minimal data loss for the data not yet replicated. 장애 조치(failover) 프로세스 디자인에 대한 자세한 내용은 클라우드 재해 복구를 위해 응용 프로그램 디자인을 참조하세요.For information on designing the failover process, see Design an application for cloud disaster recovery.

참고

데이터 센터가 다시 온라인 상태가 되면 이전 주 데이터베이스는 새 주 데이터베이스에 자동으로 다시 연결되고 보조 데이터베이스가 됩니다.When the data center comes back online the old primaries automatically reconnect to the new primary and become secondary databases. 주 데이터베이스를 다시 원래 지역으로 재배치해야 할 경우 계획된 장애 조치를 수동으로 시작할 수 있습니다(장애 복구).If you need to relocate the primary back to the original region, you can initiate a planned failover manually (failback).

지역 복원 수행Perform a geo-restore

복구 메커니즘으로 지역 중복 저장소 복제와 자동화된 백업을 함께 사용하는 경우 지역 복원을 사용하여 데이터베이스 복구를 시작합니다.If you are using automated backups with geo-redundant storage replication as your recovery mechanism, initiate a database recovery using geo-restore. 일반적으로 복구는 12시간 이내에 수행됩니다. 이때 마지막으로 수행된 매시간 차등 백업의 실행 및 복제를 기준으로 최대 1시간의 데이터 손실이 있을 수 있습니다.Recovery usually takes place within 12 hours - with data loss of up to one hour determined by when the last hourly differential backup with taken and replicated. 복구가 완료될 때까지 데이터베이스는 어떤 트랜잭션도 기록할 수 없으며 쿼리에 응답할 수 없습니다.Until the recovery completes, the database is unable to record any transactions or respond to any queries. 이 경우 데이터베이스를 사용 가능한 마지막 시점으로 복원하지만 지역 보조 복제본에 대한 지정 시간 복원은 현재 지원되지 않습니다.While this restores a database to the last available point in time, restoring the geo-secondary to any point in time is not currently supported.

참고

응용 프로그램이 복구된 데이터베이스로 전환하기 전에 데이터 센터가 다시 온라인 상태가 되면 복구를 취소할 수 있습니다.If the data center comes back online before you switch your application over to the recovered database, you can cancel the recovery.

사후 장애 조치(failover)/복구 작업 수행Perform post failover / recovery tasks

복구 메커니즘에서 복구한 후에는 사용자 및 응용 프로그램이 다시 실행되기 전에 다음과 같은 추가 작업을 수행해야 합니다.After recovery from either recovery mechanism, you must perform the following additional tasks before your users and applications are back up and running:

  • 클라이언트 및 클라이언트 응용 프로그램을 새 서버 및 복원된 데이터베이스로 리디렉션Redirect clients and client applications to the new server and restored database
  • 사용자가 연결할 수 있도록 적절한 서버 수준 방화벽 규칙이 설정되어 있는지 확인합니다(또는 데이터베이스 수준 방화벽사용).Ensure appropriate server-level firewall rules are in place for users to connect (or use database-level firewalls)
  • 적절한 로그인 및 master 데이터베이스 수준 사용 권한이 설정되었는지 확인합니다(또는 포함된 사용자사용).Ensure appropriate logins and master database level permissions are in place (or use contained users)
  • 필요에 따라 감사를 구성합니다.Configure auditing, as appropriate
  • 필요에 따라 경고를 구성합니다.Configure alerts, as appropriate

최소 가동 중단으로 응용 프로그램 업그레이드Upgrade an application with minimal downtime

응용 프로그램 업그레이드와 같은 계획된 유지 관리로 인해 응용 프로그램을 오프라인 상태로 전환해야 하는 경우도 있습니다.Sometimes an application must be taken offline because of planned maintenance such as an application upgrade. 응용 프로그램 업그레이드 관리 에서는 활성 지역 복제를 사용하여 클라우드 응용 프로그램의 롤링 업그레이드를 사용하도록 설정함으로써 업그레이드 기간에 가동 중지 시간을 최소화하고 오류가 발생한 경우 복구 경로를 제공하는 방법을 설명합니다.Manage application upgrades describes how to use active geo-replication to enable rolling upgrades of your cloud application to minimize downtime during upgrades and provide a recovery path if something goes wrong.

다음 단계Next steps

독립 실행형 데이터베이스 및 탄력적 풀에 대한 응용 프로그램 디자인 고려 사항에 대한 자세한 내용은 클라우드 재해 복구를 위해 응용 프로그램 디자인탄력적 풀 재해 복구 전략을 참조하세요.For a discussion of application design considerations for stand-alone databases and for elastic pools, see Design an application for cloud disaster recovery and Elastic Pool disaster recovery strategies.