Condividi tramite


Ripristinare un'istanza esclusa di Database di Azure per PostgreSQL - Server flessibile

SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile

Quando un server viene escluso, il backup flessibile del Database di Azure per PostgreSQL viene conservato per cinque giorni nel servizio. Il backup del database è accessibile e può essere ripristinato solo dalla sottoscrizione di Azure in cui risiedeva originariamente il server. È possibile seguire la procedura consigliata di seguito per ripristinare una risorsa del server flessibile del Database di Azure per PostgreSQL esclusa entro cinque giorni dal momento dell'eliminazione del server. I passaggi consigliati funzionano solo se il backup per il server è ancora disponibile e non è stato eliminato dal sistema. Anche se il ripristino di un server eliminato ha spesso esito positivo, questo non è sempre garantito, poiché il ripristino dipende da diversi altri fattori.

Prerequisiti

Per ripristinare un’istanza esclusa del server flessibile del Database di Azure per PostgreSQL, è necessario quanto segue

  • Nome della sottoscrizione di Azure che ospita il server originale
  • Percorso in cui è stato creato il server
  • Usare la versione api-version 2024-08-01

Passaggi per il ripristino

  1. Accedere al portale di Azure. Selezionare il servizio Monitoraggio, quindi selezionare Log attività.

  2. In Log attività selezionare Aggiungi filtro come illustrato e impostare i filtri seguenti per i seguenti

    • Sottoscrizione = Sottoscrizione che ospita il server eliminato

    • Operazione = Elimina server PostgreSQL (Microsoft.DBforPostgreSQL/flexibleservers/delete)

      Screenshot del log attività filtrato per eliminare operazione del server PostgreSQL.

  3. Selezionare l'evento Elimina server PostgreSQL, quindi selezionare la scheda JSON. Copiare gli attributi resourceId e submissionTimestamp nell'output di JSON. L'attributo resourceId ha il formato seguente: /subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/ResourceGroup-name/providers/Microsoft.DBforPostgreSQL/flexibleServers/deletedserver.

  4. Accedere alla pagina Crea API REST del server flessibile del Database di Azure per PostgreSQL e selezionare la scheda Provalo evidenziata in verde. Accedere con l'account Azure.

Importante

Usare questa api-version 2024-08-01 anziché l'impostazione predefinita prima di eseguire per abilitare questa funzione API come previsto, come descritto nel passaggio seguente.

  1. Specificare le proprietà resourceGroupName, serverName (nome server di destinazione), subscriptionId, in base al valore JSON dell'attributo resourceId acquisito nel passaggio 3 precedente. La proprietà api-version è prepopolata e può essere lasciata così.

  2. Andare alla sezione Corpo della richiesta e incollare quanto segue sostituendo "Posi" (ad esempio CentralUS, EastUS e così via), "submissionTimestamp" e "resourceId". Per "pointInTimeUTC", specificare il valore "submissionTimestamp" più 5 minuti per verificare che il comando non dia l'errore.

      {
        "location": "Dropped Server Location",
        "properties":
        {
          "pointInTimeUTC": "submissionTimestamp + 10 minutes",
          "createMode": "ReviveDropped",
          "sourceServerResourceId": "resourceId"
        }
      }
    

    Ad esempio, se il timestamp di invio è 2023-06-15T15:58:02Z, è consigliabile aggiungere almeno 10 minuti per ripristinare il punto nel tempo 2023-06-15T16:05:02Z e assicurarsi di modificare tre parametri (location,pointInTimeUTC,sourceServerResourceId) in base ai requisiti di ripristino.

        {
        "location": "WestUS",
        "properties":
        {
          "pointInTimeUTC": "2023-06-15T16:08:02Z",
          "createMode": "ReviveDropped",
          "sourceServerResourceId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/SourceResourceGroup-Name/providers/Microsoft.DBforPostgreSQL/flexibleServers/SourceServer-Name"
        }
      }
    

    Importante

    È previsto un limite di tempo di cinque giorni dopo l'eliminazione del server. Dopo cinque giorni, è previsto un errore perché non è possibile trovare il file di backup.

  3. Se viene visualizzato il codice di risposta 201 o 202, la richiesta di ripristino è stata inviata correttamente.

    La creazione del server può richiedere tempo a seconda delle dimensioni del database e delle risorse di calcolo di cui è stato effettuato il provisioning nel server originale. Lo stato della creazione del server è possibile monitorarlo dal log attività filtrando per

    • Sottoscrizione = sottoscrizione
    • Tipo di risorsa = Database di Azure per PostgreSQL Server flessibili (Microsoft.DBforPostgreSQL/flexibleServers)
    • Operazione: aggiornare la creazione del server PostgreSQL

Ripristinare un server abilitato per la rete virtuale esclusa

Il ripristino di un server abilitato per la rete virtuale eliminata prevede la specifica di proprietà di rete aggiuntive, ad esempio l'ID risorsa della subnet delegata e l'ID risorsa della zona DNS privato di Azure Resource Manager. Seguire questa procedura per ripristinare il server con le configurazioni di rete necessarie.

{
  "location": "EastUS",
  "properties": {
    "createMode": "ReviveDropped",
    "sourceServerResourceId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/SourceResourceGroup-Name/providers/Microsoft.DBforPostgreSQL/flexibleServers/SourceServer-Name",
    "pointInTimeUTC": "2023-06-20T20:50:59.4078005+00:00",
    "Network": {
      "DelegatedSubnetResourceId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/SourceResourceGroup-Name/providers/Microsoft.Network/virtualNetworks/VirtualNetwork-Name/subnets/Subnet-Name",
      "PrivateDnsZoneArmResourceId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/SourceResourceGroup-Name/providers/Microsoft.Network/privateDnsZones/privatednszonename"
    }
  }
}

Errori comuni

  1. Se si usa la versione dell'API non corretta, è possibile che si verifichino errori di ripristino o timeout. Usare l'API 2024-08-01 per evitare tali problemi.
  2. Per evitare potenziali errori DNS, è consigliabile usare un nome diverso quando si avvia il processo di ripristino, perché alcune operazioni di ripristino potrebbero non riuscire con lo stesso nome.