Recuperación ante desastres

AccessPoint se ejecuta por completo en su suscripción de Azure. La planificación de la recuperación ante desastres aprovecha las capacidades de redundancia y recuperación integradas de Azure. El publicador no conserva ningún dato de cliente, por lo que la recuperación está totalmente bajo su control.

Objetivos de recuperación

Copia de seguridad y recuperación

Base de datos

• Restauración a un momento dado (PITR): Automática, hasta 35 días. No requiere configuración manual.
• Retención a largo plazo (LTR): Configure copias de seguridad semanales, mensuales o anuales para el cumplimiento normativo. Configúrela mediante Portal de Azure > SQL Database > Copias de seguridad > Directivas de retención.
• Copia de seguridad con redundancia geográfica: Habilitada de forma predeterminada en los niveles Standard y Premium. Permite la restauración en una región de Azure emparejada en caso de una interrupción regional.

Blob Storage

• Eliminación temporal: Habilite la eliminación temporal de blobs y contenedores para recuperar documentos eliminados accidentalmente. Retención recomendada: 30 días.
• Control de versiones: Habilite el control de versiones de blobs para mantener versiones anteriores de documentos sobrescritos.

Configuración

Exporte o documente sus paquetes de configuración antes de realizar cambios importantes. Si es necesario revertir un cambio de configuración, la única opción es restaurar desde una copia de seguridad de la base de datos.

Procedimientos de reversión

Reversión de la API

La API se implementa como un paquete zip en Azure App Service. Para revertir a una implementación anterior:

1. Abra el Portal de Azure y vaya a su App Service
2. Vaya a Centro de implementación > Historial de implementación
3. Localice la implementación correcta anterior
4. Selecciónela y haga clic en Volver a implementar
5. Compruebe que la aplicación funciona correctamente

Si usa espacios de implementación, vuelva a intercambiar al espacio anterior mediante Espacios de implementación > Intercambiar.

Reversión de la base de datos

Las implementaciones de DacPac son aditivas de forma predeterminada: se agregan nuevas columnas y tablas, pero no se eliminan los objetos existentes. Esto proporciona una red de seguridad para la mayoría de los cambios de esquema.

Para problemas de datos (datos dañados o incorrectos), use la restauración a un momento dado de Azure SQL:

1. Restaure la base de datos a un momento anterior a que ocurriera el problema
2. Compruebe el contenido de la base de datos restaurada
3. Actualice la cadena de conexión del App Service para que apunte a la base de datos restaurada, o cambie el nombre de las bases de datos para intercambiarlas

Reversión de SPFx

Para revertir el elemento web SPFx a una versión anterior:

1. Descargue el paquete .sppkg de la versión anterior desde el portal de Realizer
2. Abra el catálogo de aplicaciones de SharePoint
3. Cargue el paquete anterior, reemplazando la versión actual
4. Haga clic en Implementar

Reversión de la configuración

Los paquetes de configuración son aditivos: importar un paquete agrega o actualiza elementos, pero no elimina los existentes. Para revertir los cambios de configuración, restaure la base de datos desde una copia de seguridad a un momento dado tomada antes del cambio.

Escenarios de recuperación ante desastres

Escenario 1: Eliminación accidental de datos

1. Documentos eliminados de Blob Storage: Si la eliminación temporal está habilitada, recupere los blobs dentro de la ventana de retención configurada
2. Registros de base de datos eliminados: Use la restauración a un momento dado de Azure SQL al instante anterior a la eliminación. Copie los registros necesarios de la base de datos restaurada a producción.

Escenario 2: Interrupción de una región de Azure

Si la región de Azure que aloja su implementación deja de estar disponible:

1. Azure SQL: Restaure desde copias de seguridad con redundancia geográfica en un nuevo SQL Server en una región diferente
2. Blob Storage: Si usa almacenamiento con redundancia geográfica (GRS o RA-GRS), inicie una conmutación por error de la cuenta. Si usa almacenamiento con redundancia local (LRS), los datos deben restaurarse desde una copia de seguridad externa.
3. App Service: Vuelva a implementar usando la plantilla Bicep en la región de recuperación
4. DNS y URL de la API: Actualice la entidad de almacenamiento de la URL de la API de AccessPoint en SharePoint para que apunte a la nueva URL del App Service

Escenario 3: Reconstrucción completa del entorno

Todo el entorno de AccessPoint se puede reconstruir desde cero usando los artefactos de implementación publicados:

1. Ejecute la plantilla Bicep para aprovisionar todos los recursos de Azure
2. Implemente el zip de la API en el App Service (incluido en la implementación de ARM)
3. El esquema de la base de datos se implementa automáticamente en el primer inicio de la API
4. Cargue el .sppkg de SPFx en el catálogo de aplicaciones de SharePoint
5. Ejecute Deploy-AccessPoint.ps1 para configurar la autenticación SQL solo con Entra y los permisos de Graph
6. Restaure la base de datos desde la copia de seguridad más reciente para recuperar los datos
7. Restaure los documentos de Blob Storage desde las copias de seguridad con redundancia geográfica

La infraestructura como código (plantillas Bicep) y el script de implementación garantizan que el entorno sea totalmente reproducible.

Recomendaciones de planificación

• Habilite el almacenamiento con redundancia geográfica (GRS) en la cuenta de Blob Storage para la redundancia de documentos entre regiones
• Habilite la retención a largo plazo (LTR) en Azure SQL para copias de seguridad semanales, mensuales y anuales más allá de la ventana PITR predeterminada
• Habilite la eliminación temporal en Blob Storage con un período de retención de 30 días
• Habilite el control de versiones de blobs para recuperar documentos sobrescritos
• Documente sus parámetros de implementación: mantenga un registro del nombre de su inquilino, el grupo de recursos, el correo electrónico de alertas y cualquier configuración personalizada del App Service para poder volver a implementar rápidamente
• Pruebe la recuperación anualmente: restaure la base de datos y Blob Storage en un entorno de prueba para comprobar que sus copias de seguridad funcionan
• Considere Azure Front Door o Traffic Manager si su organización requiere una conmutación por error automática con un tiempo de inactividad mínimo

Supervisión del estado

AccessPoint expone dos puntos de conexión de comprobación de estado:

Métricas clave que supervisar

Escalado

Escalado vertical (escalar verticalmente)

Cambie el nivel del plan de App Service en Portal de Azure > App Service > Escalar verticalmente (plan de App Service). No se requiere volver a implementar.

Escalado horizontal (escalar horizontalmente)

La API de AccessPoint no tiene estado y admite varias instancias. Configure el escalado manual o automático en Portal de Azure > App Service > Escalar horizontalmente (plan de App Service).

Escalado de SQL

Ajuste el nivel de la base de datos según la carga de trabajo. Objetivos de servicio comunes: Basic, S0, S1, S2, S3, P1, P2.

Rotación de certificados y secretos