Compartir a través de


Restauración de una instancia de servidor flexible de Azure Database for PostgreSQL eliminada

SE APLICA A: Azure Database for PostgreSQL con servidor flexible

Cuando se quita un servidor, la copia de seguridad del servidor flexible de Azure Database for PostgreSQL se conserva durante cinco días en el servicio. Solo se puede acceder a la copia de seguridad de la base de datos y restaurarla desde la suscripción de Azure en la que residía originalmente el servidor. Se pueden seguir los pasos recomendados siguientes para recuperar un recurso de servidor flexible de Azure Database for PostgreSQL eliminado en un plazo de cinco días a partir del momento de la eliminación del servidor. Los pasos recomendados solo funcionan si la copia de seguridad del servidor todavía está disponible y no se ha eliminado del sistema. Aunque la restauración de un servidor eliminado se suele realizar correctamente, no siempre está garantizada, ya que restauración depende de otros factores.

Requisitos previos

Para restaurar una instancia de servidor flexible de Azure Database for PostgreSQL eliminada, necesita

  • El nombre de la suscripción de Azure que hospeda el servidor original.
  • La ubicación en la que se creó el servidor.
  • Uso de la versión api-version 2023-03-01-preview

Pasos para la restauración

  1. Vaya a Azure Portal. Selecciona el servicio Monitor y luego Registro de actividad.

  2. En Registro de actividad, seleccione Agregar filtro como se muestra y establezca filtros para lo siguiente

    • La suscripción = la suscripción que hospeda el servidor eliminado.

    • Operación = elimine el servidor PostgreSQL (Microsoft.DBforPostgreSQL/flexibleservers/delete)

      Captura de pantalla que muestra el registro de actividad filtrado para la operación de eliminación del servidor PostgreSQL.

  3. Seleccione el evento Eliminar servidor PostgreSQL y luego la pestaña JSON. Copie los atributos resourceId y submissionTimestamp en la salida JSON. ResourceId tiene el formato siguiente: /subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/ResourceGroup-name/providers/Microsoft.DBforPostgreSQL/flexibleServers/deletedserver.

  4. Vaya a la página API de REST del servidor Azure Database for PostgreSQL flexible Create Server y seleccione la pestaña Probar resaltada en verde. Inicie sesión con su cuenta de Azure.

Importante

Use esta versión de API 2023-03-03-01-preview en lugar del valor predeterminado antes de ejecutarse para habilitar esta función de API según lo previsto, como se detalla en el paso siguiente.

  1. Especifica las propiedades resourceGroupName, serverName (nombre del servidor de destino) y subscriptionId en función del valor JSON del atributo resourceId capturado en el paso 3 anterior. La propiedad api-version está rellenada previamente y se puede conservar sin cambios.

  2. Vaya a la sección Cuerpo de la solicitud y pegue lo siguiente, y sustituya "Ubicación del servidor descartado" (por ejemplo, CentralUS, EastUS, etc.), "submissionTimestamp" y "resourceId". En el caso de "restorePointInTime", especifica un valor de "submissionTimestamp" más 5 minutos para asegurarse de que el comando no tiene errores.

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

    Por ejemplo, si la marca de tiempo de envío es 2023-06-15T15:58:02Z, recomendamos agregar un mínimo de 5 minutos para restaurar un momento dado 2023-06-15T16:05:02Z y asegurarse de que está cambiando tres parámetros (location,pointInTimeUTC,sourceServerResourceId) según sus requisitos de restauración.

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

    Importante

    Hay un límite de tiempo de cinco días después de la eliminación del servidor. Transcurrido este tiempo, es previsible un error, ya que no es posible encontrar el archivo de copia de seguridad.

  3. Si ve el código de respuesta 201 o 202, quiere decir que la solicitud de restauración se envió correctamente.

    La creación del servidor puede llevar tiempo según el tamaño de la base de datos y los recursos de proceso aprovisionados en el servidor original. El estado de la restauración se puede supervisar desde el registro de actividad mediante el filtrado de

    • La suscripción = su suscripción.
    • Tipo de recurso = servidores flexibles de Azure Database for PostgreSQL (Microsoft.DBforPostgreSQL/flexibleServers)
    • Operación: actualización de la creación del servidor PostgreSQL

Restauración de un servidor habilitado para la red virtual descartada

La restauración de un servidor habilitado para la red virtual quitada implica especificar propiedades de red adicionales, como el identificador de recurso de subred delegada y el identificador de recurso de Azure Resource Manager de la zona DNS privada. Siga los pasos que se indican a continuación para restaurar el servidor con las configuraciones de red necesarias.

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

Errores comunes

  1. Si utiliza la versión de API incorrecta, puede experimentar errores de restauración o tiempos de espera. Use la API 2023-03-01-preview para evitar estos problemas.
  2. Para evitar posibles errores de DNS, se recomienda usar un nombre diferente al iniciar el proceso de restauración, ya que algunas operaciones de restauración pueden producir un error con el mismo nombre.

Paso siguiente