백업의 주요 특징

• 수명 주기: 백업은 데이터베이스 인스턴스의 수명 주기와 연동되어 있으며, 인스턴스가 삭제되면 백업도 함께 삭제됩니다
• 보존 기간: 백업 데이터는 30일간 보관됩니다
• 암호화: 백업 데이터는 저장 시 ‘ AES-256 ’ 암호화를 통해 암호화됩니다
• 복원: 백업은 생성된 리전 내에서만 복원할 수 있습니다
• 유형: 자동(매일) 백업과 수동(요청 시) 백업 모두 사용할 수 있습니다

중요한 백업 정보

• 백업 스토리지가 암호화되어 있습니다. 암호화 키를 관리하려면 ‘ IBM® Key Protect ’ 연동 항목을 참조하세요. 그렇지 않은 경우, 백업 데이터는 해당 인스턴스에 대해 자동으로 생성된 키로 암호화됩니다.
• 백업은 복원을 수행하는 사용자가 해당 백업에 대한 액세스 권한은 물론, 원본 및 대상 계정 모두에 대한 액세스 권한을 가지고 있는 경우에만 계정 간에 복원할 수 있습니다.
• Cloud Databases 백업 파일은 다운로드할 수 없습니다. 로컬 백업이 필요한 경우, 적절한 소프트웨어를 사용하십시오. 예를 들어, pg_dump는 PostgreSQL 백업을 관리하는 데 유용한 도구입니다.

백업을 삭제하면 영구적으로 삭제되며, 이 작업을 되돌릴 수 없습니다. 삭제하기 전에 해당 백업 데이터가 더 이상 필요하지 않은지 확인하십시오.

On-Demand 백업 수행

인스턴스에 대한 대규모 변경(예: 확장 또는 데이터베이스, 테이블, 컬렉션 제거 등)을 계획하고 있다면, 온디맨드 백업이 유용합니다. 또한 스케줄을 백업해야 하는 경우에도 유용할 수 있습니다. On-Demand 백업은 30일 동안 보관됩니다.

인스턴스에는 총 디스크 용량과 동일한 용량의 백업 저장 공간이 무료로 제공됩니다. 백업 저장소 사용량이 총 디스크 용량을 초과하는 경우, 초과된 1기가바이트당 $0.095/month 의 요금이 부과됩니다. 백업 데이터는 압축되어 있으므로, 주문형 백업을 사용하더라도 대부분의 인스턴스는 할당된 크레딧 한도를 초과하지 않습니다.

백업 복원

백업 데이터는 새로운 인스턴스로 복원됩니다. 새 인스턴스의 프로비저닝이 완료되면, 백업 파일에 있는 데이터가 새 인스턴스로 복원됩니다.

기본적으로 새 인스턴스는 복원 대상인 백업 시점의 소스 인스턴스와 동일한 호스트 크기와 기본 디스크 크기로 자동 조정됩니다. 새 인스턴스에 할당된 리소스를 조정하려면 UI, CLI 또는 API의 선택적 필드를 사용하여 새 인스턴스의 크기를 조정하십시오. 데이터 및 워크로드에 필요한 만큼의 리소스를 충분히 할당해야 합니다. 인스턴스에 충분한 리소스가 할당되지 않았거나, 백업에 포함된 스토리지 용량이 기본 디스크 크기보다 크면서 디스크 크기가 명시되지 않은 경우, 복원이 실패합니다.

백업 복원 작업이 진행 중인 동안 소스 인스턴스를 삭제하지 마십시오. 기존 인스턴스를 삭제하기 전에, 새 인스턴스가 프로비저닝되고 백업이 복원될 때까지 기다리십시오. 인스턴스를 삭제하면 해당 인스턴스의 백업도 함께 삭제됩니다.

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-ID>-gen2-<PLAN NAME> <REGION> -p  '{"dataservices":{"restore_backup_id":"<BACKUP_CRN>"}}'

ibmcloud resource service-instance-create postgresql-restore-abc databases-for-postgresql databases-for-postgresql-gen2-standard ca-mon -p  '{"dataservices":{"restore_backup_id":"crn:v1:bluemix:public:databases-for-postgresql:ca-mon:a/26b19aex04da4475b6e31205fa93248d:a1e247d8-01c2-3bbe-a5e6-fdb5eb872d2f:backup:f689275f-7da9-4e90-9055-70b02c575492"}}'

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-ID> gen2-<PLAN NAME> <REGION> -p
'{"restore_backup_id":"BACKUP_ID","key_protect_key":"KEY_PROTECT_KEY_CRN", "storage_gb":"DESIRED_DISK_IN_GB", "host_flavor": "<VALUE>"}'

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "<INSTANCE_NAME>",
    "target": "<REGION>",
    "resource_group": "<YOUR-RESOURCE-GROUP>",
    "resource_plan_id": "<SERVICE-ID>",
    "parameters":{
      "restore_backup_id": "<BACKUP_ID>"
    }
  }'

백업 암호화

백업 데이터는 저장 시 데이터베이스 인스턴스와 동일한 암호화 방식으로 암호화됩니다. Key Protect 를 사용하여 데이터베이스 암호화를 관리하는 경우, 백업 파일도 동일한 키로 암호화됩니다. 자세한 정보는 Key Protect 통합을 참조하십시오.

Key Protect 키로 암호화된 백업을 복원할 때는 동일한 키를 사용하거나 다른 키를 사용할 수 있습니다. 다른 키를 사용하면 새 인스턴스는 해당 키로 암호화됩니다.

하이드레이션이 완료될 때까지 IO 성능이 저하된 상태로 복원된 데이터베이스 인스턴스에 즉시 액세스할 수 있습니다. 복원된 인스턴스의 하이드레이션이 완료되기 전까지는 백업을 생성할 수 없습니다. 플랫폼의 활동 추적 이벤트를 통해 수분 섭취 완료 여부를 확인할 수 있습니다. 자세한 내용은 ‘플랫폼 이벤트 목록’을 참조하십시오.

계정 간 복원

백업은 IBM Cloud 계정 간에 복원할 수 있으며, 이를 통해 다음과 같은 시나리오가 가능합니다:

• 테스트를 위해 개발 계정에 프로덕션 데이터를 복원하기
• 조직 단위 간 데이터베이스 마이그레이션
• 별도의 계정으로의 재해 복구

백업을 다른 계정에 복원하려면:

1. 소스 계정은 대상 계정에 백업 리소스에 대한 액세스 권한을 부여해야 합니다
2. 대상 계정에서 새 인스턴스를 생성할 때 백업 CRN을 사용하십시오
3. 대상 계정에 적절한 IAM 권한이 부여되어 있는지 확인하십시오

백업 및 복구 책임

• Cloud Databases 당사는 해당 백업의 복원, 적시성 또는 유효성에 대해 책임을 지지 않습니다.
• 사용자로서 수행하는 조치가 메모리 및 디스크 할당 부족과 같이 백업의 무결성을 손상시킬 수 있습니다. 사용자는 API를 사용하여 백업이 성공적으로 수행되는지 모니터하고, 백업을 주기적으로 복원하여 유효성과 무결성을 확인할 수 있습니다. 사용자는 Cloud Databases 리소스 컨트롤러 CLI 및 Cloud Databases 리소스 컨트롤러 API를 통해 가장 최근에 예약된 백업 세부 정보를 확인할 수 있습니다.
• 관리 서비스인 Cloud Databases은(는) 백업 상태를 모니터하고 가능한 경우 수정을 시도할 수 있습니다. 복구할 수 없는 문제가 발생하면 지원팀에 문의하여 추가 도움을 받으십시오.

비즈니스 연속성 및 재해 복구

Cloud Databases 데이터를 보호하고 서비스 기능을 복구할 수 있는 메커니즘을 제공합니다. 자세한 내용( 백업 스토리지 리전 포함)은 “ Cloud Databases 의 비즈니스 연속성 및 재해 복구 이해”를 참조하십시오.