Bigtable 백업 개요

이 페이지에서는 Bigtable 백업을 간략히 설명합니다. 여기에 제시된 콘텐츠는 Bigtable 관리자와 개발자를 대상으로 합니다.

백업을 사용하면 테이블 스키마와 데이터의 사본을 저장하고 나중에 백업에서 새 테이블로 복원할 수 있습니다. Bigtable은 두 가지 유형의 백업을 제공합니다. 생성하는 백업 유형은 재해 복구(DR) 요구사항과 Bigtable 클러스터에서 사용하는 스토리지 유형(HDD 또는 SSD)에 따라 다릅니다.

표준 백업은 장기 보관에 최적화되어 있습니다. 표준 백업에서 SSD 클러스터로 복원할 때 복원 작업을 통해 테이블을 프로덕션 수준의 성능으로 가져오려면 Bigtable의 추가 최적화가 필요합니다. 자세한 내용은 복원 시 성능을 참조하세요.
핫 백업은 프로덕션 수준의 성능과 지연 시간이 짧은 서빙을 가장 효율적으로 복원합니다. 자세한 내용은 핫 백업을 참조하세요.

다음과 같은 방법으로 백업을 만들 수 있습니다.

자동 백업을 사용 설정하여 Bigtable에서 자동으로 일일 백업을 만들도록 하기
Google Cloud 콘솔, gcloud CLI 또는 Bigtable 클라이언트 라이브러리를 사용하여 주문형 백업 만들기
백업 사본 만들기

이 페이지를 읽기 전에 Bigtable 개요 및 테이블 관리를 숙지해야 합니다.

특성

완전 통합: 백업은 Bigtable 서비스에서 전적으로 처리되므로 가져오거나 내보낼 필요가 없습니다.
증분: 백업은 물리적 스토리지를 소스 테이블 및 테이블의 다른 백업과 공유합니다.
비용 효율: Bigtable 백업을 사용하면 다른 서비스를 사용하여 데이터를 내보내고, 저장하고, 가져오는 데 따른 비용을 방지할 수 있습니다.
자동 만료: 각 백업에는 사용자 정의된 만료일이 있으며 백업이 생성된 후 최대 90일까지 가능합니다. 백업 사본을 최대 30일 동안 저장할 수 있습니다.
유연한 복원 옵션: 백업에서 백업이 생성된 다른 인스턴스의 테이블로 복원할 수 있습니다.
자동 백업: Bigtable에서 일일 백업을 만들도록 하려면 자동 백업을 사용 설정합니다.
핫 백업: 프로덕션에 즉시 사용 가능한 핫 백업으로 재해 복구를 계획합니다.

사용 사례

백업은 다음과 같은 사용 사례에 유용합니다.

비즈니스 연속성
규정 준수
테스트 및 개발
재해 복구

다음 재해 복구 시나리오를 고려합니다.

목표	백업 전략	복원 전략
인적 오류로부터 보호: 실수로 인한 삭제나 손상이 발생할 경우를 대비해 항상 데이터의 최근 백업을 확보하는 것이 좋습니다.	비즈니스 니즈에 적합한 백업 생성 일정(예: 매일)을 결정합니다. 원하는 경우 백업 사본을 주기적으로 만들고 격리 및 보호를 강화하기 위해 다른 프로젝트 또는 리전에 저장합니다. 더 강력한 보호를 원한다면 제한된 액세스 권한으로 프로젝트 또는 인스턴스에 백업 사본을 저장합니다.	백업 또는 복사에서 새 테이블로 복원한 후 요청을 새 테이블로 다시 라우팅합니다.
영역 사용 불가: 드물지만 Google Cloud 영역을 사용할 수 없게 되더라도 데이터를 계속 사용할 수 있도록 해야 합니다.	자동 백업을 사용 설정하면 Bigtable에서 인스턴스의 모든 클러스터에 대한 일일 백업을 만들 수 있습니다. 또는 정기적으로 백업을 만든 후 가장 최근의 백업 사본을 주기적으로 만들고 다른 영역(원하는 경우 다른 인스턴스나 프로젝트)에 있는 클러스터 하나 이상에 저장합니다.	서빙 클러스터를 사용할 수 없게 된 영역에서는 원격 백업 사본에서 새 테이블로 복원한 후 요청을 새 테이블로 다시 라우팅합니다.
데이터 손상: 예를 들어 소스 테이블의 일부가 손상된 경우 백업을 사용하여 테이블 데이터 일부를 복구합니다.	복제 및 자동 백업을 사용 설정하여 여러 리전에서 매일 백업을 만듭니다. 그러면 한 클러스터에서 테이블이 손상되더라도 손상된 클러스터의 스토리지를 공유하지 않는 백업이 하나 이상 있게 됩니다.	백업에서 새 클러스터 또는 인스턴스의 새 테이블로 복원합니다. 그런 다음 Bigtable 클라이언트 라이브러리 또는 Dataflow를 사용하여 새 테이블에서 데이터를 읽고 소스 테이블에 다시 쓰는 애플리케이션을 만듭니다. 데이터가 원본 테이블에 복사되면 새 테이블을 삭제합니다.
빠른 복구: 다운타임을 최소화하여 전체 프로덕션 성능 수준으로 빠르게 복원합니다.	항상 테이블의 최신 핫 백업을 유지합니다.	핫 백업에서 새 테이블로 복원한 후 요청을 새 테이블로 다시 라우팅합니다.

핫 백업

핫 백업은 복원 직후 새 테이블에서 읽을 때 지연 시간이 짧고 빠른 복구에 최적화된 프로덕션에 즉시 사용 가능한 백업입니다. 핫 백업에서 프로덕션 성능으로 복원하는 것이 표준 백업에서 복원하는 것보다 빠릅니다.

핫 백업을 표준 백업으로 변환할 수는 있지만 표준 백업을 핫 백업으로 변환할 수는 없습니다.

자동 백업을 사용하여 핫 백업을 만들 수 없으며 HDD 클러스터에서는 핫 백업을 만들 수 없습니다.

Bigtable 백업 작업

Bigtable 백업에 다음 작업을 수행할 수 있습니다. 어떤 경우든 대상 프로젝트, 인스턴스, 클러스터가 이미 존재하고 있어야 합니다. 백업 작업의 일부로 이러한 리소스를 만들 수 없습니다.

작업	대상 옵션
백업 사본의 사본을 만들 수 없습니다. 백업 사본은 소스가 핫 백업인 경우에도 항상 표준 백업입니다.
표준 백업 만들기	소스 테이블과 동일한 인스턴스의 모든 클러스터
핫 백업 만들기	소스 테이블과 동일한 인스턴스의 모든 클러스터 인스턴스는 SSD 스토리지를 사용해야 합니다.
표준 또는 핫 백업에서 새 테이블로 복원	모든 인스턴스 모든 Bigtable 리전 모든 프로젝트
백업 복사^{1, 2}	모든 인스턴스 모든 Bigtable 리전 모든 프로젝트

이러한 작업은 물론 백업 업데이트 및 삭제와 같은 작업에 대한 단계별 안내는 백업 관리를 참조하세요.

백업 스토리지

주문형으로 만드는 테이블 백업은 지정한 단일 클러스터에 저장됩니다. 자동 백업이 사용 설정되면 백업이 생성되고 인스턴스의 모든 클러스터에 저장됩니다.

테이블의 백업에는 백업이 생성된 시점에 백업이 생성된 클러스터에서 테이블에 있던 모든 데이터가 포함됩니다. 백업은 백업 생성 시점의 소스 테이블 크기보다 크지 않습니다.

표준 백업은 증분 백업입니다. 표준 백업에서 사용하는 스토리지 양은 테이블 크기 및 변경되지 않은 데이터 스토리지를 원본 테이블이나 같은 테이블의 다른 백업과 공유할 수 있는 범위에 따라 달라집니다. 이러한 이유로 백업 크기는 이전 백업 이후의 데이터 불일치 양에 따라 다릅니다.

반면 핫 백업은 소스 테이블이 얼마나 변경되든 관계없이 백업 시 동일한 양의 스토리지를 사용하는 완전한 사본입니다. 최적화된 스토리지를 사용하기 때문에 백업이 핫으로 간주되므로 프로덕션 성능 수준으로 효율적으로 복원할 수 있습니다.

클러스터별로 테이블당 최대 150개의 백업을 만들 수 있습니다.

백업이 있는 테이블을 삭제할 수 있습니다. 백업을 보호하기 위해 백업이 포함된 클러스터를 삭제할 수 없으며 클러스터에 백업이 한 개 이상 있는 인스턴스를 삭제할 수 없습니다.

새 테이블로 복원한 후에도 백업은 계속 존재합니다. 백업이 더 이상 필요하지 않을 때 삭제하거나 만료시킬 수 있습니다. 백업 스토리지는 프로젝트의 노드 스토리지 한도에 포함되지 않습니다.

백업의 데이터는 암호화됩니다.

보관

백업 보관 기간을 최대 90일까지 지정할 수 있습니다. 백업 사본을 만드는 경우 사본 최대 보관 기간은 사본이 생성된 시점으로부터 30일입니다.

자동 백업이 사용 설정된 테이블의 경우 기본 보관 기간은 3일입니다. 백업 생성 후 최대 90일까지 보관할 수 있도록 백업 보관 기간을 변경할 수 있습니다.

복원 후 스토리지

백업에서 복원된 새 테이블의 스토리지 비용은 모든 테이블과 동일합니다.

백업에서 복원된 테이블은 원본 테이블과 동일한 스토리지 용량을 소비하지 않으며 복원 후 크기가 줄어들 수 있습니다. 크기 차이는 소스 클러스터와 대상 클러스터가 최근에 압축되었는지에 따라 다릅니다.

압축은 순차적으로 수행되므로 테이블이 생성되는 즉시 압축이 수행될 수 있습니다. 그러나 압축이 수행되는 데 최대 일주일이 걸릴 수 있습니다.

백업에서 복원된 새 테이블은 소스 테이블의 가비지 컬렉션 정책을 상속하지 않습니다. 새 데이터를 테이블에 쓰기 전에 새 테이블에 가비지 컬렉션 정책을 구성합니다. 자세한 내용은 가비지 컬렉션 구성을 참조하세요.

비용

백업을 사용할 때는 표준 네트워크 비용이 적용됩니다. 백업에서 생성, 복사 또는 복원을 포함한 백업 작업에는 요금이 청구되지 않습니다.

스토리지 비용

표준 백업과 핫 백업의 스토리지 비용은 다릅니다.

표준 백업 스토리지 비용

표준 백업 또는 백업 사본을 저장하면 백업 또는 백업 사본이 포함된 클러스터가 있는 리전에 대한 표준 백업 스토리지 요금이 청구됩니다.

표준 백업은 테이블의 완전한 논리적 사본입니다. 백그라운드에서 Bigtable은 표준 백업 스토리지 사용률을 최적화합니다. 이러한 최적화는 표준 백업이 증분 백업임을 의미합니다. 즉, 가능한 경우 물리적 스토리지를 원본 테이블이나 테이블의 다른 백업과 공유합니다. Bigtable의 기본 제공 스토리지 최적화 기능으로 인해 표준 백업이나 백업 복사본을 저장하는 비용이 테이블 백업의 전체 물리적 복사 비용보다 적게 청구되는 경우도 있습니다.

자동 백업이 사용 설정된 복제된 인스턴스의 경우 백업이 매일 각 클러스터에 생성되므로 스토리지 비용이 더 높을 수 있습니다.

핫 백업 스토리지 비용

핫 백업을 저장하면 핫 백업이 포함된 클러스터가 있는 리전에 대해 핫 백업 스토리지 요금이 청구됩니다.

핫 백업은 빠른 복원에 최적화된 준비 상태로 저장되므로 표준 백업과 달리 증분 부분이 아닌 테이블의 전체 논리적 사본 스토리지에 대한 요금이 청구됩니다.

백업 복사 시 비용

소스 백업과 다른 리전에 백업 사본을 만들면 데이터를 대상 클러스터로 복사하는 비용에 대해 표준 네트워크 요금이 부과됩니다. 소스 백업과 동일한 리전에 사본을 만들 때는 네트워크 트래픽에 대한 요금이 청구되지 않습니다.

복원 시 비용

백업에서 새 테이블을 복원하면 네트워크 복제 비용이 청구됩니다. 새 테이블이 복제를 사용하는 인스턴스에 있는 경우 데이터가 인스턴스의 모든 클러스터로 복사되면 일회성 복제 비용이 청구됩니다.

백업이 생성된 인스턴스와 다른 인스턴스로 복원하는 경우 같은 리전에 있는 클러스터가 백업 인스턴스와 대상 인스턴스에 최소 하나 이상 없으면 표준 네트워크 요금으로 대상 클러스터에 대한 초기 데이터 복사 비용이 1회 청구됩니다.

CMEK

고객 관리 암호화 키(CMEK)로 보호되는 클러스터에서 백업을 만들면 백업을 가져온 때에 백업이 클러스터의 CMEK 키의 기본 버전에 고정됩니다. 백업을 만든 후에는 KMS 키가 순환되어도 해당 키 및 키 버전을 수정할 수 없습니다.

백업에서 복원할 때 백업 복호화 프로세스가 성공하려면 백업이 고정된 키 버전이 사용 설정되어야 합니다. 새 테이블은 대상 인스턴스의 각 클러스터에 대한 최신 CMEK 키 기본 버전으로 보호됩니다. CMEK로 보호되는 백업에서 다른 인스턴스로 복원하려면 대상 인스턴스도 CMEK로 보호되어야 합니다. 하지만 소스 인스턴스와 동일한 CMEK 구성을 사용할 필요는 없습니다.

복제 고려사항

이 섹션에서는 복제를 사용하는 인스턴스에서 테이블을 백업하고 복원할 때 알아야 할 추가 개념을 설명합니다.

복제 및 백업

복제된 인스턴스에서 테이블을 수동으로 백업할 때는 백업을 만들고 저장할 클러스터를 선택합니다. 자동 백업이 사용 설정된 테이블의 경우 매일 백업이 인스턴스의 각 클러스터에 생성됩니다.

백업이 포함된 클러스터에 쓰기 작업을 중지할 필요는 없지만 Bigtable에서 클러스터에 복제된 쓰기를 처리하는 방식을 이해해야 합니다.

백업은 백업이 생성되는 시점에 백업이 저장된 클러스터 상태의 테이블 복사본입니다. 인스턴스의 다른 클러스터에서 아직 복제되지 않은 테이블 데이터는 백업에 포함되지 않습니다.

각 백업에는 시작 시간과 종료 시간이 있습니다. 백업 작업 전 또는 중에 잠시 클러스터에 전송되는 쓰기는 백업에 포함되지 않을 수 있습니다. 이러한 불확실성에 기여하는 두 가지 요소는 다음과 같습니다.

백업이 이미 복사된 테이블의 섹션으로 쓰기가 전송될 수 있습니다.
다른 클러스터에 쓰기가 백업이 포함된 클러스터로 복제되지 않을 수 있습니다.

즉, 백업 시간 전에 타임스탬프가 있는 일부 쓰기가 백업에 포함되지 않을 수 있습니다.

이러한 비일관성이 비즈니스 요구사항에 허용되지 않는 경우 일관성 토큰을 쓰기 요청과 함께 사용하여 모든 복제된 쓰기가 백업에 포함되도록 할 수 있습니다.

백업 시간은 클러스터마다 다를 수 있으므로 자동 백업의 일부로 생성된 복제된 테이블의 백업은 서로 정확한 사본이 아닙니다.

복제 및 복원

백업을 새 테이블로 복원하면 대상 클러스터에서 복원 작업이 완료된 직후 인스턴스의 다른 클러스터에 대한 복제가 시작됩니다.

성능

백업을 만드는 동안 다음 권장사항을 수행하여 성능이 최적의 상태로 유지되는지 확인합니다.

백업 시 성능

백업을 만드는 데 걸리는 시간은 일반적으로 1분 미만이지만 최대 1시간이 걸릴 수 있습니다. 일반적인 상황에서는 백업 생성이 제공 성능에 영향을 미치지 않습니다.

최적의 성능을 위해 단일 테이블의 백업을 5분 간격으로 2회 이상 만들지 마세요. 백업을 더 자주 만들면 처리 지연 시간이 크게 증가할 수 있습니다.

복원 시 성능

백업에서 단일 클러스터 인스턴스의 테이블로 복원하는 데 몇 분 정도 걸립니다. 복제된 인스턴스에서는 데이터가 모든 클러스터에 복사되어야 하므로 복원 시간이 더 오래 걸립니다. Bigtable은 항상 데이터 복사에 가장 효율적인 경로를 선택합니다.

백업이 생성된 인스턴스와 다른 인스턴스로 복원하면 복원 작업이 같은 인스턴스로 복원되는 것보다 시간이 오래 걸립니다. 대상 인스턴스에 백업이 생성된 클러스터와 동일한 영역에 클러스터가 없는 경우 특히 그렇습니다.

테이블이 클수록 작은 테이블보다 복원 시간이 오래 걸립니다.

SSD 인스턴스가 있으면 복원이 완료된 후에도 테이블은 최적화되는 중에 처음에는 읽기 지연 시간이 길어질 수 있습니다. 최적화가 계속 진행 중인지 확인하려면 언제든지 복원 작업 중에 상태를 확인하면 됩니다.

백업이 생성된 인스턴스와 다른 인스턴스로 복원하는 경우 대상 인스턴스는 HDD 또는 SSD 스토리지를 사용할 수 있습니다. 소스 인스턴스와 동일한 스토리지 유형을 사용할 필요는 없습니다.

액세스 제어

IAM 권한은 백업 및 복원 작업에 대한 액세스를 제어합니다. 백업 권한은 인스턴스 수준에 있으며 인스턴스의 모든 백업에 적용됩니다.

테이블 백업을 만드는 데 사용하는 계정에는 테이블을 읽고 테이블이 있는 인스턴스(소스 인스턴스)에서 백업을 만들 수 있는 권한이 있어야 합니다.

백업을 복사하는 데 사용하는 계정에는 소스 백업을 읽고 대상 인스턴스와 프로젝트에서 백업을 만들 수 있는 권한이 있어야 합니다.

백업에서 새 테이블을 복원하는 데 사용하는 계정에는 복원할 인스턴스에 테이블을 만들 권한이 있어야 합니다.

작업	필수 IAM 권한
백업 만들기	bigtable.tables.readRows, bigtable.backups.create
백업 가져오기	bigtable.backups.get
백업 표시	bigtable.backups.list
백업 삭제	bigtable.backups.delete
백업 업데이트	bigtable.backups.update
백업 복사	bigtable.backups.read, bigtable.backups.create
백업에서 새 테이블로 복원	bigtable.tables.create, bigtable.backups.restore
작업 가져오기	bigtable.instances.get
작업 나열	bigtable.instances.get

권장사항

백업 전략을 만들기 전에 다음 권장사항을 참조해야 합니다.

백업 만들기

테이블을 5분마다 두 번 이상 백업하지 마세요.
복제를 사용하는 테이블을 백업하는 경우 다음 요소를 고려하여 백업을 저장할 클러스터를 선택합니다.
- 비용: 인스턴스의 클러스터 하나가 다른 클러스터보다 비용이 저렴한 리전에 있을 수 있습니다.
- 애플리케이션 서버와의 근접성: 가능한 한 백업을 제공 애플리케이션과 가깝게 저장할 수 있습니다.
- 스토리지 사용량: 백업이 누적되면 충분한 저장공간이 필요합니다. 워크로드에 따라 크기가 다르거나 디스크 사용량이 다른 클러스터가 있을 수 있습니다. 이러한 사항은 클러스터 선택에 반영됩니다.
복제를 사용하는 인스턴스의 테이블을 백업할 때 복제된 모든 쓰기가 백업에 포함되도록 해야 하면 쓰기 요청에 일관성 토큰을 사용합니다.

백업에서 복원

백업에서 복원해야 하는 경우 새 테이블의 이름을 사전에 계획합니다. 요점은 문제를 처리할 때 결정할 필요가 없도록 미리 준비해야 하는 것입니다.
실수로 삭제한 경우를 제외하고 테이블을 복원하는 경우 원본 테이블을 삭제하기 전에 모든 읽기와 쓰기가 새 테이블로 이동하는지 확인합니다.
다른 인스턴스로 복원하려면 백업 복원 작업을 시작하기 전에 대상 인스턴스를 만듭니다.

할당량 및 한도

백업 및 복원 요청과 백업 스토리지에는 Bigtable 할당량 및 한도가 적용됩니다.

제한사항

Bigtable 백업에는 다음 제한사항이 적용됩니다.

일반

백업에서 직접 읽을 수 없습니다.
백업은 특정 시점에 단일 클러스터에 있는 테이블 버전입니다. 백업은 일관된 상태를 나타내지 않습니다. 서로 다른 클러스터에 있는 동일한 테이블의 백업에도 동일하게 적용됩니다.
단일 작업에서 테이블을 두 개 이상 백업할 수 없습니다.
Bigtable 백업을 다른 서비스(예: Cloud Storage)로 내보내거나, 복사하거나, 이동할 수 없습니다.
Bigtable 백업은 Bigtable 데이터만 포함하며 다른 Google 서비스의 백업과 통합되거나 관련되지 없습니다.

복원 중

백업에서 기존 테이블로 복원할 수 없습니다.
이미 존재하는 인스턴스로만 복원할 수 있습니다. Bigtable은 백업에서 복원할 때 새 인스턴스를 만들지 않습니다. 복원 요청에 지정된 대상 인스턴스가 존재하지 않으면 복원 작업이 실패합니다.
백업을 SSD 클러스터의 테이블로 복원한 후 새로 복원된 테이블을 삭제하면 테이블이 삭제되는 데 다소 시간이 걸릴 수 있습니다. Bigtable이 테이블 최적화가 완료될 때까지 기다리기 때문입니다.

복사 중

만료된 지 24시간이 지나지 않은 백업의 사본은 만들 수 없습니다.
백업 사본의 사본을 만들 수 없습니다.

CMEK

CMEK로 보호하는 백업을 CMEK로 보호하는 인스턴스의 새 테이블로 복원해야 합니다.
CMEK로 보호되는 백업의 사본을 만드는 경우 대상 클러스터도 CMEK로 보호되어야 합니다.