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

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

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 para restaurar y recuperar normalmente depende del tamaño de los datos y de la cantidad de recuperación que se va a realizar.

Introducción a Backup

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. Use estas copias de seguridad para restaurar un servidor a cualquier momento dado dentro del período de retención de copia de seguridad configurado.

El período de retención de copia de seguridad predeterminado es de siete días, pero puede extender el período a 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.

No puede exportar estos archivos de copia de seguridad ni usarlos para crear servidores fuera de la instancia de servidor flexible 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 realiza ninguna modificación adicional en ninguna base de datos del servidor después de la última copia de seguridad de instantáneas, el sistema suspende temporalmente las copias de seguridad de instantáneas. En cuanto modifique cualquier base de datos en el servidor, el sistema 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, dependiendo de la carga de trabajo y de cuándo el archivo WAL queda lleno y está listo para ser archivado. En general, el retraso del RPO (objetivo de punto de recuperación) puede ser de hasta cinco minutos.

Opciones de redundancia de copia de seguridad

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.

Azure Database for PostgreSQL ofrece tres opciones:

• Almacenamiento de copia de seguridad con redundancia de zona: Azure Database for PostgreSQL selecciona automáticamente esta opción para las regiones que admiten zonas de disponibilidad. Al almacenar copias de seguridad en el almacenamiento de copia de seguridad con redundancia de zona, el servicio mantiene tres copias de los datos dentro de la zona de disponibilidad donde se hospeda el servidor. Además, el servicio replica los datos en otra zona de disponibilidad 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. Proporciona al menos un 99,9999999999 por ciento de durabilidad para los objetos de copia de seguridad durante un año.

• Almacenamiento de copia de seguridad con redundancia local: Azure Database for PostgreSQL selecciona automáticamente esta opción para las regiones que aún no admiten zonas de disponibilidad. Al almacenar copias de seguridad en el almacenamiento de copia de seguridad con redundancia local, el servicio almacena varias copias de seguridad en el mismo centro de datos.

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

  De forma predeterminada, el servicio establece el almacenamiento de copias de seguridad para los servidores con alta disponibilidad (HA) en la misma zona o sin configuración de alta disponibilidad 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. Al almacenar copias de seguridad en el almacenamiento de copia de seguridad con redundancia geográfica, además de tres copias de datos almacenados en la región donde se hospeda el servidor, el servicio replica los datos en una 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 copias de seguridad

El servidor conserva las copias de seguridad en función del período de retención establecido. Puede seleccionar un período de retención de entre 7 (valor predeterminado) y 35 días. Establezca el período de retención durante la creación del servidor o cámbielo más adelante. El servidor conserva las copias de seguridad incluso para los servidores detenidos.

El período de retención de copia de seguridad determina el período de tiempo para recuperar una restauración a un momento dado (PITR) de las copias de seguridad disponibles. También puede considerar el período de retención de copia de seguridad como una ventana de recuperación desde una perspectiva de restauración.

El almacenamiento de copia de seguridad conserva todas las copias de seguridad necesarias para realizar una PITR dentro del período de retención de copia de seguridad. Por ejemplo, si establece el período de retención de copia de seguridad en 7 días, la ventana de recuperación es los últimos 7 días. En este escenario, el almacenamiento de copia de seguridad conserva todos los datos y registros necesarios para restaurar y recuperar el servidor en los últimos 7 días.

Costo del almacenamiento de copia de seguridad

Azure Database for PostgreSQL proporciona hasta el 100 % del almacenamiento de servidor aprovisionado como almacenamiento de copia de seguridad sin costo adicional. Paga por cualquier almacenamiento de copia de seguridad adicional que use en gigabytes al mes.

Por ejemplo, si aprovisiona un servidor con 250 gibibytes (GiB) de almacenamiento, obtendrá 250 GiB de capacidad de almacenamiento de copia de seguridad sin cargo adicional. Si el uso diario de la copia de seguridad es de 25 GiB, puede tener hasta 10 días de almacenamiento de copia de seguridad gratuito. Se paga por el consumo de almacenamiento de copia de seguridad que supera los 250 GiB tal como se define en el modelo de precios.

Si configura 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 es el doble del tamaño de la copia de seguridad local. La facturación se calcula como ((2 x tamaño de copia de seguridad local): tamaño de almacenamiento aprovisionado) x precio @ gigabytes al mes.

Use la métrica Almacenamiento de copia de seguridad usado del portal de Azure para supervisar el almacenamiento de copia de seguridad consumido por un servidor. 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.

Restauración a un momento dado

En una instancia de 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 precios, generación de procesamiento, número de núcleos virtuales, tamaño de almacenamiento, período de retención de las copias de seguridad y opción de redundancia en las copias de seguridad.

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. La base de datos se recupera hasta las 10:00 am del 15 de agosto mediante la copia de seguridad del registro de transacciones del 14 de agosto de 11:00 p. m. al 15 de agosto de 10:00 a. m.

Para restaurar el servidor de bases de datos, consulte cualquiera de las siguientes opciones:

• Restauración al punto de restauración más reciente.
• Restaurar a un punto de restauración personalizado.
• Restaurar a una copia de seguridad completa (restauración rápida).
• Restauración a una región emparejada (restauración geográfica).

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.

Mediante 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 restaura el servidor al punto más reciente 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 última transacción confirmada con fines de prueba. También puede elegir otros días y horas.

• Punto de restauración rápido: esta opción restaura el servidor en el tiempo más rápido posible dentro del período de retención definido para su instancia de servidor flexible 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 completa de instantáneas. No requiere recuperación de registros, lo que hace que sea rápido. Seleccione una fecha y hora de copia de seguridad posterior al primer punto temporal de restauración para que la operación de restauración se complete correctamente.

El tiempo necesario para recuperarse mediante las opciones de punto de restauración más recientes y personalizados 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 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.

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 en Azure Portal, consulte Creación de una instancia de Azure Database for PostgreSQL.

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.

Al configurar el servidor 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. Ese período de espera 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, no está disponible el PITR de las copias de seguridad con redundancia geográfica.

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, puede cambiar las configuraciones de servidor que 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 del servidor —como el nivel de proceso, almacenamiento o precio (Burstable, de uso general u Optimizado para memoria)— durante la restauración geográfica.

Para obtener más información, consulte Restauración a una región emparejada (restauración geográfica).

Restauración y redes

Restauración a un momento dado

Si configura su servidor de origen con una red de acceso público, solo puede restaurarlo a una red de acceso público.

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

Restauración geográfica

Si configura su servidor de origen con una red de acceso público, solo puede restaurarlo a una red de acceso público. Además, debe aplicar reglas de firewall una vez completada la operación de restauración.

Si configura el servidor de origen con una red virtual de acceso privado , solo puede restaurar a otra red virtual, ya que 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, realice las siguientes tareas para que sus usuarios y aplicaciones vuelvan a estar operativos:

• Si el nuevo servidor reemplaza al servidor original, redirija 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.

• Los valores de todos los parámetros del servidor original no se aplican automáticamente al nuevo servidor. Asegúrese de volver a configurar todos los parámetros en el nuevo servidor según los requisitos de ese nuevo servidor.

• Asegúrese de que las reglas de firewall de nivel de servidor adecuadas, los puntos de conexión privados y las reglas de red virtual estén en vigor para las conexiones de usuario. Estas reglas no se copian del servidor original.

• Ajuste o modifique la capacidad de cómputo del servidor restaurado según sea necesario.

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

• Configure las alertas según corresponda.

• Si el servidor de origen desde el que restauró se configuró con alta disponibilidad y desea configurar el servidor restaurado con alta disponibilidad, siga estos pasos.

• Si el servidor de origen desde el que restauró se configuró con réplicas de lectura y desea configurar réplicas de lectura en el servidor restaurado, siga las instrucciones de Creación de una réplica de lectura.

Copia de seguridad a petición

La instancia de 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. Esta opción es ideal para escenarios como preparar una operación potencialmente arriesgada o realizar actualizaciones periódicas fuera de la programación de copia de seguridad habitual.

Realice copias de seguridad a petición además de las copias de seguridad automáticas programadas. La ventana de retención de copia de seguridad determina cuánto tiempo se conservan estas copias de seguridad. Puede eliminar copias de seguridad a petición en cualquier momento si ya no son necesarias. Para iniciar una copia de seguridad a petición, 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 copias de seguridad a petición. El servicio administra y conserva las copias de seguridad automatizadas para cumplir los requisitos de retención de copia de seguridad.

Para obtener más información, consulte Realización de copias de seguridad a petición.

Limitaciones

• El nivel de proceso del servidor Burstable no admite la característica de copia de seguridad bajo demanda.
• El nivel de almacenamiento SSDv2 no admite la característica de copia de seguridad a petición.
• Puede realizar hasta siete copias de seguridad a petición por instancia de servidor flexible. La ventana de retención de copia de seguridad determina cuánto tiempo se conservan estas copias de seguridad.

Retención a largo plazo

Azure Backup y Azure Database for PostgreSQL servicios proporcionan una solución de copia de seguridad a largo plazo de clase empresarial para Azure Database for PostgreSQL instancias de servidor flexibles que conservan las copias de seguridad durante hasta 10 años. Puede usar la retención a largo plazo (LTR) de forma independiente o junto con la solución de copia de seguridad automatizada que ofrece 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 a satisfacer 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:

• Copias de seguridad programadas y a petición, controladas por el cliente, a nivel individual de base de datos.
• 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 proporciona mayor flexibilidad para restaurar 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

• Pruebe la copia de seguridad y restauración de LTR inmediatamente después de la configuración para asegurarse de que cumplen sus requisitos empresariales.
• 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 puede seleccionar bases de datos individuales para la configuración de LTR.
• La copia de seguridad LTR no se admite en réplicas, pero puede realizarse en servidores primarios.
• El tamaño máximo de base de datos admitido para las copias de seguridad de retención a largo plazo (LTR) es de 1 TiB.
• Puede programar copias de seguridad ltR semanales, mensuales o anuales. Actualmente no se admite la programación de copia de seguridad diaria.
• Las copias de seguridad de LTR no admiten tablas que contengan una fila con una longitud BYTEA superior a 500 MB.
• Al restaurar roles para Microsoft Entra usuarios, asegúrese de que la autenticación de Microsoft Entra esté habilitada y de que haya iniciado sesión como administrador de Microsoft Entra para crear usuarios adicionales. Si se intenta crear roles de Entra como usuario normal, se producen errores.

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

Preguntas más frecuentes

Preguntas relacionadas con la copia de seguridad

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

  De forma predeterminada, Azure Database for PostgreSQL habilita las 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 siete 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, Azure Database for PostgreSQL admite un máximo de 35 días de retención. Use copias de seguridad manuales para un requisito de 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 tomar 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 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 instancia de servidor flexible de Azure Database for PostgreSQL, las copias de seguridad y los archivos temporales creados durante la ejecución de consultas se cifran a través del cifrado AES (Advanced Encryption Standard) de 256 bits. 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 base de datos única o de algunas bases de datos o tablas. Sin embargo, puede restaurar todo el servidor en un nuevo servidor y, a continuación, quitar tablas o bases de datos que no necesite en el 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?

  La instancia de 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.

  No puede exportar estos archivos de copia de seguridad, ya que se almacenan en cuentas de almacenamiento administradas Microsoft. Tiene acceso de solo lectura para restaurar estos archivos, pero no puede modificarlos ni eliminarlos. Los archivos de copia de seguridad se eliminan automáticamente después del período de retención.

  Puede utilizar copias de seguridad solo para restaurar el servidor a un momento dado. El período de retención predeterminado es siete 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?

  Al configurar el servidor con copia de seguridad con redundancia geográfica, los datos de 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 en una instancia de servidor flexible de Azure Database para PostgreSQL se respaldan mediante instantáneas incrementales de disco administrado del 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. El servicio conserva todas las copias de seguridad anteriores (dentro de la ventana de retención) en el momento de detener el servidor hasta que se reinicie 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 cobran y facturan mis copias de seguridad?

  Azure Database for PostgreSQL proporciona hasta el 100 % del almacenamiento de servidor aprovisionado como almacenamiento de copia de seguridad sin costo adicional. Paga por cualquier almacenamiento de copia de seguridad adicional que use, que se cobra 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 factura un servidor detenido?

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

  El almacenamiento de copia de seguridad gratuito se limita al tamaño de la base de datos aprovisionada. Usted paga por cualquier exceso de datos de copia de seguridad según el precio de copia de seguridad.

• He configurado mi servidor con alta disponibilidad redundante por 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, el servicio mantiene solo un conjunto de copias de seguridad. Solo pagas una vez.

Preguntas relacionadas con la restauración

• Cómo restaurar mi servidor?

  Azure admite la restauración a un momento dado para todos los servidores. Puede restaurar al punto de restauración más reciente o a un punto de restauración personalizado mediante el portal de Azure, el 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 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 un PITR? ¿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 para reproducir) puede variar, en función de la copia de seguridad anterior de la fecha y hora solicitadas y el número de registros que se van a procesar. Esta condición se aplica tanto a la restauración dentro de la misma zona como a la restauración de datos en 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, 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.

Contenido relacionado

• Restauración al punto de restauración más reciente.
• Restaurar a un punto de restauración personalizado.
• Restaurar a una copia de seguridad completa (restauración rápida).
• Restauración a una región emparejada (restauración geográfica).