Delen via


Een verwijderde Azure Database for PostgreSQL - Flexible Server-instantie herstellen

VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexibele server

Wanneer een server wordt verwijderd, wordt de back-up van de flexibele Azure Database for PostgreSQL-server vijf dagen bewaard in de service. De back-up van de database kan alleen worden geopend en hersteld vanuit het Azure-abonnement waarin de server zich oorspronkelijk bevond. De volgende aanbevolen stappen kunnen worden gevolgd om binnen vijf dagen na het verwijderen van de server een verwijderde Azure Database for PostgreSQL flexibele serverresource te herstellen. De aanbevolen stappen werken alleen als de back-up voor de server nog steeds beschikbaar is en niet is verwijderd uit het systeem. Hoewel het herstellen van een verwijderde server vaak slaagt, is het niet altijd gegarandeerd, omdat het herstellen van een verwijderde server afhankelijk is van verschillende andere factoren.

Vereisten

Als u een verwijderd exemplaar van een flexibele Azure Database for PostgreSQL-server wilt herstellen, hebt u

  • Azure-abonnementsnaam die als host fungeert voor de oorspronkelijke server
  • Locatie waar de server is gemaakt
  • De api-versie 2024-08-01 gebruiken

Stappen voor het herstellen

  1. Blader naar Azure Portal. Selecteer de Monitor-service en selecteer vervolgens Activiteitenlogboek.

  2. Selecteer in het activiteitenlogboek de optie Filter toevoegen zoals wordt weergegeven en stel de volgende filters in voor het volgende

    • Abonnement = Uw abonnement dat als host fungeert voor de verwijderde server

    • Bewerking = PostgreSQL-server verwijderen (Microsoft.DBforPostgreSQL/flexibleservers/delete)

      Schermopname van het activiteitenlogboek dat is gefilterd voor het verwijderen van de PostgreSQL-serverbewerking.

  3. Selecteer de gebeurtenis PostgreSQL Server verwijderen en selecteer vervolgens het tabblad JSON. Kopieer de resourceId en submissionTimestamp kenmerken in JSON-uitvoer. De resourceId heeft de volgende notatie: /subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/ResourceGroup-name/providers/Microsoft.DBforPostgreSQL/flexibleServers/deletedserver.

  4. Blader naar de azure Database for PostgreSQL flexible server Create Server REST API Page en selecteer het tabblad Try It gemarkeerd in het groen. Meld u aan met uw Azure-account.

Belangrijk

Gebruik deze API-versie 2024-08-01 in plaats van de standaardinstelling voordat u deze API-functie uitvoert, zoals verwacht in de volgende stap.

  1. Geef de eigenschappen resourceGroupName, serverName (doelservernaam), subscriptionId-eigenschappen op op basis van de JSON-waarde van het resourceId-kenmerk die in de vorige stap 3 is vastgelegd. De eigenschap api-versie wordt vooraf ingevuld en kan alleen worden gelaten.

  2. Ga naar de sectie Aanvraagtekst en plak het volgende ter vervanging van de locatie van de verwijderde server (bijvoorbeeld CentralUS, EastUS, enzovoort), 'submissionTimestamp' en 'resourceId'. Geef voor pointInTimeUTC een waarde op van 'submissionTimestamp' plus 5 minuten om ervoor te zorgen dat de opdracht geen foutmelding geeft.

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

    Als de tijdstempel voor inzending bijvoorbeeld 2023-06-15T15:58:02Z is, wordt u aangeraden minimaal 10 minuten toe te voegen om een herstelpunt te herstellen naar een tijdstip van 2023-06-15T16:05:02Z en ervoor te zorgen dat u drie parameters wijzigt (locatie, pointInTimeUTC, sourceServerResourceId) volgens uw herstelvereisten.

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

    Belangrijk

    Er is een tijdslimiet van vijf dagen nadat de server is verwijderd. Na vijf dagen wordt een fout verwacht omdat het back-upbestand niet kan worden gevonden.

  3. Als u antwoordcode 201 of 202 ziet, wordt de herstelaanvraag verzonden.

    Het maken van de server kan enige tijd duren, afhankelijk van de databasegrootte en rekenresources die op de oorspronkelijke server zijn ingericht. De herstelstatus kan worden bewaakt vanuit het activiteitenlogboek door te filteren op

    • Abonnement = Uw abonnement
    • Resourcetype = Flexibele Azure Database for PostgreSQL-servers (Microsoft.DBforPostgreSQL/flexibleServers)
    • Bewerking = PostgreSQL-server maken bijwerken

Een verwijderde server met een virtueel netwerk herstellen

Het herstellen van een verwijderde server met een virtueel netwerk omvat het opgeven van extra netwerkeigenschappen, zoals de gedelegeerde subnetresource-id en de privé-DNS-zone azure Resource Manager-resource-id. Volg de onderstaande stappen om uw server te herstellen met de benodigde netwerkconfiguraties.

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

Algemene fouten

  1. Als u de onjuiste API-versie gebruikt, kunnen er herstelfouten of time-outs optreden. Gebruik de API 2024-08-01 om dergelijke problemen te voorkomen.
  2. Om mogelijke DNS-fouten te voorkomen, is het raadzaam een andere naam te gebruiken bij het initiëren van het herstelproces, omdat sommige herstelbewerkingen mogelijk mislukken met dezelfde naam.