Backup Vault는 백업을 위한 격리되고 변경할 수 없으며 삭제할 수 없는 스토리지를 제공하는 Google 관리 리전 리소스입니다. 데이터를 보관소, 데이터 소스, 백업의 계층 구조로 정리하여 강제 보관 기간과 프로젝트 수준 ID 격리를 통해 실수로 인한 삭제 또는 악의적인 삭제로부터 데이터를 보호합니다.
이 문서에서는 계층적 리소스 모델, 지원되는 워크로드, 백업 모델, 위치 호환성, 가용성, 이름 지정 요구사항 등 백업 보관소의 작동 방식을 설명합니다.
리소스 계층 구조
백업 및 DR 내의 데이터는 Backup Vault 내에서 3계층 계층 구조로 구성됩니다.
Backup Vault: 전역 최소 보관 정책을 적용하는 최상위 컨테이너입니다.
데이터 소스: 특정 보호 대상(예: Compute Engine 인스턴스)을 나타내는 하위 리소스입니다. 시스템은 첫 번째 백업 시 자동으로 이를 생성합니다.
백업: 특정 PITR(point-in-time recovery) 지점이 있는 개별 백업을 나타내는 데이터 소스의 하위 리소스입니다.
다음 다이어그램은 Backup Vault 리소스 모델을 보여줍니다.
제한사항
이 페이지에서는 Google Cloud 콘솔 (예: Compute Engine 또는 Cloud SQL)을 통해 관리되는 리소스의 백업 보관소에 대해 설명합니다. Oracle 또는 Google Cloud VMware Engine과 같은 워크로드에 어플라이언스 관리 콘솔을 사용하는 경우 어플라이언스 관리 콘솔에서 관리되는 백업 보관소 개요를 참고하세요.
백업 보관소의 AlloyDB 클러스터와 Filestore 인스턴스는 멀티 리전에서 지원되지 않습니다.
백업 및 DR은 Backup Vault 백업에서 워크로드를 복원할 때 호환되는 대상 위치에 제한을 두지 않습니다.
Backup Vault와 소스 워크로드의 위치에 따라 네트워크 전송 수수료가 발생할 수 있습니다. 자세한 내용은 백업 및 DR 가격 책정을 참고하세요.
지원되는 리소스
| 워크로드 유형 | 관리 |
|---|---|
| Compute Engine 인스턴스 | Google Cloud 콘솔 |
| Compute Engine 디스크 | Google Cloud 콘솔 |
| Filestore 인스턴스 | Google Cloud 콘솔 |
| Cloud SQL 인스턴스 | Google Cloud 콘솔 |
| AlloyDB 클러스터 | Google Cloud 콘솔 |
| Google Cloud VMware Engine, Oracle 데이터베이스, SQL Server 데이터베이스 | 어플라이언스 관리 콘솔 |
리소스 백업 모델
| 중앙 집중식 모델 | 분산형 모델 | |
|---|---|---|
| Google Cloud 콘솔 | 중앙 관리자 프로젝트에서 Backup Vault 및 백업 계획을 만들어 백업 관리를 통합합니다. 관리자는 중앙에서 관리되는 이러한 계획을 사용하여 여러 서비스 프로젝트의 리소스를 보호하거나 IAM 권한을 사용하여 애플리케이션 소유자에게 백업 계획 액세스 권한을 위임할 수 있습니다. |
각 프로젝트 내에 별도의 Backup Vault와 백업 계획을 만들어 백업 관리를 격리합니다. 이 접근 방식은 개별 애플리케이션 팀이 자체 리소스 백업을 담당하는 분산형 조직에 적합합니다. |
| 어플라이언스 관리 콘솔 | 어플라이언스 관리 콘솔을 배포하고 중앙 관리자 프로젝트에 Backup Vault를 만들어 백업 관리를 통합합니다. 관리자는 중앙 관리 콘솔 내에서 백업 정책을 구성하여 여러 서비스 프로젝트에 걸쳐 Google Cloud VMware Engine VM과 같은 리소스를 보호합니다. |
각 프로젝트 또는 비즈니스 라인에 별도의 어플라이언스 관리 콘솔과 Backup Vault를 배포하여 백업 관리를 격리합니다. 이 접근 방식은 백업 관리 책임이 여러 팀에 분산된 분산형 조직에 적합합니다. |
Backup Vault 지원 위치
소스 워크로드와 동일한 리전 (리전), 소스 워크로드와 다른 리전(리전 간) 또는 여러 리전 (멀티 리전)에 Backup Vault를 만들 수 있습니다.
지원되는 리전 및 교차 리전
다음 리전 및 교차 리전에서 백업 볼트를 만들 수 있습니다.
| 지리적 지역 | 리전 이름 | 리전 설명 | |
|---|---|---|---|
| 북미 | |||
northamerica-northeast1 * |
몬트리올 |
 낮은 CO2
|
|
northamerica-northeast2 |
토론토 |
낮은 CO2
|
|
us-central1 |
아이오와 |
낮은 CO2
|
|
us-east1 |
사우스캐롤라이나 | ||
us-east4 |
북버지니아 | ||
us-east5 |
콜럼버스 | ||
us-south1 |
댈러스 |
낮은 CO2
|
|
us-west1 |
오리건 |
낮은 CO2 |
|
us-west2 |
로스앤젤레스 | ||
us-west3 |
솔트레이크시티 | ||
us-west4 |
라스베이거스 | ||
northamerica-south1 * |
케레타로 | ||
| 남미 | |||
southamerica-east1 |
상파울루 |
낮은 CO2
|
|
southamerica-west1 |
산티아고 |
낮은 CO2
|
|
| 유럽 | |||
europe-central2 |
바르샤바 | ||
europe-north1 |
핀란드 |
낮은 CO2
|
|
europe-north2 |
스톡홀름 |
낮은 CO2
|
|
europe-southwest1 |
마드리드 |
낮은 CO2
|
|
europe-west1 |
벨기에 |
낮은 CO2
|
|
europe-west2 |
런던 |
낮은 CO2
|
|
europe-west3 |
프랑크푸르트 | ||
europe-west4 |
네덜란드 |
낮은 CO2
|
|
europe-west6 |
취리히 |
낮은 CO2
|
|
europe-west8 |
밀라노 | ||
europe-west9 |
파리 |
낮은 CO2
|
|
europe-west10 |
베를린 | ||
europe-west12 |
토리노 | ||
| 중동 | |||
me-central1 |
도하 | ||
me-central2 |
담맘 | ||
me-west1 |
이스라엘 | ||
| 아프리카 | |||
africa-south1 |
요하네스버그 | ||
| 아시아 태평양 | |||
asia-east1 |
타이완 | ||
asia-east2 |
홍콩 | ||
asia-northeast1 |
도쿄 | ||
asia-northeast2 * |
오사카 | ||
asia-northeast3 |
서울 | ||
asia-southeast1 |
싱가포르 | ||
asia-southeast2 |
자카르타 | ||
australia-southeast1 |
시드니 | ||
australia-southeast2 |
멜버른 | ||
| 인도 | |||
asia-south1 |
뭄바이 | ||
asia-south2 |
델리 |
* 케레타로 (northamerica-south1), 몬트리올 (northamerica-northeast1), 오사카 (asia-northeast2)는 영역 분리를 지원하지 않습니다. 즉, 이러한 각 리전 내의 여러 영역이 물리적으로 분리된 데이터 센터 캠퍼스에 위치하지 않을 수 있습니다. 따라서 단일의 현지화된 물리적 재해 이벤트가 동일한 리전 내의 여러 영역에 영향을 미칠 수 있으므로 영역 분리를 지원하는 리전에 비해 데이터 손실 위험이 증가합니다.
지원되는 멀티 리전
다음 멀티 리전에서 백업 보관함을 만들 수 있습니다.
| 멀티 리전 이름 | 설명 |
|---|---|
ASIA |
아시아의 데이터 센터 |
EU |
유럽 연합의 데이터 센터 |
US |
미국의 데이터 센터 |
워크로드 위치 호환성
다음 표에서는 리전 및 교차 리전 Backup Vault를 사용할 때 지원되는 각 워크로드의 호환되는 Backup Vault 위치를 설명합니다. Google Cloud 콘솔의 백업 계획은 소스 워크로드와 동일한 리전에 만들어야 합니다.
| 워크로드 | Backup Vault는 소스 워크로드와 동일한 리전에 있어야 합니다. | 리전 지원 | 멀티 리전 지원 | 리전 간 지원 |
|---|---|---|---|---|
| Compute Engine 인스턴스 | 아니요 | |||
| Compute Engine 디스크 | 아니요 | |||
| Cloud SQL 인스턴스 | 예 | |||
| AlloyDB 클러스터 | 예 | |||
| Filestore 인스턴스 | 아니요 | |||
| Google Cloud VMware Engine, Oracle 데이터베이스, SQL Server 데이터베이스 | 아니요 |
멀티 리전 호환성
멀티 리전을 사용하려면 다음 요구사항을 충족해야 합니다.
워크로드가 멀티 리전 Backup Vault를 지원하는 경우 소스 워크로드 위치가 멀티 리전 Backup Vault 위치와 호환되어야 합니다.
접두사가 동일한 리전의 리소스만 백업할 수 있습니다. 예를 들어
asia접두사가 있는 리전의 리소스는asia멀티 리전에만 백업할 수 있습니다.
다음 표에서는 멀티 리전 Backup Vault를 사용할 때 지원되는 각 워크로드의 호환되는 Backup Vault 위치를 설명합니다.
| 워크로드 유형 | 멀티 리전 Backup Vault 사용을 지원하나요? | 지원되는 Backup Vault 멀티 리전 |
|---|---|---|
| Compute Engine 인스턴스 | asia, eu, us |
|
| Compute Engine 디스크 | asia, eu, us |
|
| Filestore 인스턴스 | 해당 사항 없음 | |
| Cloud SQL 인스턴스 | asia, eu, us |
|
| AlloyDB 클러스터 | 해당 사항 없음 | |
| Google Cloud VMware Engine, Oracle 데이터베이스, SQL Server 데이터베이스 | 해당 사항 없음 |
가용성
리전 및 리전 간 위치에 생성된 Backup Vault는 단일 영역 서비스 중단에 대한 복원력을 제공합니다. 백업 데이터는 최소 두 개 이상의 별도 영역에 중복 저장됩니다.
멀티 리전 위치에 생성된 백업 볼트는 단일 리전 중단에 대한 복원력을 제공합니다. 백업 데이터는 두 개 이상의 서로 다른 리전에 중복 저장됩니다.
멀티 리전 및 리전 간 Backup Vault 비교
| 기준 | 멀티 리전 백업 | 리전 간 백업 |
|---|---|---|
| 백업 만들기 | 대륙 내 두 리전에서 Google에 의해 자동화됩니다. | 백업을 생성할 리전을 명시적으로 정의할 수 있는 자율성 |
| 사용 사례 | 고가용성 및 운영 단순성 | 엄격한 규정 준수, 데이터 레지던시 법규 또는 소스 지역 경계 내외의 타겟 재해 복구 사이트 |
| 관리 | 오버헤드가 낮습니다. 단일 보관소, 자동 균형 조정 | 중간 오버헤드 특정 타겟 페어링을 설정해야 합니다. |
| 고객 관리 암호화 키(CMEK) | 멀티 리전 Backup Vault는 Backup Vault와 동일한 리전의 CMEK를 사용해야 합니다. | 교차 리전 Backup Vault는 Backup Vault와 동일한 리전의 CMEK를 사용해야 합니다. |
| 비용 영향 | 해당하는 경우 멀티 리전 업로드 및 다운로드 요금 멀티 리전 보관소의 백업 스토리지 요금입니다. 관리 수수료입니다. | 리전 간 데이터 전송 요금 백업 스토리지 요금입니다. 관리 수수료입니다. |
| 지원되는 워크로드 |
|
|
Backup Vault 이름
Backup Vault 이름은 다음 요구사항을 충족해야 합니다.
Backup Vault 이름에는 소문자, 숫자, 하이픈 (
-)만 포함할 수 있습니다. 공백은 허용되지 않습니다.Backup Vault 이름은 숫자 또는 문자로 시작하고 끝나야 합니다.
Backup Vault 이름은 3~63자를 포함해야 합니다. 점을 포함하는 이름은 최대 222자를 포함할 수 있으나, 점으로 구분된 각 부분은 63자 이하여야 합니다.
Backup Vault 이름은 마침표로 구분된 십진수 표기 형식의 IP 주소로 표시할 수 없습니다. 예를 들면
192.0.2.255입니다.
백업 삭제 방지
실수 또는 악의적인 삭제로부터 데이터를 보호하기 위해 관리자는 Backup Vault의 강제 보관 기간을 구성합니다. 구성된 백업은 완전히 변경할 수 없습니다. 지정된 기간이 지나기 전에는 사용자, 다른 사용자 또는 Google에서 수동으로 삭제할 수 없습니다.
다음 세 가지 주요 보관 파일 설정으로 강제 보관을 관리할 수 있습니다.
- 최소 적용 보관 기간: 보관소를 만들 때 기준 보관 기간 (1일~99년)을 설정해야 합니다. 이렇게 하면 보관 파일 전체에 필수 최저 금액이 설정됩니다.
이 시간이 지나기 전에는 백업을 삭제할 수 없습니다. 이 Vault에 데이터를 저장하는 모든 백업 계획의 백업 보관 기간은 이 최소 기간 이상이어야 합니다.
백업 규칙에서 보관 기간 상속: Vault의 기준 최소 기간에만 의존하는 대신 특정 백업 계획에 정의된 정확한 보관 기간을 채택하도록 Vault를 구성할 수 있습니다. Vault를 만드는 동안 이 설정을 사용 설정해야 합니다.
보관 기간이 3일인 Vault를 사용하고 있지만 백업 계획의 보관 기간이 7일인 경우 백업은 7일 동안 잠깁니다. 결과: 수동 삭제가 완전히 방지됩니다. 백업은 백업 계획의 특정 기간이 만료된 후에만 자동으로 삭제됩니다.
적용된 보관 기간 잠금: 엄격한 규정 준수 요구사항이 있는 경우 적용된 최소 보관 구성이 영구적으로 잠글 수 있습니다.
잠금을 설정할 때 시행일을 선택합니다. 시행일 전에는 실수를 수정하기 위해 최소 보관 기간을 늘리거나 줄일 수 있습니다. 시행일이 지난 후에는 프로젝트 소유자를 포함하여 누구도 보관 기간을 줄일 수 없습니다. 증가만 허용됩니다.
Backup Vault 액세스 제한
Backup Vault의 액세스 제한 설정을 사용하면 데이터를 Backup Vault에 백업하거나 Backup Vault에서 복원할 수 있는 소스를 제어할 수 있습니다. 이 설정은 백업 보관소에 저장할 수 있는 리소스 유형을 결정합니다.
백업 보관소에 대해 다음 액세스 제한 설정 중 하나를 선택할 수 있습니다. 이 설정은 영구적이며 변경할 수 없습니다.
현재 조직에 대한 액세스 제한: 백업 및 복원 작업은 현재 조직 내에서만 지원됩니다. 이 선택을 통해 백업 볼트는Google Cloud 콘솔을 통해 관리되는 리소스(예: Compute Engine 인스턴스)와 호환되지만 어플라이언스 관리 콘솔을 통해 관리되는 리소스와는 호환되지 않습니다.
현재 프로젝트에 대한 액세스 제한: 백업 및 복원 작업은 현재 프로젝트 내에서만 지원됩니다. 이 옵션을 선택하면 백업 보관함이Google Cloud 콘솔을 통해 관리되는 리소스 (예: Compute Engine 인스턴스)와 호환되지만 어플라이언스 관리 콘솔을 통해 관리되는 리소스와는 호환되지 않습니다.
현재 조직에 대한 액세스 제한 및 백업 어플라이언스에 대한 무제한 액세스: Google Cloud 콘솔을 통해 관리되는 리소스의 경우 백업 및 복원 작업은 현재 조직 내에서만 지원됩니다. 어플라이언스 관리 콘솔을 통해 관리되는 리소스 (예: Google Cloud VMware Engine VM)도 지원되지만 이러한 리소스의 백업 및 복원 작업은 현재 조직으로 제한되지 않습니다. 이렇게 선택하면 백업 볼트가Google Cloud 콘솔을 통해 관리되는 리소스 및 어플라이언스 관리 콘솔을 통해 관리되는 리소스와 호환됩니다.
무제한 액세스 허용: 모든 프로젝트 또는 조직에서 백업 및 복원 작업을 허용합니다. 이 옵션을 선택하면 백업 볼트가 Google Cloud 콘솔을 통해 관리되는 리소스 및 어플라이언스 관리 콘솔을 통해 관리되는 리소스와 호환됩니다.
암호화
기본적으로 Google Cloud 는 Google-owned and Google-managed encryption keys를 사용하여 데이터를 저장할 때 자동으로 암호화합니다. 데이터를 보호하는 키와 관련된 특정 규정 준수 또는 규제 요구사항이 있으면 백업에 고객 관리 암호화 키 (CMEK)를 사용할 수 있습니다. 고객 관리 암호화 키 (CMEK)를 참고하세요.
다음 단계
- Google Cloud 콘솔에서 Backup Vault 만들기 및 관리
- Backup Vault에 Compute Engine 인스턴스 백업
- Backup Vault에 Cloud SQL 인스턴스 백업
- AlloyDB 클러스터를 Backup Vault로 백업
- Backup Vault에 Filestore 인스턴스 백업
- 디스크를 Backup Vault에 백업