Azure Database for PostgreSQL 유연한 서버의 백업 및 복원(미리 보기)

적용 대상: Azure Database for MySQL - 유연한 서버

중요

Azure Database for MySQL - 유연한 서버는 현재 공개 미리 보기로 제공됩니다.

Azure Database for MySQL 유연한 서버는 자동으로 서버 백업을 만들고 지역 내의 로컬 중복 스토리지에 안전하게 저장합니다. 백업을 사용하여 특정 시점의 서버를 복원할 수 있습니다. 백업 및 복원은 실수로 인한 손상이나 삭제로부터 데이터를 보호하므로 비즈니스 연속성 전략의 필수적인 부분입니다.

Backup 개요

유연한 서버는 데이터 파일의 스냅샷 백업을 사용하여 로컬 중복 스토리지에 저장합니다. 또한 서버는 트랜잭션 로그 백업을 수행하고 로컬 중복 스토리지에도 저장합니다. 이러한 백업을 사용하면 서버를 구성된 백업 보존 기간 내의 특정 시점으로 복원할 수 있습니다. 기본 백업 보존 기간은 7일입니다. 필요에 따라 데이터베이스 백업을 1-35일로 구성할 수 있습니다. 모든 백업은 저장된 미사용 데이터에 대한 AES 256비트 암호화를 사용하여 암호화됩니다.

이러한 백업 파일은 내보낼 수 없습니다. 백업은 유연한 서버의 복원 작업에만 사용할 수 있습니다. MySQL 클라이언트에서 mysqldump를 사용하여 데이터베이스를 복사할 수도 있습니다.

Backup 주기

유연한 서버의 백업은 스냅샷 기반입니다. 첫 번째 스냅샷 백업은 서버를 만든 직후에 예약됩니다. 스냅샷 백업은 매일 한 번 수행됩니다. 트랜잭션 로그 백업은 5분마다 발생합니다.

백업 중복 옵션

Azure Database for MySQL는 일시적인 하드웨어 오류, 네트워크 또는 정전, 대규모 자연 재해 등의 계획 되거나 계획 되지 않은 이벤트에서 데이터가 보호 되도록 백업 복사본을 여러 개 저장 합니다. Azure Database for MySQL는 기본, 범용 및 메모리 최적화 계층에서 로컬 중복, 영역 중복 또는 지역 중복 백업 저장소 중에서 선택할 수 있는 유연성을 제공 합니다. 기본적으로 Azure Database for MySQL 서버 백업 저장소는 동일한 영역 고가용성 (HA)을 사용 하는 서버와 영역 중복 HA 구성이 있는 서버에 대 한 영역 중복의 서버에 대해 로컬로 중복 됩니다.

백업 중복성은 오류가 발생 Azure Database for MySQL 하는 경우에도 데이터베이스가 가용성 및 내구성 목표를 충족 하 고 사용자에 게 세 가지 옵션을 확장 하도록 보장 합니다.

  • 로컬 중복 백업 저장소 : 백업이 로컬 중복 백업 저장소에 저장 되는 경우 여러 백업 복사본이 동일한 데이터 센터에 저장 됩니다. 이 옵션은 서버 랙 및 드라이브 오류 로부터 데이터를 보호 합니다. 또한이는 지정 된 연도에 대해 최소 99.999999999% (11 9)의 백업 개체 내 구성을 제공 합니다. 기본적으로 동일한 영역 HA (고가용성)를 사용 하는 서버에 대 한 백업 저장소는 로컬 중복으로 설정 됩니다.

  • 영역 중복 백업 저장소 : 백업이 영역 중복 백업 저장소에 저장 되는 경우 여러 복사본이 서버가 호스트 되는 가용성 영역 내에 저장 되는 것이 아니라 동일한 지역의 다른 가용성 영역에도 복제 됩니다. 이 옵션은 데이터 상주 요구 사항을 충족 하기 위해 국가/지역 내에서 데이터 복제를 제한 하거나 고가용성을 요구 하는 시나리오에 활용할 수 있습니다. 또한이는 지정 된 기간 동안 백업 개체의 최소 99.9999999999% (12 9) 내 구성을 제공 합니다. 서버 만든 시간에 Zone-Redundant 고가용성 옵션을 선택 하 여 영역 중복 백업 저장소를 보장할 수 있습니다. 서버에 대 한 고가용성은 사후 만들기를 사용 하지 않도록 설정할 수 있지만 백업 저장소는 영역 중복으로 계속 유지 됩니다.

  • 지역 중복 백업 저장소 : 백업이 지역 중복 백업 저장소에 저장 되는 경우 여러 복사본이 서버를 호스트 하는 지역 내에 저장 되는 것이 아니라 지역 쌍 지역에도 복제 됩니다. 이렇게 하면 재해 발생 시 다른 지역에서 서버를 복원하는 데 더 효율적인 보호와 기능을 제공합니다. 또한 지정 된 연도에 대해 최소 99.99999999999999% (16 9)의 백업 개체 내구성이 제공 됩니다. 서버를 만들 때 Geo-Redundancy 옵션을 사용 하도록 설정 하 여 지역 중복 백업 저장소를 보장할 수 있습니다. 지리적 중복성은 Azure 쌍을 이루는 지역에서 호스트 되는 서버에 대해 지원 됩니다.

참고

영역 중복성을 지원 하기 위한 지역 중복 및 영역 중복 고가용성은 현재 만들기 시간 작업 으로만 표시 됩니다.

다른 백업 저장소 옵션에서 지역 중복 백업 저장소로 이동

백업을 위한 지역 중복 스토리지 구성은 서버 생성 중에만 허용됩니다. 서버가 프로비전되면 백업 스토리지 중복 옵션을 변경할 수 없습니다. 그러나 다음과 같은 제안 된 방법을 사용 하 여 기존 백업 저장소를 지역 중복 저장소로 계속 이동할 수 있습니다.

  • 로컬 중복에서 지역 중복 백업 저장소로 이동 -백업 저장소를 로컬 중복 저장소에서 지역 중복 저장소로 이동 하기 위해 지정 시간 복원 작업을 수행 하 고 계산 + Storage 서버 구성을 변경 하 여 로컬 중복 원본 서버에 대해 지역 중복을 사용 하도록 설정할 수 있습니다. 동일한 영역 중복 HA 서버는 기본 백업 저장소가 동일 하 게 중복 되는 것과 비슷한 방식으로 지역 중복 서버로 복원 될 수도 있습니다.

  • 영역 중복에서 지역 중복 백업 저장소-Azure Database for MySQL로 이동 하면 계산 + Storage 설정 변경 또는 지정 시간 복원 작업을 통해 지역 중복 저장소 변환에 대 한 영역 중복 저장소를 지원 하지 않습니다. 백업 저장소를 영역 중복 저장소에서 지역 중복 저장소로 이동 하기 위해 새 서버를 만들고 dump 및 restore 를 사용 하 여 데이터를 마이그레이션하는 것은 유일 하 게 지원 되는 옵션입니다.

백업 보존

백업은 서버의 백업 보존 기간에 따라 보존됩니다. 1-35일의 보존 기간을 선택할 수 있고 기본 보존 기간은 7일입니다. 서버 생성 도중이나 Azure Portal을 사용하여 나중에 백업 구성을 업데이트하여 보존 기간을 설정할 수 있습니다.

백업 보존 기간은 사용 가능한 백업을 기반으로 하기 때문에 특정 시점 복원 작업을 수행할 수 있는 시간을 제어합니다. 백업 보존 기간은 복원 관점에서 복구 기간으로 취급될 수도 있습니다. 백업 보존 기간 내에 특정 시점 복원을 수행하기 위해 필요한 모든 백업이 백업 스토리지에 보존됩니다. 예를 들어 백업 보존 기간이 7일로 설정되었으면 복구 기간은 최근 7일로 간주됩니다. 이 시나리오에서는 최근 7일 동안 서버 복원에 필요한 모든 백업이 보존됩니다. 7일의 백업 보존 기간을 사용하는 경우 데이터베이스 스냅샷 및 트랜잭션 로그 백업은 마지막 8일 동안(기간 1일 전) 저장됩니다.

백업 스토리지 비용

유연한 서버는 추가 비용 없이 최대 100%의 프로비저닝된 서버 스토리지를 백업 스토리지로 제공합니다. 사용되는 모든 추가 백업 스토리지는 매월 GB 단위로 청구됩니다. 예를 들어 250GB 스토리지 서버를 프로비전한 경우 서버 백업에 250GB의 스토리지를 추가 비용 없이 이용할 수 있습니다. 매일 백업 사용량이 25GB이면 최대 10일 동안 체험용 백업 스토리지를 사용할 수 있습니다. 250GB를 초과하여 백업에 소비된 스토리지는 가격 책정 모델에 따라 비용이 청구됩니다.

Azure Portal에서 제공되는 Azure Monitor의 사용된 백업 스토리지 메트릭을 사용하여 서버에서 사용된 백업 스토리지를 모니터링할 수 있습니다. 사용된 백업 스토리지 메트릭은 서버에 대해 설정된 백업 보존 기간에 따라 유지되는 모든 데이터베이스 백업 및 로그 백업에서 사용하는 스토리지의 합계를 나타냅니다. 서버에서 과도한 트랜잭션 작업을 수행하면 전체 데이터베이스 크기에 관계없이 백업 스토리지 사용량이 증가할 수 있습니다. 지역 중복 서버에 사용 되는 백업 저장소는 로컬 중복 서버의 두 배입니다.

백업 스토리지 비용을 제어하는 기본적인 방법은 적절한 백업 보존 기간을 설정하는 것입니다. 1-35일 사이의 보존 기간을 선택할 수 있습니다.

중요

영역 중복 고가용성 구성으로 구성된 데이터베이스 서버에서의 백업은 스냅샷 백업의 경우 오버헤드가 최소한이므로 주 데이터베이스 서버에서 수행됩니다.

복원

Azure Database for MySQL에서 복원을 수행하면 원래 서버의 백업에서 새 서버가 만들어집니다. 사용할 수 있는 두 가지 유형의 복원이 있습니다.

  • 지정 시간 복원:는 백업 중복성 옵션과 함께 사용할 수 있으며, 원본 서버와 동일한 지역에 새 서버를 만듭니다.
  • 지역 복원:은 지역 중복 저장소에 대해 서버를 구성 하 고 지리적으로 쌍을 이루는 지역으로 서버를 복원할 수 있는 경우에만 사용할 수 있습니다. 다른 지역으로의 지역 복원은 현재 지원 되지 않습니다.

서버 복구의 예상 시간은 여러 요인에 따라 달라집니다.

  • 데이터베이스의 크기
  • 관련된 트랜잭션 로그의 수
  • 복원 지점으로 복구하기 위해 재생해야 하는 작업의 양
  • 다른 지역으로 복원되는 경우의 네트워크 대역폭
  • 대상 지역에서 처리되는 동시 복원 요청 개수
  • 데이터베이스에 있는 테이블에 기본 키가 있는지 여부입니다. 빠른 복구를 위해서는 데이터베이스에서 모든 테이블에 기본 키를 추가하는 것이 좋습니다.

참고

사용 가능한 고가용성 서버는 지정 시간 복원 및 지역 복원 모두에 대해 복원 후 비 HA (고가용성 사용 안 함) 서버가 됩니다.

지정 시간 복원

Azure Database for MySQL 유연한 서버에서 특정 시점 복원을 수행하면 원본 서버와 동일한 지역에 있는 유연한 서버의 백업에서 새 서버가 만들어집니다. 이 경우 컴퓨팅 계층, vCore 수, 스토리지 크기, 백업 보존 기간 및 백업 중복 옵션에 대한 원래 서버의 구성으로 만들어집니다. 또한 가상 네트워크 및 방화벽과 같은 태그와 설정은 원본 서버에서 상속됩니다. 복원이 완료된 후 복원된 서버의 컴퓨팅 및 스토리지 계층, 구성 및 보안 설정을 변경할 수 있습니다.

참고

복원 작업 후 기본값으로 재설정되는(그리고 주 서버에서 복사되지 않는) 두 개의 서버 매개변수가 있습니다.

  • time_zone - 이 값은 기본값 SYSTEM으로 설정됩니다.
  • event_scheduler - event_scheduler는 복원된 서버에서 OFF로 설정됩니다.

특정 시점 복원은 여러 시나리오에서 유용합니다. 몇 가지 일반적인 사용 사례는 다음과 같습니다.

  • 사용자가 데이터베이스의 데이터를 실수로 삭제하는 경우
  • 사용자가 중요한 테이블 또는 데이터베이스를 삭제
  • 사용자 애플리케이션 결함으로 인해 실수로 적절한 데이터를 잘못된 데이터로 덮어쓸 수도 있습니다.

Azure Portal를 통해 최신 복원 지점과 사용자 지정 복원 지점 사이에서 선택할 수 있습니다.

  • 최신 복원 지점: 최신 복원 지점 옵션을 사용하면 복원 작업이 트리거되었을 때의 타임스탬프로 서버를 복원할 수 있습니다. 이 옵션은 서버를 가장 많이 업데이트된 상태로 신속하게 복원하는 데 유용합니다.
  • 사용자 지정 복원 지점:이 옵션을 사용하면 유연한 서버에 대해 정의된 보존 기간 내의 시점을 선택할 수 있습니다. 이 옵션은 사용자 오류로부터 복구하기 위해 정확한 시점에 서버를 복원하는 데 유용합니다.

예상 복구 시간은 데이터베이스 크기, 트랜잭션 로그 백업 크기, SKU의 컴퓨팅 크기, 복원 시간까지 포함하여 여러 가지 요인에 따라 달라집니다. 트랜잭션 로그 복구는 복원 프로세스에서 가장 시간이 많이 소요되는 부분입니다. 복원 시간이 스냅샷 백업 일정에 더 가깝게 선택된 경우 트랜잭션 로그 애플리케이션이 최소한이므로 복원 작업이 더 빠릅니다. 서버에 대한 정확한 복구 시간을 추정하려면 환경별 변수가 너무 많기 때문에 사용자의 환경에서 테스트하는 것이 좋습니다.

중요

영역 중복 고가용성을 사용하여 구성된 유연한 서버를 복원하는 경우 복원된 서버는 주 서버와 동일한 지역 및 영역에 구성되고 비 HA 모드에서 단일 유연한 서버로 배포됩니다. 유연한 서버에 대해서는 영역 중복 고가용성을 참조하세요.

중요

삭제된 서버는 복원할 수 없습니다. 서버를 삭제하면 해당 서버에 속한 모든 데이터베이스도 삭제되고 복구할 수 없습니다. 배포 후에 실수로 인한 삭제 또는 예기치 않은 변경에서 서버 리소스를 보호하려면 관리자는 관리 잠금을 활용할 수 있습니다.

지역 복원

지역 중복 백업을 위한 서버를 구성한 경우 해당 서비스를 사용할 수 있는 지리적으로 쌍을 이루는 지역 으로 서버를 복원할 수 있습니다. 다른 지역으로의 지역 복원은 현재 지원 되지 않습니다.

지역 복원은 서버가 호스팅되는 지역에 사고가 발생하여 서버를 사용할 수 없는 경우에 대비한 기본 복구 옵션입니다. 지역에서 발생한 대규모 사고로 인해 데이터베이스 애플리케이션을 사용할 수 없는 경우 지역 중복 백업에서 다른 지역에 있는 서버로 서버를 복원할 수 있습니다. 지리적 복원에는 서버의 최신 백업이 활용됩니다. 백업을 수행할 때와 다른 지역으로 복제할 때 사이에 지연이 있습니다. 재해가 발생한 경우 최대 1시간 동안의 데이터가 손실되므로 이 지연은 최대 1시간일 수 있습니다.

지역에서 복원 하는 동안 변경할 수 있는 서버 구성에는 보안 구성 (방화벽 규칙 및 가상 네트워크 설정)만 포함 됩니다. 지역 복원 중 계산, 저장소 또는 가격 책정 계층 (기본, 범용 또는 메모리 액세스에 최적화 됨)과 같은 기타 서버 구성 변경은 지원 되지 않습니다.

예상 복구 시간은 데이터베이스 크기, 트랜잭션 로그 크기, 네트워크 대역폭 및 동일한 지역에서 동시에 복구되는 데이터베이스의 총 수를 포함한 여러 요소에 따라 달라집니다.

참고

영역 중복 고가용성으로 구성 된 유연한 서버를 지리적으로 복원 하는 경우 복원 된 서버는 지리적으로 쌍을 이루는 지역 및 주 서버와 동일한 영역에 구성 되 고 비 HA 모드로 단일 유연한 서버로 배포 됩니다. 유연한 서버에 대해서는 영역 중복 고가용성을 참조하세요.

중요

주 지역이 다운 된 경우 주 지역에서 저장소를 프로 비전 할 수 없기 때문에 지리적으로 쌍을 이루는 지역에 지역 중복 서버를 만들 수 없습니다. 지리적으로 쌍을 이루는 지역에서 지역 중복 서버를 프로 비전 하기 위해 주 지역이 준비 될 때까지 기다려야 합니다. 주 지역에서 아래로 이동 하는 경우, 복원 포털 환경에서 지역 중복 옵션을 사용 하지 않도록 설정 하 고, 비즈니스 연속성을 보장 하기 위해 로컬 중복 서버로 복원 하는 방식으로 지역 중복 Storage 옵션을 사용 하지 않도록 설정 하 여 지리적으로 쌍을 이루는 지역으로 원본 서버를 지역 복원할 수 있습니다.

복원 후 작업 수행

최신 복원 지점 또는 사용자 지정 복원 지점 복구 메커니즘에서 복원한 후에 다음 작업을 수행하여 사용자 및 애플리케이션이 다시 백업 및 실행되도록 해야 합니다.

  • 새 서버가 원래 서버를 교체하기 위한 것이라면 클라이언트와 클라이언트 애플리케이션을 새 서버로 리디렉션합니다.
  • 사용자가 연결할 수 있도록 적절한 서버 수준 방화벽 및 가상 네트워크 규칙이 설정되어 있는지 확인합니다.
  • 적절한 로그인 및 데이터베이스 수준 권한이 있는지 확인합니다.
  • 필요에 따라 경고를 구성합니다.

FAQ(질문과 대답)

  • 서버를 백업하려면 어떻게 해야 하나요? 기본적으로 Azure Database for MySQL은 기본 7일 보존 기간으로 전체 서버(생성된 모든 데이터베이스 포함)의 자동화된 백업을 사용하도록 설정합니다. 수동으로 백업을 수행하는 유일한 방법은 여기에 설명된 mysqldump 또는 여기에 설명된 mydumper와 같은 커뮤니티 도구를 사용하는 것입니다. Azure Database for MySQL을 Blob Storage에 백업하려면 기술 커뮤니티 블로그 Blob Storage에 Azure Database 백업을 참조하세요.

  • 장기간 보존되도록 자동 백업을 구성할 수 있나요? 아니요, 현재 자동 백업 보존 기간은 최대 35일까지만 지원됩니다. 수동 백업을 수행하고 장기 보존 요구 사항에 사용할 수 있습니다.

  • 내 서버의 백업 기간은 어떻게 되나요? 사용자 지정할 수 있나요? 첫 번째 스냅샷 백업은 서버를 만든 직후에 예약됩니다. 스냅샷 백업은 매일 한 번 수행됩니다. 트랜잭션 로그 백업은 5분마다 발생합니다. 백업 기간은 기본적으로 Azure에서 관리하며 사용자 지정할 수 없습니다.

  • 내 백업이 암호화되나요? 쿼리 실행 중에 생성된 모든 Azure Database for MySQL 데이터, 백업 및 임시 파일은 AES 256비트 암호화를 사용하여 암호화됩니다. 스토리지 암호화는 항상 켜져 있고 해제할 수 없습니다.

  • 단일/일부 데이터베이스를 복원할 수 있나요? 단일/일부 데이터베이스 또는 테이블 복원은 지원되지 않습니다. 특정 데이터베이스를 복원하려는 경우 특정 시점 복원을 수행한 다음 필요한 테이블 또는 데이터베이스를 추출합니다.

  • 백업 기간 동안 내 서버를 사용할 수 있나요? 예. 백업은 온라인 작업이며 스냅샷 기반입니다. 스냅샷 작업은 몇 초밖에 걸리지 않으며 프로덕션 워크로드를 방해하지 않아 서버의 고가용성을 보장합니다.

  • 서버의 유지 관리 기간을 설정할 때 백업 기간을 고려해야 하나요? 아니요, 백업은 관리되는 서비스의 일부로 내부적으로 트리거되며 관리되는 유지 관리 기간과 관련이 없습니다.

  • 자동 백업은 어디에 저장되며 보존은 어떻게 관리하나요? Azure Database for MySQL은 자동으로 서버 백업을 만들어 사용자가 로컬로 구성한 중복 스토리지 또는 로컬 중복 스토리지에 저장합니다. 이러한 백업 파일을 내보낼 수 없습니다. 기본 백업 보존 기간은 7일입니다. 필요에 따라 데이터베이스 백업을 1-35일로 구성할 수 있습니다.

  • 내 백업의 유효성을 검사하려면 어떻게 해야 하나요? 유효한 백업의 가용성을 검증하는 가장 좋은 방법은 주기적인 특정 시점 복원을 수행하고 백업이 유효하고 복원 가능한지 확인하는 것입니다. 백업 작업이나 파일은 최종 사용자에게 노출되지 않습니다.

  • 백업 사용량은 어디에서 확인할 수 있나요? Azure Portal의 모니터링 탭 - 메트릭 섹션에서 총 백업 사용량을 모니터링하는 데 도움이 되는 사용된 백업 스토리지 메트릭을 찾을 수 있습니다.

  • 서버를 삭제하면 백업은 어떻게 되나요? 서버를 삭제하면 해당 서버에 속한 모든 백업도 삭제되고 복구할 수 없습니다. 배포 후에 실수로 인한 삭제 또는 예기치 않은 변경에서 서버 리소스를 보호하려면 관리자는 관리 잠금을 활용할 수 있습니다.

  • 백업 사용 요금은 어떻게 청구되나요? 유연한 서버는 추가 비용 없이 최대 100%의 프로비저닝된 서버 스토리지를 백업 스토리지로 제공합니다. 사용된 추가 백업 스토리지는 가격 책정 모델에 따라 매월 GB 단위로 청구됩니다. 백업 스토리지 청구는 또한 선택한 백업 보존 기간과 직접 사용되는 총 백업 스토리지에 영향을 미치는 서버의 트랜잭션 작업과는 별도로 선택된 백업 중복성 옵션에 의해 결정됩니다.

  • 중지된 서버의 백업은 어떻게 보존되나요? 중지된 서버에 대해 새 백업은 수행되지 않습니다. 서버를 중지할 때의 모든 이전 백업(보존 기간 내)은 활성 서버에 대한 백업 보존이 백업 보존 기간에 의해 관리되는 이후 서버가 다시 시작될 때까지 보존됩니다.

  • 중지된 서버의 백업 비용은 어떻게 청구되나요? 서버 인스턴스가 중지되는 동안 프로비저닝된 스토리지(프로비저닝된 IOPS 포함) 및 백업 스토리지(지정된 보존 기간 내에 저장된 백업)에 대해 요금이 부과됩니다. 무료 백업 스토리지는 프로비저닝된 데이터베이스의 크기로 제한되며 활성 서버에만 적용됩니다.

  • 서버를 복원하려면 어떻게 해야 하나요? Azure Portal은 사용자가 최신 또는 사용자 지정 복원 지점으로 복원할 수 있도록 특정 시점 복원(모든 서버에 대해)을 지원합니다. mysqldump/myDumper가 수행한 백업에서 서버를 수동으로 복원하려면 myLoader를 사용하여 데이터베이스 복원을 읽어보세요.

  • 복원에 시간이 오래 걸리는 이유는 무엇인가요? 서버 복구의 예상 시간은 여러 요인에 따라 달라집니다.

    • 데이터베이스의 크기. 복구 프로세스의 일부로 데이터베이스는 마지막 물리적 백업에서 하이드레이션되어야 하므로 복구하는 데 걸리는 시간은 데이터베이스 크기에 비례합니다.
    • 복구를 위해 다시 재생해야 하는 트랜잭션 활동의 활성 부분입니다. 마지막으로 성공한 검사점의 추가 트랜잭션 활동에 따라 복구 시간이 더 오래 걸릴 수 있습니다.
    • 다른 지역으로 복원되는 경우의 네트워크 대역폭
    • 대상 지역에서 처리되는 동시 복원 요청 개수
    • 데이터베이스에 있는 테이블에 기본 키가 있는지 여부입니다. 빠른 복구를 위해서는 데이터베이스에서 모든 테이블에 기본 키를 추가하는 것이 좋습니다.

다음 단계