다음을 통해 공유

Azure Database for PostgreSQL - 유연한 서버의 백업 및 복원

  • 아티클

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

백업은 비즈니스 연속성 전략의 필수적인 부분을 형성하고, 우발적인 손상이나 삭제로부터 데이터를 보호하는 데 도움이 됩니다.

Azure Database for PostgreSQL 유연한 서버는 서버의 정기적인 백업을 자동으로 수행합니다. 그런 다음 지정한 보존 기간 내에 PITR(특정 시점 복원)을 수행할 수 있습니다. 복원 및 복구에 소요되는 전체 시간은 일반적으로 데이터 크기와 수행할 복구 양에 따라 다릅니다.

Backup 개요

Azure Database for PostgreSQL 유연한 서버는 데이터 파일의 스냅샷 백업을 수행하고 이를 지역에 따라 영역 중복 스토리지 또는 로컬 중복 스토리지에 안전하게 저장합니다. 서버는 또한 WAL(미리 쓰기 로그) 파일을 보관할 준비가 되면 트랜잭션 로그를 백업합니다. 이러한 백업을 사용하여 구성된 백업 보존 기간 내에서 원하는 시점으로 서버를 복원할 수 있습니다.

기본 백업 보존 기간은 7일이지만 기간을 최대 35일까지 연장할 수 있습니다. 모든 백업은 미사용 데이터에 대해 AES 256비트 암호화를 통해 암호화됩니다.

이러한 백업 파일은 내보내거나 Azure Database for PostgreSQL 유연한 서버 외부에서 서버를 만드는 데 사용할 수 없습니다. 이를 위해 PostgreSQL 도구 pg_dump 및 pg_restore/psql을 사용할 수 있습니다.

Backup 주기

Azure Database for PostgreSQL 유연한 서버 인스턴스의 백업은 스냅샷 기반입니다. 첫 번째 전체 스냅샷 백업은 서버를 만든 직후에 예약됩니다. 스냅샷 백업은 현재 매일 한 번 수행됩니다. 마지막 스냅샷 백업이 생성된 후 서버의 데이터베이스 중 어느 것도 추가 수정 사항을 수신하지 않으면 스냅샷 백업은 데이터베이스 중 하나에 새로운 수정 사항이 있을 때까지 일시 중지되며, 이때 새 스냅샷이 즉시 생성됩니다. 첫 번째 스냅샷은 전체 백업이고 연속 스냅샷은 차등 백업입니다.

트랜잭션 로그 백업은 워크로드와 WAL 파일이 채워지고 보관할 준비가 되었을 때 다양한 빈도로 발생합니다. 일반적으로 지연(복구 지점 목표 또는 RPO)은 최대 15분이 될 수 있습니다.

백업 중복 옵션

Azure Database for PostgreSQL 유연한 서버는 계획된 이벤트와 계획되지 않은 이벤트로부터 데이터를 보호하는 데 도움이 되도록 백업의 여러 복사본을 저장합니다. 이러한 이벤트에는 일시적인 하드웨어 오류, 네트워크 또는 정전, 자연 재해가 포함될 수 있습니다. 백업 중복성은 장애가 발생하더라도 데이터베이스가 가용성 및 내구성 대상을 충족하는지 확인하는 데 도움이 됩니다.

Azure Database for PostgreSQL 유연한 서버는 세 가지 옵션을 제공합니다.

  • 영역 중복 백업 스토리지: 이 옵션은 가용성 영역을 지원하는 지역에 대해 자동으로 선택됩니다. 백업이 영역 중복 백업 스토리지에 저장되면 여러 복사본이 동일한 가용성 영역 내에 저장될 뿐만 아니라 동일한 지역 내의 다른 가용성 영역에도 복제됩니다.

    이 옵션은 가용성 영역 전반에 걸쳐 백업 데이터 가용성을 제공하고 데이터 보존 요구 사항을 충족하기 위해 국가/지역 내로 데이터 복제를 제한합니다. 이 옵션은 1년 동안 백업 개체에 대해 최소 99.9999999999%(12개의 9) 내구성을 제공합니다.

  • 로컬 중복 백업 스토리지: 이 옵션은 아직 가용성 영역을 지원하지 않는 지역에 대해 자동으로 선택됩니다. 백업이 로컬 중복 백업 스토리지에 저장되면 여러 백업 복사본이 동일한 데이터 센터에 저장됩니다.

    이 옵션은 서버 랙 및 드라이브 오류로부터 데이터를 보호하는 데 도움이 됩니다. 1년 동안 백업 개체에 대해 최소 99.999999999%(11개의 9) 내구성을 제공합니다.

    기본적으로 동일한 영역 HA(고가용성)가 있거나 고가용성 구성이 없는 서버의 백업 스토리지는 로컬 중복으로 설정됩니다.

  • 지역 중복 백업 스토리지: 서버를 만들 때 이 옵션을 선택할 수 있습니다. 백업이 지역 중복 백업 스토리지에 저장되면 서버가 호스팅되는 지역에 저장된 3개의 데이터 복사본과 함께 데이터가 지리적으로 쌍을 이루는 지역에 복제됩니다.

    이 옵션을 사용하면 재해 발생 시 다른 지역에 서버를 복원할 수 있습니다. 또한 1년 동안 백업 개체에 대해 최소 99.99999999999999%(16개의 9) 내구성을 제공합니다.

    지리적 중복성은 Azure 쌍을 이루는 지역에서 호스팅되는 서버에 대해 지원됩니다.

다른 백업 스토리지 옵션에서 지역 중복 백업 스토리지로 이동

서버 만들기 중에만 백업을 위해 지역 중복 스토리지를 구성할 수 있습니다. 서버가 프로비저닝된 후에는 백업 스토리지 중복성 옵션을 변경할 수 없습니다.

백업 보존

백업은 서버에 대해 설정한 보존 기간에 따라 보존됩니다. 7(기본값)에서 35일 사이의 보존 기간을 선택할 수 있습니다. 보존 기간은 서버를 만들 때 설정하거나 나중에 변경할 수 있습니다. 백업은 중지된 서버의 경우에도 보존됩니다.

백업 보존 기간 프레임은 사용 가능한 백업을 사용하여 PITR을 검색할 수 있는 시간 프레임을 제어합니다. 백업 보존 기간을 복원 관점에서 복구 창으로 처리할 수도 있습니다.

백업 보존 기간 내에 PITR을 수행하는 데 필요한 모든 백업은 백업 스토리지에 보존됩니다. 예를 들어 백업 보존 기간을 7일로 설정한 경우 복구 기간은 지난 7일입니다. 이 시나리오에서는 지난 7일 동안 서버를 복원하고 복구하는 데 필요한 모든 데이터와 로그가 유지됩니다.

백업 스토리지 비용

Azure Database for PostgreSQL 유연한 서버는 추가 비용 없이 프로비전된 서버 스토리지의 최대 100%를 백업 스토리지로 제공합니다. 사용하는 추가 백업 스토리지는 월별 기가바이트 단위로 청구됩니다.

예를 들어 250GiB의 스토리지를 제공하는 서버를 프로비저닝한 경우 추가 비용 없이 250GiB(기가바이트)의 백업 스토리지 용량을 사용할 수 있습니다. 매일 백업 사용량이 25GiB이면 최대 10일 동안 체험용 백업 스토리지를 사용할 수 있습니다. 250GiB를 초과하는 백업 스토리지 사용량은 가격 책정 모델에 정의된 대로 청구됩니다.

지역 중복 백업으로 서버를 구성한 경우 백업 데이터도 Azure 쌍을 이루는 지역으로 복사됩니다. 따라서 백업 크기는 로컬 백업 복사본 크기의 두 배가 됩니다. 청구 금액은 ((2 x 로컬 백업 크기) - 프로비전된 스토리지 크기 ) x 가격 @ 월별 기가바이트로 계산됩니다.

Azure Portal에서 사용된 백업 스토리지 메트릭을 사용하여 서버가 사용하는 백업 스토리지를 모니터링할 수 있습니다. 사용된 백업 스토리지 메트릭은 서버에 대해 설정된 백업 보존 기간에 따라 유지되는 모든 데이터베이스 백업 및 로그 백업에서 사용하는 스토리지의 합계를 나타냅니다.

참고 항목

데이터베이스 크기에 관계없이 서버에서 트랜잭션 작업이 많으면 WAL 파일이 더 많이 생성됩니다. 파일이 증가하면 백업 스토리지도 늘어납니다.

지정 시간 복구

Azure Database for PostgreSQL 유연한 서버에서 PITR을 수행하면 원본 서버와 동일한 지역에 새 서버가 만들어지지만 가용성 영역을 선택할 수 있습니다. 이 경우 가격 책정 계층, 컴퓨팅 세대, 가상 코어 수, 스토리지 크기, 백업 보존 기간 및 백업 중복 옵션에 대한 원본 서버의 구성으로 만들어집니다. 또한 가상 네트워크 및 방화벽 설정과 같은 태그 및 설정은 원본 서버에서 상속됩니다.

물리적 데이터베이스 파일은 먼저 스냅샷 백업에서 서버의 데이터 위치로 복원됩니다. 원하는 시점보다 이전에 수행된 적절한 백업이 자동으로 선택되고 복원됩니다. 그런 다음 WAL 파일을 사용하여 데이터베이스를 일관된 상태로 가져옴으로써 복구 프로세스가 시작됩니다.

예를 들어, 백업이 매일 밤 11시에 수행된다고 가정합니다. 복원 지점이 8월 15일 오전 10시인 경우 8월 14일 매일 백업이 복원됩니다. 8월 14일 오후 11시부터 8월 15일 오전 10시까지 트랜잭션 로그 백업을 사용하여 8월 15일 오전 10시까지 데이터베이스를 복구합니다.

데이터베이스 서버를 복원하려면 이 단계를 참조하세요.

Important

Azure Database for PostgreSQL 유연한 서버의 복원 작업은 항상 사용자가 제공한 이름으로 새 데이터베이스 서버를 만듭니다. 기존 데이터베이스 서버를 덮어쓰지 않습니다.

PITR은 다음과 같은 시나리오에서 유용합니다.

  • 사용자가 실수로 데이터, 테이블 또는 데이터베이스를 삭제했습니다.
  • 애플리케이션 결함으로 인해 애플리케이션이 실수로 좋은 데이터를 잘못된 데이터로 덮어씁니다.
  • 테스트, 개발 또는 데이터 확인을 위해 서버를 복제하려고 합니다.

트랜잭션 로그를 지속적으로 백업하면 마지막 트랜잭션까지 복원할 수 있습니다. 다음 복원 옵션 중에서 선택할 수 있습니다.

  • 최신 복원 지점(현재): 서버를 최신 시점으로 복원할 수 있도록 하는 기본 옵션입니다.

  • 사용자 지정 복원 지점: 이 옵션을 사용하면 이 Azure Database for PostgreSQL 유연한 서버 인스턴스에 대해 정의된 보존 기간 내의 특정 시점을 선택할 수 있습니다. 기본적으로 UTC의 최신 시간이 자동으로 선택됩니다. 테스트 목적으로 커밋된 마지막 트랜잭션으로 복원하려는 경우 자동 선택이 유용합니다. 필요에 따라 다른 날짜와 시간을 선택할 수 있습니다.

  • 빠른 복원 지점: 이 옵션을 사용하면 사용자는 Azure Database for PostgreSQL 유연한 서버 인스턴스에 대해 정의된 보존 기간 내에서 가능한 가장 빠른 시간에 서버를 복원할 수 있습니다. 백업 목록에서 타임스탬프를 직접 선택하여 가장 빠른 복원이 가능합니다. 이 복원 작업은 서버를 프로비전하고 전체 스냅샷 백업을 복원할 뿐이며 로그 복구가 필요하지 않으므로 속도가 빠릅니다. 성공적인 복원 작업을 위해 가장 이른 복원 지점보다 큰 백업 타임스탬프를 선택하는 것이 좋습니다.

최신 및 사용자 지정 복원 지점 옵션을 사용하여 복구하는 데 필요한 시간은 마지막 백업 이후 처리할 트랜잭션 로그의 양과 동일한 지역에서 동시에 복구되는 총 데이터베이스 수와 같은 요인에 따라 달라집니다. 전체 복구 시간은 일반적으로 몇 분에서 몇 시간까지 걸립니다.

가상 네트워크 내에서 서버를 구성하는 경우 동일한 가상 네트워크 또는 다른 가상 네트워크로 복원할 수 있습니다. 그러나 공용 액세스로 복원할 수는 없습니다. 마찬가지로 공용 액세스로 서버를 구성한 경우 프라이빗 가상 네트워크 액세스로 복원할 수 없습니다.

Important

삭제된 서버는 복원할 수 없습니다. 서버를 삭제하는 경우 삭제된 Azure Database for Azure Database for PostgreSQL - 유연한 서버 복원 지침에 따라 복원할 수 있습니다. Azure 리소스 잠금을 사용하여 사고로 인한 서버 삭제를 방지할 수 있습니다.

지역 중복 백업 및 복원

Azure Portal의 컴퓨팅 + 스토리지 창에서 지역 중복 백업을 사용하도록 설정하려면 빠른 시작 가이드를 참조하세요.

Important

지역 중복 백업은 서버 만들기 시에만 구성할 수 있습니다.

지역 중복 백업으로 서버를 구성한 후 지역 쌍을 이루는 지역으로 복원할 수 있습니다. 자세한 내용은 지역 중복 백업에 대해 지원되는 지역을 참조하세요.

서버가 지역 중복 백업으로 구성된 경우 스토리지 복제를 통해 백업 데이터와 트랜잭션 로그가 쌍으로 된 지역에 비동기적으로 복사됩니다. 서버를 만든 후 지역 복원을 시작하기 전에 최소 1시간을 기다리세요. 이를 통해 첫 번째 백업 데이터 집합을 쌍을 이루는 지역에 복제할 수 있습니다.

나중에 트랜잭션 로그와 일별 백업이 쌍을 이루는 지역에 비동기식으로 복사됩니다. 데이터 전송이 최대 1시간 지연될 수 있습니다. 따라서 복원할 때 최대 1시간의 RPO를 기대할 수 있습니다. 쌍을 이루는 지역에서 사용할 수 있는 마지막 사용 가능한 백업 데이터로만 복원할 수 있습니다. 현재 지역 중복 백업의 PITR은 사용할 수 없습니다.

서버를 복구하는 데 예상되는 시간(복구 시간 목표 또는 RTO)은 데이터베이스 크기, 마지막 데이터베이스 백업 시간 및 마지막으로 받은 백업 데이터까지 처리할 WAL 양과 같은 요인에 따라 다릅니다. 전체 복구 시간은 일반적으로 몇 분에서 몇 시간까지 걸립니다.

지역 복원 중에 변경할 수 있는 서버 구성에는 가상 네트워크 설정과 복원된 서버에서 지역 중복 백업을 제거하는 기능이 포함됩니다. 지역 복원 중에 컴퓨팅, 스토리지 또는 가격 책정 계층(버스트 가능, 범용 또는 메모리 최적화)과 같은 다른 서버 구성을 변경하는 것은 지원되지 않습니다.

지역 복원 수행에 대한 자세한 내용은 방법 가이드를 참조하세요.

Important

주 지역이 다운되면 주 지역에서 스토리지를 프로비저닝할 수 없기 때문에 각 지역 쌍을 이루는 지역에서 지역 중복 서버를 만들 수 없습니다. 지리적 쌍을 이루는 지역에서 지역 중복 서버를 프로비저닝하려면 먼저 주 지역이 가동될 때까지 기다려야 합니다.

주 지역이 다운된 상태에서도 원본 서버를 지리적 쌍을 이루는 지역으로 지역 복원할 수 있습니다. 지역 복원 수행에 대한 자세한 내용은 방법 가이드를 참조하세요. DR을 모든 지역에 구성해야 하거나 주 지역에서 지역 중복 백업을 지원하지 않는 경우 지역 복제본을 DR(재해 복구) 전략으로 사용해야 합니다.

복원 및 네트워킹

지정 시간 복구

원본 서버가 공용 액세스 네트워크로 구성된 경우 공용 액세스로만 복원할 수 있습니다.

원본 서버가 프라이빗 액세스 가상 네트워크로 구성된 경우 동일한 가상 네트워크 또는 다른 가상 네트워크로 복원할 수 있습니다. 공용 및 프라이빗 액세스에서 PITR을 수행할 수 없습니다.

지역 복원

원본 서버가 공용 액세스 네트워크로 구성된 경우 공용 액세스로만 복원할 수 있습니다. 원본 서버의 기존 방화벽 규칙은 복원된 서버로 복사됩니다. 프라이빗 엔드포인트는 인수되지 않습니다. 복원 작업이 완료되면 이월된 방화벽 규칙을 조정하고 필요할 수 있는 프라이빗 엔드포인트를 만들어야 하는지 검토합니다.

원본 서버가 프라이빗 액세스 가상 네트워크로 구성된 경우 가상 네트워크는 여러 지역에 걸쳐 있을 수 없기 때문에 다른 가상 네트워크로만 복원할 수 있습니다. 공용 및 프라이빗 액세스에서 지역 복원을 수행할 수 없습니다.

복원 후 작업

서버를 복원한 후 다음 작업을 수행하여 사용자와 애플리케이션을 백업하고 실행할 수 있습니다.

  • 새 서버가 원래 서버를 교체하기 위한 것이라면 클라이언트와 클라이언트 애플리케이션을 새 서버로 리디렉션합니다. 새 서버를 가리키도록 연결 문자열의 서버 이름을 변경합니다.

  • 사용자 연결에 적절한 서버 수준 방화벽, 프라이빗 엔드포인트 및 가상 네트워크 규칙이 있는지 확인합니다. 공용 액세스 네트워크에서 규칙은 원래 서버에서 복사되지만 이는 복원된 환경에 필요한 규칙이 아닐 수도 있습니다. 따라서 요구 사항에 따라 조정합니다. 프라이빗 엔드포인트는 이월되지 않습니다. 복원된 서버에 필요할 수 있는 프라이빗 엔드포인트를 만듭니다. 프라이빗 액세스 가상 네트워크에서 복원은 원본에서 복원된 서버 네트워크로 네트워크 인프라 아티팩트 간에 복사되지 않습니다. VNET, 서브넷 또는 네트워크 보안 그룹의 구성과 관련된 모든 작업은 복원 후 작업으로 처리해야 합니다.

  • 필요에 따라 복원된 서버의 컴퓨팅을 스케일 업하거나 스케일 다운합니다.

  • 적절한 로그인 및 데이터베이스 수준 권한이 있는지 확인합니다.

  • 필요에 따라 경고를 구성합니다.

  • 복원한 원본 서버가 고가용성으로 구성되어 있고 복원된 서버를 고가용성으로 구성하려는 경우 이 단계를 따르세요.

  • 복원한 원본 서버가 읽기 복제본으로 구성되어 있고 복원된 서버에서 읽기 복제본을 구성하려는 경우 이 단계를 따르면 됩니다.

장기 보존(미리 보기)

Azure Backup 및 Azure Database for PostgreSQL 유연한 서버 서비스는 최대 10년 동안 백업을 보존하는 Azure Database for PostgreSQL 유연한 서버 인스턴스용 엔터프라이즈급 장기 백업 솔루션을 빌드했습니다. 장기 보존은 독립적으로 사용하거나 최대 35일 보존을 제공하는 Azure Database for PostgreSQL 유연한 서버에서 제공하는 자동화된 백업 솔루션과 함께 사용할 수 있습니다. 자동화된 백업은 특히 최신 백업에서 복원하려는 경우 운영 복구에 적합한 물리적 백업입니다. 장기 백업은 준수 요구 사항을 충족하는 데 도움이 되고 더욱 세부적이며 네이티브 pg_dump를 사용하여 논리적 백업으로 사용됩니다. 이 솔루션은 장기 보존 외에도 다음과 같은 기능을 제공합니다.

  • 개별 데이터베이스 수준에서 고객이 제어하는 예약 및 온디맨드 백업.
  • 모든 운영 및 작업에 대한 중앙 모니터링.
  • 별도의 보안 및 장애 도메인에 백업이 저장됩니다. 원본 서버 또는 구독이 손상된 경우 백업은 Backup 자격 증명 모음(Azure Backup 관리형 스토리지 계정)에서 안전하게 유지됩니다.
  • pg_dump를 사용하면 다양한 데이터베이스 버전에서 데이터를 복원할 때 유연성이 향상됩니다.
  • Azure Backup 자격 증명 모음은 불변성 및 일시 삭제(프리뷰) 기능을 지원하여 데이터를 보호합니다.
  • CMK 지원 서버에 대한 LTR 백업 지원

제한 사항 및 고려 사항

  • LTR 복원은 현재 스토리지 계정에 '파일로 복원'으로만 사용할 수 있으며, 향후 '서버로 복원' 기능이 계획되어 있습니다.
  • LTR은 유연한 서버 인스턴스의 모든 데이터베이스를 백업하며 개별 데이터베이스는 LTR 구성에 대해 선택할 수 없습니다.
  • LTR 백업은 지역 복제본에서 지원되지 않지만 주 서버에서 수행할 수 있습니다.
  • LTR 백업에 지원되는 최대 데이터베이스 크기는 4TiB입니다.
  • LTR 백업은 매주, 매월 또는 매년 예약할 수 있습니다. 일일 백업 일정은 현재 지원되지 않습니다.

장기 백업 수행에 대한 자세한 내용을 보려면 방법 가이드를 참조하세요.

자주 묻는 질문

  • Azure는 내 서버의 백업을 어떻게 처리하나요?

    기본적으로 Azure Database for PostgreSQL 유연한 서버를 사용하면 기본 보존 기간 7일로 전체 서버(만들어진 모든 데이터베이스 포함)를 자동으로 백업할 수 있습니다. 자동 백업에는 데이터베이스의 일별 증분 스냅샷이 포함됩니다. 로그(WAL) 파일은 Azure Blob Storage에 지속적으로 보관됩니다.

  • 장기간 데이터를 보관하도록 자동 백업을 구성할 수 있나요?

    아니요. 현재 Azure Database for PostgreSQL 유연한 서버는 최대 35일의 보존을 지원합니다. 장기 보존 요구 사항에 대해 수동 백업을 사용할 수 있습니다.

  • Azure Database for PostgreSQL 유연한 서버 인스턴스를 수동으로 백업하려면 어떻게 해야 하나요?

    PostgreSQL 도구 pg_dump를 사용하여 수동으로 백업할 수 있습니다. 예를 보려면 덤프 및 복원을 사용하여 Azure Database for PostgreSQL 유연한 서버 데이터베이스 마이그레이션을 참조하세요.

    Azure Database for PostgreSQL 유연한 서버를 Blob Storage에 백업하려면 기술 커뮤니티 블로그에서 Blob Storage에 Azure Database for PostgreSQL 백업을 참조하세요.

  • 내 서버의 백업 창은 무엇인가요? 사용자 지정할 수 있나요?

    Azure는 백업 기간을 관리하며 사용자는 이를 사용자 지정할 수 없습니다. 첫 번째 전체 스냅샷 백업은 서버를 만든 직후에 예약됩니다. 후속 스냅샷 백업은 증분식이며 하루에 한 번 발생합니다.

  • 내 백업이 암호화되나요?

    예. 쿼리 실행 중에 만들어진 모든 Azure Database for PostgreSQL 유연한 서버 데이터, 백업 및 임시 파일은 AES 256비트 암호화를 통해 암호화됩니다. 스토리지 암호화는 항상 켜져 있고 해제할 수 없습니다.

  • 서버에서 단일 데이터베이스 또는 몇 개의 데이터베이스를 복원할 수 있나요?

    단일 데이터베이스 또는 몇 개의 데이터베이스 또는 테이블을 복원하는 것은 직접 지원되지 않습니다. 그러나 전체 서버를 새 서버로 복원한 다음 테이블이나 데이터베이스를 추출하여 새 서버로 가져올 수 있습니다.

  • 백업이 진행되는 동안 내 서버를 사용할 수 있나요?

    예. 백업은 스냅샷을 사용하는 온라인 작업입니다. 스냅샷 작업은 몇 초 밖에 걸리지 않으며 프로덕션 워크로드를 방해하지 않으므로 서버의 고가용성을 보장하는 데 도움이 됩니다.

  • 서버의 유지 관리 기간을 설정할 때 백업 기간을 고려해야 하나요?

    아니요. 백업은 관리되는 서비스의 일부로 내부적으로 트리거되며 유지 관리 기간과 관련이 없습니다.

  • 자동 백업은 어디에 저장되며 보존은 어떻게 관리하나요?

    Azure Database for PostgreSQL 유연한 서버는 자동으로 서버 백업을 만들고 다음 위치에 저장합니다.

    • 여러 영역이 지원되는 지역의 영역 중복 스토리지.
    • 아직 여러 영역을 지원하지 않는 지역의 로컬 중복 스토리지.
    • 지역 중복 백업을 구성하는 경우 쌍을 이루는 지역입니다.

    이러한 백업 파일을 내보낼 수 없습니다.

    백업을 사용하여 특정 시점으로만 서버를 복원할 수 있습니다. 기본 백업 보존 기간은 7일입니다. 선택적으로 백업 보존을 최대 35일까지 구성할 수 있습니다.

  • 지역 중복 백업을 사용하면 백업이 쌍을 이루는 지역에 얼마나 자주 복사되나요?

    서버가 지역 중복 백업으로 구성된 경우 백업 데이터는 지역 중복 스토리지 계정에 저장됩니다. 스토리지 계정은 주 서버에서 일별 백업이 발생할 때 데이터 파일을 쌍을 이루는 지역에 복사합니다. WAL 파일은 보관할 준비가 되면 백업됩니다.

    백업 데이터는 쌍을 이루는 영역에 지속적으로 비동기식으로 복사됩니다. 백업 데이터를 수신하는 데 최대 1시간이 지연될 수 있습니다.

  • 원격 지역에서 PITR을 할 수 있나요?

    아니요. 데이터는 원격 지역에서 사용 가능한 마지막 백업 데이터로 복구됩니다.

  • HA 지원 서버에서 백업은 어떻게 수행되나요?

    Azure Database for PostgreSQL 유연한 서버의 데이터 볼륨은 주 서버의 관리 디스크 증분 스냅샷을 통해 백업됩니다. WAL 백업은 주 서버 또는 대기 서버에서 수행됩니다.

  • 내 서버에서 백업이 수행되는지 어떻게 유효성 검사할 수 있나요?

    백업을 확인하는 가장 좋은 방법은 주기적인 PITR을 수행하고 백업이 유효하고 복원 가능한지 확인하는 것입니다. 백업 작업이나 파일은 최종 사용자에게 노출되지 않습니다.

  • 백업 사용량은 어디에서 확인할 수 있나요?

    Azure Portal의 모니터링에서 메트릭을 선택합니다. 사용된 백업 스토리지에서는 총 백업 사용량을 모니터링할 수 있습니다.

  • 서버를 삭제하면 백업은 어떻게 되나요?

    서버를 삭제하면 해당 서버에 속한 모든 백업도 삭제되어 복구할 수 없습니다. 배포 후 실수로 삭제되거나 예기치 않은 변경으로부터 서버 리소스를 보호하기 위해 관리자는 관리 잠금을 사용할 수 있습니다.

  • 중지된 서버의 백업은 어떻게 보존되나요?

    중지된 서버에 대해 새 백업은 수행되지 않습니다. 서버를 중지할 때 보존 기간 내에 있는 모든 이전 백업은 서버를 다시 시작할 때까지 보존됩니다. 그 후 활성 서버에 대한 백업 보존은 보존 기간에 따라 결정됩니다.

  • 백업 비용은 어떻게 청구되나요?

    Azure Database for PostgreSQL 유연한 서버는 추가 비용 없이 프로비전된 서버 스토리지의 최대 100%를 백업 스토리지로 제공합니다. 추가로 사용하는 백업 스토리지는 가격 책정 모델에 정의된 대로 월별 기가바이트 단위로 청구됩니다.

    서버에서의 트랜잭션 작업과 함께 선택한 백업 보존 기간 및 백업 중복성 옵션은 총 백업 스토리지 및 청구에 직접적인 영향을 미칩니다.

  • 중지된 서버에 대한 요금은 어떻게 청구되나요?

    서버 인스턴스가 중지된 동안에는 새 백업이 수행되지 않습니다. 프로비저닝된 스토리지 및 백업 스토리지(지정된 보존 기간 내에 저장된 백업)에 대해 요금이 청구됩니다.

    무료 백업 스토리지는 프로비저닝된 데이터베이스의 크기로 제한됩니다. 초과 백업 데이터는 백업 가격에 따라 청구됩니다.

  • 영역 중복 고가용성으로 서버를 구성했습니다. 백업을 두 번 하면 두 번 청구되나요?

    아니요. HA 또는 비HA 서버에 관계없이 백업 복사본 집합은 하나만 유지됩니다. 요금은 한 번만 청구됩니다.

  • 서버를 복원하려면 어떻게 해야 하나요?

    Azure는 모든 서버에 대해 PITR을 지원합니다. 사용자는 Azure Portal, Azure CLI 및 API를 사용하여 최신 복원 지점 또는 사용자 지정 복원 지점으로 복원할 수 있습니다.

    pg_dump와 같은 도구를 사용하여 수동 백업에서 서버를 복원하려면 먼저 Azure Database for PostgreSQL 유연한 서버 인스턴스를 만든 다음 pg_restore를 사용하여 데이터베이스를 서버에 복원할 수 있습니다.

  • 동일한 지역 내의 다른 가용성 영역으로 복원할 수 있나요?

    예. 지역이 여러 가용성 영역을 지원하는 경우 다른 영역으로 복원할 수 있도록 백업이 영역 중복 스토리지 계정에 저장됩니다.

  • PITR은 얼마나 걸리나요? 복원에 시간이 오래 걸리는 이유는 무엇인가요?

    스냅샷에서 데이터 복원 작업은 데이터 크기에 의존하지 않습니다. 단, 이전 백업 요청 날짜/시간과 처리할 로그 개수에 따라 로그(재생할 트랜잭션 작업)를 적용하는 복구 프로세스 타이밍이 달라질 수 있습니다. 이는 동일한 영역 내에서 복원하거나 데이터를 다른 영역으로 복원하는 경우 모두에 적용됩니다.

  • HA 지원 서버를 복원하면 복원 서버가 자동으로 고가용성으로 구성되나요?

    아니요. 서버는 단일 인스턴스 Azure Database for PostgreSQL 유연한 서버 인스턴스로 복원됩니다. 복원이 완료된 후 선택적으로 고가용성으로 서버를 구성할 수 있습니다.

  • 가상 네트워크 내에서 서버를 구성했습니다. 다른 가상 네트워크로 복원할 수 있나요?

    예. 복원할 때 복원할 다른 가상 네트워크를 선택합니다.

  • 공용 액세스 서버를 가상 네트워크로 또는 그 반대로 복원할 수 있나요?

    아니요. Azure Database for PostgreSQL 유연한 서버는 현재 공용 및 프라이빗 액세스를 통한 서버 복원을 지원하지 않습니다.

  • 복원 작업을 추적하려면 어떻게 해야 하나요?

    현재로서는 복원 작업을 추적할 수 있는 방법이 없습니다. 작업이 진행 중인지 또는 완료되었는지 확인하기 위해 활동 로그를 모니터링할 수 있습니다.

다음 단계