Recupero point-in-time

IBM Cloud® Databases for PostgreSQL offre il Point-in-time recovery (PITR) per qualsiasi momento degli ultimi 7 giorni. La distribuzione esegue backup incrementali continui e può ripetere le transazioni per portare una nuova distribuzione ripristinata da un backup a qualsiasi punto in quella finestra di 7 giorni di cui hai bisogno.

La scheda Backup e ripristino dell'interfaccia utente dell'installazione client conserva tutte le informazioni PITR sotto la voce Ripristino in tempo reale.

In PostgreSQL versioni 13 e successive, quando si esegue il ripristino in un determinato punto negli ultimi 7 giorni, con un tempo di ripristino dopo l'ultima transazione, il ripristino ha esito negativo con il messaggio recovery ended before configured recovery target is reached. Prima di PostgreSQL v13, quando si esegue il ripristino in un determinato punto negli ultimi 7 giorni, con un tempo di ripristino dopo l'ultima transazione, viene utilizzato il punto di ripristino più recente. Se il ripristino non riesce per questo motivo, Restore to last available point oppure scegliere una data / ora precedente per Restore to a specific point in the last 7 days.

Le informazioni incluse sono la prima ora per un PITR. Per rilevare il primo punto di recupero tramite CLI, utilizzare il comando cdb postgresql earliest-pitr-timestamp.

ibmcloud cdb postgresql earliest-pitr-timestamp <INSTANCE_NAME_OR_CRN>

Per rilevare il primo punto di recupero tramite l'API, utilizzare l'endpoint /deployments/{id}/point_in_time_recovery_data per individuare la prima ora PITR.

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

Ripristino

I backup vengono ripristinati in una nuova distribuzione. Una volta terminata la nuova distribuzione, i dati nel file di backup vengono ripristinati nella nuova distribuzione. I backup sono ripristinabili anche tra gli account, ma solo utilizzando l'API e solo se l'utente che sta eseguendo il ripristino ha accesso sia agli account di origine che a quelli di destinazione.

Per impostazione predefinita, la nuova distribuzione viene ridimensionata automaticamente alla stessa assegnazione di disco e memoria della distribuzione di origine al momento del backup da cui si sta eseguendo il ripristino. Specialmente nel caso di PITR che potrebbe non essere la dimensione corrente della tua distribuzione. Se hai bisogno di modificare le risorse assegnate alla nuova distribuzione, utilizza i campi facoltativi nell'IU, nella CLI o nell'API per ridimensionare la nuova distribuzione. Assicurarsi di assegnare una quantità sufficiente per i dati e il carico di lavoro, se la distribuzione non dispone di risorse sufficienti, il ripristino non riesce.

Mentre l'archiviazione e la memoria vengono ripristinati allo stesso modo della distribuzione di origine, le configurazioni specifiche dell'istanza non vengono impostate automaticamente per l'istanza nuova. In questo caso, potrebbe essere necessario rieseguire la configurazione dopo un ripristino. Prendere nota di tutte le modifiche dell'istanza prima di eseguire il ripristino (parametri come shared_buffers, max_connections, deadlock_timeout, archive_timeout e altri) per garantire un'impostazione accurata per l'istanza dopo il completamento del ripristino.

È importante non eliminare la distribuzione di origine durante il ripristino del backup. È necessario attendere il provisioning della nuova distribuzione e il ripristino del backup prima di eliminare la vecchia distribuzione. L'eliminazione di una distribuzione elimina anche i relativi backup, quindi non solo il ripristino ha esito negativo, ma potrebbe anche non essere possibile ripristinare il backup.

Ripristino nell'interfaccia utente

Per avviare un PITR, immettere l'ora in cui si desidera ripristinare in Coordinated Universal Time. Se si desidera ripristinare l'ora disponibile più recente, selezionare tale opzione. Facendo clic sul pulsante Ripristina, viene visualizzata la nuova interfaccia utente di provisioning in una scheda con le opzioni per il ripristino. Immettere i dettagli del servizio, allocare le risorse e impostare la versione del database, la crittografia e l'endpoint per la nuova distribuzione. Fare clic su Point in time recovery per avviare il processo.

Se si utilizza Key Protect e si dispone di una chiave, è necessario utilizzare la CLI per il ripristino e viene fornito un comando per comodità.

Ripristino nella CLI

Il controller delle risorse supporta il provisioning delle distribuzioni di database e il provisioning e il ripristino sono di competenza della CLI del controller delle risorse. Utilizzare il comando resource service-instance-create.

Per PITR, utilizzare i parametri point_in_time_recovery_time e point_in_time_recovery_deployment_id. point_in_time_recovery_deployment_id è l'ID della distribuzione di origine e point_in_time_recovery_time è la data/ora in Coordinated Universal Time in cui si desidera eseguire il ripristino. Per ripristinare l'ultimo point - in - time disponibile, utilizzare "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":" "}'

Un comando pre - formattato per un backup specifico o PITR è disponibile nella vista dettagliata del backup.

Quando si esegue il ripristino tramite la CLI, sono disponibili parametri facoltativi. Utilizzale per personalizzare le risorse o utilizza una chiave Key Protect per la crittografia BYOK sulla nuova distribuzione.

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

Ripristino nell'API

Il Resource Controller supporta il provisioning delle distribuzioni di database e il provisioning e il ripristino sono di competenza dell'API del Resource Controller. Devi completare i passi necessari per utilizzare l'API del controller di risorse prima di poterla utilizzare per il ripristino da un backup.

Una volta che hai tutte le informazioni, la richiesta di creazione è un POST all'endpoint /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>"
  }'

I parametri name, target, resource_group e resource_plan_id sono tutti obbligatori. Il target è la regione in cui si desidera ubicare la nuova distribuzione, che può essere una regione diversa dalla distribuzione di origine. I ripristini tra regioni sono supportati, ad eccezione del ripristino di un backup eu-de in un'altra regione.

Se devi modificare le risorse o utilizzare una chiave Key Protect, aggiungi i parametri facoltativi key_protect_key, members_disk_allocation_mb, members_memory_allocation_mb e / o members_cpu_allocation_count e i rispettivi valori al corpo della richiesta.

Verifica di PITR

Per verificare il corretto tempo di ripristino, controllare i log del database. Il controllo dei registri del database richiede che l'integrazione Logging sia impostata sulla distribuzione.

Quando si effettua un ripristino, i dati vengono ripristinati dal backup incrementale più recente. Tutte le transazioni in sospeso dal log WAL vengono utilizzate per ripristinare il database fino al momento in cui è stato eseguito il ripristino. Una volta terminato il ripristino e eseguite le transazioni, i log visualizzano un messaggio. È possibile verificare che i log contengano il messaggio con il seguente comando:

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

Esistono due scenari in cui il ripristino non viene visualizzato nei log.

La distribuzione dispone di un backup completo recente e non vi è alcuna attività dopo l'esecuzione del backup che deve essere rieseguita.
Se è stata immessa un'ora per il ripristino dopo l'ora corrente o è stata superata l'ultimo punto di ripristino point - in - time disponibile.

In entrambi i casi, il ripristino è di solito ancora riuscito, ma non ci sarà una voce nei log per controllare l'ora esatta in cui è stato ripristinato il database.