Compartir a través de

Copia de seguridad y restauración en Azure Database for PostgreSQL: servidor flexible

  • Artículo

SE APLICA A: Azure Database for PostgreSQL: servidor flexible

Las copias de seguridad forman una parte esencial de cualquier estrategia de continuidad empresarial. Ayudan a proteger los datos en caso de daños o eliminaciones accidentales.

El servidor flexible de Azure Database for PostgreSQL realiza automáticamente copias de seguridad periódicas del servidor. Por lo que puede realizar una restauración a un momento dado (PITR) dentro de un período de retención que especifique. El tiempo total de restauración y recuperación depende normalmente del tamaño de los datos y la cantidad de recuperación que se va a realizar.

Introducción a Backup

El servidor flexible de Azure Database for PostgreSQL realiza copias de seguridad de instantáneas de archivos de datos y las almacena de forma segura en el almacenamiento con redundancia de zona o en el almacenamiento con redundancia local, en función de la región . El servidor también hace una copia de seguridad de los registros de transacciones cuando el archivo de registro de escritura previa (WAL) está listo para archivarse. Puede usar estas copias de seguridad para restaurar un servidor a un momento dado dentro del período de retención de copias de seguridad configurado.

El período de retención de copia de seguridad predeterminado es de 7 días, pero puede ampliar el período hasta un máximo de 35 días. Todas las copias de seguridad se cifran mediante cifrado AES de 256 bits para los datos almacenados en reposo.

Estos archivos de copia de seguridad no se pueden exportar ni usar para crear servidores fuera del servidor flexible de Azure Database for PostgreSQL. Para ello, puede usar herramientas de PostgreSQL pg_dump y pg_restore/psql.

Frecuencia de copia de seguridad

Las copias de seguridad en instancias de servidor flexible de Azure Database for PostgreSQL se basan en instantáneas. La primera copia de seguridad de instantáneas se programa inmediatamente después de la creación de un servidor. Las copias de seguridad de instantáneas se realizan una vez al día. Si no se realizan más modificaciones en ninguna base de datos del servidor después de la última copia de seguridad de instantáneas, las copias de seguridad de instantáneas se suspenden temporalmente. En cuanto se modifica cualquier base de datos del servidor, se toma inmediatamente una nueva instantánea para capturar los cambios más recientes. La primera instantánea es una copia de seguridad completa y las instantáneas consecutivas son copias de seguridad diferenciales.

Las copias de seguridad del registro de transacciones se realizan con una frecuencia variable en función de la carga de trabajo y cuándo ser rellena y está listo el archivo WAL para archivarse. En general, el RPO de retraso (objetivo de punto de recuperación) puede ser de hasta 5 minutos.

Opciones de redundancia de copia de seguridad

El servidor flexible de Azure Database for PostgreSQL almacena varias copias de las copias de seguridad para ayudar a proteger los datos de eventos planeados y no planeados. Estos eventos pueden incluir errores transitorios de hardware, cortes de red o de energía y desastres naturales. La redundancia de copia de seguridad ayuda a garantizar que la base de datos cumple sus objetivos de disponibilidad y durabilidad, incluso si se producen errores.

El servidor flexible de Azure Database for PostgreSQL ofrece tres opciones:

  • Zone-redundant backup storage (Almacenamiento de copia de seguridad con redundancia de zona): esta opción se elige automáticamente para las regiones que admiten zonas de disponibilidad. Cuando las copias de seguridad se almacenan en el almacenamiento de copia de seguridad con redundancia geográfica, se conservan tres copias de los datos dentro de la región donde se hospeda el servidor. Además, los datos se replican en una región emparejada para la protección agregada.

    Esta opción proporciona disponibilidad de datos de copia de seguridad entre zonas de disponibilidad y restringe la replicación de datos a dentro de un país o región para cumplir los requisitos de residencia de datos. Esta opción proporciona al menos una durabilidad del 99,9999999999 % (12 nueves) de los objetos de copia de seguridad durante un año.

  • Locally redundant backup storage (Almacenamiento de copias de seguridad con redundancia local): esta opción se elige automáticamente para las regiones que aún no admiten zonas de disponibilidad. Cuando las copias de seguridad se almacenan en un almacenamiento de copia de seguridad con redundancia local, son varias las copias de seguridad que se almacenan en el mismo centro de datos.

    Esta opción ayuda a proteger los datos frente a errores en la estantería de servidores y en la unidad. Proporciona al menos una durabilidad del 99,999999999 % (11 nueves) de los objetos de copia de seguridad durante un año.

    De manera predeterminada, el almacenamiento de copia de seguridad para servidores con alta disponibilidad en la misma zona o sin configuración de alta disponibilidad se establece en redundancia local.

  • Almacenamiento de copias de seguridad con redundancia geográfica: puede elegir esta opción en el momento de la creación del servidor. Cuando las copias de seguridad se guardan en un almacenamiento de copia de seguridad con redundancia geográfica, además de tres copias de datos almacenadas en la región en la que está alojado el servidor, se replican los datos en la región emparejada geográficamente.

    Esta opción le permite restaurar el servidor en una región diferente en caso de desastre. Proporciona al menos una durabilidad del 99,99999999999999 % (16 nueves) de los objetos de copia de seguridad durante un año.

    La redundancia geográfica es compatible con los servidores hospedados en cualquiera de las regiones emparejadas de Azure.

Cambio de otras opciones de almacenamiento de copia de seguridad al almacenamiento de copia de seguridad con redundancia geográfica

El almacenamiento con redundancia geográfica para la copia de seguridad solo se puede configurar durante la creación del servidor. Una vez que se ha aprovisionado el servidor, no se puede cambiar la opción de redundancia del almacenamiento de copia de seguridad.

Retención de copia de seguridad

Las copias de seguridad se conservan según el período de retención que especifique para el servidor. Puede seleccionar un período de retención de entre 7 (valor predeterminado) y 35 días. Puede establecer el período de retención durante la creación del servidor o cambiarlo más adelante. Las copias de seguridad de los servidores detenidos también se conservan.

El período de retención de copia de seguridad rige el período de tiempo desde el que se puede recuperar una PITR mediante las copias de seguridad disponibles. El período de retención de copia de seguridad también se puede tratar como un período de recuperación desde una perspectiva de restauración.

Todas las copias de seguridad que se necesitan para realizar una restauración a un momento dado dentro del período de retención de copia de seguridad se conservan en el almacenamiento de copia de seguridad. Por ejemplo, si la ventana de retención de la copia de seguridad se establece en 7 días, el período de recuperación sería los últimos 7 días. En este escenario, se conservan todos los datos y los registros necesarios para restaurar y recuperar el servidor en los últimos 7 días.

Costo del almacenamiento de copia de seguridad

El servidor flexible de Azure Database for PostgreSQL proporciona hasta el 100 % del almacenamiento del servidor aprovisionado como almacenamiento de copia de seguridad sin costo adicional. Cualquier almacenamiento de copia de seguridad adicional que use se cobra en gigabytes por mes.

Por ejemplo, si ha aprovisionado un servidor con 250 gibibytes (GiB) de almacenamiento, tendrá 250 GiB de capacidad para almacenar copias de seguridad sin costes adicionales. Si el uso de la copia de seguridad diaria es de 25 GiB, puede tener hasta diez días de almacenamiento de copia de seguridad. El consumo de almacenamiento de copia de seguridad que supere los 250 GiB se cobrará según se defina en el modelo de precios.

Si configuró el servidor con copia de seguridad con redundancia geográfica, los datos de copia de seguridad también se copian en la región emparejada de Azure. Por lo tanto, el tamaño de la copia de seguridad será el doble del tamaño de la copia de seguridad local. La facturación se calcula como ([2 x el tamaño de copia de seguridad local] - el tamaño de almacenamiento aprovisionado) x el precio @ gigabytes por mes.

Puede usar la métrica Almacenamiento de copia de seguridad utilizado en Azure Portal para supervisar el almacenamiento de copia de seguridad que un servidor consume. La métrica Almacenamiento de copia de seguridad utilizado representa la suma del almacenamiento consumido por todas las copias de seguridad de base de datos conservadas y las copias de seguridad de registros, en función del período de retención de copia de seguridad establecido para el servidor.

Nota:

Independientemente del tamaño de la base de datos, la actividad transaccional intensa en el servidor genera más archivos WAL. A su vez, el aumento de los archivos aumenta el almacenamiento de copia de seguridad.

Restauración a un momento dado

En el servidor flexible de Azure Database for PostgreSQL, la realización de un PITR crea un nuevo servidor en la misma región que el servidor de origen, pero puede elegir la zona de disponibilidad. Se crea con la configuración del servidor de origen correspondiente al plan de tarifa, generación de procesos, número de núcleos virtuales, tamaño de almacenamiento, período de retención de copia de seguridad y opción de redundancia de copia de seguridad. Además, las etiquetas y configuraciones como las de redes virtuales y del firewall se heredan del servidor de origen.

Los archivos físicos de base de datos se restauran primero a partir de las copias de seguridad de instantáneas en la ubicación de datos del servidor. Se elige y restaura automáticamente la copia de seguridad pertinente, realizada antes del momento indicado. A continuación, se inicia un proceso de recuperación con archivos WAL para llevar la base de datos a un estado coherente.

Por ejemplo, suponga que las copias de seguridad se realizan todas las noches a las 23:00. Si el punto de restauración es el 15 de agosto a las 10:00, se restaurará la copia de seguridad diaria del 14 de agosto. Se recuperará la base de datos hasta las 10:00 del 15 de agosto con la copia de seguridad de los registros de transacciones del 14 de agosto a las 23:00 hasta el 15 de agosto a las 10:00.

Siga estos pasos para restaurar el servidor de bases de datos.

Importante

Una operación de restauración en el servidor flexible de Azure Database for PostgreSQL siempre crea un nuevo servidor de bases de datos con el nombre que proporcione. No sobrescribe el servidor de bases de datos existente.

La restauración a un momento dado es útil en escenarios como estos:

  • Un usuario elimina accidentalmente datos, una tabla o una base de datos.
  • Una aplicación sobrescribe accidentalmente datos correctos con otros no válidos debido a un defecto en ella.
  • Quiere clonar el servidor para la prueba, el desarrollo o para la comprobación de datos.

Con la copia de seguridad continua de los registros de transacciones, puede restaurar a la última transacción. Puede elegir entre las siguientes opciones de restauración:

  • Punto de restauración más reciente (ahora): esta es la opción predeterminada, que permite restaurar el servidor al último momento en el tiempo.

  • Punto de restauración personalizado: esta opción le permite elegir cualquier momento en el período de retención definido para esta instancia de servidor flexible de Azure Database for PostgreSQL. De forma predeterminada, se selecciona automáticamente la hora UTC más reciente. La selección automática es útil si quiere restaurar a la transacción más reciente confirmada para la prueba. También puede elegir otros días y horas.

  • Punto de restauración rápido: esta opción permite a los usuarios restaurar el servidor en el tiempo más rápido posible dentro del período de retención definido para su instancia de servidor flexible de Azure Database for PostgreSQL. La restauración más rápida es posible si se elige directamente la marca de tiempo de la lista de copias de seguridad. Esta operación de restauración aprovisiona un servidor y simplemente restaura la copia de seguridad de instantánea completa y no necesita la recuperación de los registros, lo que hace que sea rápida. Se recomienda seleccionar una marca de tiempo de copia de seguridad que sea mayor que el primer punto de restauración en el tiempo para una operación de restauración correcta.

El tiempo necesario para recuperarse con las opciones de punto de restauración más recientes y personalizado varía en función de factores como el volumen de registros de transacciones que se van a procesar desde la última copia de seguridad y el número total de bases de datos que se recuperan simultáneamente en la misma región. El tiempo de recuperación general suele tardar desde unos minutos hasta unas horas.

Si configura el servidor dentro de una red virtual, puede restaurarlo a la misma red virtual o en una red virtual diferente. Sin embargo, no se puede restaurar a un acceso público. De forma similar, si ha configurado el servidor con acceso público, no podrá restaurar a un acceso privado de red virtual.

Importante

Puede restaurar los servidores eliminados. Si elimina el servidor, puede seguir nuestras instrucciones Restaurar una base de datos Azure anulada para Azure Database for PostgreSQL: servidor flexible recuperar. Use el bloqueo de recursos de Azure para evitar la eliminación accidental del servidor.

Copia de seguridad y restauración con redundancia geográfica

Para habilitar la copia de seguridad con redundancia geográfica desde el panel Proceso y almacenamiento de Azure Portal, consulte la guía de inicio rápido.

Importante

La copia de seguridad con redundancia geográfica solo se puede configurar en el momento de la creación del servidor.

Después de configurar el servidor con copia de seguridad con redundancia geográfica, puede restaurarlo en una región emparejada geográficamente. Para más información, consulte las regiones admitidas para la copia de seguridad con redundancia geográfica.

Cuando el servidor se configura con copia de seguridad con redundancia geográfica, los datos de copia de seguridad y los registros de transacciones se copian en la región emparejada de forma asincrónica mediante la replicación de almacenamiento. Después de crear un servidor, espere al menos una hora antes de iniciar una restauración geográfica. Esto permite que el primer conjunto de datos de copia de seguridad se replique en la región emparejada.

Posteriormente, los registros de transacciones y las copias de seguridad diarias se copian asincrónicamente en la región emparejada. Puede haber hasta una hora de retraso en la transmisión de datos. Por lo tanto, puede esperar hasta una hora de RPO al restaurar. Solo puede restaurar los últimos datos de copia de seguridad disponibles en la región emparejada. Actualmente, la restauración a un momento dado de copias de seguridad con redundancia geográfica no está disponible.

El tiempo estimado para recuperar el servidor RTO (objetivo de tiempo de recuperación) depende de factores como el tamaño de la base de datos, la hora de la última copia de seguridad de la base de datos y la cantidad de WAL que se procesará hasta la última vez que se recibieron los datos de copia de seguridad. Normalmente, el tiempo de recuperación general tarda entre unos minutos y unas horas.

Durante la restauración geográfica, las configuraciones de servidor que se pueden cambiar incluyen la configuración de red virtual y la capacidad de quitar la copia de seguridad con redundancia geográfica del servidor restaurado. No se admite el cambio de otras configuraciones de servidor, como proceso, almacenamiento o plan de tarifa (Ampliable, de uso general o optimizada para memoria) durante la restauración geográfica.

Para obtener más información sobre cómo realizar una restauración geográfica, consulte la guía paso a paso.

Importante

Cuando la región primaria está fuera de servicio, no se pueden crear servidores con redundancia geográfica en la región emparejada geográficamente correspondiente, ya que el almacenamiento no se puede aprovisionar en la región primaria. Para aprovisionar servidores con redundancia geográfica en la región emparejada geográficamente, hay que esperar a que la región primaria esté lista.

Aunque la región primaria esté fuera de servicio, puede restaurar geográficamente el servidor de origen a la región emparejada geográficamente. Para obtener más información sobre cómo realizar una restauración geográfica, consulte la guía paso a paso. Debe usar réplicas geográficas como estrategia de recuperación ante desastres (DR) si necesita configurar la recuperación ante desastres en cualquier región o si la región primaria no admite copias de seguridad con redundancia geográfica.

Restauración y redes

Restauración a un momento dado

Si el servidor de origen está configurado con una red de acceso público, solo puede restaurar al acceso público.

Si el servidor de origen está configurado con una red virtual de acceso privado, puede restaurar a la misma red virtual o a otra red virtual. No se puede realizar la restauración a un momento dado al acceso público y privado.

Geo-restore

Si el servidor de origen está configurado con una red de acceso público, solo puede restaurar al acceso público. Las reglas de firewall existentes en el servidor de origen se copian en el servidor restaurado. No se toman los puntos de conexión privados. Una vez completada la operación de restauración, revise si necesita ajustar cualquiera de las reglas de firewall que se llevan a cabo y cree los puntos de conexión privados que necesite.

Si el servidor de origen está configurado con una red virtual de acceso privado, solo puede restaurar a otra red virtual, porque las redes virtuales no pueden abarcar regiones. No se puede realizar la restauración geográfica al acceso público y privado.

Tareas posteriores a la restauración

Después de restaurar el servidor, puede realizar las siguientes tareas para que los usuarios y las aplicaciones vuelvan a estar activos y en ejecución:

  • Si el nuevo servidor está destinado a reemplazar al original, redirija a los clientes y las aplicaciones cliente al nuevo servidor. Cambie el nombre del servidor de la cadena de conexión para que apunte al nuevo servidor.

  • Asegúrese de aplicar reglas de red virtual, puntos de conexión privados y de firewall de nivel de servidor adecuadas para las conexiones de los usuarios. En una red de acceso público, las reglas se copian desde el servidor original, pero es posible que no sean las necesarias en el entorno restaurado. Por lo tanto, ajuste según sus requisitos. Los puntos de conexión privados no se transfieren. Cree cualquier punto de conexión privado que necesite en el servidor restaurado. En una red virtual de acceso privado, la restauración no copia a través de artefactos de infraestructura de red de origen a redes de servidor restauradas. Todo lo relacionado con la configuración de la VNET (red virtual), las subredes o los grupos de seguridad de red, se debe tener en cuenta como una tarea posterior a la restauración.

  • Escale o reduzca verticalmente el proceso del servidor restaurado según sea necesario.

  • Asegúrese de emplear los permisos de nivel de base de datos y los inicios de sesión apropiados.

  • Configure las alertas según corresponda.

  • Si el servidor de origen desde el que ha restaurado estaba configurado con alta disponibilidad, y desea configurar el servidor restaurado con alta disponibilidad, puede seguir estos pasos.

  • Si el servidor de origen desde el que ha restaurado estaba configurado con réplicas de lectura, y quiere configurar réplicas de lectura en el servidor restaurado, puede seguir estos pasos.

Copias de seguridad a petición (versión preliminar)

El servidor flexible de Azure Database for PostgreSQL genera automáticamente instantáneas de volumen de almacenamiento de toda la instancia de base de datos, que abarcan todas las bases de datos, como parte de sus copias de seguridad programadas. Además, puede crear una copia de seguridad a petición siempre que sea necesario, lo que es ideal para escenarios como preparar una operación potencialmente de riesgo o realizar actualizaciones periódicas fuera de la programación de copia de seguridad habitual.

Las copias de seguridad a petición se pueden realizar además de las copias de seguridad automáticas programadas. Estas copias de seguridad se conservan según la ventana de retención de copia de seguridad. Puede eliminar estas copias de seguridad a petición en cualquier momento si ya no son necesarias. Para iniciar una copia de seguridad a petición, simplemente seleccione la instancia de base de datos de la que desea realizar una copia de seguridad y especifique un nombre de copia de seguridad. Estas copias de seguridad se almacenan junto con copias de seguridad automatizadas, pero solo los usuarios pueden eliminar las copias de seguridad a petición, ya que el servicio de servidor flexible administra y conserva las copias de seguridad automatizadas para satisfacer los requisitos de retención de copia de seguridad.

Para obtener más información sobre cómo realizar una copia de seguridad a petición, visite la guía paso a paso.

Limitaciones

La característica de copia de seguridad a petición no se admite actualmente con el nivel de proceso de servidor ampliable.

Retención a largo plazo

Azure Backup y los servicios de servidor flexible de Azure Database for PostgreSQL han creado una solución de copia de seguridad a largo plazo de clase empresarial para instancias de servidor flexible de Azure Database for PostgreSQL que conserva las copias de seguridad durante hasta 10 años. Puede usar la retención a largo plazo (LTR) de forma independiente o además de la solución de copia de seguridad automatizada que ofrece el servidor flexible de Azure Database for PostgreSQL, que ofrece retención de hasta 35 días. Las copias de seguridad automatizadas son copias de seguridad físicas adecuadas para las recuperaciones operativas, especialmente cuando se desea restaurar a partir de las copias de seguridad más recientes. Las copias de seguridad a largo plazo le ayudan con sus necesidades de cumplimiento, son más granulares y se toman como copias de seguridad lógicas mediante pg_dump nativas. Además de la retención a largo plazo, la solución ofrece las siguientes funcionalidades:

  • Copia de seguridad a petición y programada controlada por el cliente en el nivel de base de datos individual.
  • Supervisión central de todas las operaciones y trabajos.
  • Las copias de seguridad se almacenan en dominios de seguridad y de error independientes. Si el servidor de origen o la suscripción están en peligro, las copias de seguridad permanecen seguras en el almacén de Backup (en cuentas de almacenamiento administradas por Azure Backup).
  • El uso de pg_dump permite una mayor flexibilidad en la restauración de datos en distintas versiones de base de datos.
  • Los almacenes de Azure Backup admiten características de inmutabilidad y eliminación temporal (versión preliminar), que protegen los datos.
  • Compatibilidad de copia de seguridad de LTR con servidores habilitados para CMK

Limitaciones y consideraciones

  • Las restauraciones de LTR solo están disponibles actualmente como "Restaurar como archivos" en cuentas de almacenamiento, con la funcionalidad "Restaurar como servidor" planeada para el futuro.
  • LTR realiza una copia de seguridad de todas las bases de datos en instancias de servidor flexibles y no se pueden seleccionar bases de datos individuales para la configuración de LTR.
  • La copia de seguridad de LTR no se admite en réplicas geográficas, pero se puede realizar desde servidores principales.
  • El tamaño máximo de base de datos admitido para la copia de seguridad LTR es 4 TiB.
  • Las copias de seguridad de LTR se pueden programar de manera semanal, mensual o anual. Actualmente, no se admite la programación de copia de seguridad diaria.

Para obtener más información sobre cómo realizar una copia de seguridad a largo plazo, visite la guía paso a paso.

Preguntas más frecuentes

  • ¿Cómo controla Azure la copia de seguridad de mi servidor?

    De manera predeterminada, el servidor flexible de Azure Database for PostgreSQL permite copias de seguridad automatizadas de todo el servidor (que abarcan todas las bases de datos creadas) con un período de retención predeterminado de 7 días. Las copias de seguridad automatizadas incluyen una instantánea incremental diaria de la base de datos. Los archivos de registros (WAL) se archivan continuamente en Azure Blob Storage.

  • ¿Puedo configurar copias de seguridad automatizadas para conservar los datos a largo plazo?

    No. Actualmente, el servidor flexible de Azure Database for PostgreSQL admite un máximo de 35 días de retención. Puede usar copias de seguridad manuales si necesita una retención a largo plazo mediante Azure Backup.

  • ¿Cómo se realiza una copia de seguridad manual de mis instancias de servidor flexible de Azure Database for PostgreSQL?

    Puede realizar manualmente una instantánea física mediante la característica de copia de seguridad a petición, también puede realizar copias de seguridad lógicas mediante la herramienta PostgreSQL pg_dump. Para obtener ejemplos, consulte Migración de la base de datos de servidor flexible de Azure Database for PostgreSQL mediante volcado y restauración.

  • ¿Cuáles son las ventanas de copia de seguridad de mi servidor? ¿Se pueden personalizar?

    Azure administra las ventanas de copia de seguridad y no se pueden personalizar. La primera copia de seguridad de instantáneas completa, se programa inmediatamente después de la creación del servidor. Las copias de seguridad de instantáneas posteriores son incrementales y se producen una vez al día.

  • ¿Mis copias de seguridad están cifradas?

    Sí. Todos los datos de servidor flexible de Azure Database for PostgreSQL, copias de seguridad y archivos temporales que se crean durante la ejecución de consultas se cifran a través del cifrado de 256 bits AES (Estándar de cifrado avanzado). El cifrado de almacenamiento siempre está activado y no se puede deshabilitar.

  • ¿Puedo restaurar una sola base de datos o solo algunas bases de datos en un servidor?

    No se admite directamente la restauración de una o varias bases de datos o tablas. Sin embargo, debe restaurar todo el servidor a un servidor nuevo y, después, extraer las tablas o bases de datos e importarlas al nuevo servidor.

  • ¿Está disponible mi servidor mientras la copia de seguridad está en curso?

    Sí. Las copias de seguridad son operaciones en línea que usan instantáneas. La operación de instantánea solo tarda unos segundos y no interfiere con las cargas de trabajo de producción que ayudan a garantizar la alta disponibilidad del servidor.

  • Al configurar la ventana de mantenimiento para el servidor, ¿es necesario tener en cuenta la ventana de copia de seguridad?

    No. Las copias de seguridad se desencadenan internamente como parte del servicio administrado y no tienen ninguna relación con la ventana de mantenimiento.

  • ¿Dónde se almacenan mis copias de seguridad automatizadas y cómo se administra su retención?

    El servidor flexible de Azure Database for PostgreSQL crea automáticamente copias de seguridad del servidor y las almacena en:

    • Almacenamiento con redundancia de zona, en regiones donde se admiten varias zonas.
    • Almacenamiento con redundancia local, en regiones que aún no admiten varias zonas.
    • La región emparejada, si configura la copia de seguridad con redundancia geográfica.

    Estos archivos de copia de seguridad no se pueden exportar.

    Puede utilizar copias de seguridad solo para restaurar el servidor a un momento dado. El período de retención de las copias de seguridad predeterminado es 7 días. Opcionalmente, puede configurar la retención de copia de seguridad hasta 35 días.

  • Con la copia de seguridad con redundancia geográfica, ¿con qué frecuencia se copia la copia de seguridad en la región emparejada?

    Cuando el servidor se configura con copia de seguridad con redundancia geográfica, los datos de la copia de seguridad se almacenan en una cuenta de almacenamiento con redundancia geográfica. La cuenta de almacenamiento copia los archivos de datos en la región emparejada cuando se produce la copia de seguridad diaria en el servidor principal. Se hace una copia de seguridad de los archivos WAL cuando están listos para archivarse.

    Los datos de copia de seguridad se copian de forma asincrónica y continua en la región emparejada. Puede esperar hasta una hora de retraso en la recepción de datos de copia de seguridad.

  • ¿Puedo realizar PITR en la región remota?

    No. Los datos se recuperan en los últimos datos de copia de seguridad disponibles en la región remota.

  • ¿Cómo se realizan las copias de seguridad en servidores habilitados para alta disponibilidad?

    Los volúmenes de datos del servidor flexible de Azure Database for PostgreSQL se realizan copias de seguridad mediante instantáneas incrementales de disco administrado desde el servidor principal. La copia de seguridad de WAL se realiza desde el servidor principal o el servidor en espera.

  • ¿Cómo puedo validar que se hacen las copias de seguridad en mi servidor?

    La mejor manera de comprobar las copias de seguridad es realizar una restauración a un momento dado periódicamente y asegurarse de que las copias de seguridad son válidas y se pueden restaurar. Las operaciones o archivos de copia de seguridad no se exponen a los usuarios finales.

  • ¿Dónde puedo ver el uso de la copia de seguridad?

    En Azure Portal, en Supervisión, seleccione Métricas. En Almacenamiento de copia de seguridad usado, puede supervisar el uso total de la copia de seguridad.

  • ¿Qué ocurre con mis copias de seguridad si se elimina el servidor?

    Si elimina un servidor, todas las copias de seguridad que pertenecen al servidor también se eliminan y no se pueden recuperar. Para ayudar a proteger los recursos del servidor frente a eliminaciones accidentales o cambios inesperados después de la implementación, los administradores pueden usar los bloqueos de administración.

  • ¿Cómo se conservan las copias de seguridad de los servidores detenidos?

    No se realizan nuevas copias de seguridad para los servidores detenidos. Todas las copias de seguridad anteriores (dentro de la ventana de retención) en el momento de detención del servidor se conservan hasta que se reinicia el servidor. Después de eso, la retención de copia de seguridad para el servidor activo se rige por su ventana de retención.

  • ¿Cómo se me cobrará y facturará por las copias de seguridad?

    El servidor flexible de Azure Database for PostgreSQL proporciona hasta el 100 % del almacenamiento del servidor aprovisionado como almacenamiento de copia de seguridad sin costo adicional. Cualquier almacenamiento de copia de seguridad que use se cargará en gigabytes al mes, tal como se define en el modelo de precios.

    El período de retención de copia de seguridad y la opción de redundancia de copia de seguridad que seleccione, junto con la actividad transaccional en el servidor, afectan directamente al almacenamiento y facturación totales de copia de seguridad.

  • ¿Cómo se me facturará por un servidor detenido?

    Mientras se detiene la instancia del servidor, no se realizan nuevas copias de seguridad. Se le cobra por el almacenamiento aprovisionado y el almacenamiento de copia de seguridad (copias de seguridad almacenadas dentro de la ventana de retención especificada).

    El almacenamiento de copia de seguridad gratuito se limita al tamaño de la base de datos aprovisionada. Cualquier exceso de datos de copia de seguridad se cobrará según el precio de la copia de seguridad.

  • He configurado mi servidor con alta disponibilidad con redundancia de zona. ¿Se realizarán dos copias de seguridad y se me cobrará dos veces?

    No. Independientemente de los servidores de alta disponibilidad o que no sean de alta disponibilidad, solo se mantiene un conjunto de copia de seguridad. Solo se le cargará una vez.

  • Cómo restaurar mi servidor?

    Azure admite la restauración a un momento dado para todos los servidores. Los usuarios pueden restaurar al punto de restauración más reciente o a un punto de restauración personalizado mediante Azure Portal, la CLI de Azure y la API.

    Para restaurar el servidor a partir de copias de seguridad manuales mediante herramientas como pg_dump, primero puede crear una instancia de servidor flexible de Azure Database for PostgreSQL y, a continuación, restaurar las bases de datos en el servidor mediante pg_restore.

  • ¿Puedo restaurar a otra zona de disponibilidad dentro de la misma región?

    Sí. Si la región admite varias zonas de disponibilidad, la copia de seguridad se almacena en una cuenta de almacenamiento con redundancia de zona por lo que puede restaurar a otra zona.

  • ¿Cuánto tiempo tarda una restauración a un momento dado? ¿Por qué mi restauración tarda tanto tiempo?

    La operación de restauración de datos de una instantánea no depende del tamaño de los datos. Pero el tiempo del proceso de recuperación que aplica los registros (actividades de transacción que se deben reproducir) puede variar, en función de la copia de seguridad anterior, de la fecha y hora de la solicitud y del número de registros que se deben procesar. Se aplica tanto a la restauración dentro de la misma zona como a la restauración de los datos a una zona diferente.

  • Si restauro mi servidor habilitado para alta disponibilidad, ¿el servidor de restauración se configura automáticamente con alta disponibilidad?

    No. El servidor se restaura como una instancia de servidor flexible de Azure Database for PostgreSQL de instancia única. Una vez completada la restauración, puede configurar opcionalmente el servidor con alta disponibilidad.

  • He configurado mi servidor dentro de una red virtual. ¿Puedo restaurar a otra red virtual?

    Sí. En el momento de la restauración, elija otra red virtual para la restauración.

  • ¿Puedo restaurar mi servidor de acceso público a una red virtual o viceversa?

    No. Actualmente, el servidor flexible de Azure Database for PostgreSQL no admite la restauración de servidores a través del acceso público y privado.

  • Cómo realizar un seguimiento de mi operación de restauración?

    Actualmente no hay ninguna manera de realizar un seguimiento de la operación de restauración. Puede supervisar el registro de actividad para ver si la operación está en curso o se ha completado.

Pasos siguientes