Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

백업 계획 개요

이 페이지에서는 리소스를 백업하기 위한 고급 백업 전략을 정의할 수 있는 백업 계획을 설명합니다. 백업 계획을 사용하여 다음 리소스를 백업할 수 있습니다.

Cloud SQL 인스턴스
Compute Engine 인스턴스 및 디스크
PostgreSQL용 AlloyDB 클러스터
Filestore 인스턴스

백업 계획에서 리소스를 백업하는 시기와 방법을 정의할 수 있습니다. 백업 빈도, 백업 보관 기간, 백업을 저장할 백업 볼트 위치를 포함할 수 있습니다. 백업 계획을 리소스에 연결하면 백업 및 DR에서 백업 계획의 구성에 따라 해당 리소스를 자동으로 백업하고 백업을 보관합니다.

백업 계획을 만들기 전에 Backup Vault를 만들어 백업의 저장소 위치를 지정해야 합니다.

백업 계획에는 하나 이상의 백업 규칙이 포함됩니다. 각 백업 규칙은 다음 매개변수를 정의합니다.

빈도: 시간별, 일별, 주별, 월별 또는 연간으로 백업이 실행되도록 예약할 수 있습니다.
- 시간별: 사용 가능한 빈도는 리소스 유형에 따라 다릅니다. 자세한 내용은 시간별 백업의 빈도 범위를 참고하세요.
- 매주: 특정 요일을 선택할 수 있습니다.
- 매월: 특정 날짜 (예: 15일)를 선택할 수 있습니다.
백업 유형: 예약된 백업에 규칙을 사용하거나 주문형 백업을 시작할 수 있습니다.
백업 기간: 백업 작업을 시작할 수 있는 기간을 정의할 수 있습니다. 백업 기간에는 다음과 같은 요구사항이 있습니다.
- 24시간 시계 형식을 사용해야 하며 시작 시간과 종료 시간은 00~24 사이여야 합니다.
- 6시간 이상이어야 합니다.

제약 조건: 백업 계획에는 항상 부팅 디스크가 포함됩니다. 머신 구성의 데이터 보호 섹션에서 부팅 디스크 제외를 선택해도 백업 계획에는 부팅 디스크가 포함됩니다. 자세한 내용은 추가 비부팅 디스크가 포함된 인스턴스 만들기를 참고하세요.

시간별 백업의 빈도 범위

이 섹션에서는 시간별 백업의 빈도를 지정합니다. 시간별 빈도 1는 시작 시간부터 종료 시간까지 매시간 작업이 실행됨을 의미합니다.

recurrence_type가 HOURLY로 설정된 경우 이 설정이 필요합니다.
recurrence_type이 HOURLY이 아닌 경우 이 설정은 적용되지 않습니다.
이 설정에 값을 제공하고 recurrence_type이 HOURLY이 아닌 경우 유효성 검사 오류가 발생합니다.

각 리소스 유형에 지원되는 값은 다음과 같습니다.

리소스 유형	시간별 빈도
Compute Engine 인스턴스	1-23
Compute Engine 디스크	1-23
Cloud SQL 인스턴스	6-23
PostgreSQL용 AlloyDB 클러스터	1-23
Filestore 인스턴스	1-23

Compute Engine 인스턴스 리소스의 경우 시간별 백업 권장사항을 참고하세요.

데이터베이스 로그 백업

데이터베이스 리소스 (예: Cloud SQL 또는 AlloyDB)의 경우 백업 계획 내에서 로그 백업을 사용 설정할 수 있습니다. 이렇게 하면 전체 백업 지점 간의 트랜잭션 로그를 캡처하여 PITR (point-in-time recovery)이 가능합니다.

백업 및 DR의 데이터 보관 개요

백업 및 DR은 다음 두 가지 보관 유형을 사용하여 백업 수명 주기와 보안을 관리합니다.

할당된 보관 기간: 다음 기간이 지난 후 백업 삭제 설정을 사용하여 백업 계획에 정의됩니다.
- 백업은 이 기간 동안 보관되며 기간이 끝나면 만료됩니다.
- 강제 보관으로 인해 삭제할 수 없는 경우를 제외하고 이 날짜 전에 백업을 수동으로 삭제할 수 있습니다.
강제 보관 기간: Backup Vault 구성에서 삭제 방지 기간 설정을 사용하여 정의됩니다.
- 이 설정을 사용하면 지정된 기간 동안 백업을 삭제할 수 없습니다.
- 적용된 보관 기간이 할당된 보관 기간보다 긴 경우 적용된 보관 기간이 종료될 때까지 백업이 삭제되지 않습니다.
- 전체 Backup Vault에 적용된 보관 기간을 적용하거나 각 보호 리소스에 할당된 보관 기간 (다음 기간이 지나면 백업 삭제)을 적용하도록 Backup Vault를 구성할 수 있습니다.

최대 커스텀 주문형 보관 기간

이 설정은 자동 일정 외부에서 수동으로 생성된 주문형 백업을 보관할 수 있는 최대 일수를 정의합니다. 이렇게 하면 사용자가 실수로 수동 스냅샷의 보관 기간을 지나치게 길게 설정하는 것을 방지할 수 있습니다.

백업 스토리지 사용량

백업 계획의 백업 스토리지에 다음 규칙을 고려하세요.

자동 삭제: 정의된 백업 보관 기간이 지나면 백업이 자동으로 삭제됩니다.
최소 보관 기간: 백업 보관 기간은 Backup Vault의 최소 보관 기간 이상이어야 합니다.
상속된 기본값: 백업 삭제의 기본값은 Backup Vault의 최소 보관 기간에서 상속됩니다.
변경 불가능성: 백업 계획을 사용하여 생성된 백업은 변경 불가능합니다. 백업 Vault의 최소 적용 보관 기간 동안에는 수정하거나 삭제할 수 없습니다.

CMEK 지원 Backup Vault에 워크로드 백업

CMEK로 Backup Vault를 구성하면 여기에 저장된 백업이 지정된 키를 사용하여 보호됩니다. 백업 계획을 CMEK 지원 볼트와 연결할 때는 다음 규칙이 적용됩니다.

CMEK로 보호되는 워크로드: 소스 워크로드가 CMEK로 보호되는 경우 (예: CMEK로 암호화된 디스크가 있는 Compute Engine 인스턴스) CMEK 지원 Backup Vault에 백업해야 합니다. Google-owned and Google-managed encryption keys를 사용하는 Backup Vault에 CMEK 보호 리소스를 백업할 수 없습니다.
Google-owned and Google-managed encryption keys를 사용하는 워크로드: 소스 워크로드에서 Google-owned and Google-managed encryption keys를 사용하는 경우 Google-owned and Google-managed encryption keys를 사용하는 Backup Vault에 백업해야 합니다.

백업 작업 재시도

예약된 작업이 실패하면 스케줄러가 작업을 최대 3번까지 자동으로 재시도합니다.

첫 번째 실패: 상태가 '다시 시도됨'으로 표시되고 4분 동안 기다립니다.
두 번째 실패: 16분 후에 다음 재시도가 대기열에 추가됩니다.
세 번째 실패: 64분 후에 최종 재시도가 대기열에 추가됩니다.
최종 실패: 총 4번의 시도 후 상태가 '실패'로 변경됩니다. 해당 일정 기간에는 더 이상 작업이 시도되지 않습니다.

작업 재시도는 모니터링 > 작업에 보고됩니다. 재시도를 식별하기 위해 네 작업 모두 고유한 접미사 (예: Job_12345, Job_12345a, Job_12345b)가 있는 동일한 작업 번호를 공유합니다.

백업 계획 지원 리전

백업 계획은 백업 및 DR을 사용할 수 있고 백업할 리소스가 있는 리전에서만 만들 수 있습니다. 백업 계획을 만들려면 호환되는 위치에 Backup Vault도 있어야 합니다. 지원되지 않는 리전에서 백업 계획을 만들어야 하는 경우 어플라이언스 관리 콘솔에서 백업 템플릿을 사용하세요.

백업 계획은 다음 리전에서 지원됩니다.

지리적 지역	리전 이름	리전 설명
북미
	`northamerica-northeast1` ^*	몬트리올	낮은 CO₂
	`northamerica-northeast2`	토론토	낮은 CO₂
	`us-central1`	아이오와	낮은 CO₂
	`us-east1`	사우스캐롤라이나
	`us-east4`	북버지니아
	`us-east5`	콜럼버스
	`us-south1`	댈러스	낮은 CO₂
	`us-west1`	오리건	낮은 CO₂
	`us-west2`	로스앤젤레스
	`us-west3`	솔트레이크시티
	`us-west4`	라스베이거스
	`northamerica-south1` ^*	케레타로
남미
	`southamerica-east1`	상파울루	낮은 CO₂
	`southamerica-west1`	산티아고	낮은 CO₂
유럽
	`europe-central2`	바르샤바	낮은 CO₂
	`europe-north1`	핀란드	낮은 CO₂
	`europe-north2`	스톡홀름	낮은 CO₂
	`europe-southwest1`	마드리드	낮은 CO₂
	`europe-west1`	벨기에	낮은 CO₂
	`europe-west2`	런던	낮은 CO₂
	`europe-west3`	프랑크푸르트
	`europe-west4`	네덜란드	낮은 CO₂
	`europe-west6`	취리히	낮은 CO₂
	`europe-west8`	밀라노	낮은 CO₂
	`europe-west9`	파리	낮은 CO₂
	`europe-west10`	베를린
	`europe-west12`	토리노	낮은 CO₂
중동
	`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)에서는 영역 분리를 지원하지 않습니다. 즉, 이러한 각 리전 내의 여러 영역이 물리적으로 분리된 데이터 센터 캠퍼스에 위치하지 않을 수 있습니다. 따라서 단일의 현지화된 물리적 재해 이벤트가 동일한 리전 내의 여러 영역에 영향을 미칠 수 있으므로 영역 분리를 지원하는 리전에 비해 데이터 손실 위험이 증가합니다.

백업 계획 및 규칙 이름

백업 계획 이름과 규칙 이름은 다음 요구사항을 충족해야 합니다.

소문자, 숫자, 대시 (-), 밑줄 (_), 마침표 (.)를 포함해야 하며 공백은 허용되지 않습니다.
숫자 또는 문자로 시작하고 끝남
최대 63자(영문 기준)
점 십진 표기법 형식의 IP 주소로 표시할 수 없습니다. 예를 들면 192.0.2.255입니다.

다음 단계

보관된 백업의 백업 계획 만들기 및 관리