Azure SQL 데이터베이스의 자동 백업

적용 대상: Azure SQL 데이터베이스

• Azure SQL 데이터베이스
• Azure SQL Managed Instance

이 문서에서는 Azure SQL 데이터베이스의 자동화된 백업 기능을 설명합니다.

백업 설정을 변경하려면 설정 변경을 참조하세요. 백업을 복원하려면 자동화된 데이터베이스 백업을 사용하여 복구를 참조하세요.

데이터베이스 백업이란?

데이터베이스 백업은 손상이나 삭제로부터 데이터를 보호하는 데 도움이 되므로 비즈니스 연속성 및 재해 복구 전략의 필수적인 부분입니다. 이러한 백업을 사용하면 구성된 보존 기간 내의 특정 시점으로 데이터베이스를 복원할 수 있습니다. 데이터 보호 규칙에서 백업을 오랫동안(최대 10년) 사용할 수 있도록 요구하는 경우 단일 데이터베이스 및 풀링된 데이터베이스에 대해 LTR(장기 보존)을 구성할 수 있습니다.

하이퍼스케일 이외의 서비스 계층의 경우 Azure SQL 데이터베이스는 SQL Server 엔진 기술을 사용하여 데이터를 백업하고 복원합니다. 하이퍼스케일 데이터베이스는 스토리지 스냅샷을 기반으로 백업 및 복원을 사용합니다. 기존의 SQL Server 백업 기술을 사용하면 데이터베이스가 클수록 백업/복원 시간이 길어집니다. 스냅샷을 사용하면 하이퍼스케일은 데이터베이스 크기에 관계없이 즉시 백업 및 빠른 복원 기능을 제공합니다. 자세한 내용은 하이퍼스케일 백업을 참조하세요.

Backup 주기

Azure SQL 데이터베이스는 다음을 만듭니다.

• 매주 전체 백업
• 12~24시간마다 차등 백업
• 약 10분마다 트랜잭션 로그 백업.

정확한 트랜잭션 로그 백업 빈도는 컴퓨팅 크기와 데이터베이스 작업의 양에 따라 달라집니다. 사용자가 데이터베이스를 복원할 때 서비스에서는 전체, 차등, 트랜잭션 로그 백업 중 무엇을 복원해야 하는지 판단합니다.

하이퍼스케일 아키텍처는 전체, 차등 또는 로그 백업이 필요 없습니다. 자세한 내용은 하이퍼스케일 백업을 참조하세요.

백업 스토리지 중복성

스토리지 중복성 메커니즘은 계획된 이벤트 및 계획되지 않은 이벤트로부터 보호되도록 데이터의 여러 복사본을 저장합니다. 이러한 이벤트로는 일시적인 하드웨어 오류, 네트워크 또는 정전이나 대규모 자연 재해가 포함될 수 있습니다.

기본적으로 Azure SQL 데이터베이스의 새 데이터베이스는 페어링된 지역에 복제되는 지역 중복 스토리지 BLOB에 데이터를 저장합니다. 지역 중복성은 주 지역의 백업 스토리지에 영향을 주는 중단으로부터 보호하는 데 도움이 됩니다. 또한 지역 가동 중단 시 다른 지역에 데이터베이스를 복원할 수 있습니다.

Azure Portal은 일부 구성 설정을 미리할 수 있는 워크로드 환경 옵션을 제공합니다. 이러한 설정은 재정의될 수 있습니다. 이 옵션은 SQL Database 만들기 포털 페이지에만 적용됩니다.

• 개발 워크로드 환경을 선택하면 로컬 중복 스토리지를 사용하도록 백업 스토리지 중복 옵션이 설정됩니다. 로컬 중복 스토리지는 비용이 적게 들며, 영역 또는 지역에서 복제 스토리지의 중복이 필요하지 않은 사전 프로덕션 환경에 적합합니다.
• 프로덕션 워크로드 환경을 선택하면 백업 스토리지 중복성이 기본값인 지역 중복 스토리지로 설정됩니다.
• 또한 워크로드 환경 옵션은 컴퓨팅에 대한 초기 설정을 변경합니다. 이 변경 사항은 재정의할 수 있습니다. 워크로드 환경 옵션은 라이선스 또는 다른 데이터베이스 구성 설정에 그 외의 영향을 주지 않습니다.

백업이 데이터베이스가 배포된 동일한 지역 내에 유지되도록 하려면 백업 스토리지 중복성을 기본 지역 중복 스토리지에서 지역 내 데이터를 유지하는 다른 유형의 스토리지로 변경할 수 있습니다. 구성된 백업 스토리지 중복성은 STR(단기 보존) 백업과 LTR 백업 모두에 적용됩니다. 스토리지 중복성에 대한 자세한 내용은 데이터 중복성을 참조하세요.

데이터베이스를 만들 때 백업 스토리지 중복성을 구성할 수 있으며, 나중에 인스턴스 수준에서 업데이트할 수 있습니다. 기존 데이터베이스에 대한 변경 사항은 향후 백업에만 적용됩니다. 기존 데이터베이스의 백업 스토리지 중복성을 업데이트한 후 변경 내용이 적용될 때까지 최대 48시간이 걸릴 수 있습니다.

백업을 위해 다음 스토리지 중복성 중 하나를 선택할 수 있습니다.

• LRS(로컬 중복 스토리지): 주 지역의 단일 물리적 위치 내에서 백업을 동기적으로 세 번 복사합니다. LRS는 가장 저렴한 스토리지 옵션이지만, 지역 가동 중단에 대한 복원력 또는 높은 데이터 내구성을 보장해야 하는 애플리케이션에는 사용하지 않는 것이 좋습니다.

  

• ZRS(영역 중복 스토리지): 주 지역에 있는 3개의 Azure 가용성 영역에서 백업을 동기적으로 복사합니다. 현재 특정 지역에서만 사용할 수 있습니다.

  

• GRS(지역 중복 스토리지): LRS를 사용하여 주 지역의 단일 물리적 위치 내에서 백업을 동기적으로 세 번 복사합니다. 그런 다음 쌍을 이룬 보조 지역의 단일 물리적 위치에 데이터를 비동기적으로 세 번 복사합니다.

  결과는 다음과 같습니다.

  • 주 지역에 있는 세 개의 동기 복사본입니다.
  • 주 지역에서 보조 지역으로 비동기적으로 복사된 쌍을 이루는 지역에 있는 세 개의 동기 복사본입니다.

  

• GZRS(지역 영역 중복 스토리지): GZRS(지역 영역 중복 스토리지)는 ZRS(가용성 영역)에서 중복성으로 제공되는 고가용성을 GRS(지역 복제)에서 제공하는 지역 중단으로부터 보호하는 기능을 결합합니다. 주 지역의 세 Azure 가용성 영역에서 동기적으로 백업을 복사하고 쌍을 이루는 보조 지역의 단일 물리적 위치에 비동기적으로 세 번 복사합니다.

  Microsoft는 재해 복구를 위해 최대 일관성, 내구성과 가용성, 뛰어난 성능 및 복원력이 필요한 응용 프로그램에 GZRS를 사용하는 것을 권장합니다.

  결과는 다음과 같습니다.

  • 주 지역의 가용성 영역 세 개의 동기 복사본입니다.

  • 주 지역에서 보조 지역으로 비동기적으로 복사된 쌍을 이루는 지역에 있는 세 개의 동기 복사본입니다.

    다음 다이어그램은 GZRS 또는 RA-GZRS를 사용하여 데이터가 복제되는 방법을 보여 줍니다.

  

Warning

• 로컬 또는 영역 중복 스토리지를 사용하도록 데이터베이스를 업데이트하는 즉시 지역 복원이 사용되지 않습니다.
• 스토리지 중복성 다이어그램은 모두 여러 가용성 영역(여러 az)이 있는 지역을 보여줍니다. 그러나 일부 지역은 단일 가용성 영역만 제공하고 ZRS를 지원하지 않습니다.
• 하이퍼스케일 데이터베이스의 백업 스토리지 중복성은 데이터베이스를 만드는 중에만 설정할 수 있습니다. 리소스가 프로비저닝된 후에는 이 설정을 수정할 수 없습니다. 가동 중지 시간을 최소화하면서 기존 하이퍼스케일 데이터베이스의 백업 스토리지 중복성 설정을 업데이트하려면 활성 지역 복제를 사용합니다. 또는 데이터베이스 복사본을 사용해도 됩니다. 하이퍼스케일 백업 및 스토리지 중복성에서 자세히 알아봅니다.

백업 사용

다음 시나리오에서는 자동으로 생성된 백업을 사용할 수 있습니다.

• Azure Portal, Azure PowerShell, Azure CLI 또는 REST API를 사용하여 보존 기간 내의 특정 시점으로 기존 데이터베이스를 복원합니다. 이 작업은 원래 데이터베이스와 동일한 서버에 새 데이터베이스를 만들지만, 원래 데이터베이스를 덮어쓰지 않도록 다른 이름을 사용합니다.

  복원이 완료된 후에는 필요에 따라 원래 데이터베이스를 삭제하고 복원된 데이터베이스의 이름을 원래 데이터베이스 이름으로 바꿀 수 있습니다. 또는 원래 데이터베이스를 삭제하는 대신 이름을 변경한 다음, 복원된 데이터베이스의 이름을 원래 데이터베이스 이름으로 바꿀 수 있습니다.

• 삭제 시간을 포함하여 보존 기간 내에 삭제된 데이터베이스를 특정 시점으로 복원합니다. 삭제된 데이터베이스는 원래 데이터베이스를 만든 서버에만 복원할 수 있습니다. 데이터베이스를 삭제하기 전에는 서비스가 데이터 손실을 방지하기 위해 최종 트랜잭션 로그 백업을 수행합니다.

• 데이터베이스를 다른 지리적 지역으로 복원합니다. 주 지역의 데이터베이스 또는 백업에 액세스할 수 없는 경우 지역 복원을 사용하면 지리적 재해로부터 복구할 수 있습니다. 지역 복원은 Azure 지역의 기존 서버에 새 데이터베이스를 만듭니다.

  중요

  지역 복원은 지역 중복 백업 스토리지가 구성된 데이터베이스에만 사용할 수 있습니다. 현재 데이터베이스에 대해 지역 복제 백업을 사용하지 않는 경우 백업 스토리지 중복 구성을 통해 이를 변경할 수 있습니다.

• LTR 정책을 사용하여 데이터베이스를 구성한 경우 단일 또는 풀링된 데이터베이스의 특정 장기 백업에서 데이터베이스를 복원합니다. LTR을 사용하면 Azure Portal, Azure CLI 또는 Azure PowerShell에서 이전 버전의 데이터베이스를 복원하여 규정 준수 요청을 충족하거나 이전 버전의 애플리케이션을 실행할 수 있습니다. 자세한 내용은 장기 보존을 참조하세요.

Warning

데이터베이스를 복원하고 원본 백업 스토리지 중복성이 GZRS(지역 영역 중복 스토리지)로 구성된 경우 대상 데이터베이스에 대한 백업 스토리지 중복 구성이 명시적으로 지정되지 않은 경우 원본 백업 스토리지 구성이 새 데이터베이스에 상속됩니다. 여기에는 특정 시점 복원, 데이터베이스 복사, 지역 복원, 장기 백업에서 복원과 같은 모든 복원 작업이 포함됩니다. 이 작업 중에 대상 Azure 지역이 특정 백업 스토리지 중복성을 지원하지 않는 경우 적절한 오류 메시지와 함께 복원 작업이 실패합니다. 이 문제는 해당 지역에 사용 가능한 스토리지 옵션을 명시적으로 지정하여 완화할 수 있습니다.

보조 복제본에서 자동 백업

이제 자동 백업은 중요 비즈니스용 서비스 계층의 보조 복제본에서 수행됩니다. 데이터는 각 노드의 SQL Server 프로세스 간에 복제되므로 백업 서비스는 읽을 수 없는 보조 복제본에서 백업됩니다. 이 설계로 기본 복제본은 주요 워크로드 전용으로 유지되고 읽기 가능한 보조 복제본은 읽기 전용 워크로드 전용으로 유지됩니다. 중요 비즈니스용 서비스 계층의 자동 백업은 대부분 보조 복제본에서 수행됩니다. 보조 복제본에서 자동 백업할 수 없는 경우, 백업 서비스는 기본 복제본에서 백업됩니다.

보조 복제본에서 자동 백업:

• 기본적으로 사용할 수 있습니다.
• 서비스 계층 요금 이외의 추가 비용이 포함되지 않습니다.
• 중요 비즈니스용 서비스 계층의 성능과 예측 가능성이 향상됩니다.

참고 항목

• 인스턴스에 대한 기능을 사용할 수 없는 Microsoft 지원 티켓을 만듭니다.

기능 및 특징 복원

이 표에는 PITR(특정 시점 복원), 지역 복원 및 장기 보존의 기능과 특징이 요약되어 있습니다.

백업 속성	PITR	지역 복원	LTR
SQL 백업 유형	전체, 차등, 로그	지역에서 복제된 최근 PITR 백업 복사본	전체 백업만
복구 지점 목표(RPO)	컴퓨팅 크기 및 데이터베이스 작업량에 따라 10분	지역 복제에 따라 최대 1시간. 1	일주일(또는 사용자 정책).
RTO(복구 시간 목표)	일반적으로 복원에 12시간 미만이 소요되지만 크기와 작업에 따라 더 오래 걸릴 수 있습니다. 복구를 참조하세요.	일반적으로 복원에 12시간 미만이 소요되지만 크기와 작업에 따라 더 오래 걸릴 수 있습니다. 복구를 참조하세요.	일반적으로 복원에 12시간 미만이 소요되지만 크기와 작업에 따라 더 오래 걸릴 수 있습니다. 복구를 참조하세요.
보존	기본 설정값은 7일이며 1일에서 35일 사이로 구성할 수 있습니다(기본 데이터베이스는 1일에서 7일 사이로 구성 가능).	기본적으로 사용하도록 설정되어 있으며 소스와 동일합니다.2	기본적으로 사용하도록 설정되어 있지 않습니다. 최대 10년간 보존됩니다.
Azure Storage	기본적으로 지역 중복 선택적으로 영역 중복 또는 로컬 중복 스토리지를 구성할 수 있습니다.	PITR 백업 스토리지 중복이 지역 중복으로 설정된 경우에 사용할 수 있습니다. PITR 백업 스토리지가 영역 중복 또는 로컬 중복 스토리지인 경우에는 사용할 수 없습니다.	기본적으로 지역 중복 영역 중복 또는 로컬 중복 스토리지를 구성할 수 있습니다.
변경 불가능 백업 구성	지원되지 않음	지원되지 않음	지원되지 않음
동일한 지역에서 새 데이터베이스 복원	지원됨	지원됨	지원됨
다른 지역에서 새 데이터베이스 복원	지원되지 않음	모든 Azure 지역에서 지원됨	모든 Azure 지역에서 지원됨
다른 구독에서 새 데이터베이스 복원	지원되지 않음	지원되지 않음3	지원되지 않음3
Azure Portal을 통한 복원	예	예	예
PowerShell을 통한 복원	예	예	Yes
Azure CLI를 통한 복원	예	예	예

¹ 대규모 데이터베이스가 필요하고 비즈니스 연속성을 보장해야 하는 중요 비즈니스용 애플리케이션의 경우 장애 조치(failover) 그룹을 사용합니다.
² 모든 PITR 백업은 기본적으로 지역 중복 스토리지에 저장됩니다. 따라서 지역 복원은 기본적으로 사용됩니다.
³ 해결 방법은 새 서버로 복원하고 리소스 이동을 사용하여 서버를 다른 구독으로 이동하거나 교차 구독 데이터베이스 복사를 사용하는 것입니다.

백업에서 데이터베이스 복원

복원을 수행하려면 백업에서 데이터베이스 복원을 참조하세요. 다음 예시를 사용하여 백업 구성 및 복원 작업을 살펴볼 수 있습니다.

작업	Azure Portal	Azure CLI	Azure PowerShell
백업 보존 변경	SQL Database SQL Managed Instance	SQL 데이터베이스 SQL Managed Instance	SQL 데이터베이스 SQL Managed Instance
장기 백업 보존 변경	SQL 데이터베이스 SQL Managed Instance	SQL 데이터베이스 SQL Managed Instance	SQL 데이터베이스 SQL Managed Instance
지정 시간에서 데이터베이스 복원	SQL 데이터베이스 SQL Managed Instance	SQL 데이터베이스 SQL Managed Instance	SQL 데이터베이스 SQL Managed Instance
삭제된 데이터베이스 복원	SQL 데이터베이스 SQL Managed Instance	SQL 데이터베이스 SQL Managed Instance	SQL 데이터베이스 SQL Managed Instance

데이터베이스 내보내기

Azure 서비스에서 수행한 자동 백업은 직접 다운로드하거나 액세스할 수 없습니다. Azure를 통해 복원 작업에만 사용할 수 있습니다.

Azure SQL Database를 내보내는 대안이 있습니다. 다른 플랫폼에 보관하거나 이동하기 위해 데이터베이스를 내보내야 할 경우 데이터베이스 스키마 및 데이터를 BACPAC 파일로 내보낼 수 있습니다. BACPAC 파일은 메타데이터 및 데이터베이스의 데이터를 포함하는 BACPAC의 확장명을 가진 ZIP 파일입니다. BACPAC 파일은 Azure Blob Storage 또는 온-프레미스 스토리지의 로컬 스토리지에 저장할 수 있으며 나중에 Azure SQL Database, Azure SQL Managed Instance 또는 SQL Server 인스턴스로 다시 가져올 수 있습니다.

Private Link를 사용하여 Azure SQL Database를 가져오거나 내보내기 또는 Azure 서비스가 서버에 액세스하도록 허용하지 않고 Azure SQL Database를 가져오거나 내보내기 할 수 있습니다.

백업 일정 예약

새 데이터베이스가 만들어지거나 복원되는 즉시 첫 번째 전체 백업이 예약됩니다. 이 백업은 일반적으로 30분 이내에 완료되지만 데이터베이스의 크기가 큰 경우에는 더 오래 걸릴 수 있습니다. 예를 들어 복원된 데이터베이스 또는 데이터베이스 복사본은 일반적으로 새 데이터베이스보다 크기 때문에 초기 백업이 더 오래 걸릴 수 있습니다.

첫 번째 전체 백업 후에는 모든 추가 백업이 자동으로 예약되고 관리됩니다. 모든 데이터베이스 백업의 정확한 타이밍은 전반적인 시스템 워크로드를 감안하여 SQL Database 서비스에 의해 결정됩니다. 백업 작업의 일정을 변경하거나 사용하지 않도록 설정할 수 없습니다.

중요

• 새 데이터베이스, 복원된 데이터베이스 또는 복사된 데이터베이스의 경우 초기 전체 백업에 이어지는 초기 트랜잭션 로그 백업이 만들어지면 특정 시점 복원 기능을 사용할 수 있게 됩니다.
• 하이퍼스케일 데이터베이스는 초기 백업에 시간이 걸리는 다른 데이터베이스와 달리 만드는 즉시 보호됩니다. 복사 또는 복원을 통해 대량의 데이터를 사용하여 하이퍼스케일 데이터베이스를 만든 경우에도 즉시 보호됩니다. 자세한 내용은 하이퍼스케일 자동화된 백업을 검토하세요.

백업 스토리지 사용량

SQL Server 백업 및 복원 기술을 사용하여 데이터베이스를 특정 시점으로 복원하려면 중단 없는 백업 체인이 필요합니다. 해당 체인은 하나의 전체 백업, 선택적으로 하나의 차등 백업 및 하나 이상의 트랜잭션 로그 백업으로 구성됩니다.

Azure SQL 데이터베이스는 매주 한 건의 전체 백업을 예약합니다. 전체 보존 기간 내에 PITR을 제공하려면 구성된 보존 기간보다 최대 일주일이 더 긴 전체, 차등 및 트랜잭션 로그 백업을 시스템에서 추가로 저장해야 합니다.

즉, 보존 기간 중 특정 시점에 대해 보존 기간의 가장 오래된 시간보다 오래된 전체 백업이 있어야 합니다. 또한 전체 백업에서 다음 전체 백업까지 차등 및 트랜잭션 로그 백업의 중단 없는 체인이 있어야 합니다.

하이퍼스케일 데이터베이스는 다른 백업 예약 메커니즘을 사용합니다. 자세한 내용은 하이퍼스케일 백업 예약을 참조하세요.

PITR 기능을 제공하는 데 더 이상 필요 없는 백업은 자동으로 삭제됩니다. 차등 백업 및 로그 백업은 이전 전체 백업을 복원할 수 있어야 하므로 세 가지 백업 유형이 주간 세트에서 함께 제거됩니다.

TDE 암호화 데이터베이스를 포함한 모든 데이터베이스는 모든 전체 및 차등 백업은 백업 스토리지 압축 및 비용을 줄이기 위해 압축됩니다. 평균 백업 압축 비율은 3~4배입니다. 하지만 데이터의 특성과 데이터베이스에서 데이터 압축 사용 여부에 따라 낮거나 훨씬 높을 수 있습니다.

Important

TDE 암호화 데이터베이스의 경우 로그 백업 파일은 성능상의 이유로 압축되지 않습니다. TDE로 암호화되지 않은 데이터베이스에 대한 로그 백업은 압축됩니다.

Azure SQL 데이터베이스는 사용한 총 백업 스토리지를 누적 값으로 계산합니다. 이 값은 1시간마다 Azure 청구 파이프라인에 보고됩니다. 파이프라인은 매시간 사용량을 집계하여 각 월말에 사용량을 계산하는 데 사용됩니다. 데이터베이스가 삭제된 후 백업이 만료되어 삭제되면 사용량이 감소합니다. 모든 백업이 삭제되고 PITR이 더 이상 가능하지 않으면 청구가 중지됩니다.

중요

데이터베이스가 삭제되어도 PITR을 제공하기 위해 데이터베이스 백업이 유지됩니다. 데이터베이스를 삭제하고 다시 만들면 스토리지 및 컴퓨팅 비용이 절감되지만 백업 스토리지 비용은 증가할 수 있습니다. 그 이유는 서비스가 삭제될 때마다 삭제된 각 데이터베이스에 대한 백업을 유지하기 때문입니다.

사용량 모니터링

Azure SQL 데이터베이스에 있는 vCore 데이터베이스의 경우 각 백업 유형(전체, 차등 및 로그)에서 사용하는 스토리지는 데이터베이스 모니터링 창에 별도의 메트릭으로 보고됩니다. 다음 스크린샷은 단일 데이터베이스에 대한 백업 스토리지 사용량을 모니터링하는 방법을 보여줍니다.

하이퍼스케일에서 사용량을 모니터링하는 방법에 대한 지침은 하이퍼스케일 백업 사용량 모니터링을 참조하세요.

백업 스토리지 사용량 미세 조정

데이터베이스의 최대 데이터 크기까지는 백업 스토리지 사용 요금이 부과되지 않습니다. 백업 스토리지 초과 사용량은 개별 데이터베이스의 워크로드 및 최대 크기에 따라 달라집니다. 백업 스토리지 사용량을 줄이기 위해 다음과 같은 몇 가지 튜닝 기법을 고려합니다.

• 백업 보존 기간을 사용자 요구에 따라 최소 기간으로 줄입니다.
• 인덱스 다시 빌드와 같은 대량 쓰기 작업은 필요 이상으로 자주 수행하지 않는 것이 좋습니다.
• 대량 데이터 로드 작업의 경우에는 클러스터형 columnstore 인덱스를 사용하고 관련 모범 사례를 따르는 것이 좋습니다. 또한 비클러스터형 인덱스 수를 줄이는 방법도 고려해 보세요.
• 범용 서비스 계층에서 프로비전된 데이터 스토리지는 백업 스토리지의 가격보다 저렴합니다. 초과 백업 스토리지 비용이 지속적으로 많이 발생하는 경우 데이터 스토리지를 늘려서 백업 스토리지를 절약할 수 있습니다.
• 임시 결과 또는 임시 데이터를 저장하기 위해 애플리케이션 논리에서 영구 테이블 대신 tempdb를 사용합니다.
• 되도록이면 로컬 중복 백업 스토리지를 사용합니다(예: 개발/테스트 환경).

백업 보존

Azure SQL 데이터베이스는 백업의 단기 및 장기 보존을 모두 제공합니다. 단기 보존은 데이터베이스의 보존 기간 내에 PITR을 허용합니다. 장기 보존은 다양한 규정 준수 요구 사항의 백업을 제공합니다.

단기 보존

모든 새 데이터베이스, 복원 및 복사된 데이터베이스에 대해 Azure SQL 데이터베이스는 기본적으로 지난 7일 이내에 PITR을 허용하기에 충분한 백업을 유지합니다. 서비스는 정규 전체, 차등 및 로그 백업을 수행하여 데이터베이스에 대해 정의된 보존 기간 내의 특정 시점으로 데이터베이스를 복원할 수 있도록 합니다.

차등 백업은 12시간 안에 한 번 또는 24시간에 한 번씩 수행되도록 구성할 수 있습니다. 24시간 차등 백업 빈도는 12시간 빈도에 비해 데이터베이스를 복원하는 데 필요한 시간이 길어질 수 있습니다. vCore 모델에서 차등 백업의 기본 빈도는 12시간에 한 번입니다. DTU 모델에서 기본 빈도는 24시간에 한 번입니다.

데이터베이스를 만들 때 STR에 대한 백업 스토리지 중복성 옵션을 지정한 다음, 나중에 변경할 수 있습니다. 데이터베이스를 만든 후 백업 중복성 옵션을 변경하면 새 백업에 새 중복성 옵션이 사용됩니다. 이전 STR 중복성 옵션으로 만든 백업 복사본은 이동되거나 복사되지 않습니다. 보존 기간이 만료될 때까지 원래 스토리지 계정에 남아 있으며 이 기간은 1~35일이 될 수 있습니다.

1~7일 사이로 구성할 수 있는 기본 데이터베이스를 제외한 각 활성 데이터베이스는 백업 보존 기간을 1~35일 사이로 변경할 수 있습니다. 백업 스토리지 사용량에 설명된 것처럼 PITR을 사용하기 위해 저장된 백업이 보존 기간보다 오래되었을 수 있습니다. 백업을 최대 단기 보존 기간인 35일보다 오래 유지해야 하는 경우 장기 보존을 사용하면 됩니다.

데이터베이스를 삭제하면 시스템에서는 해당 보존 기간을 사용하여 온라인 데이터베이스와 동일한 방식으로 백업을 유지합니다. 삭제된 데이터베이스의 백업 보존 기간은 변경할 수 없습니다.

중요

서버를 삭제하면 해당 서버에 속한 모든 데이터베이스도 삭제되고 복구할 수 없습니다. 삭제된 서버는 복원할 수 없습니다. 그러나 데이터베이스에 대한 장기 보존을 구성한 경우 LTR 백업은 삭제되지 않습니다. 그런 다음, 이러한 백업을 사용하여 LTR 백업이 수행된 특정 시점으로 동일한 구독의 다른 서버로 데이터베이스를 복원할 수 있습니다. 자세한 내용은 장기 백업 복원을 검토하세요.

장기 보존

SQL Database의 경우 Azure Blob Storage에서 전체 LTR 백업을 최대 10년으로 구성할 수 있습니다. LTR 정책을 구성한 후에는 매주 전체 백업이 다른 스토리지 컨테이너에 자동으로 복사됩니다.

다양한 규정 준수 요구 사항을 충족하기 위해 주간, 월간 및/또는 연간 전체 백업에 대해 다른 보존 기간을 선택할 수 있습니다. 빈도는 정책에 따라 달라집니다. 예를 들어 W=0, M=1을 설정하면 매월 LTR 복사본이 만들어집니다. LTR에 대한 자세한 내용은 장기 보존을 참조하세요.

기존 데이터베이스의 백업 스토리지 중복성을 업데이트하면 기존 백업이 아닌 나중에 수행된 후속 백업에만 변경 내용이 적용됩니다. 데이터베이스의 모든 기존 LTR 백업은 계속해서 기존 스토리지 Blob에 남아 있습니다. 구성된 백업 스토리지 중복성에 따라 새 백업이 복제됩니다.

스토리지 사용량은 선택한 LTR 백업 빈도 및 보존 기간에 따라 달라집니다. LTR 가격 계산기를 사용하여 LTR 스토리지 비용을 추정할 수 있습니다.

LTR 백업에서 하이퍼스케일 데이터베이스를 복원할 때, 읽기 확장 속성은 비활성화 됩니다. 복원한 데이터베이스의 읽기 확장 속성을 활성화하려면 해당 데이터베이스를 만든 다음 업데이트 하세요. LTR 백업으로 복원할 경우 대상 서비스 수준 목표를 지정해야 합니다.

다른 서비스 계층에서 만들거나 마이그레이션한 하이퍼스케일 데이터베이스에 대해 장기 보존을 사용하도록 설정할 수 있습니다. 아직 지원되지 않는 하이퍼스케일 데이터베이스에 대해 LTR을 사용하도록 설정하려고 하면 다음과 같은 오류가 발생합니다. "이 데이터베이스의 장기 백업 보존을 사용하도록 설정하는 동안 오류가 발생했습니다. 장기 백업 보존을 사용하도록 설정하려면 Microsoft 지원에 문의하세요." 이 경우 Microsoft 지원에 문의하고 이를 해결하기 위해 지원 티켓을 만드세요.

백업 스토리지 비용

백업 스토리지 가격은 구매 모델(DTU 또는 vCore), 선택한 백업 스토리지 중복성 옵션 및 지역에 따라 달라집니다. 백업 스토리지는 매월 사용되는 기가바이트를 기준으로 모든 백업에 대해 같은 요금으로 청구됩니다.

백업 스토리지 중복성은 다음과 같은 방식으로 백업 비용에 영향을 줍니다.

• Locally redundant price = published price
• Zone-redundant price = published price x 1.25
• Geo-redundant price = published price x 2

가격 책정에 대한 자세한 내용은 Azure SQL 데이터베이스 가격 책정 페이지를 참조하세요.

참고

Azure 청구서에는 전체 백업 스토리지 사용량이 아닌 백업 스토리지 초과 사용량만 표시됩니다. 예를 들어 데이터 스토리지 4TB를 프로비저닝할 경우 무료 백업 스토리지 공간은 4TB입니다. 총 5.8TB의 백업 스토리지 공간을 사용하는 경우, 사용한 초과 백업 스토리지에 대해서만 요금이 청구되므로 Azure 청구서에는 1.8TB만 표시됩니다.

DTU 모델

DTU 모델에서는 데이터베이스 및 Elastic Pool의 7일 이상의 기본 보존을 사용하는 경우 PITR 데이터베이스 스토리지에 대한 추가 요금이 부과되지 않습니다. PITR 백업 스토리지 비용은 데이터베이스 또는 풀 비용에 포함되어 있습니다.

Important

DTU 모델에서 데이터베이스 및 Elastic Pool은 LTR 백업이 사용하는 실제 스토리지에 따라 LTR 백업 스토리지에 대한 요금이 청구됩니다.

vCore 모델

Azure SQL 데이터베이스는 청구 가능한 총 백업 스토리지를 모든 백업 파일의 누적 값으로 계산합니다. 이 값은 1시간마다 Azure 청구 파이프라인에 보고됩니다. 파이프라인에서는 이 시간당 사용량을 집계하여 매월 말에 백업 스토리지 사용량을 산정합니다.

데이터베이스가 삭제되면 오래된 백업이 만료되어 삭제되므로 백업 스토리지 사용량이 점차 감소합니다. 차등 백업 및 로그 백업은 이전 전체 백업을 복원할 수 있어야 하므로 세 가지 백업 유형이 주간 세트에서 함께 제거됩니다. 모든 백업이 삭제되면 청구가 중지됩니다.

백업 스토리지 비용은 하이퍼스케일 데이터베이스에 대해 다르게 계산됩니다. 자세한 내용은 하이퍼스케일 백업 스토리지 비용을 참조하세요.

단일 데이터베이스의 경우 데이터베이스의 최대 데이터 스토리지 크기의 100%에 해당하는 백업 스토리지 용량이 추가 요금 없이 제공됩니다. 다음 수식은 청구 가능한 총 백업 스토리지 사용량을 계산하는 데 사용됩니다.

Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage

탄력적 풀의 경우 풀 스토리에 대한 최대 데이터 스토리지 크기의 100%에 해당하는 백업 스토리지 용량이 추가 요금 없이 제공됩니다. 풀링된 데이터베이스의 경우 청구 가능한 총 백업 스토리지 크기는 풀 수준에서 집계되며 다음과 같이 계산됩니다.

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

청구 가능한 총 백업 스토리지(있는 경우)는 사용한 백업 스토리지 중복성 비율에 따라 매월 기가바이트 단위로 청구됩니다. 이 백업 스토리지 사용량은 개별 데이터베이스, 탄력적 풀 및 관리형 인스턴스의 워크로드 및 크기에 따라 달라집니다. 백업의 크기는 변경된 데이터 양에 비례하므로 자주 수정되는 데이터베이스는 차등 및 로그 백업의 크기가 큽니다. 따라서 이러한 데이터베이스는 백업 비용이 더 많이 듭니다.

간단한 예로, 데이터베이스의 누적 백업 스토리지가 744GB이고 데이터베이스가 완전히 유휴 상태이기 때문에 이 양이 한 달 내내 그대로 유지된다고 가정하겠습니다. 이 누적 스토리지 사용량을 시간당 사용량으로 변환하려면 744.0(매월 31일 X 매일 24시간)로 나눕니다. SQL Database는 데이터베이스가 시간당 1GB의 일정한 속도로 PITR 백업을 사용했다고 Azure 청구 파이프라인에 보고합니다. Azure 청구는 이 사용량을 집계하고 전체 월에 대해 744GB의 사용량을 표시합니다. 비용은 해당 지역의 월 기가바이트 요금을 기준으로 합니다.

다음은 또 다른 예시입니다. 동일한 유휴 데이터베이스의 보존 기간이 월 중간에 7일에서 14일로 증가했다고 가정해보겠습니다. 이와 같은 증가로 인해 총 백업 스토리지가 2배로 늘어나서 1,488GB가 됩니다. SQL Database는 1~372시간(해당 월의 앞쪽 절반)의 사용량이 1GB라고 보고합니다. 시간 373~744(해당 월의 뒤쪽 절반)의 사용량은 2GB라고 보고합니다. 이 사용량은 최종 청구 1,116GB/월로 집계됩니다.

실제 백업 청구 시나리오는 더 복잡합니다. 데이터베이스의 변동률은 워크로드에 따라 다르고 시간이 지나면서 가변적이기 때문에 각 차등 및 로그 백업의 크기도 달라집니다. 백업 스토리지의 시간당 사용량은 그에 따라 변동됩니다.

각 차등 백업에는 마지막 전체 백업 이후 데이터베이스의 모든 변경 내용도 포함됩니다. 따라서 모든 차등 백업의 총 크기는 일주일 동안 점진적으로 증가합니다. 그런 다음, 이전 세트의 전체, 차등 및 로그 백업이 오래되면 급격하게 감소합니다.

예를 들어 인덱스 다시 빌드와 같은 많은 쓰기 작업이 전체 백업이 완료된 직후에 실행된다고 가정합니다. 그러면 인덱스 다시 빌드에서 수행하는 수정 내용이 다음에 포함됩니다.

• 다시 빌드 기간 동안 수행되는 트랜잭션 로그 백업에서
• 다음 차등 백업에서
• 다음 전체 백업이 발생할 때까지 수행되는 모든 차등 백업에서

대규모 데이터베이스의 마지막 시나리오에서는 차등 백업이 지나치게 커지는 경우 서비스에서 최적화를 통해 차등 백업 대신 전체 백업을 만듭니다. 이렇게 하면 다음 전체 백업이 수행될 때까지 모든 차등 백업의 크기가 줄어듭니다.

사용량 모니터링에 설명된 것처럼 시간에 따른 각 백업 유형(전체, 차등, 트랜잭션 로그)의 총 백업 스토리지 사용량을 모니터링할 수 있습니다.

비용 모니터링

백업 스토리지 비용을 이해하려면 Azure Portal의 비용 관리 + 청구로 이동합니다. Cost Management를 선택한 다음, 비용 분석을 선택합니다. 범위에 대해 원하는 구독을 선택한 후, 다음과 같이 관심 있는 기간 및 서비스를 필터링합니다.

1. 서비스 이름에 대한 필터를 추가합니다.

2. 드롭다운 목록에서 단일 데이터베이스 또는 탄력적 데이터베이스 풀에 대해 sql database를 선택합니다.

3. 미터 하위 범주에 대한 다른 필터를 추가합니다.

4. PITR 백업 비용을 모니터링하려면 드롭다운 목록에서 단일 데이터베이스 또는 탄력적 데이터베이스 풀에 대해 단일/탄력적 풀 pitr 백업 스토리지를 선택합니다. 백업 스토리지 사용량이 있는 경우에만 미터가 표시됩니다.

   LTR 백업 비용을 모니터링하려면 드롭다운 목록에서 단일 데이터베이스 또는 탄력적 데이터베이스 풀에 대해 ltr 백업 스토리지를 선택합니다. 백업 스토리지 사용량이 있는 경우에만 미터가 표시됩니다.

스토리지 및 컴퓨팅 하위 범주에도 관심이 갈지 모르지만, 이 둘은 백업 스토리지 비용과는 관련이 없습니다.

중요

현재 사용 중인 카운터의 경우에만 미터가 표시됩니다. 카운터를 사용할 수 없는 경우 범주가 현재 사용되고 있지 않을 수 있습니다. 예를 들어 스토리지를 사용하지 않는 리소스의 스토리지 카운터는 표시되지 않습니다. PITR 또는 LTR 백업 스토리지 사용량이 없는 경우에는 이러한 미터가 표시되지 않습니다.

자세한 내용은 Azure SQL 데이터베이스 비용 관리를 참조하세요.

암호화된 백업

데이터베이스가 TDE를 사용하여 암호화된 경우 LTR 백업을 포함한 백업이 미사용 시 자동으로 암호화됩니다. Azure SQL의 모든 새 데이터베이스는 기본적으로 TDE를 사용하도록 구성됩니다. TDE에 대한 자세한 내용은 SQL Database를 사용한 투명한 데이터 암호화를 참조하세요.

백업 무결성

주기적으로 Azure SQL 엔지니어링 팀은 자동화된 데이터베이스 백업의 복원을 자동으로 테스트합니다. 지정 시간 복원 시 데이터베이스도 DBCC CHECKDB 무결성 검사를 받습니다.

무결성 검사 중에 문제가 발견되면 해당 경고를 엔지니어링 팀에 문의하세요. 자세한 내용은 SQL Database의 데이터 무결성을 참조하세요.

모든 데이터베이스 백업은 추가 백업 무결성을 제공하는 CHECKSUM 옵션을 통해 수행됩니다.

규정 준수

DTU 기반 서비스 계층에서 vCore 기반 서비스 계층으로 데이터베이스를 마이그레이션하는 경우 애플리케이션의 데이터 복구 정책이 손상되지 않도록 PITR 보존이 유지됩니다. 기본 보존 기간이 규정 준수 요구 사항을 충족하지 못하는 경우 PITR 보존 기간을 변경할 수 있습니다. 자세한 내용은 PITR 백업 보존 기간 변경을 참조하세요.

참고

자동 백업 설정 변경 문서에서는 디바이스 또는 서비스에서 개인 데이터를 삭제하는 방법에 대한 단계를 제공하며 GDPR에 따른 의무를 지원하는 데 사용할 수 있습니다. GDPR에 대한 일반정인 정보는 Microsoft Trust Center의 GDPR 섹션 및 Service Trust 포털의 GDPR 섹션을 참조하세요.

Azure Policy를 사용하여 백업 스토리지 중복성 적용

모든 데이터를 단일 Azure 지역에 유지해야 하는 데이터 보존 요구 사항이 있는 경우 Azure Policy를 사용하여 SQL 데이터베이스에 영역 중복 또는 로컬 중복 백업을 적용하면 됩니다.

Azure Policy는 Azure 리소스에 규칙을 적용하는 정책을 만들고, 할당하고, 관리하는 데 사용할 수 있는 서비스입니다. Azure Policy는 해당 리소스가 회사 표준 및 서비스 수준 계약을 준수하도록 유지하는 데 도움이 됩니다. 자세한 내용은 Azure Policy 개요를 참조하세요.

기본 제공 백업 스토리지 중복성 정책

조직 수준에서 데이터 보존 요구 사항을 적용하려면 Azure Portal 또는 Azure PowerShell을 사용하여 구독에 정책을 할당할 수 있습니다.

예를 들어 "Azure SQL DB를 GRS 백업에 사용하지 않습니다."라는 정책에 따라 기본 스토리지를 전역 중복 스토리지로 사용하여 데이터베이스를 만들 수 없으며 사용자는 "데이터베이스를 만들거나 업데이트하는 동안 백업 스토리지 계정 유형을 'Standard_RAGRS'으로 구성하지 못했습니다."라는 오류 메시지를 받는 동시에 GRS를 사용할 수 없습니다.

SQL Database의 기본 제공 정책 정의 전체 목록은 정책 참조를 검토하세요.

중요

T-SQL을 통해 데이터베이스를 만들 때에는 Azure 정책이 적용되지 않습니다. T-SQL을 사용하여 데이터베이스를 만들 때 데이터 보존을 지정하려면 CREATE DATABASE 문에서 BACKUP_STORAGE_REDUNDANCY 매개 변수의 입력으로 LOCAL 또는 ZONE을 사용합니다.

관련 콘텐츠

• 다른 SQL Database 비즈니스 연속성 솔루션에 대해 알아보려면 비즈니스 연속성 개요를 참조하세요.
• 백업 설정을 변경하려면 설정 변경을 참조하세요.
• 백업을 복원하려면 백업을 사용하여 복구 또는 PowerShell을 사용하여 특정 시점으로 데이터베이스 복원을 참조하세요.
• Azure Blob에서 자동화된 백업의 장기 보존을 구성, 관리 및 복원하는 방법에 대한 내용은 장기 백업 보존 관리를 참조하세요.
• Azure SQL Managed Instance에 대한 내용은 SQL Managed Instance의 자동화된 백업을 참조하세요.