Recuperação point-in-time

O IBM Cloud® Databases for PostgreSQL oferece Recuperação point-in-time (PITR) para qualquer horário nos últimos sete dias. A implementação executa backups incrementais contínuos e pode reproduzir transações para trazer uma nova implementação restaurada de um backup para qualquer ponto necessário nesse intervalo de sete dias.

A guia Backups e restauração da interface do usuário de sua implantação mantém todas as suas informações de PITR em Recuperação pontual.

No PostgreSQL versões 13 e mais recente, ao restaurar para um ponto específico nos últimos sete dias, com um tempo de restauração após a última transação, sua restauração falha com a mensagem recovery ended before configured recovery target is reached.. Antes do PostgreSQL v13, ao restaurar para um ponto específico nos últimos sete dias, com um tempo de restauração após a última transação, o ponto de restauração mais recente é usado Se a sua restauração falhar por esta razão, então Restore to last available point ou escolha uma data / hora anterior para Restore to a specific point in the last 7 days.

As informações incluídas são o horário mais antigo de um PITR. Para descobrir a ponto de recuperação mais antigo por meio da CLI, use o comando cdb postgresql earliest-pitr-timestamp.

ibmcloud cdb postgresql earliest-pitr-timestamp <INSTANCE_NAME_OR_CRN>

Para descobrir o ponto de recuperação mais antigo por meio da API, use o terminal /deployments/{id}/point_in_time_recovery_data para localizar o horário mais antigo do PITR.

{
    "point_in_time_recovery_data": {
        "earliest_point_in_time_recovery_time": "2019-09-09T23:16:00Z"
    }
}

Recuperação

Os backups são restaurados para uma nova implementação. Após a nova implementação concluir o fornecimento, seus dados no arquivo de backup são restaurados na nova implementação. Os backups também serão restauráveis nas contas, mas apenas usando a API e apenas se o usuário que está executando a restauração tiver acesso às contas de origem e de destino.

Por padrão, o tamanho da nova implementação é automaticamente ajustado de acordo com a alocação de disco e de memória da implementação de origem no horário do backup a partir do qual a restauração está sendo feita. Especialmente no caso do PITR que pode não ser o tamanho atual de sua implementação. Se for necessário ajustar os recursos alocados para a nova implementação, use os campos opcionais na IU, na CLI ou na API para redimensionar a nova implementação. Certifique-se de alocar o suficiente para os seus dados e carga de trabalho; se a implementação não receber recursos suficientes, a restauração falhará.

Embora o armazenamento e a memória sejam restaurados para corresponder à implementação de origem, as configurações específicas da nova instância não são configuradas automaticamente. Nesse caso, pode ser necessária a nova execução da configuração após uma restauração. Observe qualquer modificação de instância antes de executar a restauração (parâmetros como shared_buffers, max_connections, deadlock_timeout, archive_timeout e outros) para assegurar uma configuração precisa para a instância após a restauração ser concluída.

É importante que você não exclua a implementação de origem enquanto o backup está restaurando. Deve-se esperar até que a nova implementação seja provisionada e o backup seja restaurado antes da exclusão da implementação antiga. A exclusão de uma implantação também exclui seus backups, portanto, além de a restauração falhar, talvez você também não consiga recuperar o backup.

Recuperação na UI

Para iniciar um PITR, insira o horário para o qual você deseja restaurar na Hora Universal Coordenada. Se você desejar restaurar para o horário disponível mais recente, selecione essa opção. Clicar no botão Restore (Restaurar ) abre a nova IU de provisionamento em uma guia com as opções para sua recuperação. Insira os detalhes do serviço, aloque recursos e defina a versão do banco de dados, a criptografia e o endpoint para sua nova implementação. Clique em Point in time recovery para iniciar o processo.

Se você usar o Key Protect e tiver uma chave, deverá usar a CLI para fazer a recuperação, e um comando é fornecido para sua conveniência.

Recuperação na CLI

O Controlador de Recursos suporta o fornecimento de implementações de banco de dados e o fornecimento e a restauração são de responsabilidade da CLI do Controlador de Recursos. Use o comando resource service-instance-create.

Para o PITR, use os parâmetros point_in_time_recovery_time e point_in_time_recovery_deployment_id. O point_in_time_recovery_deployment_id é o ID de implementação da origem e point_in_time_recovery_time é o registro de data e hora para o qual você deseja restaurar na Hora Universal Coordenada. Para restaurar para o point-in-time mais recente disponível, use "point_in_time_recovery_time":" ".

ibmcloud resource service-instance-create <databases-for-postgresql> <INSTANCE_NAME> <REGION> -p '{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP", "version":" "}'

Um comando pré-formatado para um backup ou um PITR específico está disponível na visualização detalhada do backup.

Ao restaurar por meio da CLI, parâmetros opcionais estão disponíveis. Use-os para customizar recursos ou use uma chave do Key Protect para a criptografia BYOK na nova implementação.

ibmcloud resource service-instance-create <databases-for-postgresql> <INSTANCE_NAME> standard <REGION> <--service-endpoints SERVICE_ENDPOINTS_TYPE> -p
'{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP","key_protect_key":"KEY_PROTECT_KEY_CRN", "members_disk_allocation_mb":"DESIRED_DISK_IN_MB", "members_memory_allocation_mb":"DESIRED_MEMORY_IN_MB", "members_cpu_allocation_count":"NUMBER_OF_CORES", "version":" "}'

Recuperação na API

O Controlador de Recursos suporta o fornecimento de implementações de banco de dados e o fornecimento e a restauração são de responsabilidade da API do Controlador de Recursos. As etapas necessárias para usar a API do controlador de recursos devem ser concluídas para que seja possível usá-la para a restauração de um backup.

Assim que você tiver todas as informações, a solicitação de criação será um POST no terminal /resource_instances.

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "<INSTANCE_NAME_OR_CRN>",
    "target": "<REGION>",
    "resource_group": "<RESOURCE_GROUP>",
    "resource_plan_id": "<SERVICE_ID>"
    "point_in_time_recovery_time":"<TIMESTAMP>",
    "point_in_time_recovery_deployment_id":"<DEPLOYMENT_ID>"
  }'

Os parâmetros name, target, resource_group e resource_plan_id são todos necessários. O target é a região na qual você deseja que a nova implementação esteja localizada, que pode ser uma região diferente da implementação de origem. A restauração entre regiões é suportada, com exceção da restauração de um backup do eu-de para outra região.

Se for necessário ajustar os recursos ou usar uma chave do Key Protect, inclua os parâmetros opcionais key_protect_key, members_disk_allocation_mb, members_memory_allocation_mb e/ou members_cpu_allocation_count, além de seus valores, no corpo da solicitação.

Verificando o PITR

Para verificar o horário de recuperação correto, verifique os logs do banco de dados. A verificação dos logs do banco de dados requer que a Integração da criação de log seja configurada em sua implementação.

Quando você executa uma recuperação, seus dados são restaurados a partir do backup incremental mais recente. Quaisquer transações pendentes do log WAL são usadas para restaurar seu banco de dados até o momento em que você se recuperou. Depois que a recuperação é concluída e as transações são executadas, os logs exibem uma mensagem. Você pode verificar se os seus registros contêm a mensagem com o seguinte comando:

LOG:  last completed transaction was at log time 2019-09-03 19:40:48.997696+00

Há dois cenários nos quais a recuperação não aparece nos logs.

Sua implementação tem um backup completo recente e não há atividade que precisa ser reproduzida após a realização do backup.
Se você tiver inserido um horário para recuperação posterior ao horário atual ou após o ponto de recuperação point-in-time disponível mais recente.

Em ambos os casos a recuperação geralmente continua bem-sucedida, mas não haverá uma entrada nos logs para verificar o horário exato para o qual o banco de dados foi restaurado.