Recupero point-in-time (PITR)

IBM Cloud® Databases for MongoDB Enterprise Edition offre PITR utilizzando qualsiasi data / ora successiva al primo punto di recupero disponibile. Per rilevare il primo punto di recupero tramite l'API, utilizza l'endpoint di data / ora di recupero point - in - time.

Quando si esegue il ripristino in un punto specifico 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. Se il ripristino non riesce per questo motivo, ripristinare l'ultimo punto disponibile o scegliere una data e un'ora precedenti per il ripristino in un punto specifico negli ultimi 7 giorni.

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

In questa fase, l'endpoint del timestamp di ripristino point-in-time restituisce sempre l'ora corrente, ovvero circa una settimana.

Istantanee

Enterprise EditionMongoDB offre PITR tramite snapshot gestiti dal Ops Manager.

Esistono considerazioni specifiche relative al PITR nei casi in cui il PITR non è supportato.

PITR dopo l'aggiornamento della versione

Dopo un aggiornamento di versione, il ripristino a un punto nel tempo (PITR) per la nuova versione non è disponibile finché non viene completata una snapshot iniziale della distribuzione aggiornata e non ne viene eseguito il backup tramite Ops Manager. Il ripristino a un punto nel tempo consente di ripristinare i dati a un momento successivo a un aggiornamento di versione principale solo dopo il completamento di questa istantanea iniziale. Questa istantanea non è presente nell'elenco dei backup disponibili. Il ripristino alla versione precedente (entro 7 giorni dall'aggiornamento) è supportato solo se tale versione è ancora supportata.

PITR non è temporaneamente disponibile per una determinata versione finché non viene completata una snapshot di quella versione e non ne viene eseguito correttamente il backup.

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.

La nuova distribuzione viene automaticamente ridimensionata allo stesso disco e alla stessa allocazione di memoria della distribuzione di origine al momento del backup da cui si esegue il ripristino. Specialmente con PITR, potrebbe non essere la dimensione corrente della 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. Se la distribuzione non dispone di risorse sufficienti, il ripristino ha esito negativo, quindi allocare risorse sufficienti per i dati e il carico di lavoro.

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 eventuali modifiche dell'istanza prima di eseguire il ripristino (parametri come shared_buffers, max_connections, deadlock_timeout, archive_timeout) per garantire impostazioni accurate per l'istanza una volta completato il ripristino.

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 non riesce, ma potrebbe non essere possibile ripristinare il backup.

Ripristino tramite l'interfaccia utente

Una volta completato il primo backup della tua distribuzione, l'opzione di ripristino point - in - time verrà visualizzata nell'IU. Per avviare un PITR, immettere l'ora in cui si desidera ripristinare in Coordinated Universal Time.

La data / ora di ripristino point - in - time deve essere formattata come segue: %Y-%m-%dT%H:%M:%SZ.

Per ripristinare l'ora disponibile più recente, selezionare tale opzione. Facendo clic su Ripristina vengono visualizzate le opzioni per il ripristino. Immettere un nome, selezionare la versione, la regione e le risorse assegnate per la nuova distribuzione. Fai clic su " Recupera " per avviare la procedura.

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 con la CLI

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

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

I parametri disponibili sono:

  • instance_name (Richiesto): Il nome leggibile dell'istanza da distribuire, ad esempio new-mongo.
  • service_id (Richiesto): In questo contesto è databases-for-mongodb.
  • service_plan_name (Richiesto): standard o enterprise.
  • region (Richiesto): La regione IBM Cloud® in cui verrà distribuito il nuovo database, ad esempio eu-gb.
  • point_in_time_recovery_deployment_id (Richiesto): L'ID dell'installazione client di origine (noto anche come CRN).
  • point_in_time_recovery_time: il momento in cui viene ripristinato il backup, nel formato %Y-%m-%dT%H:%M:%SZ, Per esempio,2024-05-10T08:15:00Z. Lascia vuoto questo campo per ottenere l'ultimo punto ripristinabile.
  • version: la versione del database, ad esempio "6.0 ". Lascia vuoto questo campo per utilizzare la versione più recente e preferita.
  • key_protect_key: ID (CRN) del Key Protect risorsa utilizzata. Questo campo è facoltativo per la crittografia BYOK (Bring Your Own Key).
  • members_host_flavor: la dimensione dell'host dell'istanza che desideri distribuire. Se non fornita, la nuova istanza verrà creata con la stessa RAM e CPU dell'istanza di origine. Vedere questa tabella per i valori disponibili.

Esempio

ibmcloud resource service-instance-create big-mongo-restore databases-for-mongodb enterprise eu-gb -p '{"point_in_time_recovery_deployment_id":"crn:v1:bluemix:public:databases-for-mongodb:eu-gb:a/f19c0f5eff94b69ae419xyz2345ra7a0ed:3c647ad1-b9a8-2233-a47e-668d8b83e79f::", "members_host_flavor":"b3c.4x16.encrypted", "point_in_time_recovery_time":"", "version":""}'

Recupero con l'API

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

Dopo aver ottenuto 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": "<SERVICE_INSTANCE_NAME>",
    "target": "<REGION>",
    "resource_group": "<YOUR-RESOURCE-GROUP>",
    "resource_plan_id": "<SERVICE-ID>",
    "parameters": {
      "point_in_time_recovery_time":"<TIMESTAMP>",
      "point_in_time_recovery_deployment_id":"<DEPLOYMENT_ID>"
    }
  }'

I seguenti campi sono tutti obbligatori:

  • name: il nome leggibile della nuova istanza da distribuire, ad es new-mongo.
  • resource_group: l'ID del gruppo di risorse, ad es 5c49eabc12fgt65
  • resource_plan_id: In questo contesto questo è databases-for-mongodb-enterprise
  • target: IL IBM Cloud regione in cui verrà distribuito il nuovo database, ad es eu-gb. Sono supportati i ripristini tra regioni, ad eccezione del ripristino di a eu-de backup in un'altra regione.

Inoltre, a parameters l'oggetto può essere fornito con i seguenti campi:

  • point_in_time_recovery_deployment_id: ID della distribuzione di origine (noto anche come CRN).
  • point_in_time_recovery_time: il momento in cui viene ripristinato il backup, nel formato %Y-%m-%dT%H:%M:%SZ, Per esempio,2024-05-10T08:15:00Z. Lascia vuoto questo campo per ottenere l'ultimo punto ripristinabile.
  • version: la versione del database, ad esempio "6.0 ". Lascia vuoto questo campo per utilizzare la versione più recente e preferita.
  • key_protect_key: ID (CRN) del Key Protect risorsa utilizzata. Questo campo è facoltativo per la crittografia BYOK (Bring Your Own Key).
  • members_host_flavor: la dimensione dell'host dell'istanza che desideri distribuire. Se non fornita, la nuova istanza verrà creata con la stessa RAM e CPU dell'istanza di origine. Vedi il tavolo per i valori disponibili.

La data / ora di ripristino point - in - time deve essere formattata come segue: %Y-%m-%dT%H:%M:%SZ.

Ripristino di un backup con Terraform

Prima del ripristino, assicurati che il tuo point_in_time_recovery_time non sia più vecchio di una settimana. Se il timestamp è più vecchio di 7 giorni, al secondo, la convalida fallisce.

Utilizzare l'origine dati ibm_database_point_in_time_recovery per ripristinare l'istanza del database con point_in_time_recovery.

La data / ora di ripristino point - in - time deve essere formattata come segue: %Y-%m-%dT%H:%M:%SZ.

Il tuo script Terraform è simile a questo.

terraform {
  required_providers {
     ibm = {
       version = "1.44.3"
       source  = "IBM-Cloud/ibm"
    }
  }
}
variable "ibmcloud_api_key" {
  description = "<Enter your IBM Cloud API Key>"
}
provider "ibm" {
  region = "us-south"
  ibmcloud_api_key = var.ibmcloud_api_key
}
data "ibm_resource_group" "default_group" {
  is_default = true
}
resource "ibm_database" "mongodb_enterprise" {
  resource_group_id = data.ibm_resource_group.default_group.id
  name              = "testing-mongodb-pitr"
  service           = "databases-for-mongodb"
  plan              = "enterprise"
  location          = "us-south"
  point_in_time_recovery_deployment_id = "<crn>"
  point_in_time_recovery_time = "2022-09-14T14:47:45Z"
}

Quanto sopra ripristinerà un nuovo database con le stesse dimensioni dell'host e del disco dell'origine. Se desideri modificare la dimensione dell'host o la dimensione del disco della tua distribuzione, fai riferimento a Documentazione di Terraform per la corretta formattazione.

Ripristino offline point-in-time recovery (PITR)

IBM Cloud® Databases for MongoDB Enterprise Edition richiede due processi per avviare un ripristino. Innanzitutto, viene eseguita un'istantanea di Ops Manager AppDB. Questa istantanea viene quindi utilizzata come backup PITR, che può essere utilizzato per ripristinare il database.

In qualche ripristino di emergenzaLa capacità di un servizio o di un carico di lavoro di riprendersi da incidenti rari e gravi e da guasti su larga scala, come l'interruzione del servizio. Ciò include un disastro fisico che colpisce un'intera regione, il danneggiamento di un database o la perdita di un servizio che contribuisce a un carico di lavoro. L'impatto supera la capacità del progetto di alta disponibilità di gestirlo. scenari, il processo PITR potrebbe non riuscire. In tali casi Databases for MongoDB Enterprise Edition Il ripristino offline Point-in-time Recovery (PITR) può essere utilizzato per ripristinare l'ultima snapshot disponibile. L'opzione Ripristino offline garantisce la disponibilità dei dati e la flessibilità del sistema in un caso in cui il metodo dell'istantanea non funziona come previsto.

Ripristino offline point-in-time recovery (PITR) attraverso l'interfaccia utente

Avvia un ripristino offline tramite il dashboard IBM Cloud come per un PITR standard. Scegliere la terza opzione di ripristino point - in - time.

Ripristino offline point-in-time recovery (PITR) tramite CLI

Avvia un ripristino offline tramite la CLI IBM Cloud utilizzando un comando come:

ibmcloud resource service-instance-create big-mongo-restore databases-for-mongodb enterprise eu-gb -p '{"point_in_time_recovery_deployment_id":"crn:v1:bluemix:public:databases-for-mongodb:eu-gb:a/f19c0f5eff94b69ae419xyz2345ra7a0ed:3c647ad1-b9a8-2233-a47e-668d8b83e79f::", "members_host_flavor":"b3c.4x16.encrypted", "point_in_time_recovery_time":"", "version":"", "offline_restore": true}'

Specificare i parametri seguenti:

  • point_in_time_recovery_deployment_id- Questo è il CRN di origine.
  • point_in_time_recovery_time- Lascia questo campo vuoto, "".
  • offline_restore- Impostare questo valore su true.

L'output del comando è il seguente:

Creating service instance <INSTANCE_NAME> in resource group Default of account <ACCOUNT> as <USER>...
OK
Service instance <INSTANCE_NAME> was created.
Name:                <INSTANCE_NAME>
ID:                  crn:v1:bluemix:public:databases-for-mongodb:eu-gb:a/f19c0f5eff94b69ae419xyz2345ra7a0ed:3c647ad1-b9a8-2233-a47e-668d8b83e79f::
GUID:                3c647ad1-b9a8-2233-a47e-668d8b83e79f
Location:            <LOCATION>
State:               provisioning
Type:                service_instance
Sub Type:            Public
Service Endpoints:   public
Allow Cleanup:       false
Locked:              false
Created at:          2023-08-03T09:36:37Z
Updated at:          2023-08-03T09:36:41Z
Last Operation:
                     Status    create in progress
                     Message   Started create instance operation

La data / ora di ripristino point - in - time deve essere formattata come segue: %Y-%m-%dT%H:%M:%SZ.

Ripristino offline point-in-time recovery (PITR) tramite API

Il controller di risorse supporta il provisioning delle distribuzioni del database e il provisioning e il ripristino sono responsabilità dell'API del controller di risorse. Completare la procedura necessaria per utilizzare l'API del controller delle risorse prima di utilizzarla per eseguire il ripristino da un backup.

Dopo aver ottenuto tutte le informazioni, la richiesta di creazione è una POST per /resource_instances che avrà il seguente aspetto:

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "<SERVICE_INSTANCE_NAME>",
    "target": "<REGION>",
    "resource_group": "<YOUR-RESOURCE-GROUP-ID>",
    "resource_plan_id": "<SERVICE-ID>",
    "parameters": {
      "point_in_time_recovery_time":"<TIMESTAMP>",
      "point_in_time_recovery_deployment_id":"<DEPLOYMENT_ID>",
      "offline_restore": true
    }
  }'

Specificare i parametri seguenti:

  • point_in_time_recovery_deployment_id- Questo è il CRN di origine.
  • point_in_time_recovery_time- Lascia questo campo vuoto, "".
  • offline_restore- Impostare questo valore su true.

La data / ora di ripristino point - in - time deve essere formattata come segue: %Y-%m-%dT%H:%M:%SZ.