SQL Server Always On 가용성 그룹 백업
Azure Backup은 모든 노드가 Recovery Services 자격 증명 모음과 동일한 지역 및 구독에 있는 경우 SQL Server AG(Always On 가용성 그룹)를 백업하는 엔드투엔드 지원을 제공합니다. 그러나 AG 노드가 지역/구독/온-프레미스 및 Azure 전체에 걸쳐 분산된 경우 몇 가지 고려 사항을 염두에 두어야 합니다.
참고 항목
- 기본 가용성 그룹 데이터베이스의 백업은 Azure Backup에서 지원되지 않습니다.
- 지원되는 구성 및 시나리오에 대한 자세한 내용은 SQL 백업 지원 매트릭스를 참조하세요.
Azure Backup SQL AG에서 사용하는 백업 기본 설정은 주 복제본에서만 전체 백업과 차등 백업을 지원합니다. 따라서 이러한 백업 작업은 항상 백업 기본 설정에 관계없이 주 노드에서 실행됩니다. 복사 전용 전체 및 트랜잭션 로그 백업의 경우 백업이 실행되는 노드를 결정하는 동안 AG 백업 기본 설정을 고려합니다.
| AG 백업 기본 설정 | 전체 및 차등 백업 실행 위치 | 복사 전용 백업과 로그 백업이 실행되는 소스 위치 |
|---|---|---|
| 기본 항목 | 주 복제본 | 주 복제본 |
| 보조만 | 주 복제본 | 보조 복제본 중 하나 |
| 보조 사용 | 주 복제본 | 보조 복제본은 기본 설정되지만 백업도 주 복제본에서 실행할 수 있습니다. |
| 없음/모두 | 주 복제본 | 임의의 복제본 |
워크로드 백업 확장은 Azure Backup 서비스에 등록하면 노드에 설치됩니다. AG 데이터베이스가 백업용으로 구성되면 백업 일정은 AG의 등록된 모든 노드로 푸시됩니다. 일정은 모든 AG 노드에서 발생하고 이러한 노드의 워크로드 백업 확장은 자체적으로 동기화되어 백업을 수행할 수 있는 노드를 결정합니다. 섹션 1에서 설명한 대로 노드 선택은 백업 유형과 백업 기본 설정에 따라 달라집니다.
선택한 노드에서 백업 작업을 진행하는 반면, 다른 노드에서 트리거된 작업은 제외됩니다. 즉, 작업을 건너뜁니다.
참고 항목
보조 복제본 중에서 결정하는 동안에는 Azure Backup에서 백업 우선 순위 또는 복제본을 고려하지 않습니다.
Recovery Services 자격 증명 모음에 AG 노드 등록
Recovery Services 자격 증명 모음은 자격 증명 모음과 동일한 지역 및 구독에 있는 VM에서만 데이터베이스 백업을 지원합니다.
- 기본 노드를 자격 증명 모음에 등록합니다(그렇지 않으면 전체 백업을 수행할 수 없습니다).
- 백업 기본 설정이 보조 전용인 경우 최소한 하나의 보조 노드를 자격 증명 모음에 등록합니다(그렇지 않으면 로그/복사 전용 전체 백업이 실행될 수 없음).
위의 조건이 충족되지 않으면 AG 데이터베이스에 대한 백업 구성에 실패하고 오류 코드 FabricSvcBackupPreferenceCheckFailedUserError가 발생합니다.
다음 AG 배포를 참조로 살펴보겠습니다.
제공된 샘플 AG 배포를 기반으로 다음과 같은 다양한 고려 사항이 있습니다.
- 주 노드가 지역 1 및 구독 1에 있기 때문에이 AG를 보호하기 위해 Recovery Services 자격 증명 모음(자격 증명 모음 1)이 지역 1 및 구독 1에 있어야 합니다.
VM3은 다른 구독에 있으므로 자격 증명 모음 1에 등록할 수 없습니다.VM4는 다른 지역에 있으므로 자격 증명 모음 1에 등록할 수 없습니다.- 백업 기본 설정이 보조만인 경우 VM1(주) 및 VM2(보조)를 자격 증명 모음 1에 등록해야 합니다. 전체 백업에는 주 노드가 필요하고 로그에는 보조 노드가 필요하기 때문입니다. 다른 백업 기본 설정의 경우 VM1(주)을 자격 증명 모음 1에 등록해야 합니다. 모든 백업은 주 노드에서 실행될 수 있기 때문에 VM2는 선택 사항입니다.
- VM3는 구독 2의 자격 증명 모음 2에 등록될 수 있지만 AG 데이터베이스는 보호를 위해 자격 증명 모음 2에 표시되지만 자격 증명 모음 2에는 주 노드가 없어 백업 구성을 하지 못합니다.
- 마찬가지로 VM4는 지역 2에 있는 자격 증명 모음 4에 등록될 수 있지만 주 노드가 자격 증명 모음 4에 등록되어 있지 않기 때문에 백업 구성에 실패합니다.
장애 조치(failover) 처리
AG가 보조 노드 중 하나로 장애 조치(failover)된 후:
- 전체 백업과 차등 백업이 자격 증명 모음에 등록되면 해당 백업은 새 주 노드에서 계속됩니다.
- 로그 및 복사 전용 전체 백업은 백업 기본 설정에 따라 주/보조 노드에서 계속됩니다.
참고 항목
장애 조치(failover)가 백업과 일치하지 않는 경우 장애 조치(failover) 시 로그 체인 중단이 발생하지 않습니다.
위의 샘플 AG 배포에 따라 다음과 같은 다양한 장애 조치(failover) 가능성이 있습니다.
- VM2로 장애 조치(failover)
- VM2에서 전체 및 차등 백업이 수행됩니다.
- 로그 및 복사 전용 전체 백업은 백업 기본 설정에 따라 VM1 또는 VM2에서 수행됩니다.
- VM3로 장애 조치(failover)(다른 구독)
- 백업이 자격 증명 모음 2에 구성되지 않았으므로 백업이 수행되지 않습니다.
- 백업 기본 설정이 보조 전용이 아닌 경우 주 노드가 이 자격 증명 모음에 등록되어 있으므로 이제 자격 증명 모음 2에서 백업을 구성할 수 있습니다. 그러나 그렇게 하면 충돌/백업 실패가 발생할 수 있습니다. 이에 대해서는 다중 지역 AG에 대한 백업 구성에서 자세히 알아보세요.
- VM4로 장애 조치(failover)(다른 지역)
- 백업이 자격 증명 모음 4에 구성되지 않았으므로 백업이 수행되지 않습니다.
- 백업 기본 설정이 보조 전용이 아닌 경우 주 노드가 이 자격 증명 모음에 등록되어 있으므로 이제 자격 증명 모음 4에서 백업을 구성할 수 있습니다. 그러나 그렇게 하면 충돌/백업 실패가 발생할 수 있습니다. 이에 대해서는 다중 지역 AG에 대한 백업 구성에서 자세히 알아보세요.
다중 지역 AG에 대한 백업 구성
Recovery Services 자격 증명 모음은 구독 간 또는 지역 간 백업을 지원하지 않습니다. 이 섹션에서는 구독 또는 Azure 지역에 걸쳐 있는 AG에 대한 백업 및 관련 고려 사항을 사용하도록 설정하는 방법을 요약합니다.
모든 노드에서 백업을 사용하도록 설정해야 하는지 여부를 평가합니다. 하나의 지역/구독에 대부분의 AG 노드가 있고 다른 노드에 대한 장애 조치(failover)가 매우 드물게 발생하는 경우 그 첫 번째 지역에서 백업을 설정하는 것으로 충분할 수 있습니다. 다른 지역/구독에 대한 장애 조치(failover)가 자주 발생하고 장기간 지속되는 경우 다른 지역에서도 사전에 백업을 설정할 수 있습니다.
백업을 사용하도록 설정한 각 자격 증명 모음에는 자체 복구 지점 체인 세트가 있습니다. 이러한 복구 지점의 복원은 해당 자격 증명 모음에 등록된 VM에 대해서만 수행할 수 있습니다.
전체/차등 백업은 주 노드가 있는 자격 증명 모음에서만 성공적으로 수행됩니다. 다른 자격 증명 모음에서는 이러한 백업이 계속 실패합니다.
로그 백업은 새 자격 증명 모음(즉, 새 주 노드가 있는 자격 증명 모음)에서 실행될 때까지 계속 이전 자격 증명 모음에서 작동하고 오래된 자격 증명 모음에 대한 로그 체인이 중단됩니다.
참고 항목
로그 백업이 실패하기 시작하는 15일의 하드 제한이 있습니다.
복사 전용 전체 백업은 모든 자격 증명 모음에서 작동됩니다.
각 자격 증명 모음의 보호는 고유한 데이터 원본으로 취급되며 별도로 청구됩니다.
두 자격 증명 모음 간의 로그 백업 충돌을 방지하려면 백업 기본 설정을 주로 설정하는 것이 좋습니다. 그러면 주 노드가 있는 자격 증명 모음도 로그 백업을 수행합니다.
위의 샘플 AG 배포에 따라 모든 노드에서 백업을 사용하도록 설정하는 단계는 다음과 같습니다. 모든 단계에서 백업 기본 설정을 충족한다고 가정합니다.
1단계: 지역 1, 구독 1(자격 증명 모음 1)에서 백업을 사용하도록 설정
주 노드가 지역 및 구독에 있으므로 백업을 사용하도록 설정하는 일반적인 단계가 작동합니다.
2단계: 지역 1, 구독 2(자격 증명 모음 2)에서 백업을 사용하도록 설정
- AG를 VM3로 장애 조치(failover)하여 주 노드가 자격 증명 모음 2에 표시되도록 합니다.
- 자격 증명 모음 2에서 AG 데이터베이스에 대한 백업을 구성합니다.
- 여기에서:
- 등록된 노드가 이 백업을 수행할 수 없으므로 자격 증명 모음 1에서 전체/차등 백업이 실패하게 됩니다.
- 로그 백업은 자격 증명 모음 2에서 실행되고 자격 증명 모음 1에 대한 로그 체인이 중단될 때까지 자격 증명 모음 1에서 성공합니다.
- AG를 VM1로 장애 복구(failback)합니다.
3단계: 지역 2, 구독 1(자격 증명 모음 4)에서 백업을 사용하도록 설정
2단계와 동일합니다.
Azure와 온-프레미스를 포괄하는 AG 백업
SQL Server에 대한 Azure Backup을 온-프레미스에서 실행할 수 없습니다. Azure에 주 노드가 있고 Azure의 노드에서 백업 기본 설정을 충족하는 경우, 다중 지역 AG에 대한 위의 참고 자료에 따라 Azure에서 복제본에 대한 백업을 사용하도록 설정할 수 있습니다. 온-프레미스 노드에 대한 장애 조치(failover)가 발생하는 경우 Azure에서 전체 및 차등 백업에 실패하기 시작합니다. 로그 체인이 끊어지거나 15일이 지날 때까지 로그 백업을 계속할 수 있습니다.
AG 데이터베이스의 백업 작업에 대한 제한
현재는 백업 제한 한도가 개별 컴퓨터 수준에서 적용됩니다. 기본 제한은 20입니다. 20개 이상의 백업을 동시에 트리거하는 경우에는 처음 20개가 실행되고 나머지는 큐에 대기됩니다. 실행 중인 작업이 완료되면 큐에 대기되는 작업이 실행되기 시작합니다.
동시 백업이 노드에서 메모리/IO/CPU 부담을 발생시키는 경우 이 값을 더 작은 값으로 변경할 수 있습니다. 제한이 노드 수준에 있기 때문에, AG 노드가 불균형하면 백업 동기화 문제가 발생할 수 있습니다. 이에 대한 이해를 돕기 위해 2개 노드 AG를 예로 들어 보겠습니다.
예를 들어, 첫 번째 노드는 50개의 독립 실행형 데이터베이스를 보호하고 두 노드 모두 5개의 AG 데이터베이스를 보호합니다. 사실상 노드 1에는 55개의 데이터베이스 백업 작업이 예약되어 있는 반면, 노드 2에는 5개만 있습니다. 또한 이러한 모든 백업은 1시간마다 동시에 실행되도록 구성됩니다. 한 시점에 55개의 모든 백업이 노드 1에서 트리거되고 이 중 35개가 큐에 대기됩니다. 그중 일부는 AG 데이터베이스 백업입니다. 그러나 노드 2에서는 AG 데이터베이스 백업이 큐에 대기하지 않고 계속 진행됩니다.
AG 데이터베이스 작업이 한 노드에서 큐에 대기하고 있으므로 다른 노드에서 실행되면 백업 동기화(섹션 6에서 설명)가 제대로 작동하지 않습니다. 노드 2는 노드 1이 다운된 것으로 간주할 수 있으므로 노드 1의 작업은 동기화에 사용되지 않습니다. 이 경우 두 노드가 독립적으로 백업을 수행할 수 있으므로 로그 체인 중단 또는 추가 백업이 발생할 수 있습니다.
보호되는 AG 데이터베이스 수가 제한 한도를 초과하는 경우에도 유사한 문제가 발생할 수 있습니다. 이러한 경우 DB1에 대한 백업은 노드 1에서 큐에 대기하는 반면, 노드 2에서 실행할 수 있습니다.
이러한 동기화 문제를 방지하려면 다음 백업 기본 설정을 사용하는 것이 좋습니다.
- 2 노드 AG의 경우 백업 기본 설정을 주 또는 보조만으로 설정합니다. 그러면, 하나의 노드만 백업을 수행할 수 있고 다른 노드는 항상 제외됩니다.
- 노드가 2개 이상인 AG의 경우 백업 기본 설정을 주로 설정합니다. 그러면, 주 노드만 백업을 수행할 수 있고 다른 노드는 제외됩니다.
AG 백업에 대한 청구
독립 실행형 SQL 인스턴스와 동일하게 백업된 하나의 AG 인스턴스는 하나의 보호된 인스턴스로 간주됩니다. 인스턴스 내 모든 보호된 데이터베이스의 총 프런트 엔드 크기가 청구됩니다. 다음 배포를 고려하세요.
보호된 인스턴스는 다음과 같이 계산됩니다.
| 보호된 인스턴스/청구 인스턴스 | 프런트 엔드 크기 계산을 위해 고려되는 데이터베이스 |
|---|---|
| AG1 | DB1, DB2 |
| AG2 | DB4 |
| VM2 | DB3 |
| VM3 | DB6 |
| VM4 | DB5 |
AG로 또는 AG에서 보호된 데이터베이스 이동
Azure Backup은 SQL 인스턴스 또는 AG 이름\데이터베이스 이름을 데이터베이스의 고유한 이름으로 간주합니다. 독립 실행형 DB를 보호하는 경우 그 고유한 이름은 StandAloneInstanceName\DBName였습니다. AG로 이동하면 고유 이름이 AGName\DBName으로 변경됩니다. 독립 실행형 데이터베이스에 대한 백업이 오류 코드(UserErrorBackupFailedStandaloneDatabaseMovedInToAG)와 함께 실패하기 시작합니다.
AG 아래에서 보호하도록 데이터베이스를 구성해야 합니다. 이는 별도의 복구 지점 체인을 사용하여 새 데이터 원본으로 처리됩니다. 독립 실행형 데이터베이스의 이전 보호는 데이터 보존으로 중지되어 향후 백업에서 트리거 및 실패를 방지할 수 있습니다. 마찬가지로, 보호된 AG 데이터베이스가 AG 외부로 이동하여 독립 실행형 데이터베이스가 되면 백업이 오류 코드(UserErrorBackupFailedDatabaseMovedOutOfAG)와 함께 실패하기 시작합니다.
독립 실행형 인스턴스 아래에서 보호하도록 데이터베이스를 구성해야 합니다. 이는 별도의 복구 지점 체인을 사용하여 새 데이터 원본으로 처리됩니다. AG 데이터베이스의 이전 보호는 데이터 보존으로 중지되어 향후 백업에서 트리거 및 실패를 방지할 수 있습니다.
AG에서 노드 추가/제거
백업에 대해 구성된 AG에 새 노드를 추가하면 이미 등록된 AG 노드에서 실행되는 워크로드 백업 확장이 AG 토폴로지 변경 내용을 검색하고 다음에 예약된 데이터베이스 검색 작업을 수행하는 동안 Azure Backup 서비스에 알립니다. 이 새 노드가 백업을 위해 다른 기존 노드와 동일한 Recovery Services 자격 증명 모음에 등록되면 Azure Backup 서비스는 AG 백업을 수행하는 데 필요한 메타데이터를 사용하여 이 새 노드를 구성하는 워크플로를 트리거합니다.
그 후에 새 노드가 Azure Backup 서비스에서 AG 백업 일정 정보를 동기화하고 동기화된 백업 프로세스에 참여하기 시작합니다. 새 노드가 백업 일정을 동기화할 수 없고 백업에 참여할 수 없는 경우 노드에서 다시 등록을 트리거하면 AG 백업을 위한 노드도 강제로 재구성됩니다. 마찬가지로 워크로드 확장인 노드 추가는 이 경우 AG 토폴로지 변경을 감지하고 Azure Backup 서비스에 알립니다. 이 서비스는 제거된 노드에서 노드 구성 취소 워크플로를 시작하여 AG 데이터베이스의 백업 일정을 지우고 AG 관련 메타데이터를 삭제합니다.
Azure Backup에서 AG 노드 등록 취소
노드가 백업에 대해 하나 이상의 데이터베이스가 구성된 AG의 일부인 경우에는 Azure Backup에서 해당 노드의 등록을 취소할 수 없습니다. 이는 이 노드 없이 백업 기본 설정을 충족할 수 없는 경우 향후 백업 실패를 방지하기 위한 것입니다. 노드의 등록을 취소하려면 먼저 AG에서 제거해야 합니다. 노드 구성 취소 워크플로가 완료되어 해당 노드가 정리되면 등록을 취소할 수 있습니다.
Azure Backup에서 AG SQL 가용성 그룹으로 데이터베이스를 복원하는 경우 AG로 직접 데이터베이스를 복원하지 않습니다. 데이터베이스를 독립 실행형 SQL 인스턴스로 복원한 다음 AG에 조인해야 합니다.
SQL 데이터베이스 서버에 대한 가용성 그룹 다시 만들기 시나리오
AG(가용성 그룹) 다시 생성, 중복 AG 및 백업 항목은 다음 시나리오에서 보호 가능한 항목 또는 보호되는 항목으로 나열됩니다.
이미 보호된 AG를 다시 만들면 백업 구성 페이지와 보호된 항목 목록에 중복 AG로 표시됩니다. 이전 AG에 이미 있는 백업 데이터를 유지하려면 새 AG 항목에서 백업을 다시 만들고 예약하기 전에 보호 중지 및 데이터 보존 옵션을 사용하여 백업을 중지합니다.
기본적으로 Azure Backup은 보호된 항목 목록, 백업 구성 페이지 또는 보호 가능한 항목 목록에서 중복 항목을 나열하고 백업 데이터를 보존할 때까지 이러한 항목을 표시합니다.
이전 AG의 백업 데이터를 원하지 않는 경우 새 AG에서 백업을 다시 만들고 예약하기 전에 이전 항목에 대해 보호 중지 및 데이터 삭제 옵션을 사용하여 백업 작업을 중지합니다.
주의
보호를 중지하고 데이터를 삭제하는 것은 파괴적인 작업입니다.
위의 보호 중지 프로세스 중 하나를 수행한 후 AG를 다시 만들어 백업 오류를 방지할 수 있습니다.
다음 단계
다음의 방법을 알아보세요.