Criação automática de backup

Ao provisionar uma instância do Cloud Databases de 2ª geração, o sistema cria automaticamente instâncias de backup independentes para seus backups diários programados. Esses backups:

• São criados diariamente de acordo com sua programação de backup
• Por padrão, permanece ativo por 30 dias
• São gerenciados automaticamente pelo serviço
• Aparecer na sua Lista de Recursos e no Hub de Bancos de Dados

Criação de backup sob demanda

Você pode criar backups independentes sob demanda a qualquer momento usando o Controlador de Recursos do IBM Cloud. Esses backups:

• São criados imediatamente após a solicitação
• Siga as mesmas políticas de retenção aplicadas aos backups automáticos
• Pode ser excluído manualmente antes do vencimento
• São úteis antes de grandes mudanças ou migrações

Ciclo de vida do backup

Os backups independentes seguem este ciclo de vida:

1. Provisionamento: a instância de backup é criada (automaticamente ou sob demanda)
2. Ativo: O backup está disponível para operações de restauração
3. Vencimento: O backup chega ao fim do período de retenção (padrão de 30 dias)
4. Exclusão: o backup é excluído automaticamente ou removido manualmente

Ao contrário dos backups acoplados, os backups independentes podem ser excluídos manualmente a qualquer momento por meio do Controlador de Recursos, proporcionando a você maior controle sobre seus dados de backup e os custos associados.

Configurando a instância do banco de dados para backups independentes

É possível configurar os seguintes recursos na instância do banco de dados:

É possível definir a configuração permitida nos parâmetros de provisionamento da instância do banco de dados. Por exemplo, a configuração a seguir faz com que os backups sejam mantidos mesmo após a exclusão do banco de dados:

ibmcloud resource service-instance-create \
  <DATABASE_INSTANCE_NAME> \
  <DATABASE_SERVICE_NAME> \
  <DATABASE_SERVICE_PLAN_NAME> \
  <REGION> \
  -g <RESOURCE_GROUP> \
  -p '{
    "dataservices": {
      "backups": {"preserve": true}
    }
  }'

É possível definir a opção de preservação na solicitação de provisionamento da instância do banco de dados. O exemplo a seguir configura a instância do banco de dados para preservar os backups após a exclusão da instância:

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "<DATABASE_INSTANCE_NAME>",
    "target": "<REGION>",
    "resource_group": "<RESOURCE-GROUP>",
    "resource_plan_id": "<DATABASE_SERVICE_PLAN_NAME>",
    "parameters": {
      "dataservices": {
        "backups": {
          "preserve": true
        }
      }
    }
  }'

Restauração a partir de um backup independente

Backups independentes podem ser restaurados em uma nova instância de banco de dados, mesmo que a instância de origem já não exista, proporcionando maior flexibilidade para cenários de recuperação de desastres e retenção de dados.

Os backups são restaurados em uma nova instância. Assim que o provisionamento da nova instância for concluído, seus dados contidos no arquivo de backup serão restaurados na nova instância.

Por padrão, a nova instância é dimensionada automaticamente para o tamanho padrão do disco e o mesmo tamanho de host da instância de origem no momento do backup a partir do qual você está restaurando. Para ajustar os recursos alocados à 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 recursos suficientes para seus dados e carga de trabalho; se a instância não receber recursos suficientes ou se o backup contiver mais espaço de armazenamento do que o tamanho padrão do disco e esse tamanho não for especificado, a restauração falhará.

Não exclua o backup enquanto ele estiver sendo restaurado. Antes de excluir o backup, aguarde até que a nova instância seja provisionada e o backup seja restaurado. A exclusão da instância do banco de dados também exclui seus backups por padrão.

Você tem acesso imediato à instância do banco de dados restaurada, mas o desempenho de E/S fica reduzido até que a hidratação seja concluída. Não é possível criar backups na instância restaurada até que a hidratação esteja concluída. Você pode acompanhar o progresso da hidratação utilizando os eventos da plataforma Activity Tracker. Para mais informações, consulte o site at-events.

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

Exemplo:

  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "mysql-restore-abc",
    "target": "us-east",
    "resource_group": "b67d9228670d473097259e2b343de464",
    "resource_plan_id": "databases-for-mysql-gen2-standard",
    "parameters": {
      "dataservices": {
        "restore_backup_id": "crn:v1:bluemix:public:databases-independent-backups:us-east:a/26b19aex04da4475b6e31205fa93248d:793b4f27-7733-4803-917f-de8e055e2deb::"
      }
    }
  }'

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 mysql-restore-abc databases-for-mysql databases-for-mysql-gen2-standard us-east -p  '{"dataservices":{"restore_backup_id":"crn:v1:bluemix:public:databases-independent-backups:us-east:a/26b19aex04da4475b6e31205fa93248d:793b4f27-7733-4803-917f-de8e055e2deb::"}}'

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

Criptografia de backup

Os backups independentes são criptografados em repouso com a mesma criptografia da instância do banco de dados. Se você usar o recurso “ Key Protect ” para gerenciar a criptografia do banco de dados, seus backups serão criptografados com a mesma chave. Para obter mais informações, acesse Key Protect integração.

Ao restaurar um backup que foi criptografado com uma chave “ Key Protect ”, você pode usar a mesma chave ou uma chave diferente. Se você usar uma chave diferente, a nova instância será criptografada com a nova chave.

Restauração entre contas

Backups independentes podem ser restaurados em todas as contas d IBM Cloud, possibilitando cenários como:

• Restaurar dados de produção em uma conta de desenvolvimento para fins de teste
• Migração de bancos de dados entre unidades organizacionais
• Recuperação de desastres em uma conta separada

Para restaurar um backup em uma conta diferente:

1. A conta de origem deve conceder à conta de destino acesso ao recurso de backup
2. Utilize o CRN do backup ao criar a nova instância na conta de destino
3. Certifique-se de que a conta de destino tenha as permissões de IAM adequadas

Para obter mais informações sobre a restauração entre contas, consulte Restauração entre contas.

Bancos de dados com backups independentes habilitados

Os backups independentes serão ativados para os bancos de dados e regiões aplicáveis, de forma gradual.

Durante o período de transição de 30 dias:

• Os backups acoplados e os backups independentes coexistem.
• Todos os novos backups são criados como backups independentes.
• Os backups associados existentes continuam funcionando e são excluídos automaticamente após 30 dias.
• A interface do usuário exibe os dois tipos de backup.
• Nenhuma ação é necessária. A transição é feita automaticamente.
• Após o período de transição de 30 dias, restam apenas os backups independentes.

MySQL

Databases for MySQL suporta apenas backups independentes a partir da disponibilidade geral. Não há backups acoplados nem período de transição para implantações do tipo “ MySQL ”.