Creazione automatica dei backup

Quando si configura un'istanza di Gen 2 Cloud Databases, il sistema crea automaticamente istanze di backup indipendenti per i backup giornalieri pianificati. Questi backup:

• Vengono creati quotidianamente in base alla pianificazione dei backup
• Per impostazione predefinita, la durata è di 30 giorni
• Vengono gestiti automaticamente dal servizio
• Verranno visualizzati nell'elenco delle risorse e nell'Hub del database

Creazione di backup su richiesta

È possibile creare backup indipendenti su richiesta in qualsiasi momento utilizzando il Resource Controller di IBM Cloud. Questi backup:

• Vengono creati immediatamente su richiesta
• Seguire le stesse politiche di conservazione previste per i backup automatici
• Può essere eliminato manualmente prima della scadenza
• Sono utili prima di apportare modifiche significative o effettuare migrazioni

Ciclo di vita del backup

I backup indipendenti seguono il seguente ciclo di vita:

1. Provisioning: viene creata un'istanza di backup (automaticamente o su richiesta)
2. Attivo: il backup è disponibile per le operazioni di ripristino
3. Scadenza: il backup raggiunge la fine del periodo di conservazione (30 giorni per impostazione predefinita)
4. Eliminazione: il backup viene eliminato automaticamente o rimosso manualmente

A differenza dei backup accoppiati, i backup indipendenti possono essere eliminati manualmente in qualsiasi momento tramite il Resource Controller, garantendo un maggiore controllo sui dati di backup e sui relativi costi.

Configurazione dell'istanza del database per backup indipendenti

È possibile configurare le seguenti funzionalità sull'istanza del database:

È possibile impostare la configurazione consentita nei parametri di provisioning dell'istanza del database. Ad esempio, la seguente configurazione fa sì che i backup vengano conservati anche dopo l'eliminazione del database:

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

È possibile impostare l’opzione di conservazione nella richiesta di provisioning dell’istanza del database. L'esempio seguente configura l'istanza del database in modo da conservare i backup anche dopo l'eliminazione dell'istanza stessa:

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

Ripristino da un backup indipendente

I backup indipendenti possono essere ripristinati in una nuova istanza di database anche se l'istanza di origine non esiste più, garantendo una maggiore flessibilità negli scenari di ripristino di emergenza e di conservazione dei dati.

I backup vengono ripristinati su una nuova istanza. Una volta completata la configurazione della nuova istanza, i dati contenuti nel file di backup vengono ripristinati nella nuova istanza.

Per impostazione predefinita, la nuova istanza viene dimensionata automaticamente in base alla dimensione predefinita del disco e alla stessa dimensione dell'host dell'istanza di origine al momento del backup da cui si sta eseguendo il ripristino. Per regolare le risorse assegnate alla nuova istanza, utilizzare i campi opzionali nell'interfaccia utente, nella CLI o nell'API per ridimensionare la nuova istanza. Assicurati di assegnare risorse sufficienti per i tuoi dati e il tuo carico di lavoro; se all'istanza non vengono assegnate risorse sufficienti oppure se il backup occupa più spazio rispetto alla dimensione predefinita del disco e non viene specificata una dimensione del disco, il ripristino non andrà a buon fine.

Non eliminare il backup mentre è in corso il ripristino. Prima di eliminare il backup, attendere che la nuova istanza sia stata configurata e che il backup sia stato ripristinato. L'eliminazione dell'istanza del database comporta, per impostazione predefinita, anche l'eliminazione dei relativi backup.

È possibile accedere immediatamente all'istanza del database ripristinata, ma le prestazioni I/O risultano ridotte fino al completamento dell'idratazione. Non è possibile eseguire backup sull'istanza ripristinata finché l'idratazione non è stata completata. È possibile monitorare i progressi nell'idratazione utilizzando gli eventi della piattaforma Activity Tracker. Per ulteriori informazioni, consultare la sezione " 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>"
      }
    }
  }'

Esempio:

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

Crittografia dei backup

I backup indipendenti vengono crittografati in fase di archiviazione utilizzando lo stesso algoritmo di crittografia dell'istanza del database. Se utilizzi Key Protect per gestire la crittografia del database, i backup vengono crittografati con la stessa chiave. Per ulteriori informazioni, consultare la sezione " Integrazione con Key Protect ".

Quando si ripristina un backup crittografato con una chiave " Key Protect ", è possibile utilizzare la stessa chiave oppure una chiave diversa. Se si utilizza una chiave diversa, la nuova istanza viene crittografata con la nuova chiave.

Ripristino tra account

I backup indipendenti possono essere ripristinati su diversi account IBM Cloud, consentendo scenari quali:

• Ripristino dei dati di produzione su un account di sviluppo a scopo di test
• Migrazione dei database tra unità organizzative
• Ripristino di emergenza su un account separato

Per ripristinare un backup su un altro account:

1. L'account di origine deve concedere all'account di destinazione l'accesso alla risorsa di backup
2. Utilizzare il CRN di backup durante la creazione della nuova istanza nell'account di destinazione
3. Assicurarsi che l'account di destinazione disponga delle autorizzazioni IAM appropriate

Per ulteriori informazioni sul ripristino tra account, consultare la sezione " Ripristino tra account ".

Banche dati dotate di backup indipendenti

I backup indipendenti saranno abilitati per i database e le regioni interessati con un approccio graduale.

Durante il periodo di transizione di 30 giorni:

• I backup accoppiati e quelli indipendenti coesistono.
• Tutti i nuovi backup vengono creati come backup indipendenti.
• I backup associati esistenti continuano a funzionare e vengono eliminati automaticamente dopo 30 giorni.
• L'interfaccia utente mostra entrambi i tipi di backup.
• Non è richiesta alcuna azione. La transizione avviene in modo automatico.
• Al termine del periodo di transizione di 30 giorni, rimarranno solo i backup indipendenti.

MySQL

Databases for MySQL Supporta solo backup indipendenti a partire dalla disponibilità generale. Non sono previsti backup accoppiati né periodi di transizione per le implementazioni di “ MySQL ”.