Matriz de soporte para Azure PostgreSQL flexible server y copia de seguridad elástica en clúster (v2) (vista previa)

Azure Backup te permite proteger servidores flexibles y clústeres elásticos de Azure PostgreSQL con copias de seguridad físicas (instantáneas de disco). Este artículo resume las regiones, escenarios, configuraciones y limitaciones soportadas de la experiencia v2.

Regiones compatibles para Azure PostgreSQL flexible server y copia de seguridad elástica con clúster vaulted (v2)

Las copias de seguridad abovedadas están disponibles en todas las regiones públicas excepto Austria Este, Bélgica Central, Chile Central, Indonesia Central, Israel Noroeste, Malasia Sur, Malasia Oeste, México Central, Catar Central, Sur Central de EE. UU., Sureste de EE. UU., Sureste de EE. UU. 3, Sureste de EE. UU. 5, Suroeste de EE. UU. y Oeste de India.

Fuentes de datos y configuraciones compatibles para Azure PostgreSQL flexible server y copia de seguridad elástica con clúster vaulted (v2)

La siguiente tabla enumera las fuentes de datos y configuraciones soportadas para Azure PostgreSQL flexible server y copia de seguridad abovedada de clúster elástico (v2):

Escenarios de copia de seguridad compatibles para Azure PostgreSQL flexible server y copia de seguridad elástica con clúster (v2)

Azure PostgreSQL para servidores flexibles y copias de seguridad vaulted de clúster elástico (v2) admiten los siguientes escenarios de respaldo:

• Todo el servidor o clúster está respaldado. No se permite copia de seguridad de bases de datos individuales.
• Se soporta clúster elástico de hasta 8 nodos.
• La primera copia de seguridad de una fuente de datos es una copia de seguridad completa; cada copia de seguridad posterior es incremental. Azure Backup realiza una replicación inicial automáticamente si la cadena de instantáneas se rompe.
• Se soportan programas de respaldo diarios o semanales, con un objetivo mínimo de puntos de recuperación de un día.
• La retención puede establecerse desde 7 días hasta 10 años, con duraciones independientes para los puntos de recuperación diarios, semanales, mensuales y anuales.
• Se soportan copias de seguridad bajo demanda (ad hoc) después de configurar la protección.
• Se soporta una instancia de copia de seguridad por fuente de datos. No se soporta la protección múltiple del mismo servidor, así que un servidor está protegido ya sea por la pila v1 o por la pila v2, nunca por ambas.
• La política de respaldo asociada a una instancia de respaldo puede cambiarse una vez configurada la protección.
• Un trabajo de copia de seguridad se marca como Exitoso una vez que la instantánea gestionada del disco ha sido copiada al refugio.
• Los metadatos del punto de recuperación, incluida la versión de PostgreSQL en la que se realizó la copia de seguridad, son visibles en cada punto de recuperación.
• Se soportan copias de seguridad inmutables en WORM. Cuando la inmutabilidad está habilitada y bloqueada en la bóveda de respaldo, los puntos de recuperación no pueden ser alterados, sobrescritos ni eliminados antes de que expire su periodo de retención configurado, por ningún usuario, incluido un administrador de la bóveda.

Escenarios de restauración soportados para Azure PostgreSQL flexible server y copia de seguridad vaulted de clúster elástico (v2)

Azure PostgreSQL flexible server y elastic cluster vaulted backup (v2) admiten los siguientes escenarios de restauración:

• Las restauraciones se realizan como Restaurar como servidor en una ubicación alternativa. El servidor flexible objetivo o el clúster elástico debe crearse antes de que se active la restauración.
• Los datos en tablas no logadas no se conservan y se pierden al restaurarse.
• El objetivo puede estar en una suscripción diferente dentro del mismo inquilino.
• Se soporta la restauración entre regiones.
• No se garantiza que las operaciones de restauración de copias de seguridad realizadas en versiones de PostgreSQL que ya no son compatibles.
• La restauración se soporta incluso después de que la fuente de datos original haya sido eliminada.
• Un trabajo de restauración se marca como Exitoso solo cuando se ha restaurado todo el punto de recuperación.
• Un punto de recuperación tomado en un servidor SSD Premium v1 se restaura en un objetivo SSD Premium v1. Un punto de recuperación tomado en un servidor Premium SSD v2 se restaura en un objetivo Premium SSD v2.

Requisitos objetivo para la restauración

El servidor flexible objetivo o el clúster elástico deben cumplir todos los siguientes criterios, que Azure Backup valida antes de que comience la operación de restauración:

• El servidor o clúster debe estar vacío.
• El servidor o el clúster no deben estar en la capa de cómputo de Burstable.
• El servidor o clúster objetivo debe usar la misma versión principal de PostgreSQL que el servidor de origen cuando se hizo la copia de seguridad. La restauración falla si las versiones no coinciden.
• El servidor o clúster destino debe tener el mismo tamaño de disco que el servidor de origen. La restauración falla si el tamaño del disco destino es menor que el tamaño del disco original, aunque el punto de recuperación requiera menos espacio en el disco objetivo.
• El servidor o clúster no debe tener alta disponibilidad configurada.
• El servidor o clúster no debe tener configurada una geo-réplica, y no debe ser una geo-réplica.
• El servidor o clúster debe estar en la misma región que la bóveda de respaldo.

Limitaciones para Azure PostgreSQL flexible server y elastic cluster vaulted backup (v2)

La experiencia v2 tiene las siguientes limitaciones:

• No se soporta la copia de seguridad y restauración a nivel de objeto. No puedes hacer una copia de seguridad ni restaurar una base de datos, tabla u objeto individual.
• El nivel de computación Burstable no está soportado. Configurar la copia de seguridad en un servidor Burstable falla con un error de usuario. Escala el servidor primero a Propósito General o Optimizado en Memoria.
• PostgreSQL 14 y versiones anteriores no son compatibles. La configuración de copia de seguridad falla en los servidores que usan estas versiones. Debes actualizar a una versión mayor compatible antes de configurar la copia de seguridad, o seguir protegiendo el servidor con la v1.
• La copia de seguridad solo se soporta para servidores principales. No puedes configurar copias de seguridad para réplicas leídas o geo-réplicas. Si intentas configurar una copia de seguridad para una réplica, la operación falla con un error de usuario.
• El objetivo del punto de recuperación de un día (RPO) no está garantizado en todos los escenarios. La copia de seguridad inicial y la replicación inicial posterior transfieren todo el contenido del disco y pueden tardar más de un día en servidores y clústeres grandes. Las copias de seguridad también pueden superar un día para servidores con altas rotaciones diarias de datos o servidores que usan SSD Premium v2.
• Mover un objeto protegido de v1 a v2 es una vía. Para volver a la v1, detén la protección y reconfigura la copia de seguridad en la pila v1.
• La configuración de copia de seguridad no se aplica automáticamente al nuevo servidor principal tras una geo-conmutación por error planificada. La configuración de copia de seguridad existente permanece asociada con el servidor principal anterior, y sus copias comienzan a fallar tras el cambio de conmutación por error. Para proteger el nuevo servidor principal, configura la copia de seguridad en ese servidor.

Paso siguiente

• Acerca de Azure PostgreSQL flexible server y elastic cluster vaulted backup (v2) (vista previa).

Contenido relacionado

• Support matrix for Azure Database for PostgreSQL - Flexible Server (v1)..