Udostępnij za pośrednictwem


Przywracanie usuniętego wystąpienia usługi Azure Database for PostgreSQL — serwer elastyczny

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

Po usunięciu serwera kopia zapasowa serwera elastycznego usługi Azure Database for PostgreSQL jest przechowywana przez pięć dni w usłudze. Dostęp do kopii zapasowej bazy danych można uzyskać i przywrócić ją tylko z poziomu subskrypcji platformy Azure, w której pierwotnie znajdował się serwer. Poniższe zalecane kroki można wykonać, aby odzyskać usunięty zasób serwera elastycznego usługi Azure Database for PostgreSQL w ciągu pięciu dni od momentu usunięcia serwera. Zalecane kroki działają tylko wtedy, gdy kopia zapasowa serwera jest nadal dostępna i nie została usunięta z systemu. Przywracanie usuniętego serwera często kończy się powodzeniem, ale nie zawsze jest gwarantowane, ponieważ przywracanie usuniętego serwera zależy od kilku innych czynników.

Wymagania wstępne

Aby przywrócić usunięte wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL, potrzebne jest

  • Nazwa subskrypcji platformy Azure hostująca oryginalny serwer
  • Lokalizacja, w której utworzono serwer
  • Użyj wersji interfejsu API-preview 2023-03-01-preview

Kroki przywracania

  1. Przejdź do witryny Azure Portal. Wybierz usługę Monitor , a następnie wybierz pozycję Dziennik aktywności.

  2. W dzienniku aktywności wybierz pozycję Dodaj filtr , jak pokazano i ustaw następujące filtry dla następujących

    • Subskrypcja = Twoja subskrypcja hostująca usunięty serwer

    • Operation = Delete PostgreSQL Server (Microsoft.DBforPostgreSQL/flexibleservers/delete)

      Zrzut ekranu przedstawiający dziennik aktywności przefiltrowany pod kątem operacji usuwania serwera PostgreSQL.

  3. Wybierz zdarzenie Usuń serwer PostgreSQL, a następnie wybierz kartę JSON. resourceId Skopiuj atrybuty i submissionTimestamp w danych wyjściowych JSON. Atrybut resourceID ma następujący format: /subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/ResourceGroup-name/providers/Microsoft.DBforPostgreSQL/flexibleServers/deletedserver.

  4. Przejdź do strony interfejsu API REST tworzenia serwera elastycznego usługi Azure Database for PostgreSQL i wybierz kartę Wypróbuj na zielono. Zaloguj się przy użyciu konta Azure.

Ważne

Użyj tego interfejsu API w wersji 2023-03-01-preview , a nie domyślnego przed uruchomieniem, aby włączyć tę funkcję interfejsu API zgodnie z oczekiwaniami zgodnie z oczekiwaniami w poniższym kroku.

  1. Podaj właściwości resourceGroupName, serverName (nazwa serwera docelowego), subscriptionId właściwości na podstawie wartości JSON atrybutu resourceId przechwyconej w poprzednim kroku 3. Właściwość api-version jest wstępnie wypełniana i może być pozostawiona sama.

  2. Przejdź do sekcji Treść żądania i wklej następujący element, zastępując ciąg "Porzuconą lokalizacją serwera" (na przykład CentralUS, EastUS itp.), "submissionTimestamp" i "resourceId". W przypadku parametru "pointInTimeUTC" określ wartość "submissionTimestamp" plus 5 minut , aby upewnić się, że polecenie nie powoduje błędu.

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

    Jeśli na przykład sygnatura czasowa przesyłania to 2023-06-15T15:58:02Z, zalecamy dodanie co najmniej 5 minut do przywrócenia punktu w czasie 2023-06-15T16:05:02Z i upewnij się, że zmieniasz trzy parametry (location,pointInTimeUTC,sourceServerResourceId) zgodnie z wymaganiami dotyczącymi przywracania.

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

    Ważne

    Po usunięciu serwera limit czasu wynosi pięć dni. Po pięciu dniach oczekiwany jest błąd, ponieważ nie można odnaleźć pliku kopii zapasowej.

  3. Jeśli zostanie wyświetlony kod odpowiedzi 201 lub 202, żądanie przywrócenia zostanie pomyślnie przesłane.

    Tworzenie serwera może zająć trochę czasu w zależności od rozmiaru bazy danych i zasobów obliczeniowych aprowizowania na oryginalnym serwerze. Stan przywracania można monitorować z dziennika aktywności, filtrując pod kątem

    • Subskrypcja = Twoja subskrypcja
    • Typ zasobu = Serwery elastyczne usługi Azure Database for PostgreSQL (Microsoft.DBforPostgreSQL/flexibleServers)
    • Operation = Update PostgreSQL Server Create

Przywracanie usuniętej sieci wirtualnej z włączoną obsługą serwera

Przywrócenie usuniętej sieci wirtualnej włączonej serwera obejmuje określenie dodatkowych właściwości sieci, takich jak identyfikator zasobu delegowanej podsieci i prywatny identyfikator zasobu usługi Azure Resource Manager strefy DNS. Wykonaj poniższe kroki, aby przywrócić serwer przy użyciu niezbędnych konfiguracji sieci.

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

Typowe błędy

  1. Jeśli używasz nieprawidłowej wersji interfejsu API, mogą wystąpić błędy przywracania lub przekroczenia limitu czasu. Użyj interfejsu API 2023-03-01-preview, aby uniknąć takich problemów.
  2. Aby uniknąć potencjalnych błędów DNS, zaleca się użycie innej nazwy podczas inicjowania procesu przywracania, ponieważ niektóre operacje przywracania mogą zakończyć się niepowodzeniem o tej samej nazwie.

Następny krok