백업 및 DR 서비스는 Google Cloud 콘솔에서 Cloud SQL 인스턴스, Compute Engine 인스턴스, 개별 디스크의 백업을 지원합니다. 이러한 리소스의 백업 및 복원 절차는 Google Cloud 콘솔 문서에서 확인할 수 있습니다. 모든 워크로드가 이러한 카테고리에 속하는 경우 백업/복구 어플라이언스가 필요하지 않습니다.
백업 및 DR 서비스는 Compute Engine 인스턴스 내에서 실행되는 VMware VM 및 SAP HANA, IBM Db2, Oracle, Microsoft SQL Server 데이터베이스의 백업도 지원합니다. 이러한 백업에는 백업 및 DR 관리 콘솔과 하나 이상의 백업/복구 어플라이언스가 필요합니다. 이 설정을 사용하는 경우 백업하는 애플리케이션에 맞게 백업/복구 어플라이언스의 크기를 선택해야 합니다. 이 설정의 흐름에는 관리 서버를 만들고, 어플라이언스를 배포하고, 백업 및 DR 관리 콘솔을 사용하여 백업 일정을 구성하고 백업할 항목과 위치를 정의하는 작업이 포함됩니다.
이 페이지에서는 Backup and DR Service를 초기 활성화하고 프로젝트 구성을 설정하는 방법을 설명합니다.
시작하기 전에
백업/복구 어플라이언스를 배포하는 방법을 계획하기 전에 백업/복구 어플라이언스 배포 고려사항을 검토하는 것이 좋습니다.
백업/복구 어플라이언스 아키텍처의 구성요소
백업 및 DR 서비스 아키텍처는 다음 구성요소를 통해 제공됩니다.
Google Cloud 콘솔: Google Cloud Google Cloud 콘솔에는 영구 디스크 보관 백업, Compute Engine 인스턴스용 백업 계획, 해당 제품의 Cloud SQL용 고급 백업을 중앙에서 관리할 수 있는 백업 및 DR 제품이 포함되어 있습니다.
관리 콘솔: 관리 콘솔은 백업/복구 어플라이언스의 관리 플레인 역할을 합니다. 각 백업 및 DR 배포에는 원하는 수의 백업/복구 어플라이언스를 관리하는 단일 관리 콘솔이 포함됩니다. 관리 콘솔은 백업 관리 프로젝트에 배포되며 배포된 리전 내에서 고가용성을 제공하여 영역 서비스 중단에 대한 복원력을 제공합니다.
백업/복구 어플라이언스: 백업/복구 어플라이언스는 기업 내에서 백업 데이터의 수명 주기를 효율적으로 캡처, 이동, 관리하는 데이터 이동기입니다. 백업/복구 어플라이언스는 클라우드 워크로드의 워크로드 엔티티에 배포됩니다.
백업 및 DR 에이전트: 백업 및 DR 에이전트는 애플리케이션 네이티브 API를 호출하여 프로덕션 애플리케이션에서 데이터를 영구 증분 방식으로 효율적으로 캡처하고 복구 시 애플리케이션 인식을 제공합니다. 에이전트는 보호할 애플리케이션이 있는 애플리케이션 호스트에 설치됩니다. 전체 VM 또는 일부 디스크만 보호하는 경우에는 Backup and DR 에이전트가 필요하지 않습니다.
관리 콘솔이 서비스 프로듀서 VPC 네트워크에 활성화됩니다. 이 서비스 제작자 VPC는 비공개 Google 액세스를 사용하여 프로젝트와 통신합니다.
관리 서버와 어플라이언스 간, 어플라이언스 간, 어플라이언스와 호스트 에이전트 간의 통신은 상호 TLS 인증으로 보호됩니다.
Google Cloud 콘솔에서 백업 및 DR 서비스 설정
Google Cloud 콘솔로 이동하여 백업 및 DR 서비스 API를 활성화하고 계정 권한을 설정합니다.
백업/복구 어플라이언스 유형
백업 및 DR 서비스는 다양한 워크로드(Compute Engine VM, VMware VM, 데이터베이스, 파일 시스템)에 최적화된 어플라이언스 유형을 제공합니다. 필요에 가장 적합한 어플라이언스 유형을 선택할 수 있습니다. 워크로드에 가장 적합한 어플라이언스 유형을 선택하는 것이 중요합니다. 백업/복구 어플라이언스가 서비스 중이면 항상 백업, 복원 및 기타 작업을 실행하고 다시 실행할 준비가 되어 있어 영원히 계속 실행됩니다.
백업 및 DR 서비스는 다음 어플라이언스 유형을 제공합니다.
- VMware VM 및 기타 데이터베이스 또는 리소스를 위한 표준: 이 n2-standard-16 머신 유형은 프로덕션 데이터베이스, VMware VM, 기타 리소스를 백업하기 위한 최적의 성능을 지원합니다. 이 어플라이언스는 배포 시 균형 잡힌 디스크 용량 4TB를 추가하며 4TB 디스크 63개를 추가할 수 있습니다. 이 어플라이언스는 최대 1,500개의 애플리케이션과 5,000개의 일일 스냅샷을 관리할 수 있습니다.
- Compute Engine VM 또는 SAP HANA 데이터베이스용 표준: 이 e2-standard-4 머신 유형은 Compute Engine 인스턴스, Cloud SQL 인스턴스, 영구 디스크를 사용하여 백업하는 데이터 리소스(영구 디스크를 사용하도록 구성된 IBM Db2 및 SAP HANA 데이터베이스)를 백업하는 데 가장 적합합니다. 이 어플라이언스 유형의 최소 영구 디스크 용량은 10GB입니다. 이 어플라이언스는 최대 5,000개의 Compute Engine 및 Cloud SQL 인스턴스와 Persistent Disk 기반 데이터 애플리케이션을 관리할 수 있습니다.
VMware VM 및 기타 데이터베이스 또는 리소스를 위한 기본: 이 e2-standard-16 머신 유형은 데이터베이스, VMware VM, 기타 리소스를 백업하기 위한 적당한 성능을 지원합니다. 이 어플라이언스는 최대 1,500개의 애플리케이션과 5,000개의 일일 스냅샷을 관리할 수 있습니다. 이 어플라이언스는 배포 시 4TB의 표준 디스크 용량을 추가하며 다음 유형의 4TB 디스크를 63개 추가할 수 있습니다.
- 최소 용량 영구 디스크: 이 옵션은 최소 디스크 용량 10GB를 제공합니다. 이 스토리지 유형에서 백업은 영구 디스크 스냅샷으로 저장되며 백업/복구 어플라이언스의 로컬 스토리지를 소비하지 않습니다.
- 표준 영구 디스크: 효율적인 블록 스토리지를 사용하려면 이 스토리지 유형을 선택하세요. Compute Engine VM 외에도 I/O가 중간 수준 이상인 Google Cloud VMware Engine VM, 데이터베이스 또는 파일 시스템 애플리케이션에 권장합니다. 이렇게 하면 영구 디스크 용량이 최소 디스크 용량으로 4TB가 추가됩니다.
- SSD 영구 디스크: 빠른 블록 스토리지를 사용하려면 이 스토리지 유형을 선택합니다. Compute Engine VM 외에도 I/O가 매우 높은 Google Cloud VMware Engine, 데이터베이스 또는 파일 시스템 애플리케이션에 권장합니다. 이렇게 하면 영구 디스크 용량이 최소 디스크 용량으로 4TB가 추가됩니다.
어플라이언스를 배포하면 어플라이언스 유형과 관계없이 서비스 계정이 자동으로 생성됩니다. 서비스 계정 페이지에서 서비스 계정을 볼 수 있습니다.
서비스 계정의 이름은 my-service-account@my-project.iam.gserviceaccount.com
형식의 이메일 주소에 표시됩니다. 여기서 appliance-name은 어플라이언스의 이름이고 projectid는 Google Cloud 프로젝트의 ID입니다.
데이터 액세스 예상 필요에 따라 장기 보관이 필요한 백업을 Google Cloud Standard, Nearline, Coldline 스토리지로 이동할 수 있습니다.
방화벽 구성
백업 및 DR 서비스로의 인그레스에 필요한 다음 방화벽 규칙이 자동으로 추가됩니다.
목적 | 소스 | 대상 | 포트 (TCP) |
---|---|---|---|
지원 트래픽 (어플라이언스 지원) | SSH 클라이언트를 실행하는 호스트 | 백업/복구 어플라이언스 | 26 |
iSCSI 백업 (호스트에서 어플라이언스로) | 백업 및 DR 에이전트를 실행하는 호스트 | 백업/복구 어플라이언스 | 3260 |
StreamSnap 트래픽 (어플라이언스 간) | 백업/복구 어플라이언스 | 백업/복구 어플라이언스 | 5107 |
백업/복구 어플라이언스와 관리 콘솔 간 연결 | 백업/복구 어플라이언스 IP 또는 서브넷 | *.backupdr.googleusercontent.com | 443 |
이 규칙을 구성하는 방법에 대한 자세한 내용은 백업 및 DR 서비스 배포 준비를 참고하세요.
Backup and DR 에이전트를 실행하는 모든 호스트의 경우 인그레스 방화벽 규칙과의 연결을 허용하도록 다음 TCP 포트를 수동으로 추가해야 합니다.
목적 | 소스 | 대상 | 포트 (TCP) |
---|---|---|---|
에이전트 트래픽 (어플라이언스에서 호스트로) | 백업/복구 어플라이언스 | 백업 및 DR 에이전트를 실행하는 호스트 | 5106 |
백업 트래픽에 NFS를 사용하는 호스트 또는 마운트에 NFS를 사용하는 Google Cloud VMware Engine에서 실행되는 ESX 호스트의 경우 인그레스 방화벽 규칙과의 연결을 허용하려면 다음 TCP 및 UDP 포트를 수동으로 추가해야 합니다.
목적 | 소스 | 대상 | 포트 (TCP/UDP) |
---|---|---|---|
NFS 백업 또는 마운트 | 에이전트를 실행하는 호스트 또는 마운트를 실행하는 ESXi 호스트 | 백업/복구 어플라이언스 | 111, 756, 2049, 4001, 4045 |
이 작업 중에 사용되는 권한 목록은 백업 및 DR 설치 권한 참조를 참고하세요.
지원되는 리전
다음 섹션에는 관리 콘솔 및 백업/복구 어플라이언스가 지원되는 리전이 나와 있습니다.
관리 콘솔 지원 리전
백업 및 DR 서비스를 사용하여 모든Google Cloud 리전에서 지원되는 워크로드를 백업할 수 있지만 관리 콘솔은 다음 리전에서만 활성화할 수 있습니다.
지리적 지역 | 리전 이름 | 리전 설명 | |
---|---|---|---|
북미 | |||
northamerica-northeast1 * |
몬트리올 |
|
|
northamerica-northeast2 |
토론토 |
|
|
us-central1 |
아이오와 |
|
|
us-east1 |
사우스캐롤라이나 | ||
us-east4 |
북버지니아 | ||
us-east5 |
콜럼버스 | ||
us-south1 |
댈러스 |
|
|
us-west1 |
오리건 |
|
|
us-west2 |
로스앤젤레스 | ||
us-west3 |
솔트레이크시티 | ||
us-west4 |
라스베이거스 | ||
northamerica-south1 * |
케레타로 | ||
남미 | |||
southamerica-east1 |
상파울루 |
|
|
southamerica-west1 |
산티아고 |
|
|
유럽 | |||
europe-central2 |
바르샤바 | ||
europe-north1 |
핀란드 |
|
|
europe-north2 |
스톡홀름 |
|
|
europe-southwest1 |
마드리드 |
|
|
europe-west1 |
벨기에 |
|
|
europe-west2 |
런던 |
|
|
europe-west3 |
프랑크푸르트 | ||
europe-west4 |
네덜란드 |
|
|
europe-west6 |
취리히 |
|
|
europe-west8 |
밀라노 | ||
europe-west9 |
파리 |
|
|
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 |
델리 |
* 케레타로, 몬트리올, 오사카의 경우 물리적 데이터 센터 1~2곳에 영역 3개가 있습니다. 드물지만 재해 발생 시 이러한 리전에 저장된 데이터가 손실될 수 있습니다.
백업/복구 어플라이언스 지원 리전
백업/복구 어플라이언스는 모든 Google Cloud 영역에 배포할 수 있습니다.
백업/복구 어플라이언스 배포를 실행하는 워크플로 서비스는 나열된 리전에서 지원됩니다. 백업/복구 어플라이언스가 배포된 리전에서 워크플로 서비스를 사용할 수 없는 경우 백업 및 DR 서비스는 기본적으로 us-central1
리전에서 워크플로를 실행합니다(어플라이언스 자체는 선택한 리전에서 계속 생성됨). 다른 리전에서 리소스 생성을 방지하도록 설정된 조직 정책이 있는 경우 us-central1
리전에서 리소스 생성을 허용하도록 조직 정책을 일시적으로 업데이트해야 합니다. 백업/복구 어플라이언스를 배포한 후 us-central1
지역을 제한할 수 있습니다.