백업을 사용하여 데이터 보호

문서 버전을 선택합니다.

이 페이지에서는 백업을 사용하여 데이터를 보호하는 AlloyDB Omni 표준 가용성 참조 아키텍처를 설명합니다.

사용 사례

이 참조 아키텍처는 다음 시나리오를 지원합니다.

  • 마지막 백업 이후 일부 다운타임과 데이터 손실을 톨러레이션(toleration)할 수 있는 데이터베이스가 있는 경우
  • 볼륨 또는 노드 스냅샷이 아닌 데이터베이스 수준에서 사용자 오류, 손상 또는 물리적 장애로부터 AlloyDB Omni 데이터베이스를 보호하려는 경우
  • 로컬 또는 원격으로 최대한 특정 시점까지 데이터베이스를 복구할 수 있어야 하는 경우

참조 아키텍처 작동 방식

표준 가용성 참조 아키텍처는 AlloyDB Omni 데이터베이스의 백업 및 복구를 다룹니다.

표준 가용성은 기본 구현이며 필요한 추가 하드웨어나 서비스를 최소화하지만 데이터베이스가 커질수록 복구 시간 목표(RTO)가 증가합니다. 백업할 데이터가 많을수록 데이터베이스를 복원하고 복구하는 데 시간이 오래 걸립니다. 데이터 손실은 백업 유형에 따라 다릅니다. 데이터 파일만 주기적으로 백업하는 경우 복원할 때 마지막 백업 이후의 데이터가 손실됩니다.

RPO 감소

PostgreSQL 연속 보관처리 기능을 사용하면 낮은 목표 복구 시간(RPO)을 달성하고 백업을 통해 PITR(point-in-time recovery)을 사용 설정할 수 있습니다. 이 프로세스에는 미리 쓰기 로깅(WAL) 파일 보관처리와 원격 스토리지 위치로 미리 쓰기 로깅 데이터 스트리밍이 포함될 수도 있습니다.

미리 쓰기 로깅 파일이 가득 차거나 특정 간격으로만 보관처리되는 경우 전체 데이터베이스 손실 (현재 미리 쓰기 로깅 파일 포함)로 인해 복구가 마지막으로 보관처리된 미리 쓰기 로깅 파일로 제한됩니다. 즉, RPO에서 잠재적인 데이터 손실을 고려해야 합니다. 반대로 미리 쓰기 로깅 데이터를 지속적으로 전송하면 잠재적인 데이터 손실이 최소화됩니다.

연속 백업을 구성할 때 특정 시점으로 복구할 수 있습니다. PITR(point-in-time recovery)을 사용하면 실수로 인한 테이블 삭제나 잘못된 일괄 업데이트와 같은 오류가 발생하기 전의 상태로 데이터베이스를 복원할 수 있습니다. 하지만 임시 보조 데이터베이스를 사용하지 않는 한 이 복구 방법은 RPO와 RTO 모두에 영향을 미칩니다. 전체 데이터베이스를 제자리에서 복원하면 영향을 받지 않는 테이블의 후속 트랜잭션이 롤백되고 데이터베이스가 오프라인으로 전환되는 반면, 임시 보조 데이터베이스로 복원하면 복구된 데이터만 복사할 수 있습니다.

백업 전략

AlloyDB Omni는 정기적인 물리적 백업, PITR(point-in-time recovery), WAL 보관처리 및 스트리밍, 다른 위치에 백업 저장과 같은 데이터 보호 전략을 지원합니다. 또는 소규모 데이터베이스의 경우 단일 데이터베이스에 pg_dump를 사용하거나 전체 클러스터에 pg_dumpall를 사용하여 논리적 백업을 수행하고 pg_restore를 사용하여 복원할 수 있습니다.

백업 도구

Kubernetes 배포의 경우 각 데이터베이스 클러스터에 대해 AlloyDB Omni 연산자가 관리하는 백업 계획 (BackupPlan)을 사용하여 연속 백업을 구성할 수 있습니다. 자세한 내용은 Kubernetes에서 백업 및 복원을 참조하세요.

배포 옵션에 따라 Cloud Storage 또는 클라우드 공급업체에서 제공하는 스토리지 옵션과 같은 로컬 또는 원격 스토리지에 백업을 저장하도록 AlloyDB Omni를 구성할 수 있습니다. 로컬 스토리지에서 더 빠르게 백업과 복구를 수행할 수 있지만 전체 노드나 영역이 실패할 때 원격 스토리지가 일반적으로 오류를 더 강력하게 처리합니다. 자세한 내용은 잠재적인 백업 대상을 보여주는 그림 1을 참조하세요.

백업 옵션이 있는 AlloyDB Omni

그림 1. 백업 옵션이 있는 AlloyDB Omni

로컬 또는 원격 스토리지 옵션으로 백업을 수행할 수 있습니다. 로컬 백업은 I/O 처리량만 사용하므로 빠르지만 원격 백업의 경우 일반적으로 지연 시간이 더 길고 네트워크 대역폭이 더 낮습니다. 하지만 원격 백업은 로컬 백업보다 호스트 및 영역 장애에 대한 보호 기능이 더 우수합니다.

로컬 백업을 로컬 또는 공유 스토리지로 분할할 수도 있습니다. 데이터베이스 노드가 실패할 때 노드 로컬 스토리지에는 재해 복구 옵션이 없지만 공유 스토리지를 사용하면 해당 스토리지를 다른 노드에 연결하고 복구에 사용할 수 있습니다. 즉, 공유 스토리지는 더 빠른 RTO를 제공할 수 있습니다.

로컬, 공유, 원격 스토리지 배포의 경우 다음 유형의 백업을 예약하거나 주문형으로 수동으로 수행할 수 있습니다.

  • 전체 백업: 데이터 복구에 필요한 모든 데이터베이스 파일을 전체 백업합니다.
  • 차등 백업: 마지막 전체 백업 이후의 파일 변경사항만 백업합니다.
  • 증분 백업: 종류에 관계없이 마지막 백업 이후의 파일 변경사항만 백업합니다.

point-in-time recovery

PostgreSQL WAL 파일의 연속 백업은 PITR(point-in-time recovery)을 지원합니다. 실패 이벤트 후 미리 쓰기 로깅 파일이 손상되지 않고 사용 가능하면 이러한 파일을 사용하여 특정 시점으로 복구하고 데이터 손실을 최소화할 수 있습니다.

백업 일정

Kubernetes 배포에서는 BackupPlan 매니페스트에서 크론 표현식을 사용하여 자동 백업 일정과 보관 규칙을 구성합니다.

대부분의 환경에서 백업은 일반적으로 주 단위로 예약됩니다. 다음은 일반적인 주간 백업 일정입니다.

  • 일요일: 전체 백업
  • 월요일, 화요일: 증분 백업
  • 수요일: 차등 백업
  • 목요일, 금요일: 증분 백업
  • 토요일: 차등 백업

이 일반적인 일정을 사용하면 1주일의 롤링 복구 기간에 전체 백업 최대 3개와 필요한 증분 또는 차등 백업을 저장할 수 있는 공간이 필요합니다. 이 방식은 일요일에 전체 백업 중에 발생하는 장애 복구를 지원하며 데이터베이스 복구가 백업이 시작되기 전 이전 일요일까지 확장되어야 합니다.

RPO가 높아질 수 있는 RTO를 최소화하기 위해 추가 데이터베이스가 연속 복구 모드로 작동할 수 있습니다. 이 모드에는 백업을 재생하고 새 미리 쓰기 로깅 파일을 보관처리하고 재생하여 보조 환경을 지속적으로 업데이트하는 작업이 포함됩니다. 잠재적인 데이터 손실을 반영하는 실제 RPO는 트랜잭션 빈도, 미리 쓰기 로깅 파일 크기, 미리 쓰기 로깅 스트리밍 사용에 따라 달라집니다.

백업 복원

저장된 백업에서 AlloyDB Omni 데이터베이스를 복원하거나 보관 기간 내의 특정 시점으로 복구할 수 있습니다. 배포 환경 및 복구 요구사항에 따라 데이터를 제자리에서 복원하거나 백업을 새 데이터베이스 인스턴스 또는 클러스터로 복원할 수 있습니다.

Kubernetes 배포의 경우 AlloyDB Omni 연산자는 명명된 백업에서 동일한 Kubernetes 클러스터 및 네임스페이스로 데이터베이스를 복구하거나 특정 시점의 클론을 지원합니다. 자세한 내용은 Kubernetes에서 백업 및 복원 및 Kubernetes 백업에서 데이터베이스 클러스터 수동 클론 개요를 참조하세요.

구현

가용성 참조 아키텍처를 선택할 때는 다음 이점, 제한사항, 대안을 고려하세요.

이점

  • 사용과 관리가 간단하며 RTO 및 RPO가 관대한 중요하지 않은 데이터베이스에 적합합니다.
  • 추가 하드웨어가 거의 필요하지 않습니다.
  • 재해 복구 계획에 필요한 기본적인 백업을 제공합니다.
  • 복구 기간 내 특정 시점으로 복구할 수 있습니다.

제한사항

  • 보관 요구사항에 따라 데이터베이스 자체보다 더 많은 저장공간이 필요할 수 있습니다.
  • 복구 속도가 느릴 수 있으며 RTO가 높아질 수 있습니다.
  • 데이터베이스 장애 후 현재 미리 쓰기 로깅 데이터 가용성에 따라 일부 데이터가 손실될 수 있으며 이는 RPO에 부정적인 영향을 미칠 수 있습니다.

대안

가용성 및 재해 복구 옵션을 개선하려면 향상된 가용성 또는 프리미엄 가용성 참조 아키텍처를 사용하는 것이 좋습니다.

다음 단계