IBM Cloud Docs
Gerenciamento de backups Cloud Databases

Gerenciamento de backups Cloud Databases

Todos os dias é feito um backup programado automaticamente do seu banco de dados. Você também pode acionar backups sob demanda a qualquer momento. Os backups são criptografados com uma chave automática ou com sua própria chave, se você usar o Bring Your Own Key (BYOK). Você pode restaurar um backup em uma nova instância de Cloud Databases.

Para acessar os backups de Cloud Databases, acesse o Painel da instância do banco de dados e veja a guia Backups e restauração.

Aqui estão algumas informações gerais adicionais sobre backups:

  • Os backups automáticos são realizados diariamente e mantidos com um cronograma de retenção simples de 30 dias.
  • Os backups não podem ser excluídos.
  • Se você excluir sua instância, seus backups serão excluídos automaticamente.
  • O agendamento diário de backup não é configurável.
  • Os backups podem ser restaurados em outras regiões, exceto em eu-de, eu-es e par-01, que podem restaurar backups somente entre si. Por exemplo, os backups par-01 podem ser restaurados para e entre eu-de e eu-es.
  • O armazenamento de backup é criptografado. Para gerenciar as chaves de criptografia, consulte IntegraçãoKey Protect. Caso contrário, os backups são criptografados com uma chave gerada automaticamente para sua instância.
  • Os backups podem ser restaurados entre contas, mas somente por meio da API e somente se o usuário que estiver executando a restauração tiver acesso às contas de origem e de destino.
  • Cloud Databases os backups não podem ser baixados. Se você precisar de um backup local, use o software apropriado. Por exemplo, o pg_dump é uma ferramenta eficaz para gerenciar os backups do site PostgreSQL. E para MySQL, você pode usar o mysqldump.

Para obter informações sobre como fazer um backup sob demanda, consulte Como fazer um backup sob demanda.

Backups na IU

Na interface do usuário, navegue até a guia Backups e restauração, onde você verá uma tabela com todos os backups disponíveis para o seu banco de dados.

Os tipos de backup podem ser On-demand ou Automatic. Cada backup é listado com seu tipo e data de criação.

Clique no backup para revelar informações para aquele backup específico, incluindo seu ID completo. Há um botão Restore (Restaurar ) ou um comando CLI pré-formatado para as opções de restauração.

Backups na CLI

Você pode acessar a lista de backups e as informações individuais de backup no plug-in Cloud Databases CLI e na API Cloud Databases.

Use o comando cdb deployment-backups-list para exibir a lista de todos os backups disponíveis para sua instância. Para obter detalhes sobre um backup específico, use o comando cdb backup-show.

Por exemplo, para visualizar os backups de uma instância chamada "example-instance", use o seguinte comando:

ibmcloud cdb deployment-backups-list <INSTANCE_NAME_OR_CRN>

Para ver os detalhes de um dos backups da lista, pegue o ID do campo ID da resposta deployment-backups-list e use-o com o comando 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

Backups na API Cloud Databases

Para obter informações sobre backups na API Cloud Databases, use o ponto de extremidade /deployments/{id}/backups para listar os backups da instância. Para obter informações sobre um backup específico, use o ponto de extremidade /backups/{backup_id}.

Fazer um backup sob demanda na interface do usuário

Se você planeja fazer grandes alterações na sua instância, como dimensionar ou remover bancos de dados, tabelas e coleções, os backups sob demanda são úteis. Eles também poderão ser úteis se for necessário fazer backup de acordo com um planejamento. Os backups sob demanda são mantidos por 30 dias.

As instâncias vêm com armazenamento de backup igual ao espaço total em disco, sem custo. Se o uso do armazenamento de backup for maior do que o espaço total em disco, cada gigabyte será cobrado com um excedente de $0.03/month. Os backups são compactados, portanto, mesmo se você usar backups sob demanda, a maioria das instâncias não excederá o crédito alocado.

Para criar um backup manual na interface do usuário, vá para a guia Backups e restauração da sua instância e clique em Criar backup. Uma mensagem é exibida informando que um backup está em andamento e um backup sob demanda é incluído na lista de backups disponíveis.

Fazer um backup sob demanda na CLI

Se você planeja fazer grandes alterações na sua instância, como dimensionar ou remover bancos de dados, tabelas e coleções, os backups sob demanda são úteis. Eles também poderão ser úteis se for necessário fazer backup de acordo com um planejamento. Os backups sob demanda são mantidos por 30 dias.

As instâncias vêm com armazenamento de backup igual ao espaço total em disco, sem custo. Se o uso do armazenamento de backup for maior do que o espaço total em disco, cada gigabyte será cobrado com um excedente de $0.03/month. Os backups são compactados, portanto, mesmo se você usar backups sob demanda, a maioria das instâncias não excederá o crédito alocado.

Na CLI, um backup sob demanda é acionado com o comando cdb deployment-backup-now.

ibmcloud cdb deployment-backup-now <INSTANCE_NAME_OR_CRN>

Fazer um backup sob demanda na API

Se você planeja fazer grandes alterações na sua instância, como dimensionar ou remover bancos de dados, tabelas e coleções, os backups sob demanda são úteis. Eles também poderão ser úteis se for necessário fazer backup de acordo com um planejamento. Os backups sob demanda são mantidos por 30 dias.

As instâncias vêm com armazenamento de backup igual ao espaço total em disco, sem custo. Se o uso do armazenamento de backup for maior do que o espaço total em disco, cada gigabyte será cobrado com um excedente de $0.03/month. Os backups são compactados, portanto, mesmo se você usar backups sob demanda, a maioria das instâncias não excederá o crédito alocado.

Na API, o envio de um POST para o terminal /deployments/{id}/backups aciona um backup sob demanda.

Restaurando um backup

Os backups são restaurados em uma nova instância. Após a conclusão do provisionamento da nova instância, seus dados no arquivo de backup serão restaurados na nova instância.

Por padrão, a nova instância é dimensionada automaticamente para a mesma alocação de disco e memória que a instância de origem no momento do backup do qual você está restaurando. Para ajustar os recursos alocados para a nova instância, use os campos opcionais na interface do usuário, na CLI ou na API para redimensionar a nova instância. Certifique-se de alocar o suficiente para seus dados e carga de trabalho; se a instância não receber recursos suficientes, a restauração falhará.

Não exclua a instância de origem enquanto o backup estiver sendo restaurado. Antes de excluir a instância antiga, aguarde até que a nova instância seja provisionada e o backup seja restaurado. A exclusão de uma instância também exclui seus backups.

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 é automaticamente denominada <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 expandir 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". Clicar em Your new instance is available now (Sua nova instância está disponível agora ) o levará à sua Lista de recursos.

Restaurando um backup na CLI

O Controlador de recursos oferece suporte ao provisionamento de instâncias de banco de dados, e 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 para sua nova instância.
  • O endereço service-id é o tipo de instância, como databases-for-postgresql ou messages-for-rabbitmq.
  • O endereço region é onde você deseja que a nova instância seja localizada, que pode ser uma região diferente 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.

Parâmetros opcionais

Há parâmetros opcionais disponibilizados por meio da CLI. Use-os se precisar personalizar recursos, alterar o modelo de hospedagem ou usar uma chave Key Protect para criptografia BYOK na nova instância. Consulte o seguinte exemplo:

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

O valor " members_host_flavor pode ser "multitenant" ou um host Isolated Compute de tamanho adequado (consulte a lista de valores disponíveis). Especifique " members_memory_allocation_mb ou " members_cpu_allocation_count somente se você usar hospedagem "multitenant".

Um comando pré-formatado para um backup específico está disponível na exibição detalhada do backup na guia Backups e restauração do painel de controle da sua instância.

Por padrão, a restauração de um backup provisiona uma instância com a versão preferencial do tipo de banco de dados, e não a versão da instância da qual você restaurou. Você pode especificar uma versão adicionando a versão no objeto de parâmetros, como no exemplo a seguir.

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

Para ver uma lista das versões disponíveis, execute ibmcloud cdb deployables.

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: false. 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 para sua nova instância.
  • O endereço resource_plan_id é o tipo de instância, como databases-for-postgresql ou messages-for-rabbitmq.
  • O target é a região onde você deseja que a nova instância seja localizada, que pode ser uma região diferente 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 acima restaurará um backup em uma máquina com a mesma configuração e no mesmo modelo de hospedagem que a implantação original.

Parâmetros opcionais

Os parâmetros opcionais estão disponíveis por meio da API. Use-as se precisar personalizar recursos, alterar o modelo de hospedagem, implementar uma versão específica ou usar uma chave Key Protect para criptografia BYOK na nova instância.

Se você precisar ajustar os recursos, adicione qualquer um dos parâmetros opcionais ' key_protect_key, ' members_disk_allocation_mb, ' members_host_flavor, ' members_memory_allocation_mb, ' members_cpu_allocation_count ou ' version e seus valores preferenciais ao corpo da solicitação. Consulte o seguinte exemplo:

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

O valor " members_host_flavor pode ser "multitenant" ou um host Isolated Compute de tamanho adequado (consulte a lista de valores disponíveis). Especifique " members_memory_allocation_mb ou " members_cpu_allocation_count somente se você usar hospedagem "multitenant".

Por padrão, a restauração de um backup provisiona uma instância com a versão preferencial do tipo de banco de dados, e não a versão da instância da qual você restaurou. Você pode especificar uma versão adicionando um valor ' version no objeto de parâmetros.

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: false. 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: false. 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 é parecido com 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.

Backups e restauração

  • Cloud Databases não são responsáveis pela restauração, pontualidade ou validade dos referidos backups.
  • Ações que você toma como usuário podem comprometer a integridade dos backups, como, por exemplo, a subalocação de memória e disco. Os usuários podem utilizar a API para monitorar se os backups foram bem-sucedidos, além de, periodicamente, poderem restaurar um backup para assegurar sua validade e integridade. Os usuários podem recuperar os detalhes do backup programado mais recente no plug-in CLI Cloud Databases CLI plug-in e da Cloud Databases API.
  • Como um serviço gerenciado, o Cloud Databases monitora o estado dos backups e, quando possível, pode tentar fazer correções. Se encontrar problemas dos quais não consegue se recuperar, entre em contato com o suporte para obter mais ajuda.

Locais de Backup

O local do backup varia de acordo com a região do banco de dados. Certifique-se de que o local da região de backup corresponda aos requisitos de local dos dados.

Instância e regiões de backup
Região da instância Região do backup
Dallas Object Storage regional dos EUA
Washington D.C. Object Storage regional dos EUA
Londres Object Storage regional da UE
Frankfurt Object Storage regional da UE
Tóquio Object Storage regional da AP
Osaka Object Storage regional da AP
Sidney Object Storage regional da AP
Toronto Object Storage de Montreal
Chennai Object Storage de Chennai
São Paulo Object Storage de São Paulo
Madri Object Storage regional da UE

Para obter mais detalhes sobre os locais do Object Storage do Cloud Databases, revise a documentação do local.

Continuidade de negócios e recuperação de desastre

Cloud Databases fornece mecanismos para proteger seus dados e restaurar as funções do serviço. Para obter mais informações (incluindo regiões de armazenamento de backup), consulte Entendendo a continuidade dos negócios e a recuperação de desastres para Cloud Databases.

Recuperação point-in-time

Com o Point-in-Time Recovery (PITR), a instância faz backups contínuos de forma incremental e pode reproduzir transações para trazer uma nova instância restaurada de um backup para qualquer ponto nos últimos 7 dias. Cloud Databases oferece o Point-In-Time Recovery (PITR) para os seguintes serviços:

Perguntas frequentes sobre backups

Para obter perguntas frequentes sobre backups, consulte as Perguntas frequentes sobre backups.