Azure Database for PostgreSQL - 단일 서버의 백업 및 복원

  • 아티클

적용 대상: Azure Database for PostgreSQL - 단일 서버

Important

Azure Database for PostgreSQL - 단일 서버는 곧 사용 중지됩니다. Azure Database for PostgreSQL - 유연한 서버로 업그레이드하는 것이 좋습니다. Azure Database for PostgreSQL - 유연한 서버로 마이그레이션하는 방법에 대한 자세한 내용은 Azure Database for PostgreSQL 단일 서버에 대한 새로운 소식을 참조하세요.

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

백업

Azure Database for PostgreSQL은 데이터 파일과 트랜잭션 로그를 백업합니다. 지원되는 최대 스토리지 크기에 따라 전체 및 차등 백업(최대 4TB 스토리지 서버) 또는 스냅샷 백업(최대 16TB 스토리지 서버)을 수행합니다. 이러한 백업을 사용하면 서버를 구성된 백업 보존 기간 내의 특정 시점으로 복원할 수 있습니다. 기본 백업 보존 기간은 7일입니다. 필요에 따라 최대 35일까지 구성할 수 있습니다. 모든 백업은 AES 256비트 암호화를 사용하여 암호화됩니다.

이러한 백업 파일은 내보낼 수 없습니다. 이러한 백업은 Azure Database for PostgreSQL의 복원 작업에만 사용할 수 있습니다. pg_dump를 사용하여 데이터베이스를 복사할 수 있습니다.

Backup 주기

최대 4TB 저장소를 포함하는 서버

최대 4TB의 스토리지를 지원하는 서버의 경우 전체 백업은 매주 한 번 이루어집니다. 차등 백업은 하루 두 번 수행됩니다. 트랜잭션 로그 백업은 5분마다 발생합니다.

최대 16TB의 저장소를 포함하는 서버

Azure 지역의 하위 집합에서 새로 프로비전되는 모든 서버는 최대 16TB 스토리지를 지원할 수 있습니다. 대용량 스토리지 서버에서의 백업은 스냅샷을 기반으로 합니다. 첫 번째 전체 스냅샷 백업은 서버를 만든 직후에 예약됩니다. 첫 번째 전체 스냅샷 백업은 서버의 기본 백업으로 유지됩니다. 후속 스냅샷 백업은 차등 백업만 수행합니다. 차등 스냅샷 백업은 정해진 일정으로 발생하지 않습니다. 하루에 여러 차등 스냅샷 백업이 수행되지만 3개의 백업만 유지됩니다. 트랜잭션 로그 백업은 5분마다 발생합니다.

참고 항목

최대 4TB의 저장소 구성으로 구성된 복제본 서버에 대해 자동 백업이 수행됩니다.

백업 보존

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

백업 보존 기간은 사용 가능한 백업을 기반으로 하기 때문에 특정 시점 복원을 검색할 수 있는 시간을 제어합니다. 백업 보존 기간은 복원 관점에서 복구 기간으로 취급될 수도 있습니다. 백업 보존 기간 내에 특정 시점 복원을 수행하기 위해 필요한 모든 백업이 백업 스토리지에 보존됩니다. 예를 들어 백업 보존 기간이 7일로 설정되었으면 복구 기간이 최근 7일로 간주됩니다. 이 시나리오에서는 최근 7일 동안 서버 복원에 필요한 모든 백업이 보존됩니다. 백업 보존 기간 7일 동안 다음이 수행됩니다.

  • 최대 4TB 스토리지 서버의 경우 가장 먼저 수행된 전체 데이터베이스 백업 이후 수행된 최대 2개의 전체 데이터베이스 백업, 모든 차등 백업 및 트랜잭션 로그 백업을 보존합니다.
  • 16TB 스토리지 서버의 경우 이전 8일 동안의 전체 데이터베이스 스냅샷, 모든 차등 스냅샷 및 트랜잭션 로그 백업을 보존합니다.

백업 중복 옵션

Azure Database for PostgreSQL은 범용 및 메모리 최적화 계층에서 로컬로 중복되거나 지리적으로 중복된 백업 스토리지 중에서 선택할 수 있는 유연성을 제공합니다. 백업이 지역 중복 백업 스토리지에 저장되면 추가 백업 복사본이 쌍을 이루는 지역에 복제됩니다. 이렇게 하면 지역 재해 발생 시 서버를 복원하는 데 더 효율적인 보호와 기능을 제공합니다. 기본 계층은 로컬 중복 백업 스토리지만 제공합니다.

Important

백업을 위한 로컬 중복 또는 지역 중복 스토리지를 구성하는 것은 서버를 만드는 동안에만 허용됩니다. 서버가 프로비전되면 백업 스토리지 중복 옵션을 변경할 수 없습니다.

백업 스토리지 비용

Azure Database for PostgreSQL은 추가 비용 없이 최대 100%의 프로비전된 서버 스토리지를 백업 스토리지로 제공합니다. 사용되는 모든 추가 백업 스토리지는 매월 GB 단위로 청구됩니다. 예를 들어 250GB 스토리지 서버를 프로비전한 경우 서버 백업에 250GB를 추가 비용 없이 추가 스토리지로 이용할 수 있습니다. 250GB를 초과하여 백업에 소비된 스토리지는 가격 책정 모델에 따라 비용이 청구됩니다.

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

백업 스토리지 비용을 제어하기 위한 기본 방법은 적합한 백업 보존 기간을 설정하고 원하는 복구 목표에 맞게 올바른 백업 중복성 옵션을 선택하는 것입니다. 보존 기간은 7~35일 사이의 범위로 선택할 수 있습니다. 범용 및 메모리 최적화 서버는 백업에 대해 지리적 중복 스토리지를 사용하도록 선택할 수 있습니다.

복원

Azure Database for PostgreSQL에서 복원을 수행하면 원래 서버의 백업에서 새 서버가 만들어집니다.

사용할 수 있는 두 가지 유형의 복원이 있습니다.

  • 특정 시점 복원은 백업 중복 옵션에서 사용할 수 있으며, 원본 서버와 동일한 지역에 새 서버를 만듭니다.
  • 지역 복원은 지역 중복 스토리지를 위해 서버를 구성하고 이 서버를 다른 지역으로 복원할 수 있는 경우에만 사용할 수 있습니다.

예상 복구 시간은 데이터베이스 크기, 트랜잭션 로그 크기, 네트워크 대역폭 및 동일한 지역에서 동시에 복구되는 데이터베이스의 총 수를 포함한 여러 요소에 따라 달라집니다. 복구 시간은 마지막 데이터 백업과 수행해야 하는 복구량에 따라 다릅니다. 일반적으로 12시간 미만입니다.

참고 항목

원본 PostgreSQL 서버가 고객 관리형 키로 암호화된 경우 설명서에서 추가로 고려해야 할 사항을 참조하세요.

참고 항목

삭제된 PostgreSQL 서버를 복원하려면 여기에서 설명하는 절차를 따르세요.

특정 시점 복원

백업 중복 옵션과는 별도로 백업 보존 기간 내의 특정 시점으로 복원을 수행할 수 있습니다. 새 서버가 원본 서버와 동일한 Azure 지역에 만들어집니다. 이 경우 가격 책정 계층, 컴퓨팅 세대, vCore 수, 스토리지 크기, 백업 보존 기간 및 백업 중복 옵션에 대한 원래 서버의 구성으로 만들어집니다.

특정 시점 복원은 여러 시나리오에서 유용합니다. 예를 들어 사용자가 실수로 데이터를 삭제하거나 중요한 테이블 또는 데이터베이스를 삭제하는 경우, 또는 애플리케이션의 결함으로 인해 우연히 적절한 데이터를 잘못된 데이터로 덮어쓰는 경우가 있습니다.

마지막 5분 내의 특정 시점으로 복원하려면, 다음 트랜잭션 로그 백업이 완료될 때까지 기다려야 할 수도 있습니다.

삭제된 테이블을 복원하려는 경우

  1. 지정 시간 메서드를 사용하여 원본 서버를 복원합니다.
  2. 복원된 서버에서 pg_dump를 사용하여 테이블을 덤프합니다.
  3. 원본 서버에서 원본 테이블 이름을 바꿉니다.
  4. 원본 서버에서 psql 명령줄을 사용하여 테이블을 가져옵니다.
  5. 복원된 서버를 선택적으로 삭제할 수 있습니다.

참고 항목

동일한 서버에 대해 동시에 여러 복원을 만들지 않는 것이 좋습니다.

지역 복원

지역 중복 백업을 위해 서버를 구성한 경우 서비스를 사용할 수 있는 다른 Azure 지역으로 서버를 복원할 수 있습니다. 최대 4TB 스토리지를 지원하는 서버는 지리적으로 쌍으로 연결된 지역 또는 최대 16TB 스토리지를 지원하는 지역으로 복원될 수 있습니다. 최대 16TB 스토리지를 지원하는 서버의 경우 지리적 백업은 16TB 서버를 지원하는 지역에서도 복원될 수 있습니다. 지원되는 지역 목록은 Azure Database for PostgreSQL 가격 책정 계층을 참조하세요.

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

지역 복원 중에 변경할 수 있는 서버 구성으로는 컴퓨팅 생성, vCore, 백업 보존 기간 및 백업 중복 옵션이 있습니다. 가격 책정 계층(기본, 범용 또는 메모리 최적화) 또는 스토리지 크기 변경은 지원되지 않습니다.

참고 항목

원본 서버에서 서버 복원을 위해 인프라 이중 암호화를 사용하는 경우 사용 가능한 지역을 포함한 제한 사항이 있습니다. 자세한 내용은 인프라 이중 암호화를 참조하세요.

복원 후 작업 수행

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

  • 복원된 서버에 액세스하려면 원래 서버와 이름이 다르기 때문에 서버 이름을 복원된 서버 이름으로 변경하고 사용자 이름을 연결 문자열의 username@new-restored-server-name로 변경하세요.

  • 새 서버가 원래 서버를 교체하기 위한 것이라면 클라이언트와 클라이언트 애플리케이션을 새 서버로 리디렉션합니다.

  • 사용자가 연결할 수 있도록 적절한 서버 수준 방화벽 및 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 자격 증명 모음은 불변성 및 일시 삭제(프리뷰) 기능을 지원하여 데이터를 보호합니다.

다음 단계