다음을 통해 공유

하이퍼스케일 데이터베이스의 자동화된 백업

  • 아티클

적용 대상: Azure SQL Database

이 문서에서는 Azure SQL Database에서 하이퍼스케일 데이터베이스를 사용하는 자동화된 백업 기능을 설명합니다.

하이퍼스케일 데이터베이스는 확장성이 뛰어난 스토리지 및 컴퓨팅 성능 계층과 함께 고유한 아키텍처를 사용합니다. 하이퍼스케일 백업은 스냅샷을 기반으로 하며 거의 즉각적입니다. 로그 백업은 백업 보존 기간 동안 장기간 Azure Storage에 저장됩니다.

하이퍼스케일 아키텍처는 전체, 차등 또는 로그 백업이 필요 없습니다. 따라서 백업 빈도, 스토리지 비용, 일정 예약, 스토리지 중복성 및 복원 기능이 Azure SQL Database의 다른 데이터베이스와 다릅니다.

백업 및 복원 성능

스토리지와 컴퓨팅이 분리되는 하이퍼스케일은 백업 및 복원 작업을 스토리지 계층으로 푸시 다운하여 기본 컴퓨팅 복제본의 리소스 사용을 없앨 수 있습니다. 데이터베이스 백업은 주 또는 보조 컴퓨팅 복제본의 성능에 영향을 주지 않습니다.

하이퍼스케일 데이터베이스의 백업 및 복원 작업은 스토리지 스냅샷을 사용하기 때문에 데이터 크기에 관계없이 빠릅니다. 백업이 거의 즉시 이루어집니다.

다음과 같은 방법을 통해 백업 보존 기간 내의 특정 시점으로 데이터베이스를 복원할 수 있습니다.

  1. 해당하는 파일 스냅샷으로 되돌립니다.
  2. 트랜잭션 로그를 적용하여 복원된 데이터베이스의 트랜잭션이 일치하도록 만듭니다.

따라서 복원은 동일한 기본 데이터 크기 작업이 아닙니다. 동일한 Azure 지역 내에 하이퍼스케일 데이터베이스 복원은 수 테라바이트 데이터베이스의 경우에도 몇 시간 또는 며칠이 아닌 몇 분 안에 완료됩니다.

복원을 실행할 때 스토리지 중복도를 변경하면 복원이 데이터 크기이므로 복원 시간이 길어질 수 있으므로 시간이 데이터베이스 크기에 비례합니다.

기존 백업을 복원하거나 데이터베이스를 복사하여 새 데이터베이스를 만들면 하이퍼스케일에서 컴퓨팅과 스토리지의 분리를 활용할 수도 있습니다. 동일한 스토리지 형식을 사용하면 데이터베이스 크기가 수 테라바이트에 달하는 경우에도 개발 또는 테스트 목적으로 데이터베이스 복사본을 몇 분 만에 만들 수 있습니다.

백업 보존

하이퍼스케일 데이터베이스의 기본 단기 백업 보존 기간은 7일입니다.

1~35일 범위의 백업의 단기 보존 및 하이퍼스케일 데이터베이스에 대한 LTR(장기 백업 보존) 기능은 2023년 9월부터 일반적으로 사용할 수 있습니다. 장기 보존에 대한 자세한 내용은 장기 보존 - Azure SQL 데이터베이스 및 Azure SQL Managed Instance를 참조하세요.

백업 일정 예약

하이퍼스케일 데이터베이스에는 기존의 전체, 차등 및 트랜잭션 로그 백업이 없습니다. 대신 데이터 파일의 일반 스토리지 스냅샷이 있습니다.

생성된 트랜잭션 로그는 구성된 보존 기간 동안 그대로 보존됩니다. 복원 시 관련 트랜잭션 로그 레코드가 복원된 스토리지 스냅샷에 적용됩니다. 그 결과로 보존 기간 내에서 지정된 특정 시점을 기준으로 데이터 손실 없이 트랜잭션 측면에서 데이터베이스의 일관성이 유지됩니다.

백업 스토리지 사용 모니터링

하이퍼스케일에서 Azure Monitor 메트릭은 다음과 같은 사용 정보를 보고합니다.

  • 데이터 백업 스토리지 크기(스냅샷 백업 크기)
  • 데이터 스토리지 크기(할당된 데이터베이스 크기)
  • 로그 백업 스토리지 크기(트랜잭션 로그 백업 크기)

Azure Portal에서 백업 및 데이터 스토리지 메트릭을 보려면 다음 단계를 수행합니다.

  1. 백업 및 데이터 스토리지 메트릭을 모니터링하려는 하이퍼스케일 데이터베이스로 이동합니다.
  2. 모니터링 섹션에서 메트릭 페이지를 선택합니다.
  3. 메트릭 드롭다운 목록에서 적절한 집계 규칙과 함께 데이터 백업 스토리지, 데이터 스토리지 크기 및 로그 백업 스토리지 메트릭을 선택합니다.

하이퍼스케일 백업 스토리지 사용량을 볼 수 있는 선택 사항을 보여주는 Azure Portal의 스크린샷

백업 스토리지 사용량 감소

하이퍼스케일 데이터베이스에 대한 백업 스토리지 사용량은 보존 기간, 지역 선택, 백업 스토리지 중복성 및 워크로드 유형에 따라 달라집니다. 하이퍼스케일 데이터베이스에 대한 백업 스토리지 사용량을 줄이기 위해 다음과 같은 몇 가지 튜닝 기법을 고려합니다.

  • 백업 보존 기간을 사용자 요구에 따라 최소 기간으로 줄입니다.
  • 인덱스 유지 관리와 같은 대규모 쓰기 작업을 필요 이상으로 자주 수행하는 것을 피해야 합니다. 인덱스 유지 관리에 대한 권장 사항은 쿼리 성능 향상 및 리소스 소비 감소를 위한 인덱스 유지 관리 최적화를 참조하세요.
  • 대규모 데이터 로드 작업의 경우 적절한 경우 데이터 압축을 사용하는 것이 좋습니다.
  • 임시 결과 및/또는 임시 데이터를 저장하기 위해 애플리케이션 논리에서 영구 테이블 대신 tempdb 데이터베이스를 사용합니다.
  • 지역 복원 기능이 필요하지 않은 경우(예: 개발/테스트 환경) 로컬 중복 또는 영역 중복 백업 스토리지를 사용합니다.

백업 스토리지 비용

하이퍼스케일 백업 스토리지 비용은 선택한 지역 및 백업 스토리지 중복성에 따라 달라집니다. 또한 워크로드 유형에 따라서도 달라집니다.

쓰기 작업이 많은 워크로드는 데이터 페이지를 자주 변경할 가능성이 높으므로 스토리지 스냅샷이 더 커집니다. 이러한 워크로드는 더 많은 트랜잭션 로그를 생성하여 전체 백업 비용에도 영향을 미칩니다. 백업 스토리지는 매월 사용한 양(기가바이트)에 따라 요금이 청구됩니다. 가격 책정에 대한 자세한 내용은 Azure SQL Database 가격 책정 페이지를 참조하세요.

하이퍼스케일의 경우 청구 가능한 백업 스토리지는 다음과 같이 계산됩니다.

Total billable backup storage size = (data backup storage size + log backup storage size)

데이터 스토리지 크기는 이미 할당된 데이터베이스 스토리지로 청구되므로 청구 가능한 백업에 포함되지 않습니다.

삭제된 하이퍼스케일 데이터베이스는 삭제 전 특정 시점까지 복구를 지원하기 위한 백업 비용이 발생합니다. 삭제된 하이퍼스케일 데이터베이스의 경우 청구 가능한 백업 스토리지는 다음과 같이 계산됩니다.

Total billable backup storage size for deleted Hyperscale database = (data storage size + data backup size + log backup storage size) * (remaining backup retention period after deletion / configured backup retention period)

데이터 스토리지 크기가 수식에 포함되는 이유는 할당된 데이터베이스 스토리지는 삭제된 데이터베이스에 대해 별도로 청구되지 않기 때문입니다. 삭제된 데이터베이스의 경우 데이터는 구성된 백업 보존 기간 동안 복구할 수 있도록 삭제 후 저장됩니다.

삭제된 데이터베이스에 대한 청구 가능한 백업 스토리지는 삭제된 후 시간이 지남에 따라 점진적으로 감소합니다. 백업이 더 이상 유지되지 않고 복구가 더 이상 가능하지 않으면 0이 됩니다. 영구 삭제이고 백업이 더 이상 필요 없는 경우 데이터베이스를 삭제하기 전에 보존 기간을 줄여 비용을 최적화할 수 있습니다.

백업 비용 모니터링

백업 스토리지 비용을 이해하려면 다음을 수행합니다.

  1. Azure Portal에서 Cost Management + Billing으로 이동합니다.

  2. Cost Management>비용 분석을 차례로 선택합니다.

  3. 범위에서 원하는 구독을 선택합니다.

  4. 다음 단계에 따라 관심 있는 기간 및 서비스를 필터링합니다.

    1. 서비스 이름에 대한 필터를 추가합니다.
    2. 드롭다운 목록에서 sql-database를 선택합니다.
    3. 미터에 대한 또 다른 필터를 추가합니다.
    4. 특정 시점 복구의 백업 비용을 모니터링하려면 드롭다운 목록에서 저장된 데이터 - 백업 - RA를 선택합니다.

다음 스크린샷은 비용 분석 예제를 보여줍니다.

하이퍼스케일 백업 스토리지 비용을 보여주는 Azure Portal의 스크린샷

데이터 및 백업 스토리지 중복성

하이퍼스케일은 구성 가능한 스토리지 중복성을 지원합니다. 하이퍼스케일 데이터베이스를 만들 때 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지), RA-GRS(읽기 액세스 지역 중복 스토리지), ZRS(영역 중복 스토리지) 또는 LRS(로컬 중복 스토리지) 중에서 원하는 스토리지 유형을 선택할 수 있습니다.

  • 지역 영역 중복 스토리지: 주 지역에 있는 3개의 Azure 가용성 영역에서 백업을 동기적으로 복사합니다. ZRS(영역 중복 스토리지)와 비슷합니다. 또한 쌍을 이룬 보조 지역의 단일 물리적 위치에 데이터를 비동기적으로 복사합니다. 현재 특정 지역에서만 사용할 수 있습니다.

다른 스토리지 유형에 대한 백업을 복제하는 방법을 알아보려면 백업 스토리지 중복도를 참조하세요.

하이퍼스케일은 백업에 스토리지 스냅샷을 사용하므로 데이터 및 백업은 동일한 스토리지 계정을 공유합니다. 따라서 선택한 백업 스토리지 중복은 데이터와 백업 모두에 적용됩니다.

참고 항목

백업 스토리지 중복성은 데이터베이스를 만드는 동안에만 설정할 수 있으므로, 하이퍼스케일 데이터베이스를 만들 때 백업 스토리지 중복성을 신중하게 고려해야 합니다. 리소스가 프로비저닝된 후에는 이 설정을 수정할 수 없습니다.

가동 중지 시간을 최소화하면서 기존 하이퍼스케일 데이터베이스의 백업 스토리지 중복성 설정을 업데이트하려면 활성 지역 복제를 사용합니다. 또는 데이터베이스 복사본을 사용해도 됩니다.

경고

  • 로컬 또는 영역 중복 스토리지를 사용하도록 데이터베이스를 업데이트하는 즉시 지역 복원이 사용되지 않습니다.
  • 영역 중복 스토리지는 현재 특정 지역에서만 사용할 수 있습니다.
  • 지역 영역 중복 스토리지는 현재 특정 지역에서만 사용할 수 있습니다.

하이퍼스케일 데이터베이스를 다른 지역으로 복원

하이퍼스케일 데이터베이스를 현재 지역과 다른 지역에 복원해야 할 때가 있습니다. 일반적인 원인으로는 재해 복구 작업, 훈련 또는 재배치가 있습니다. 기본 방법은 데이터베이스를 지역 복원하는 것입니다. Azure SQL Database의 다른 데이터베이스를 다른 지역으로 복원하는 데 사용하는 것과 동일한 단계를 사용합니다.

  1. 적절한 서버가 아직 없는 경우 서버를 대상 지역에 만듭니다. 이 서버는 원래(원본) 서버와 동일한 구독에서 소유해야 합니다.
  2. 자동 백업에서 Azure SQL Database의 데이터베이스를 복원하는 방법에 대한 페이지의 지역 복원 섹션에 있는 지침을 따릅니다.

참고

원본과 대상이 별도의 지역에 있으므로, 비지역 복원처럼 데이터베이스가 스냅샷 스토리지를 원본 데이터베이스와 공유할 수 없습니다. 비지역 복원은 데이터베이스 크기에 관계없이 빠르게 완료됩니다.

대상이 쌍을 이루는 지역 복제 스토리지 지역에 있는 경우에도 하이퍼스케일 데이터베이스의 지역 복원은 데이터 크기 작업입니다. 따라서 지역 복원은 동일한 지역에 특정 시점으로 복원하는 것보다 훨씬 오래 걸립니다.

대상이 쌍을 이루는 지역에 있는 경우 데이터 전송은 지역 내에서 수행됩니다. 이 전송은 지역 간 데이터 전송보다 훨씬 빠릅니다. 그러나 여전히 데이터 크기 작업입니다.

원한다면 데이터베이스를 다른 지역에 복사할 수 있습니다. 선택한 스토리지 중복 유형에서 지역 복원이 지원되지 않아 사용할 수 없는 경우에는 이 방법을 사용합니다. 자세한 내용은 하이퍼스케일에 대한 데이터베이스 복사를 참조하세요.

관련 콘텐츠

데이터베이스 백업은 실수로 손상되거나 삭제되지 않도록 데이터를 보호해 주기 때문에 비즈니스 연속성 및 재해 복구 전략의 필수적인 부분입니다.