Cloud Databases 백업 관리하기
매일 자동으로 예약된 데이터베이스 백업이 수행됩니다. 원할 때 언제든지 주문형 백업을 실행할 수도 있습니다. 백업은 자동 키로 암호화되거나 BYOK(Bring Your Own Key)를 사용하는 경우 사용자의 키로 암호화됩니다. Cloud Databases 새 인스턴스로 백업을 복원할 수 있습니다.
Cloud Databases 대한 백업에 액세스하려면 데이터베이스 인스턴스의 대시보드로 이동하여 백업 및 복원 탭을 참조하세요.
백업에 관한 몇 가지 추가적인 일반 정보:
- 자동 백업은 매일 수행되며 30일의 간단한 보존 일정으로 유지됩니다.
- 백업을 삭제할 수 없습니다.
- 인스턴스를 삭제하면 해당 인스턴스의 백업도 자동으로 삭제됩니다.
- 일일 백업 일정은 구성할 수 없습니다.
- 백업은 서로 간에만 백업을 복원할 수 있는
eu-de,eu-es,par-01제외한 다른 지역으로 복원할 수 있습니다. 예를 들어par-01백업은eu-de, *와eu-es사이로 복원할 수 있습니다. - 백업 스토리지가 암호화되어 있습니다. 암호화 키를 관리하려면 Key Protect 통합을 참조하세요. 그렇지 않은 경우, 백업 데이터는 해당 인스턴스에 대해 자동으로 생성된 키로 암호화됩니다.
- 백업은 계정 간에 복원할 수 있지만, API를 통해서만 가능하며, 복원을 실행하는 사용자가 원본 계정과 대상 계정 모두에 대한 접근 권한을 가지고 있는 경우에만 가능합니다.
- Cloud Databases 백업은 다운로드할 수 없습니다. 로컬 백업이 필요한 경우 적절한 소프트웨어를 사용하세요. 예를 들어, pg_dump는 PostgreSQL 백업을 관리하는 데 효과적인 도구입니다. MySQL, 의 경우 mysqldump를 사용할 수 있습니다.
주문형 백업을 만드는 방법에 대한 자세한 내용은 주문형 백업 만들기를 참조하세요.
주문형 백업을 만드는 방법에 대한 자세한 내용은 주문형 백업 만들기를 참조하세요.
주문형 백업을 만드는 방법에 대한 자세한 내용은 주문형 백업 만들기를 참조하세요.
UI의 백업
UI에서 백업 및 복원 탭으로 이동하면 데이터베이스에 사용 가능한 모든 백업이 표시된 표가 표시됩니다.
백업 유형은 온디맨드 또는 자동 중 하나를 선택할 수 있습니다. 각 백업은 해당 유형 및 백업이 수행된 시기와 함께 나열됩니다.
전체 ID를 포함하여 특정 백업에 대한 정보를 표시하려면 백업을 클릭하십시오. 복원 옵션으로는 ‘복원’ 버튼이나 미리 형식이 지정된 CLI 명령어가 제공됩니다.
UI에서 온디맨드 백업하기
데이터베이스, 테이블, 컬렉션을 확장하거나 제거하는 등 인스턴스를 크게 변경할 계획이라면 온디맨드 백업이 유용합니다. 또한 스케줄을 백업해야 하는 경우에도 유용할 수 있습니다. On-Demand 백업은 30일 동안 보관됩니다.
인스턴스에는 총 디스크 용량과 동일한 용량의 백업 저장 공간이 무료로 제공됩니다. 백업 저장소 사용량이 총 디스크 용량을 초과하는 경우, 초과된 1기가바이트당 $0.03/month 의 요금이 부과됩니다. 백업 데이터는 압축되어 있으므로, 주문형 백업을 사용하더라도 대부분의 인스턴스는 할당된 크레딧 한도를 초과하지 않습니다.
UI에서 수동 백업을 만들려면 인스턴스의 백업 및 복원 탭으로 이동한 다음 백업 만들기를 클릭합니다. 백업이 진행 중이라는 메시지가 표시되고 On-Demand 백업이 사용 가능한 백업 목록에 추가됩니다.
CLI의 백업
Cloud Databases CLI 플러그인과 Cloud Databases API를 통해 백업 목록 및 개별 백업 정보를 확인할 수 있습니다.
다음 cdb deployment-backups-list 명령을 사용하여 인스턴스에 대해 사용 가능한 모든 백업 목록을 확인하십시오. 특정 백업에 대한 자세한 내용을 보려면 cdb backup-show 명령을 사용하세요.
예를 들어, "example-instance"라는 이름의 인스턴스에 대한 백업을 확인하려면 다음 명령어를 사용하십시오:
ibmcloud cdb deployment-backups-list <INSTANCE_NAME_OR_CRN>
목록에 있는 백업 중 하나의 세부 정보를 확인하려면, deployment-backups-list 응답의 ID 필드에서 ID를 가져와 backup-show 명령어와 함께 사용하십시오:
ibmcloud cdb backup-show crn:v1:staging:public:cloud-databases:us-south:a/6284014dd5b487c87a716f48aeeaf99f:3b4537bf-a585-4594-8262-2b1e24e2701e:backup:a3364821-d061-413f-a0df-6ba0e2951566
CLI에서 온디맨드 백업하기
데이터베이스, 테이블, 컬렉션을 확장하거나 제거하는 등 인스턴스를 크게 변경할 계획이라면 온디맨드 백업이 유용합니다. 또한 스케줄을 백업해야 하는 경우에도 유용할 수 있습니다. On-Demand 백업은 30일 동안 보관됩니다.
인스턴스에는 총 디스크 용량과 동일한 용량의 백업 저장 공간이 무료로 제공됩니다. 백업 저장소 사용량이 총 디스크 용량을 초과하는 경우, 초과된 1기가바이트당 $0.03/month 의 요금이 부과됩니다. 백업 데이터는 압축되어 있으므로, 주문형 백업을 사용하더라도 대부분의 인스턴스는 할당된 크레딧 한도를 초과하지 않습니다.
CLI에서 cdb deployment-backup-now 명령어로 주문형 백업이 트리거됩니다. 백업 상태를 확인하려면 ibmcloud cdb backup-show 명령을 사용하세요. 예를 들어, 다음과 같습니다.
ibmcloud cdb deployment-backup-now <INSTANCE_NAME_OR_CRN>
ibmcloud cdb backup-show <INSTANCE_NAME_OR_CRN>
Cloud Databases API의 백업 기능
Cloud Databases API의 백업 정보를 확인하려면 /deployments/{id}/backups 엔드포인트를 사용하여 인스턴스의 백업 목록을 확인하십시오. 특정 백업에 대한 정보를 얻으려면 /backups/{backup_id} 엔드포인트를 사용하세요.
API에서 온디맨드 백업하기
데이터베이스, 테이블, 컬렉션을 확장하거나 제거하는 등 인스턴스를 크게 변경할 계획이라면 온디맨드 백업이 유용합니다. 또한 스케줄을 백업해야 하는 경우에도 유용할 수 있습니다. On-Demand 백업은 30일 동안 보관됩니다.
인스턴스에는 총 디스크 용량과 동일한 용량의 백업 저장 공간이 무료로 제공됩니다. 백업 저장소 사용량이 총 디스크 용량을 초과하는 경우, 초과된 1기가바이트당 $0.03/month 의 요금이 부과됩니다. 백업 데이터는 압축되어 있으므로, 주문형 백업을 사용하더라도 대부분의 인스턴스는 할당된 크레딧 한도를 초과하지 않습니다.
API에서 /deployments/{id}/backups 엔드포인트에 대한 POST를 보내면 On-Demand 백업이 트리거됩니다.
백업 복원
백업 데이터는 새로운 인스턴스로 복원됩니다. 새 인스턴스의 프로비저닝이 완료되면, 백업 파일에 있는 데이터가 새 인스턴스로 복원됩니다.
기본적으로 새 인스턴스는 복원 대상인 백업 시점의 소스 인스턴스와 동일한 디스크 및 메모리 할당량으로 자동 조정됩니다. 새 인스턴스에 할당된 리소스를 조정하려면 UI, CLI 또는 API의 선택적 필드를 사용하여 새 인스턴스의 크기를 조정하십시오. 데이터 및 워크로드에 필요한 만큼의 리소스를 충분히 할당해야 합니다. 인스턴스에 충분한 리소스가 할당되지 않으면 복원이 실패합니다.
백업 복원 중에는 소스 인스턴스를 삭제하지 마십시오. 기존 인스턴스를 삭제하기 전에, 새 인스턴스가 프로비저닝되고 백업이 복원될 때까지 기다리십시오. 인스턴스를 삭제하면 해당 백업도 삭제됩니다.
UI에서 백업 복원
백업을 새 서비스 인스턴스로 복원하려면 다음을 수행하십시오.
- 해당 행을 클릭하여 복원할 백업에 대한 옵션을 펼치십시오.
- 복원을 누릅니다.
- 프로비저닝 페이지에서 사용 가능한 몇 가지 옵션 중에서 선택합니다.
- 새 인스턴스의 이름은 자동으로 ‘
<name>-restore-[timestamp]’로 지정되지만, 이름을 변경할 수 있습니다. - 또한 새 인스턴스가 위치할 지역을 선택할 수도 있습니다.
eu-de지역으로(부터) 복원하는 경우를 제외하고 교차 지역 복원이 지원됩니다. - 새 인스턴스의 리소스를 확장하거나 축소할 수 있도록 초기 리소스 할당량을 선택할 수 있습니다. 전용 코어를 사용 또는 사용 안함으로 설정할 수도 있습니다. 리소스 양을 줄이면 프로비저닝이 실패하거나 데이터베이스가 제대로 작동하지 않을 수 있다는 점에 유의하세요.
- 새 인스턴스의 이름은 자동으로 ‘
- 백업 복원을 클릭합니다. "백업에서 복원이 시작됨" 메시지가 나타납니다. '새 인스턴스가 이제 사용 가능합니다'를 클릭하면 리소스 목록으로 이동합니다.
CLI에서 백업 복원
리소스 컨트롤러는 데이터베이스 인스턴스의 프로비저닝을 지원하며, 프로비저닝 및 복원은 리소스 컨트롤러 CLI의 담당 영역입니다. resource service-instance-create 명령을 사용하십시오.
ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-ID> standard <REGION> --service-endpoints <ENDPOINT-TYPE> -p '{"backup_id":"BACKUP_ID"}'
instance_name의 값을 새 인스턴스에 부여할 이름으로 변경하십시오.service-id는 인스턴스의 유형으로, databases-for-postgresql이나 messages-for-rabbitmq 등이 이에 해당합니다.region는 새 인스턴스를 배치할 위치로, 소스 인스턴스와는 다른 리전일 수도 있습니다. 다른 지역을 사용하여eu-de으로(부터) 복원하는 경우를 제외하고 교차 지역 복원이 지원됩니다.backup_id는 복원할 백업입니다.
이전 명령은 원래 배포와 동일한 구성 및 동일한 호스팅 모델에 있는 컴퓨터로 백업을 복원합니다.
선택적 매개변수
CLI를 통해 선택적 매개변수를 사용할 수 있습니다. 리소스를 사용자 지정하거나, 호스팅 모델을 변경하거나, 새 인스턴스에서 BYOK( Key Protect ) 암호화를 위해 키를 사용해야 하는 경우 이를 활용하십시오. 다음 예를 참조하십시오.
ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-ID> standard <REGION> -p
'{"backup_id":"BACKUP_ID","key_protect_key":"KEY_PROTECT_KEY_CRN", "members_disk_allocation_mb":"DESIRED_DISK_IN_MB", "members_host_flavor": "<VALUE>", "members_memory_allocation_mb":"DESIRED_MEMORY_IN_MB", "members_cpu_allocation_count":"NUMBER_OF_CORES"}'
' members_host_flavor ' 값은 "멀티테넌트" 또는 적절한 크기의 격리 컴퓨트 호스트일 수 있습니다( 사용 가능한 값 목록 참조). "멀티테넌트" 호스팅을 사용하는 경우에만 ' members_memory_allocation_mb ' 또는 ' members_cpu_allocation_count '를 지정하세요.
특정 백업에 대한 미리 형식화된 명령어는 인스턴스 대시보드의 ‘백업 및 복원’ 탭에서 해당 백업의 상세 보기에서 확인할 수 있습니다.
기본적으로 백업에서 복원하면 복원하는 인스턴스의 버전이 아니라 선호하는 데이터베이스 유형의 버전으로 인스턴스가 프로비저닝됩니다. 다음 예제에서와 같이 매개변수 객체에 버전을 추가하여 버전을 지정할 수 있습니다.
`ibmcloud resource service-instance-create <INSTANCE_NAME> databases-for-mysql standard us-south -p '{"backup_id":"<BACKUP_ID>", "version": "<VERSION>"}'
사용 가능한 버전 목록을 보려면 ibmcloud cdb deployables 실행하세요.
매개변수 async_restore 추가 (새로 추가)- PostgreSQL 단독으로
복원 parameters 블록에 새로운 선택적 매개변수 가 async_restore 추가되었습니다.
async_restore (부울) — 기본값: false. true로 설정하면 복원이 비동기 작업으로 시작되어 전체 복원 시간을 단축하는 데 도움이 됩니다.
`ibmcloud resource service-instance-create <INSTANCE_NAME> databases-for-postgresql standard us-south -p '{"point_in_time_recovery_deployment_id":"<SOURCE_CRN>", "point_in_time_recovery_time":"<PITR_TIME>", version": "<VERSION>", "async_restore": true }'
예:
`ibmcloud resource service-instance-create <INSTANCE_NAME> databases-for-postgresql standard us-south -p '{"point_in_time_recovery_deployment_id":"test_crn", "point_in_time_recovery_time":"2025-12-08T17:08:32Z", version": "17", "async_restore": true }'
비동기 복원은 소스 데이터베이스와 대상 PostgreSQL 데이터베이스가 동일한 주요 버전을 실행 중인 경우에만 요청할 수 있습니다. 다른 주요 버전 간 복원은 지원되지 않습니다. 매개변수가 async_restore 지정되지 않은 경우 서비스는 기본적으로 복원을 동기식으로 수행하며, 이는 현재 동작 방식입니다.
API를 통해 백업 복원
리소스 컨트롤러 API는 데이터베이스 인스턴스 프로비저닝 및 복원을 지원합니다. 생성 요청은 /resource_instances 엔드포인트에 대한 POST.
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":{
"backup_id": "<BACKUP_ID>"
}
}'
매개변수 name, target, resource_group, resource_plan_id는 모두 필수이며 backup_id는 복원할 백업입니다.
name의 값을 새 인스턴스에 부여할 이름으로 변경하십시오.resource_plan_id는 인스턴스의 유형으로, databases-for-postgresql이나 messages-for-rabbitmq 등이 이에 해당합니다.target는 새 인스턴스를 배치할 리전을 의미하며, 이는 소스 인스턴스와 다른 리전일 수 있습니다.eu-de지역으로(부터) 복원하는 경우를 제외하고 교차 지역 복원이 지원됩니다.backup_id는 복원할 백업입니다.
앞서 실행한 명령어는 백업을 원래 배포 환경과 동일한 구성 및 호스팅 모델을 가진 머신에 복원합니다.
선택적 매개변수
API를 통해 선택적 매개변수를 사용할 수 있습니다. 리소스를 사용자 지정하거나, 호스팅 모델을 변경하거나, 특정 버전으로 배포하거나, 새 인스턴스에서 BYOK 암호화를 위해 Key Protect 키를 사용해야 하는 경우 이 기능을 사용하세요.
리소스를 조정해야 하는 경우, 요청 본문에 ' key_protect_key, ' members_disk_allocation_mb' , ' members_host_flavor' , ' members_memory_allocation_mb' , ' members_cpu_allocation_count' , 또는 '
version ' 옵션 파라미터와 원하는 값을 추가하세요. 다음 예를 참조하십시오.
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":{
"backup_id": "<BACKUP_ID>",
"members_host_flavor": "<members_host_flavor_value>",
"version": "<VERSION_NUMBER>"
}
}'
' members_host_flavor ' 값은 "멀티테넌트" 또는 적절한 크기의 격리 컴퓨트 호스트일 수 있습니다( 사용 가능한 값 목록 참조). "멀티테넌트" 호스팅을 사용하는 경우에만 ' members_memory_allocation_mb ' 또는 ' members_cpu_allocation_count '를 지정하세요.
기본적으로 백업에서 복원하면 복원하는 인스턴스의 버전이 아니라 선호하는 데이터베이스 유형의 버전으로 인스턴스가 프로비저닝됩니다. 매개변수 객체에 ' version 값을 추가하여 버전을 지정할 수 있습니다.
async_restore 매개변수 추가 (새 기능)- PostgreSQL 단독
복원 parameters 블록에 새로운 선택적 매개변수 가 async_restore 추가되었습니다.
async_restore (부울) — 기본값: false. true로 설정하면 복원이 비동기 작업으로 시작되어 전체 복원 시간을 단축하는 데 도움이 됩니다.
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":{
"point_in_time_recovery_deployment_id": "<SOURCE_CRN>",
"point_in_time_recovery_time": "<PITR_TIME>",
"version": "<VERSION_NUMBER>",
"async_restore": true
}
}'
비동기 복원은 소스 데이터베이스와 대상 PostgreSQL 데이터베이스가 동일한 주요 버전을 실행 중인 경우에만 요청할 수 있습니다. 다른 주요 버전 간 복원은 지원되지 않습니다. 매개변수가 async_restore 지정되지 않은 경우 서비스는 기본적으로 복원을 동기식으로 수행하며, 이는 현재 동작 방식입니다.
Terraform을 통해 백업 복원하기
Terraform을 사용하여 이전 버전에서 새 버전으로 백업으로 복원할 수 있습니다.
코드는 다음과 같습니다:
resource "ibm_database" "<your-instance>" {
name = "<your_database_name>"
service = "<service>"
plan = "<plan>"
location = "<region>"
version = "<version>"
backup_id = "<backup_id>"
}
자세한 내용은 Cloud Databases Terraform Registry 참조하세요.
테라폼을 통한 빠른 PG 복원(비동기 복원)- PostgreSQL 전용
-
새로운 선택적 매개변수
async_restore가 블록에 추가되었습니다. -
async_restore(부울) — 기본값: false. true로 설정하면 복원이 비동기 작업으로 시작되어 전체 복원 시간을 단축하는 데 도움이 됩니다. -
이 매개 변수는 PostgreSQL 인스턴스를 복원할 때만 적용할 수 있습니다.
코드는 다음과 같습니다:
data "ibm_resource_group" "group" {
name = "<your_group>"
}
resource "ibm_database" "<your-instance>" {
name = "<your_database_name>"
location = "<region>"
plan = "<plan>"
service = "databases-for-postgresql"
resource_group_id = data.ibm_resource_group.group.id
service_endpoints = "private"
async_restore = true
point_in_time_recovery_time = "<PITR_TIME>"
point_in_time_recovery_deployment_id = "<SOURCE_CRN>"
version = "<VERSION_NUMBER>"
}
비동기 복원은 소스 데이터베이스와 대상 PostgreSQL 데이터베이스가 동일한 주요 버전을 실행 중인 경우에만 요청할 수 있습니다. 다른 주요 버전 간 복원은 지원되지 않습니다. 매개변수가 async_restore 지정되지 않은 경우 서비스는 기본적으로 복원을 동기식으로 수행하며, 이는 현재 동작 방식입니다.
백업 및 복원
- Cloud Databases 당사는 해당 백업의 복원, 적시성 또는 유효성에 대해 책임을 지지 않습니다.
- 사용자로서 수행하는 조치가 메모리 및 디스크 할당 부족과 같이 백업의 무결성을 손상시킬 수 있습니다. 사용자는 API를 사용하여 백업이 성공적으로 수행되는지 모니터하고, 백업을 주기적으로 복원하여 유효성과 무결성을 확인할 수 있습니다. 사용자는 Cloud Databases CLI 플러그인 및 Cloud Databases API에서 가장 최근에 예약된 백업 세부 정보를 검색할 수 있습니다.
- 관리 서비스인 Cloud Databases은(는) 백업 상태를 모니터하고 가능한 경우 수정을 시도할 수 있습니다. 복구할 수 없는 문제가 발생하면 지원팀에 문의하여 도움을 받으세요.
백업 위치
데이터베이스 지역마다 백업 위치가 다릅니다. 백업 영역 위치가 데이터 위치 요구사항과 일치하는지 확인하십시오.
| 인스턴스 지역 | 백업 지역 |
|---|---|
| Dallas | 미국 Cross Regional Object Storage |
| 워싱턴 D.C. | 미국 Cross Regional Object Storage |
| 런던 | EU Cross Regional Object Storage |
| 프랑크푸르트 | EU Cross Regional Object Storage |
| 도쿄 | AP Cross Regional Object Storage |
| 오사카 | AP Cross Regional Object Storage |
| 시드니 | AP Cross Regional Object Storage |
| 토론토 | 몬트리올 Object Storage |
| 첸나이 | 첸나이 Object Storage |
| 상파울루 | 상파울루 Object Storage |
| 마드리드 | EU Cross Regional Object Storage |
Cloud Databases Object Storage 위치에 대한 자세한 정보는 위치의 문서를 검토하십시오.
비즈니스 연속성 및 재해 복구
Cloud Databases 데이터를 보호하고 서비스 기능을 복구할 수 있는 메커니즘을 제공합니다. 백업 저장 영역 등 자세한 내용은 Cloud Databases 대한 비즈니스 연속성 및 재해 복구 이해를 참조하세요.
특정 시점 복구
특정 시점 복구(PITR)를 사용하면 인스턴스가 지속적으로 점진적으로 백업하고 트랜잭션을 재생하여 백업에서 지난 7일 중 어느 시점으로든 복원된 새 인스턴스를 가져올 수 있습니다. { Cloud Databases 다음 서비스에 대해 특정 시점 복구(PITR)를 제공합니다:
백업 FAQ
백업에 관해 자주 묻는 질문은 백업 FAQ를 참조하세요.