Azure SQL Managed Instance의 자동화된 백업
적용 대상: 
Azure SQL Managed Instance
이 문서에서는 Azure SQL Managed Instance의 자동화된 백업 기능을 설명합니다.
백업 설정을 변경하려면 설정 변경을 참조하세요. 백업을 복원하려면 자동화된 데이터베이스 백업을 사용하여 복구를 참조하세요.
자동화된 데이터베이스 백업이란 무엇인가요?
데이터베이스 백업은 손상이나 삭제로부터 데이터를 보호하는 데 도움이 되므로 비즈니스 연속성 및 재해 복구 전략의 필수적인 부분입니다. Azure SQL Managed Instance를 사용하면 SQL Server 데이터베이스 엔진 백업이 Microsoft에서 자동으로 관리되고 Microsoft에서 관리하는 Azure Storage 계정에 저장됩니다.
이러한 백업을 사용하면 구성된 보존 기간(최대 35일) 내 특정 시점으로 데이터베이스를 복원할 수 있습니다. 그러나 데이터 보호 규칙에서 백업을 오랫동안(최대 10년) 사용할 수 있도록 요구하는 경우 데이터베이스당 LTR(장기 보존) 정책을 구성할 수 있습니다.
Backup 주기
Azure SQL Managed Instance는 다음을 만듭니다.
- 매주 전체 백업
- 12시간마다 차등 백업.
- 최대 10분마다 트랜잭션 로그 백업.
트랜잭션 로그 백업의 빈도는 컴퓨팅 크기와 데이터베이스 작업의 양에 따라 달라집니다. 트랜잭션 로그는 약 10분마다 수행되지만 다를 수 있습니다. 데이터베이스를 복원할 때 서비스에서는 각각 순서에 따라 전체, 차등, 트랜잭션 로그 백업 중 무엇을 복원해야 하는지 판단합니다.
주의
자동 전체 백업은 Microsoft에서 결정한 일정에 따라 일주일에 한 번 시작됩니다. 사용자가 시작한 백업은 자동 전체 백업보다 우선 순위가 있으므로 장기 실행 복사 전용 백업은 다음 자동 전체 백업의 타이밍에 영향을 줄 수 있습니다.
백업 스토리지 중복성
기본적으로 Azure SQL Managed Instance는 쌍으로 연결된 지역에 복제되는 지역 중복 스토리지 BLOB에 백업을 저장합니다. 지역 중복성은 주 지역의 백업 스토리지에 영향을 주는 중단으로부터 보호하는 데 도움이 됩니다. 또한 재해 발생 시 인스턴스를 다른 지역으로 복원할 수 있습니다.
스토리지 중복성 메커니즘은 계획된 이벤트 및 계획되지 않은 이벤트로부터 보호되도록 데이터의 여러 복사본을 저장합니다. 이러한 이벤트로는 일시적인 하드웨어 오류, 네트워크 또는 정전이나 대규모 자연 재해가 포함될 수 있습니다.
백업이 데이터베이스가 배포된 동일한 지역 내에 유지되도록 하려면 백업 스토리지 중복성을 기본 지역 중복 스토리지에서 지역 내 데이터를 유지하는 다른 유형의 스토리지로 변경할 수 있습니다. 스토리지 중복성에 대한 자세한 내용은 데이터 중복성을 참조하세요.
인스턴스를 만들 때 백업 스토리지 중복성을 구성할 수 있으며 나중에 인스턴스 수준에서 업데이트할 수 있습니다. 기존 인스턴스에 대한 변경 사항은 향후 백업에만 적용됩니다. 기존 인스턴스의 백업 스토리지 중복성을 업데이트한 후 변경 내용을 적용하는 데 최대 24시간이 걸릴 수 있습니다. 백업 스토리지 중복성에 대한 변경 내용은 단기 백업에만 적용됩니다. 장기 보존 정책은 정책을 만들 때 단기 백업의 중복성 옵션을 상속합니다. 단기 백업에 대한 중복성 옵션이 나중에 변경되더라도 장기 백업에 대해서는 중복성 옵션이 유지됩니다.
참고 항목
백업 중복성 변경은 장애 조치(failover)를 시작하는 업데이트 관리 작업입니다.
백업을 위해 다음 스토리지 중복성 중 하나를 선택할 수 있습니다.
LRS(로컬 중복 저장소): 주 지역의 단일 물리적 위치 내에서 백업을 동기적으로 세 번 복사합니다. LRS는 가장 저렴한 복제 옵션이지만 고가용성이나 높은 내구성이 필요한 애플리케이션에는 권장되지 않습니다.
ZRS(영역 중복 스토리지): 주 지역에 있는 3개의 Azure 가용성 영역에서 백업을 동기적으로 복사합니다. 현재 특정 지역에서 사용할 수 있습니다.
GRS(지역 중복 스토리지): LRS를 사용하여 주 지역의 단일 물리적 위치 내에서 백업을 동기적으로 세 번 복사합니다. 그런 다음 쌍을 이룬 보조 지역의 단일 물리적 위치에 데이터를 비동기적으로 세 번 복사합니다.
결과는 다음과 같습니다.
- 단일 가용성 영역 내 주 지역에 있는 세 개의 동기 복사본.
- 주 지역에서 보조 지역으로 비동기적으로 복사된, 단일 가용성 영역 내 쌍을 이루는 지역에 있는 세 개의 동기화된 복사본.
GZRS(지역 영역 중복 스토리지): 가용성 영역 전체의 중복성으로 제공되는 고가용성과 지역에서 복제를 통해 제공되는 지역 중단 방지를 결합합니다. GZRS 계정의 데이터는 주 지역에 있는 3개의 Azure 가용성 영역에 복사됩니다. 또한 데이터는 지역 재해로부터 보호하기 위해 보조 지리적 지역으로 복제됩니다. 해당 지역에는 주 지역에서 보조 지역으로 비동기적으로 복사된, 단일 가용성 영역 내 세 개의 동기화된 복사본도 있습니다.
경고
백업 사용
백업을 사용하여 다음을 수행할 수 있습니다.
Azure Portal, Azure PowerShell, Azure CLI 또는 REST API를 사용하여 보존 기간 내에 과거의 특정 시점으로 기존 데이터베이스를 복원합니다. 이 작업은 원본 데이터베이스와 동일한 인스턴스 또는 동일한 구독 및 지역의 다른 인스턴스에 새 데이터베이스를 만듭니다. 원본 데이터베이스를 덮어쓰지 않도록 다른 이름을 사용합니다. Azure Portal 사용하여 특정 시점 데이터베이스 백업을 원본 인스턴스와 다른 구독의 인스턴스로 복원할 수도 있습니다.
복원이 완료되면 원본 데이터베이스를 삭제할 수 있습니다. 또는 원본 데이터베이스의 이름 바꾸기를 수행한 다음, 복원된 데이터베이스의 이름을 원본 데이터베이스 이름으로 바꿀 수 있습니다.
삭제 시간을 포함하여 보존 기간 내에 삭제된 데이터베이스를 특정 시점으로 복원합니다. 삭제된 데이터베이스를 백업이 수행된 관리되는 인스턴스 또는 원본 인스턴스에 대한 동일한 구독의 다른 인스턴스 또는 다른 구독의 인스턴스로 복원할 수 있습니다. 데이터베이스를 삭제하기 전에 서비스에서는 데이터 손실을 방지하기 위한 최종 트랜잭션 로그 백업이 수행됩니다.
데이터베이스를 다른 지리적 지역으로 복원합니다. 주 지역의 서버와 데이터베이스에 액세스할 수 없는 경우 지역 복원을 사용하면 지리적 재해로부터 데이터베이스를 복구할 수 있습니다. 지역 복원은 Azure 지역의 기존 관리되는 인스턴스에 새 데이터베이스를 만듭니다.
중요
지역 복원은 지역 중복 백업 스토리지가 구성된 데이터베이스에만 사용할 수 있습니다. 현재 데이터베이스에 대해 지역 복제 백업을 사용하지 않는 경우 백업 스토리지 중복 구성을 통해 이를 변경할 수 있습니다.
데이터베이스에 구성된 LTR 정책이 있는 경우 데이터베이스의 장기 백업에서 데이터베이스를 복원합니다. LTR을 사용하면 Azure Portal, Azure CLI 또는 Azure PowerShell에서 이전 버전의 데이터베이스를 복원하여 규정 준수 요청을 충족하거나 이전 버전의 애플리케이션을 실행할 수 있습니다. 자세한 내용은 장기 보존 개요 페이지를 검토하세요.
기능 및 특징 복원
이 표에는 PITR(특정 시점 복원), 지역 복원 및 장기 보존의 기능과 특징이 요약되어 있습니다.
| 백업 속성 | PITR | 지역 복원 | LTR |
|---|---|---|---|
| SQL 백업 유형 | 전체, 차등 및 트랜잭션 로그 백업. | PITR 백업의 복제된 복사본 | 전체 백업만. |
| 복구 지점 목표(RPO) | 컴퓨팅 크기 및 데이터베이스 활동 크기에 따라 약 10분. | 지역 복제에 따라 최대 1시간. 1 | 일주일(또는 사용자 정책). |
| RTO(복구 시간 목표) | 일반적으로 복원에 12시간 미만이 소요되지만 크기와 작업에 따라 더 오래 걸릴 수 있습니다. 복구를 참조하세요. | 일반적으로 복원에 12시간 미만이 소요되지만 크기와 작업에 따라 더 오래 걸릴 수 있습니다. 복구를 참조하세요. | 일반적으로 복원에 12시간 미만이 소요되지만 크기와 작업에 따라 더 오래 걸릴 수 있습니다. 복구를 참조하세요. |
| 보존 | 1~35일 | 기본적으로 사용, 소스와 동일. 2 | 기본적으로 사용하도록 설정되어 있지 않습니다. 최대 10년간 보존됩니다. |
| Azure Storage | 기본적으로 지역 중복 선택적으로 영역 중복 또는 로컬 중복 스토리지를 구성할 수 있습니다. | PITR 백업 스토리지 중복이 지역 중복으로 설정된 경우에 사용할 수 있습니다. PITR 백업 스토리지가 영역 중복 또는 로컬 중복 스토리지인 경우에는 사용할 수 없습니다. | 기본적으로 지역 중복 영역 중복 또는 로컬 중복 스토리지를 구성할 수 있습니다. |
| 변경 불가능 백업 구성 | 지원되지 않음 | 지원되지 않음 | 지원되지 않음 |
| 업데이트 정책3 | 일치하거나 업그레이드해야 함 | 일치하거나 업그레이드해야 함 | 일치하거나 업그레이드해야 함 |
| 동일한 지역에서 새 데이터베이스 복원 | 지원됨 | 지원됨 | 지원됨 |
| 다른 지역에서 새 데이터베이스 복원 | 지원되지 않음 | 모든 Azure 지역에서 지원됨 | 모든 Azure 지역에서 지원됨 |
| 다른 구독에서 새 데이터베이스 복원 | 지원 여부 | 지원되지 않음 4 | 지원되지 않음 4 |
| Azure Portal을 통한 복원 | 예 | 예 | 예 |
| PowerShell을 통한 복원 | 예 | 예 | Yes |
| Azure CLI를 통한 복원 | 예 | 예 | 예 |
1대규모 데이터베이스가 필요하고 비즈니스 연속성을 보장해야 하는 업무상 중요한 애플리케이션의 경우 장애 조치(failover) 그룹을 사용합니다.
2 모든 PITR 백업은 기본적으로 지역 중복 스토리지에 저장됩니다. 따라서 지역 복원은 기본값으로 사용됩니다.
3 SQL Server 2022 업데이트 정책으로 구성된 인스턴스에서 가져온 데이터베이스 백업을 SQL Server 2022 또는 항상 최신 업데이트 정책으로 구성된 인스턴스로 복원할 수 있습니다. 항상 최신 업데이트 정책으로 구성된 인스턴스에서 가져온 데이터베이스 백업을 항상 최신 업데이트 정책으로 구성된 인스턴스로 복원할 수도 있습니다.
4 해결 방법은 새 서버로 복원하고 리소스 이동을 사용하여 서버를 다른 구독으로 이동하는 것입니다.
백업에서 데이터베이스 복원
복원을 수행하려면 백업에서 데이터베이스 복원을 참조하세요. 다음 예제를 사용하여 백업 구성 및 복원 작업을 시도해 볼 수 있습니다.
| 작업 | Azure Portal | Azure CLI | Azure PowerShell |
|---|---|---|---|
| 백업 보존 변경 | SQL Database / SQL Managed Instance | SQL Database / SQL Managed Instance | SQL Database / SQL Managed Instance |
| 장기 백업 보존 변경 | SQL Database / SQL Managed Instance | SQL Database / SQL Managed Instance | SQL Database / SQL Managed Instance |
| 지정 시간에서 데이터베이스 복원 | SQL Database / SQL Managed Instance | SQL Database / SQL Managed Instance | SQL Database / SQL Managed Instance |
| 삭제된 데이터베이스 복원 | SQL Database / SQL Managed Instance | SQL Database / SQL Managed Instance | SQL Database / SQL Managed Instance |
| Azure Blob Storage에서 데이터베이스 복원 | SQL Managed Instance |
자동 백업 일정
Azure SQL Managed Instance는 전체, 차등 및 트랜잭션 로그 백업을 생성하여 백업을 자동으로 관리합니다. 이 프로세스는 내부 일정에 따라 관리됩니다.
초기 백업:
새 데이터베이스: 새 데이터베이스를 생성 또는 복원하거나 ㅂ개업 중복이 변경된 직후에 첫 번째 전체 백업이 시작됩니다. 이 백업은 일반적으로 30분 이내에 완료되지만 데이터베이스가 큰 경우 더 오래 걸릴 수 있습니다.
복원된 데이터베이스: 복원된 데이터베이스에 대한 초기 백업 기간은 데이터베이스 크기에 따라 다릅니다. 종종 더 커지는 복원된 데이터베이스 또는 데이터베이스 복사본의 경우 초기 백업에 더 많은 시간이 필요할 수 있습니다.
Important
새 데이터베이스에 대한 첫 번째 전체 백업은 다른 데이터베이스 백업보다 우선하므로 첫 번째 전체 백업 기간 동안 수행되는 첫 번째 백업입니다. 전체 백업 창이 이미 활성화되어 있고 다른 데이터베이스가 백업되는 경우 새 데이터베이스에 대한 첫 번째 전체 백업은 다른 데이터베이스의 전체 백업이 완료된 직후에 수행됩니다.
예약된 전체 백업
- 주별 일정: 시스템은 전체 인스턴스에 대해 매주 전체 백업 기간을 설정합니다.
- 전체 백업 기간: 전체 백업이 수행될 때 지정된 기간입니다. 시스템은 이 기간 내 전체 백업을 완료하는 것을 목표로 하지만, 필요한 경우 백업이 완료될 때까지 예약된 시간 이후에도 계속될 수 있습니다.
- 적응형 예약: 백업 알고리즘은 CPU 사용량 및 I/O 처리량을 표시기로 사용하여 일주일에 한 번 정도 백업 기간이 워크로드에 미치는 영향을 평가합니다. 이전 주의 워크로드에 따라 전체 백업 기간이 조정될 수 있습니다.
- 사용자 구성: 사용자가 백업 일정을 수정하거나 사용하지 않도록 설정할 수 없다는 점에 유의해야 합니다.
Important
새 데이터베이스, 복원된 데이터베이스 또는 복사된 데이터베이스의 경우 초기 전체 백업에 이어지는 초기 트랜잭션 로그 백업이 만들어지면 PITR(특정 시점 복원) 기능을 사용할 수 있게 됩니다.
백업 스토리지 사용량
SQL Server 백업 및 복원 기술을 사용하여 데이터베이스를 특정 시점으로 복원하려면 중단 없는 백업 체인이 필요합니다. 해당 체인은 하나의 전체 백업, 선택적으로 하나의 차등 백업 및 하나 이상의 트랜잭션 로그 백업으로 구성됩니다.
Azure SQL Managed Instance 백업 일정에는 매주 1회의 전체 백업이 포함됩니다. 전체 보존 기간 내에 PITR을 제공하려면 구성된 보존 기간보다 최대 일주일이 더 긴 전체, 차등 및 트랜잭션 로그 백업을 시스템에서 추가로 저장해야 합니다.
즉, 보존 기간 중 특정 시점에 대해 보존 기간의 가장 오래된 시간보다 오래된 전체 백업이 있어야 합니다. 또한 전체 백업에서 다음 전체 백업까지 차등 및 트랜잭션 로그 백업의 중단 없는 체인이 있어야 합니다.
PITR 기능을 제공하는 데 더 이상 필요 없는 백업은 자동으로 삭제됩니다. 차등 백업 및 로그 백업은 이전 전체 백업을 복원할 수 있어야 하므로 세 가지 백업 유형이 주간 세트에서 함께 제거됩니다.
TDE 암호화 데이터베이스를 포함한 모든 데이터베이스는 모든 전체 및 차등 백업은 백업 스토리지 압축 및 비용을 줄이기 위해 압축됩니다. 평균 백업 압축 비율은 3~4배입니다. 하지만 데이터의 특성과 데이터베이스에서 데이터 압축 사용 여부에 따라 훨씬 낮거나 훨씬 높을 수 있습니다.
Important
TDE 암호화 데이터베이스의 경우 로그 백업 파일은 성능상의 이유로 압축되지 않습니다. TDE로 암호화되지 않은 데이터베이스에 대한 로그 백업은 압축됩니다.
Azure SQL Managed Instance는 사용한 총 백업 스토리지를 누적 값으로 계산합니다. 이 값은 매시간 Azure 청구 파이프라인에 보고됩니다. 파이프라인은 매시간 사용량을 집계하여 각 월말에 사용량을 계산하는 데 사용됩니다. 데이터베이스가 삭제된 후 백업이 만료되어 삭제되면 사용량이 감소합니다. 모든 백업이 삭제되고 PITR이 더 이상 가능하지 않으면 청구가 중지됩니다.
Important
삭제된 데이터베이스에 대한 백업은 PITR(특정 시점 복원)을 위해 유지되므로 데이터베이스가 삭제된 경우에도 백업이 유지되어 스토리지 비용이 증가할 수 있습니다. 비용을 줄이기 위해 백업 보존 기간을 0일로 설정할 수 있지만 이는 삭제된 데이터베이스에 대해서만 가능합니다. 일반 데이터베이스의 경우 최소 보존 기간은 1일입니다.
백업 스토리지 사용량 미세 조정
데이터베이스의 최대 데이터 크기까지는 백업 스토리지 사용 요금이 부과되지 않습니다. 백업 스토리지 초과 사용량은 개별 데이터베이스의 워크로드 및 최대 크기에 따라 달라집니다. 백업 스토리지 사용량을 줄이기 위해 다음과 같은 몇 가지 튜닝 기법을 고려합니다.
- 데이터베이스 백업 보존 기간을 사용자 요구에 따라 최소 기간으로 줄입니다.
- 인덱스 다시 빌드와 같은 대량 쓰기 작업은 수행하지 않는 것이 좋습니다.
- 대량 데이터 로드 작업의 경우에는 클러스터형 columnstore 인덱스를 사용하고 관련 모범 사례를 따르는 것이 좋습니다. 또한 비클러스터형 인덱스 수를 줄이는 방법도 고려해 보세요.
- 범용 서비스 계층에서 프로비전된 데이터 스토리지는 백업 스토리지의 가격보다 저렴합니다. 초과 백업 스토리지 비용이 지속적으로 많이 발생하는 경우 데이터 스토리지를 늘려서 백업 스토리지를 절약할 수 있습니다.
- 임시 결과 또는 임시 데이터를 저장하기 위해 애플리케이션 논리에서 영구 테이블 대신
tempdb를 사용합니다. - 되도록이면 로컬 중복 백업 스토리지를 사용합니다(예: 개발/테스트 환경).
백업 보존
Azure SQL Managed Instance는 백업의 단기 및 장기 보존을 모두 제공합니다. 단기 보존은 데이터베이스의 보존 기간 내에 PITR을 허용합니다. 장기 보존은 다양한 규정 준수 요구 사항의 백업을 제공합니다.
단기 보존
모든 새 데이터베이스, 복원된 데이터베이스, 복사된 데이터베이스의 경우 Azure SQL Managed Instance는 기본적으로 최근 7일 내에 PITR을 허용하기 위해 충분한 백업을 유지합니다. 1~35일 범위로 이 구성을 변경할 수 있습니다. 서비스는 정규 전체, 차등 및 로그 백업을 수행하여 데이터베이스 또는 관리되는 인스턴스에 대해 정의된 보존 기간 내의 특정 시점으로 데이터베이스를 복원할 수 있도록 합니다.
인스턴스를 생성할 때 STR에 대한 백업 스토리지 중복성 옵션을 지정한 다음, 나중에 변경할 수 있습니다. 인스턴스를 만든 후 백업 중복 옵션을 변경하면 새 백업에서 새 중복성 옵션을 사용합니다. 이전 STR 중복성 옵션으로 만든 백업 복사본은 이동되거나 복사되지 않습니다. 보존 기간이 만료될 때까지 원래 스토리지 계정에 남아 있습니다. 백업 스토리지 사용량에 설명된 것처럼 정확한 데이터 복원을 보장하고자 PITR을 사용하기 위해 저장된 백업이 보존 기간보다 오래되었을 수 있습니다.
데이터베이스를 삭제하면 시스템에서는 해당 보존 기간을 사용하여 온라인 데이터베이스와 동일한 방식으로 백업을 유지합니다. 그러나 삭제된 데이터베이스의 경우 보존 기간이 1~35일에서 0~35일로 업데이트되므로 수동으로 백업을 삭제할 수 있습니다. 백업을 최대 단기 보존 기간인 35일보다 오래 유지해야 하는 경우 장기 보존을 사용하면 됩니다.
중요
관리되는 인스턴스를 삭제하면 해당 관리되는 인스턴스의 모든 데이터베이스도 삭제되며 복구할 수 없습니다. 관리되는 인스턴스가 삭제되면 복원할 수 없습니다. 그러나 관리되는 인스턴스에 대한 장기 보존을 구성한 경우 LTR 백업은 삭제되지 않습니다. 그런 다음 이러한 백업을 사용하여 LTR 백업이 수행된 특정 시점으로 동일한 구독의 다른 관리되는 인스턴스로 데이터베이스를 복원할 수 있습니다. 자세한 내용은 장기 백업 복원을 검토해 보세요.
LTR(장기 보존)
SQL Managed Instance를 사용하면 Azure Blob Storage에서 최대 10년 동안 전체 LTR 백업 저장을 구성할 수 있습니다. LTR 정책을 구성한 후에는 전체 백업이 다른 스토리지 컨테이너에 자동으로 복사됩니다.
다양한 규정 준수 요구 사항을 충족하기 위해 주간, 월간 및/또는 연간 전체 백업에 대해 다른 보존 기간을 선택할 수 있습니다. 빈도는 정책에 따라 달라집니다. 예를 들어 W=0, M=1, Y=0을 설정하면 매월 LTR 복사본이 생성됩니다. LTR에 대한 자세한 내용은 장기 보존을 참조하세요.
Azure SQL Managed Instance의 LTR 백업 스토리지 중복성은 LTR 정책이 정의된 시점에 STR에서 사용하는 백업 스토리지 중복성에서 상속됩니다. 향후 STR 백업 스토리지 중복성이 변경되더라도 변경할 수 없습니다.
스토리지 사용량은 선택한 LTR 백업 빈도 및 보존 기간에 따라 달라집니다. LTR 가격 계산기를 사용하여 LTR 스토리지 비용을 추정할 수 있습니다.
백업 스토리지 비용
Azure SQL Managed Instance는 청구 가능한 총 백업 스토리지를 모든 백업 파일의 누적 값으로 계산합니다. 이 값은 매시간 Azure 청구 파이프라인에 보고됩니다. 파이프라인에서는 이 시간당 사용량을 집계하여 매월 말에 백업 스토리지 사용량을 산정합니다.
데이터베이스가 삭제되면 오래된 백업이 만료되어 삭제되므로 백업 스토리지 사용량이 점차 감소합니다. 차등 백업 및 로그 백업은 이전 전체 백업을 복원할 수 있어야 하므로 세 가지 백업 유형이 주간 세트에서 함께 제거됩니다. 모든 백업이 삭제된 후에 청구가 중지됩니다.
백업 스토리지의 가격은 다양합니다. 선택한 백업 스토리지 중복성 옵션과 지역에 따라 달라집니다. 백업 스토리지는 매월 사용되는 기가바이트를 기준으로 모든 백업에 대해 같은 요금으로 청구됩니다.
백업 스토리지 중복성은 다음과 같은 방식으로 백업 비용에 영향을 줍니다.
Locally redundant price = published priceZone-redundant price = published price x 1.25Geo-redundant price = published price x 2Geo-zone-redundant price = published price x 3.4
가격 책정에 대해서는 Azure SQL Managed Instance 가격 책정 페이지를 검토하세요.
참고
Azure 청구서에는 전체 백업 스토리지 사용량이 아닌 백업 스토리지 초과 사용량만 표시됩니다. 예를 들어 데이터 스토리지 4TB를 프로비저닝할 경우 무료 백업 스토리지 공간은 4TB입니다. 총 5.8TB의 백업 스토리지 공간을 사용하는 경우 사용한 초과 백업 스토리지에 대해서만 요금이 청구되므로 Azure 청구서에 1.8TB만 표시됩니다.
관리되는 인스턴스의 경우 청구 가능한 총 백업 스토리지 크기는 인스턴스 수준에서 집계되며 다음과 같이 계산됩니다.
Total billable backup storage size = (total size of full backups + total size of differential backups + total size of log backups) – maximum instance data storage
청구 가능한 총 백업 스토리지(있는 경우)는 사용한 백업 스토리지 중복성 비율에 따라 각 지역별로 매월 기가바이트 단위로 청구됩니다. 백업 스토리지 사용량은 개별 데이터베이스 및 관리되는 인스턴스의 워크로드와 크기에 따라 달라집니다. 백업의 크기는 변경된 데이터 양에 비례하므로 자주 수정되는 데이터베이스는 차등 및 로그 백업의 크기가 큽니다. 따라서 이러한 데이터베이스는 백업 비용이 더 많이 듭니다.
간단한 예로, 데이터베이스의 누적 백업 스토리지가 744GB이고 데이터베이스가 완전히 유휴 상태이기 때문에 이 양이 한 달 내내 그대로 유지된다고 가정하겠습니다. 이 누적 스토리지 사용량을 시간당 사용량으로 변환하려면 744.0(매월 31일 X 매일 24시간)로 나눕니다. SQL Managed Instance는 데이터베이스가 시간당 1GB의 일정한 속도로 PITR 백업을 사용했다고 Azure 청구 파이프라인에 보고합니다. Azure 청구는 이 사용량을 집계하고 전체 월에 대해 744GB의 사용량을 표시합니다. 비용은 해당 지역의 월 기가바이트 요금을 기준으로 합니다.
다음은 또 다른 예시입니다. 동일한 유휴 데이터베이스의 보존 기간이 월 중간에 7일에서 14일로 증가했다고 가정해보겠습니다. 이와 같은 증가로 인해 총 백업 스토리지가 2배로 늘어나서 1,488GB가 됩니다. SQL Managed Instance는 1~372시간(월 상반기) 동안 1GB의 사용량을 보고합니다. 373~744(해당 월의 뒤쪽 절반)의 사용량은 2GB라고 보고합니다. 이 사용량은 최종 청구 1,116GB/월로 집계됩니다. 보존 비용은 즉시 증가하지 않습니다. 보존 비용은 백업이 최대 보존 기간인 14일에 도달할 때까지 증가하기 때문에 매일 점진적으로 증가합니다.
실제 백업 청구 시나리오는 더 복잡합니다. 데이터베이스의 변동률은 워크로드에 따라 다르고 시간이 지나면서 가변적이기 때문에 각 차등 및 로그 백업의 크기도 달라집니다. 백업 스토리지의 시간당 사용량은 그에 따라 변동됩니다.
각 차등 백업에는 마지막 전체 백업 이후 데이터베이스의 모든 변경 내용도 포함됩니다. 따라서 모든 차등 백업의 총 크기는 일주일 동안 점진적으로 증가합니다. 그런 다음 이전 세트의 전체, 차등 및 로그 백업이 오래되면 급격하게 감소합니다.
예를 들어 인덱스 다시 빌드와 같은 많은 쓰기 작업이 전체 백업이 완료된 직후에 실행된다고 가정합니다. 그러면 인덱스 다시 빌드가 수행하는 수정 내용이 포함됩니다.
- 다시 빌드 기간 동안 수행되는 트랜잭션 로그 백업에서
- 다음 차등 백업에서
- 다음 전체 백업이 발생할 때까지 수행되는 모든 차등 백업에서
모든 차등 백업의 크기를 줄이기 위해 마지막 전체 백업이 수행된 시점이 24시간이 넘은 경우 750GB를 초과하고 데이터베이스 크기의 75%에 상당하는 지나치게 큰 차등 백업은 전체 백업으로 승격됩니다.
비용 모니터링
백업 스토리지 비용을 이해하려면 Azure Portal의 비용 관리 + 청구로 이동합니다. Cost Management를 선택한 다음, 비용 분석을 선택합니다. 범위에 대해 원하는 구독을 선택한 후, 다음과 같이 관심 있는 기간 및 서비스를 필터링합니다.
서비스 이름에 대한 필터를 추가합니다.
드롭다운 목록에서 관리되는 인스턴스의 SQL Managed Instance를 선택합니다.
Meter 하위 범주에 대한 다른 필터를 추가합니다.
PITR 백업 비용을 모니터링하려면 드롭다운 목록에서 Managed Instance PITR 백업 스토리지를 선택합니다. 백업 스토리지 사용량이 있는 경우에만 미터가 표시됩니다.
LTR 백업 비용을 모니터링하려면 드롭다운 목록에서 SQL Managed Instance - LTR 백업 스토리지를 선택합니다. 백업 스토리지 사용량이 있는 경우에만 미터가 표시됩니다.
스토리지 및 컴퓨팅 하위 범주에도 관심이 갈지 모르지만, 이 둘은 백업 스토리지 비용과는 관련이 없습니다.
중요
현재 사용 중인 카운터의 경우에만 미터가 표시됩니다. 카운터를 사용할 수 없는 경우 범주가 현재 사용되고 있지 않을 수 있습니다. 예를 들어 관리되는 인스턴스가 배포되지 않은 고객에게는 관리되는 인스턴스 카운터가 표시되지 않습니다. 마찬가지로 스토리지를 사용하지 않는 리소스의 스토리지 카운터는 표시되지 않습니다. PITR 또는 LTR 백업 스토리지 사용량이 없는 경우에는 이러한 미터가 표시되지 않습니다.
암호화된 백업
데이터베이스가 TDE를 사용하여 암호화된 경우 LTR 백업을 포함한 백업이 미사용 시 자동으로 암호화됩니다. Azure SQL의 모든 새 데이터베이스는 기본적으로 TDE를 사용하도록 구성됩니다. TDE에 대한 자세한 내용은 SQL Managed Instance를 사용한 투명한 데이터 암호화를 참조하세요.
Microsoft는 SMK(서비스 관리형 키)를 사용하여 데이터베이스에 대한 키를 유지하고 회전하는 책임을 집니다. SMK가 활성화된 TDE가 있는 인스턴스에서 가져온 PITR 또는 LTR 백업은 Microsoft에서 복원할 수 있습니다.
Azure 관리형 스토리지 계정에 저장된 자동 백업은 Azure Storage에서 자동으로 암호화됩니다. 미사용 데이터에 대한 Azure Storage 암호화에 대해 알아봅니다.
백업 무결성
모든 데이터베이스 백업은 추가 백업 무결성을 제공하는 CHECKSUM 옵션을 통해 수행됩니다. Azure SQL 엔지니어링 팀의 자동화된 데이터베이스 백업 자동 테스트는 현재 Azure SQL Managed Instance에서 사용할 수 없습니다. 워크로드 주변의 SQL Managed Instance 데이터베이스에서 테스트 백업 복원 및 DBCC CHECKDB를 예약합니다.
시스템에서 백업의 무결성을 확인하지는 않지만, 백업 서비스에 문제가 있는 경우 Microsoft에 알림을 보내는 백업 기본 보호 기능은 계속 제공됩니다. 또한 Microsoft에서는 전체 백업 미실행, 백업 서비스 중단, SLA를 벗어난 로그 백업, 백업 하드웨어 또는 소프트웨어 손상 같은 백업 문제가 발생하는 경우 사용자를 지원합니다.
Azure Policy를 사용하여 백업 스토리지 중복성 적용
모든 데이터를 단일 Azure 지역에 유지해야 하는 데이터 보존 요구 사항이 있는 경우 Azure Policy를 사용하여 SQL Managed Instance에 영역 중복 또는 로컬 중복 백업을 적용하면 됩니다.
Azure Policy는 Azure 리소스에 규칙을 적용하는 정책을 만들고, 할당하고, 관리하는 데 사용할 수 있는 서비스입니다. Azure Policy는 해당 리소스가 회사 표준 및 서비스 수준 계약을 준수하도록 유지하는 데 도움이 됩니다. 자세한 내용은 Azure Policy 개요를 참조하세요.
기본 제공 백업 스토리지 중복성 정책
조직 수준에서 데이터 보존 요구 사항을 적용하려면 Azure Portal 또는 Azure PowerShell을 사용하여 구독에 정책을 할당할 수 있습니다. 예를 들어 구독 또는 리소스 그룹 수준에서 다음 기본 제공 정책을 할당하는 경우 구독의 사용자는 Azure Portal 또는 Azure PowerShell을 통해 지역 중복 백업 스토리지를 사용하여 관리되는 인스턴스를 만들 수 없습니다. SQL Managed Instances는 GRS 백업 중복성을 사용하지 않아야 합니다.
SQL Managed Instance의 기본 제공 정책 정의 전체 목록은 정책 참조를 검토하세요.
중요
T-SQL을 통해 데이터베이스를 만들 때는 Azure 정책이 적용되지 않습니다. T-SQL을 사용하여 데이터베이스를 만들 때 데이터 보존을 적용하려면 CREATE DATABASE 문에서 BACKUP_STORAGE_REDUNDANCY 매개 변수의 입력으로 LOCAL 또는 ZONE을 사용합니다.
규정 준수
기본 보존 기간이 규정 준수 요구 사항을 충족하지 못하는 경우 PITR 보존 기간을 변경할 수 있습니다. 자세한 내용은 PITR 백업 보존 기간 변경을 참조하세요.
참고
자동 백업 설정 변경 문서에서는 디바이스 또는 서비스에서 개인 데이터를 삭제하는 방법에 대한 단계를 제공하며 GDPR에 따른 의무를 지원하는 데 사용할 수 있습니다. GDPR에 대한 일반정인 정보는 Microsoft Trust Center의 GDPR 섹션 및 Service Trust 포털의 GDPR 섹션을 참조하세요.