Restaurando um backup na IU

Para restaurar um backup para uma nova instância de serviço,

1. Clique na linha correspondente para expandir as opções para o backup que deseja restaurar.
2. Clique em Restaurar.
3. Na página Provisioning (Provisionamento ), selecione entre algumas opções disponíveis.
   • A nova instância recebe automaticamente o nome “ <name>-restore-[timestamp] ”, mas você pode renomeá-la.
   • Você também pode selecionar a região onde a nova instância está localizada. As restaurações de região cruzada são suportadas, exceto para restaurar dentro ou fora da região de eu-de.
   • Você pode escolher a alocação inicial de recursos, seja para aumentar ou reduzir os recursos na nova instância. Também é possível ativar ou desativar núcleos dedicados. Observe que, se você diminuir a quantidade de recursos, poderá ocorrer falha no provisionamento ou o banco de dados não funcionará corretamente.
4. Clique em Restore backup (Restaurar backup). Aparece uma mensagem "restauração do backup iniciada". Ao clicar em “Sua nova instância já está disponível”, você será direcionado à sua Lista de Recursos.

Restaurando um backup na CLI

O Controlador de Recursos oferece suporte ao provisionamento de instâncias de banco de dados, sendo que o provisionamento e a restauração são de responsabilidade da CLI do Controlador de Recursos. Use o comando resource service-instance-create.

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-ID> standard <REGION> --service-endpoints <ENDPOINT-TYPE> -p '{"backup_id":"BACKUP_ID"}'

• Altere o valor de “ instance_name ” para o nome que você deseja dar à sua nova instância.
• O service-id é o tipo de instância, como _databases-for-postgresql_ ou _messages-for-rabbitmq_.
• O “ region ” é o local onde você deseja que a nova instância seja criada, que pode ser uma região diferente daquela da instância de origem. As restaurações de região cruzada são suportadas, exceto pela restauração em eu-de e dessa região usando outra região.
• backup_id é o backup que você deseja restaurar.

O comando anterior restaurará um backup em uma máquina com a mesma configuração e no mesmo modelo de hospedagem que a implantação original.

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"}'

`ibmcloud resource service-instance-create <INSTANCE_NAME> databases-for-mysql standard us-south -p '{"backup_id":"<BACKUP_ID>", "version": "<VERSION>"}'

Adicionar async_restore parâmetro (novo)- PostgreSQL apenas

Um novo parâmetro opcional, async_restore foi adicionado ao bloco parameters restore.

async_restore (booleano) — padrão: falso. Quando definido como verdadeiro, a restauração é iniciada como uma operação assíncrona, o que ajuda a reduzir o tempo total de restauração.

`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 }'

Exemplo:

`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 }'

Uma restauração assíncrona só pode ser solicitada quando os bancos de dados de PostgreSQL origem e destino estiverem executando a mesma versão principal. A restauração entre diferentes versões principais não é suportada. Se o async_restore parâmetro não for especificado, o serviço executará a restauração de forma síncrona por padrão, que é o comportamento atual.

Restaurando um backup por meio da API

A API do controlador de recursos oferece suporte ao provisionamento e à restauração de instâncias de banco de dados. A solicitação de criação é um POST para o /resource_instances ponto de extremidade.

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>"
    }
  }'

Os parâmetros name, target, resource_group e resource_plan_id são todos necessários e backup_id é o backup que você deseja restaurar.

• Altere o valor de “ name ” para o nome que você deseja dar à sua nova instância.
• O resource_plan_id é o tipo de instância, como _databases-for-postgresql_ ou _messages-for-rabbitmq_.
• A “ target ” é a região onde você deseja que a nova instância seja localizada, podendo ser uma região diferente daquela da instância de origem. As restaurações de região cruzada são suportadas, exceto para restaurar dentro ou fora da região de eu-de.
• backup_id é o backup que você deseja restaurar.

O comando anterior restaura um backup em uma máquina com a mesma configuração e no mesmo modelo de hospedagem da sua implantação original.

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>"
    }
  }'

Adicionar parâmetro async_restore (novo)- PostgreSQL apenas

Um novo parâmetro opcional, async_restore foi adicionado ao bloco parameters restore.

async_restore (booleano) — padrão: falso. Quando definido como verdadeiro, a restauração é iniciada como uma operação assíncrona, o que ajuda a reduzir o tempo total de restauração.

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
    }
  }'

Uma restauração assíncrona só pode ser solicitada quando os bancos de dados de PostgreSQL origem e destino estiverem executando a mesma versão principal. A restauração entre diferentes versões principais não é suportada. Se o async_restore parâmetro não for especificado, o serviço executará a restauração de forma síncrona por padrão, que é o comportamento atual.

Restauração de um backup por meio do Terraform

Use o Terraform para restaurar um backup de uma versão mais antiga para uma nova versão.

1. Defina seu backup_id. Para obter mais informações, consulte backup_id.
2. Defina seu version no atributo de versão. Para obter mais informações, consulte version.

O código tem a seguinte aparência:

resource "ibm_database" "<your-instance>" {
  name                                 = "<your_database_name>"
  service                              = "<service>"
  plan                                 = "<plan>"
  location                             = "<region>"
  version                              = "<version>"
  backup_id                            = "<backup_id>"
}

Para obter mais informações, consulte o Cloud Databases Registro do Terraform.

Fast PG Restore (async_restore) por meio do Terraform - somente PostgreSQL

1. Um novo parâmetro opcional, async_restore, foi adicionado ao bloco.

2. async_restore (booleano) — padrão: falso. Quando definido como verdadeiro, a restauração é iniciada como uma operação assíncrona, o que ajuda a reduzir o tempo total de restauração.

3. Esse parâmetro só é aplicável ao restaurar uma instância de PostgreSQL.

O código é o seguinte:

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>"
}

Uma restauração assíncrona só pode ser solicitada quando os bancos de dados de PostgreSQL origem e destino estiverem executando a mesma versão principal. A restauração entre diferentes versões principais não é suportada. Se o async_restore parâmetro não for especificado, o serviço executará a restauração de forma síncrona por padrão, que é o comportamento atual.