다음에 적용됩니다:
Azure SQL DatabaseAzure SQL Managed Instance
이 문서에서는 Azure SQL Database 및 Azure SQL Managed Instance 대한 LTR(장기 보존) 백업에 대한 개념적 개요를 제공합니다. 장기 보존은 Azure SQL Database(하이퍼스케일 서비스 계층 포함) 및 Azure SQL Managed Instance 백업에서 최대 10년 동안 구성할 수 있습니다.
장기 보존 백업 기능을 사용하려면 다음을 참조하세요.
중요합니다
LTR(장기 보존) 백업 작업에 사용되는 일부 이전 API는 더 이상 사용되지 않으며 더 이상 지원되지 않습니다. 와 같은 Copy-AzSqlDatabaseLongTermRetentionBackup레거시 PowerShell cmdlet을 사용하지 마십시오. 대신 이 문서에 설명된 지원되는 복원 방법을 사용합니다.
장기 보존 작동 방식
많은 애플리케이션에는 1~35일 동안의 자동 백업 단기 보존 기간을 초과하여 데이터베이스 백업을 보존해야 하는 규제, 규정 준수 또는 기타 비즈니스 목적이 존재합니다. LTR(장기 백업 보존)은 Azure SQL 서비스에서 자동으로 생성되는 전체 데이터베이스 백업을 사용합니다. 자세한 내용은 Azure SQL Database 또는 Azure SQL Managed Instance의 인증된 백업을 참조하세요.
LTR 기능을 사용하면 최대 10년의 구성 가능한 보존 정책을 사용하여 지정된 전체 SQL Database 및 SQL Managed Instance 백업을 중복 Azure Blob Storage에 저장할 수 있습니다. 그런 다음 LTR 백업을 새 데이터베이스로 복원할 수 있습니다. LTR 정책을 구성한 경우 자동화된 백업은 장기 스토리지를 위해 다른 Blob에 복사합니다. 이는 데이터베이스를 특정 시점으로 복원하는 데 사용할 수 있습니다. 복사 프로세스는 데이터베이스 워크로드에 성능에 영향을 주지 않는 백그라운드 작업입니다. 각 데이터베이스에 대한 LTR 정책은 LTR 백업을 만드는 빈도를 지정할 수도 있습니다.
참고
- Azure SQL Database 장기 보존 백업을 변경할 수 없는 것으로 구성할 수 있습니다.
- Azure SQL Managed Instance에서는 현재 백업을 immutable로 구성할 수 없습니다. LTR 백업은 수정할 수 없지만 Azure 포털, Azure CLI, PowerShell 또는 REST API를 통해 삭제할 수 있습니다. Azure SQL Managed Instance 해결책으로, 복사 전용 데이터베이스 백업을 수행하여 변경 불가능한 파일로 만들고 이를 자신의 Azure Storage 계정에 보관할 수 있습니다.
LTR을 사용하도록 설정하기 위해 4개의 매개 변수(주간 백업 보존(W), 월간 백업 보존(M), 연간 백업 보존(Y), 연간 주(WeekOfYear)) 조합을 사용하여 정책을 정의할 수 있습니다. W를 지정하는 경우 매주 하나의 백업을 장기 스토리지에 복사합니다. M을 지정하는 경우 각 월의 첫 번째 백업을 장기 스토리지에 복사합니다. Y를 지정하는 경우 WeekOfYear로 지정한 주 동안 하나의 백업을 장기 스토리지에 복사합니다. 정책을 구성했을 때 지정한 WeekOfYear가 과거인 경우 첫 번째 LTR 백업은 다음 해에 만듭니다. 각 백업은 LTR 백업을 만들 때 구성한 정책 매개 변수에 따라 장기 스토리지에 보관합니다.
LTR 정책의 변경 내용은 이후 백업에만 적용됩니다. 예를 들어 W(주간 백업 보존), M(월간 백업 보존) 또는 Y(연간 백업 보존)를 수정하는 경우 새 보존 설정은 새 백업에만 적용됩니다. 기존 백업의 보존은 수정되지 않습니다. Azure SQL Database 및 Azure SQL Managed Instance 각 데이터베이스에 대해 LTR 정책을 구성할 수 있습니다. 보존 기간이 만료되기 전에 이전 LTR 백업을 삭제하려는 경우 백업을 수동으로 삭제할 수 있습니다.
참고
Azure SQL Database 및 Azure SQL Managed Instance 데이터베이스에 대해 처음으로 LTR 정책을 사용하도록 설정하면 PITR(특정 시점 복원)의 최신 전체 백업이 장기 스토리지로 복사됩니다.
LTR 정책의 예제:
W=0, M=0, Y=5, WeekOfYear=3각 연도의 세 번째 전체 백업은 5년 동안 유지합니다.
W=0, M=3, Y=0매월 첫 번째 전체 백업은 3개월 동안 유지합니다.
W=12, M=0, Y=0각각의 매주 전체 백업은 12주 동안 유지합니다.
W=6, M=12, Y=10, WeekOfYear=20각각의 매주 전체 백업은 6주 동안 유지합니다. 매월 첫 번째 전체 백업을 제외하고 12개월 동안 유지합니다. 연간 20번째 주에 수행한 전체 백업을 제외하고 10년 동안 유지합니다.
다음 표는 다음 정책에 대한 장기 백업의 주기 및 만료를 나타냅니다.
W=12 weeks (84일), M=12 months (365일), Y=10 years (3,650일), WeekOfYear=20 (5월 13일 이후 주)
다음 날짜는 ISO 8601(YYYY-MM-DD) 형식을 따릅니다.
| PITR 백업을 LTR로 | 만료 | 유효기간 M | 만료 Y |
|---|---|---|---|
| 2018-03-07 | 2019-03-02 | ||
| 2018-03-14 | 2018-06-06 | ||
| 2018-03-21 | 2018-06-13 | ||
| 2018-03-28 | 2018-06-20 | ||
| 2018년 4월 4일 | 2019-03-30 | ||
| 2018-04-11 | 2018-07-04 | ||
| 2018-04-18 | 2018-07-11 | ||
| 2018-04-25 | 2018-07-18 | ||
| 2018-05-02 | 2019-04-27 | ||
| 2018-05-09 | 2018-08-01 | ||
| 2018-05-16 | 2028년 05월 13일 | ||
| 2018-05-23 | 2018-08-15 | ||
| 2018-05-30 | 2018-08-22 | ||
| 2018-06-06 | 2019-06-01 | ||
| 2018-06-13 | 2018-09-05 | ||
| 2018-06-20 | 2018-09-12 | ||
| 2018-06-27 | 2018-09-19 | ||
| 2018-07-04 | 2019-06-29 | ||
| 2018-07-11 | 2018-10-03 | ||
| 2018-07-18 | 2018-10-10 | ||
| 2018-07-25 | 2018-10-17 | ||
| 2018-08-01 | 2019-07-27 | ||
| 2018-08-08 | 2018-10-31 | ||
| 2018-08-15 | 2018-11-07 | ||
| 2018-08-22 | 2018-11-14 | ||
| 2018-08-29 | 2018-11-21 |
이 정책을 수정하고 설정 W=0 (주간 백업 없음)하는 경우 주간 백업은 만료될 때까지 유지되고 서비스는 월별 및 연간 백업만 유지합니다. 이후 주간 백업은 LTR 정책에 따라 저장되지 않습니다. 이러한 백업을 유지하는 데 필요한 스토리지 용량은 적절하게 줄어듭니다.
중요합니다
개별 LTR 백업의 타이밍은 Microsoft 의해 제어됩니다. LTR 백업을 수동으로 만들거나 백업 생성 타이밍을 제어할 수 없습니다. LTR 정책을 구성한 후 사용 가능한 백업 목록에 첫 번째 LTR 백업이 표시되기까지 최대 7일이 걸릴 수 있습니다.
논리 서버 또는 SQL 관리형 인스턴스를 삭제하면 해당 서버 또는 관리되는 인스턴스의 모든 데이터베이스도 삭제됩니다. 삭제된 논리 서버 또는 SQL 관리형 인스턴스는 복원할 수 없습니다. 그러나 데이터베이스에 대해 LTR을 구성한 경우 LTR 백업은 삭제되지 않으며 LTR 백업이 수행된 시점까지 동일한 구독의 다른 서버 또는 관리되는 인스턴스로 데이터베이스를 복원하는 데 사용할 수 있습니다.
마찬가지로 데이터베이스를 삭제하는 경우 LTR 백업은 삭제되지 않으며 구성된 보존 기간 동안 유지됩니다. 이러한 백업은 동일한 서버 또는 동일한 구독의 다른 서버로 복원할 수 있습니다.
지역 복제 및 장기 백업 보존
활성 지역 복제 또는 장애 조치(failover) 그룹을 비즈니스 연속성 솔루션으로 사용하는 경우 최종 장애 조치를 준비하고 주 데이터베이스 또는 인스턴스에서와 동일한 LTR 정책을 구성합니다. 백업이 보조 데이터베이스에서 생성되지 않으므로 LTR 스토리지 비용은 증가하지 않습니다. 백업은 장애 조치(failover)가 트리거되고 주 백업이 보조 지역으로 이동할 때 중단 없는 LTR 백업 생성을 보장하기 위해 보조 백업이 기본이 된 후에만 만들어집니다.
원래 주 데이터베이스가 장애 조치(failover)를 발생시킨 중단에서 복구되면 새 보조 데이터베이스가 됩니다. 따라서 백업 만들기는 새 보조 데이터베이스에서 다시 시작되지 않으며, 기존 LTR 정책은 다시 주 정책이 될 때까지 적용되지 않습니다.
네트워크 보안 경계 및 LTR 복원 (미리보기)
참고
네트워크 보안 경계(미리보기)는 Azure SQL Database에만 적용됩니다. Azure SQL Managed Instance는 온보딩 리소스가 아니므로 이 섹션은 해당되지 않습니다. 현재 목록은 Onboarded Private Link 리소스를 참조하세요.
LTR 복원은 장기 백업에서 대상 논리 서버로 데이터베이스를 복원하는 플랫폼 관리 작업입니다. 논리 서버 중 하나가 Perimeter에 속해 있을 경우, 복원은 Perimeter의 액세스 규칙에 따라 진행됩니다.
서비스는 소스 서버가 아직 존재할 때 아웃바운드 접근을, 대상 서버에서 인바운드 접근을 확인합니다. 소스 논리 서버가 삭제된 경우, 타겟 측 인바운드 검사만 실행될 수 있습니다.
지원되는 구성
LTR 복원은 전환 모드와 강제 모드 모두에서 작동합니다. 전환 모드에서는 복원 작업이 접근 규칙 없이도 성공적으로 수행됩니다. 강제 모드로 전환하기 전에 규칙을 설정하세요.
강제 모드에서는 다음과 같은 구성이 지원됩니다:
| 원본 서버 | 대상 서버 | 액세스 규칙이 필요합니다 |
|---|---|---|
| 경계 안에 | 같은 경계 안에서 | None. 같은 경계 내의 자원 간 접근은 항상 허용됩니다. |
| 경계 내부에 | 다른 범위에서 | 소스에서는 아웃바운드, 타겟에서는 인바운드입니다. |
| 경계 내부에 | 범위 안에 있지 않아 | 소스의 아웃바운드 |
| 범위 안에 있지 않아 | 경계 내에서 | 목표물로 진입 중. |
| 삭제됨 | 경계 내부에 | 목표물을 향해 이동 중. |
| 경계 내에 있지 않음 | 경계 내에 없음 | None. |
LTR 복원에는 관리 ID가 필요하지 않습니다.
LTR 복원을 위한 접근 규칙을 설정하세요
- 아직 하지 않았다면 각 논리 서버를 해당 네트워크 경계와 연결하세요. 경계 밖에 머무르는 서버나 삭제된 소스 서버의 경우 이 단계를 건너뛰세요.
- 만약 소스 서버가 경계에 있고 대상 서버가 같은 경계에 있지 않다면, 소스 프로필에 목적지 유형을 FQDN으로 설정하고 대상 서버의 완전히 정규화된 도메인 이름을 지정하는 아웃바운드 규칙을 추가하세요.
- 대상 서버가 보안 경계 내에 있고 소스 서버가 같은 보안 경계에 있지 않다면, 대상 방화벽 프로필에 인바운드 규칙을 추가하세요. 복원 요청은 소스 서버가 아니라 Azure SQL 관리 인프라에서 옵니다. 규칙에서는 다음 출처 중 하나를 허용합니다:
- 소스 서버의 구독 ID(권장).
- 서비스 태그(권장).
- IP 주소 범위. 퍼블릭 클라우드의 경우, Azure IP 범위와 서비스 태그 - 퍼블릭 클라우드는 각 서비스 태그와 그 IP 주소 범위를 나열합니다. 서비스 태그 이름은
SqlManagement입니다. Microsoft는 이 범위들을 지역별로 공개하지 않으니 모두 허용하세요.
- 서버가 아직 전환 모드인 상태에서 복원을 실행하고 네트워크 보안 경계 진단 로그 에서 예상치 못한 거부가 있는지 확인하세요.
- 모든 진단 검사를 통과한 후에만 강제 모드로 전환하세요.
한계와 행동 차이
- LTR 백업이 있는 논리 서버는 해당 서버의 perimeter association이 enforced 모드인 동안 삭제할 수 없습니다. 변경 불가능한 LTR 백업은 서버가 보안 경계 내에 있든 없든 삭제를 차단합니다. 자세한 내용은 변경할 수 없는 장기 백업 및 논리 서버 삭제를 참조하세요.
- 연결이 전환 모드에 있는 동안 소스 서버를 삭제하면, 서비스는 더 이상 해당 서버의 경계 메타데이터를 읽을 수 없게 되므로, 복원의 대상 쪽만 검증할 수 있습니다. 소스측 검증을 통제 수단으로 의존한다면 이 공백을 고려하세요.
- 전환 모드에서는 필요한 규칙이 없어도 복원이 성공합니다. 강제 모드에서는 같은 복원이 차단됩니다.
장기 백업 보존 구성
중요합니다
LTR(장기 보존) 백업 작업에 사용되는 일부 이전 API는 더 이상 사용되지 않으며 더 이상 지원되지 않습니다. 와 같은 Copy-AzSqlDatabaseLongTermRetentionBackup레거시 PowerShell cmdlet을 사용하지 마십시오. 대신 이 문서에 설명된 지원되는 복원 방법을 사용합니다.
Azure SQL Database 및 Azure SQL Managed Instance 위해 Azure 포털 및 PowerShell을 사용하여 장기 백업 보존을 구성할 수 있습니다. LTR 스토리지에서 데이터베이스를 복원하기 위해 해당 타임스탬프에 따라 특정 백업을 선택할 수 있습니다. 데이터베이스는 원래 데이터베이스와 동일한 구독에서 기존 서버 또는 관리되는 인스턴스로 복원할 수 있습니다. 복원 기능, 제한 사항 및 기능의 전체 목록은 Azure SQL Managed InstanceRestore 기능 및 기능을 참조하세요>.
LTR 보존 기간의 마지막 7일 동안 복원 요청이 시작되면 보존 기간이 만료된 경우에도 복원 작업이 완료된 후에만 LTR 백업이 삭제됩니다.
참고
하이퍼스케일 서비스 계층과 Azure SQL Database 다른 서비스 계층 간의 데이터베이스 복원은 현재 지원되지 않습니다.
Azure SQL Managed Instance에서 SQL 에이전트 작업을 사용하여 복사 전용 데이터베이스 백업을 예약하고, 대안으로 고유한 저장소 계정으로 이동할 수 있습니다.
- 10년 이상 백업을 유지합니다.
- 데이터베이스의 일일 복사본을 35일 이상 유지합니다.
- 변경할 수 없는 스토리지에 데이터베이스 백업을 저장합니다.
팁 (조언)
LTR 백업을 사용하여 규정 준수 또는 기타 중요 업무용 요구 사항을 충족하는 경우 주기적인 복구 훈련을 수행하여 LTR 백업을 복원할 수 있는지, 복원으로 인해 데이터베이스 상태가 예상되는지 확인하는 것이 좋습니다.
참고
LTR 백업은 성공적인 전체 백업에 따라 달라집니다. 전체 거래 로그는 예약된 전체 백업을 방해할 수 있으며, 이는 LTR 백업을 방해할 수 있습니다. 변경 데이터 캡처(CDC) 및 트랜잭션 로그 절단을 방지하는 기타 기능은 LTR 백업을 지연시킬 수 있으며, LTR 백업은 전체 백업이 성공한 후에야 성공할 수 있습니다. 트랜잭션 로그 절단을 방지하는 기능을 평가하고, 백업 작업이 복구될 때까지 임시로 비활성화하는 것을 고려하세요.
다음 단계
관련 콘텐츠
데이터베이스 백업은 실수로 손상되거나 삭제되지 않도록 데이터를 보호해 주기 때문에 비즈니스 연속성 및 재해 복구 전략에서 필수입니다.
Azure SQL Database Azure SQL Managed Instance - Azure SQL Database의 자동 백업
- Azure SQL Managed Instance에서 자동화된 백업
- Azure SQL Database의 수정 가능한 구성 참조
- Azure SQL Database용 네트워크 보안 경계(미리 보기)