Preguntas frecuentes: copia de seguridad de bases de datos de SAP HANA en máquinas virtuales de Azure

Puede tener una copia de seguridad completa programada y varias copias de seguridad a petición en un día.

Actualmente, los trabajos de copia de seguridad correctos no generan alertas. Solo se generan alertas para los trabajos de copia de seguridad con errores. Obtenga información sobre cómo usar Azure Portal para ver alertas de copias de seguridad.

Puede comprobar el estado de las copias de seguridad (programadas o a petición) desde cualquiera de las siguientes ubicaciones:

1. Trabajos de copia de seguridad: Azure Backup muestra todos los trabajos desencadenados manualmente en la sección "Trabajos de copia de seguridad" de Azure Portal.
   
   Los trabajos que ve en Azure Portal incluyen operaciones de detección y registro de bases de datos, y operaciones de copia de seguridad y restauración. Los trabajos programados, incluidas las copias de seguridad de registros, no se muestran en esta sección. Las copias de seguridad desencadenadas manualmente desde los clientes nativos de SAP HANA (Studio/Cockpit/DBA Cockpit) tampoco se muestran aquí.

   

   

2. Alertas de copia de seguridad: las alertas le ayudan a supervisar las copias de seguridad de las bases de datos de SAP HANA. De esta forma, puede centrarse en los eventos necesarios, lo que elimina el esfuerzo de comprobar con frecuencia la gran cantidad de eventos que genera una copia de seguridad. Para obtener más información, consulte Visualización de alertas de copia de seguridad.

3. Informes de copia de seguridad: los informes son otra manera de ver el estado de los trabajos de copia de seguridad. Los informes serán como los que se muestran a continuación:

   

   

   Obtenga más información sobre la configuración de informes de Azure Backup.

4. Clientes nativos de SAP HANA: si es un cliente SAP HANA, también puede usar HANA Studio, uno de los clientes de HANA más comunes. En este cliente, vaya a la Consola de copias de seguridad ->Catálogo de copias de seguridad para comprobar el Estado de copia de seguridad.

   

En el menú "Trabajos de copia de seguridad" solo se mostrarán los trabajos de copia de seguridad a petición que estén en curso, se hayan completado correctamente o hayan dado error. Para los trabajos programados, use Azure Monitor.

Azure Backup no establece un período de retención explícito en las copias de seguridad completas de recuperación automática. Esta copia de seguridad se conserva hasta el momento en que conserva las copias de seguridad delta dependientes (diferenciales o incrementales) y de registro. Una vez eliminada la última copia de seguridad dependiente de esta copia de seguridad de recuperación automática, también se elimina la copia de seguridad de recuperación automática.

Sí, una copia de seguridad completa y una copia de seguridad de registros se pueden ejecutar simultáneamente. Esta instancia se produce de una de las siguientes maneras:

• La copia de seguridad completa está en curso y se desencadena una copia de seguridad de registros: la copia de seguridad de registros debe realizarse correctamente independientemente de si existe una copia de seguridad completa en curso. A menos que la copia de seguridad completa que se desencadene fuera una corrección completa para controlar cualquier interrupción de la cadena LSN.
• La copia de seguridad de registros está en curso y se desencadena una copia de seguridad completa: ambas copias de seguridad deben ejecutarse simultáneamente y realizarse correctamente.

No, no se admite actualmente.

Si se elimina una base de datos de una instancia de SAP HANA, se siguen intentando las copias de seguridad de la base de datos. Esto implica que la base de datos eliminada comienza a aparecer como incorrecta en Elementos de copia de seguridad y todavía está protegida. La manera correcta de detener la protección de esta base de datos es realizar una acción Detener copia de seguridad con eliminación de datos en esta base de datos.

Una base de datos después de un cambio de nombre se trata como una nueva base de datos. Por lo tanto, el servicio trata esta situación como si no se encontrara la base de datos y producirá un error en las copias de seguridad. La base de datos cuyo nombre se ha cambiado aparecerá como una nueva base de datos y se debe configurar su protección.

En el tutorial encontrará una guía paso a paso para empezar a usar Azure Backup con bases de datos SAP HANA. También puede usar la CLI para configurar y administrar copias de seguridad.

Consulte los requisitos previos para usar Azure Backup con SAP HANA.

Consulte esta sección de la guía de solución de problemas.

Consulte esta sección en la guía de solución de problemas.

Actualmente no tenemos la posibilidad de configurar la solución con relación a una IP virtual o un proxy. Se necesita una máquina virtual para ejecutar la solución.

Puede desencadenar una copia de seguridad a petición mediante clientes nativos de SAP HANA en el sistema de archivos local en lugar de Backint. Obtenga más información sobre cómo administrar operaciones mediante clientes nativos de SAP.

Puede eliminar el catálogo de HANA mediante métodos recomendados de SAP, como instrucciones BACKUP CATALOG DELETE o HANA Studio/Cockpit. Obtenga más información sobre cómo administrar operaciones mediante clientes nativos de SAP.

Actualmente, Azure Backup no tiene la capacidad de comprender una configuración de HSR. Esto significa que los nodos principal y secundario del HSR se tratarán como dos máquinas virtuales individuales no relacionadas. Primero deberá configurar la copia de seguridad en el nodo principal. Cuando se produce una conmutación por error, se debe configurar la copia de seguridad en el nodo secundario (que ahora se convierte en el nodo principal). No hay ninguna conmutación errónea automática de la copia de seguridad en el otro nodo.

Para realizar una copia de seguridad de los datos del nodo activo (principal) en cualquier momento dado, puede cambiar la protección al nodo secundario que ahora se ha convertido en el principal después de la conmutación por error.

Para realizar este cambio de la protección, siga estos pasos:

• Detener la protección (con conservación de datos) en el nodo principal
• Ejecutar el script de registro previo en el nodo secundario
• Detectar las bases de datos en el nodo secundario y configurar las copias de seguridad en ellas

Estos pasos deben realizarse manualmente después de cada conmutación por error. Puede realizar estos pasos mediante la línea de comandos/REST de HTTP y en Azure Portal. Para automatizar estos pasos, puede usar un runbook de Azure.

Este es un ejemplo detallado de cómo se debe realizar la protección del conmutador:

En este ejemplo, tiene dos nodos: nodo 1 (principal) y nodo 2 (secundario) en la configuración del HSR. Las copias de seguridad se configuran en el nodo 1. Como se mencionó anteriormente, no intente configurar las copias de seguridad en el nodo 2.

Cuando se produce la primera conmutación por error, el nodo 2 se convierte en el principal. A continuación,

1. Detenga la protección del nodo 1 (principal anterior) con la opción de conservación de datos.
2. Ejecute el script de registro previo en el nodo 2 (que ahora es el principal).
3. Detecte bases de datos en el nodo 2, asigne directivas de copia de seguridad y configure copias de seguridad.

A continuación, se desencadena una primera copia de seguridad completa en el nodo 2 y, una vez completada, se inician las copias de seguridad de los registros.

Cuando se produce la siguiente conmutación por error, el nodo 1 vuelve a ser principal y el nodo 2 se convierte en secundario. Ahora repita el proceso:

1. Detenga la protección del nodo 2 con la opción de conservación de datos.
2. Ejecute el script de registro previo en el nodo 1 (que se ha convertido de nuevo en el principal).
3. A continuación, reanude la copia de seguridad en el nodo 1 con la directiva necesaria (ya que las copias de seguridad se detuvieron antes en el nodo 1).

A continuación, se desencadenará de nuevo una copia de seguridad completa en el nodo 1 y, una vez completada, se inician las copias de seguridad de los registros.

1. En el caso de la replicación del sistema HANA (HSR), el nodo secundario no acepta ninguna conexión. Una vez configurada la copia de seguridad, el servicio de Azure Backup hace ping periódicamente y produce un error. A veces estos intentos con errores se reflejan en el nodo principal. Después de varios errores, el usuario se bloquea y, a continuación, el nodo principal comienza a producir un error con ODBCConnectionError.
   
   Hemos observado que no todos los usuarios experimentan esta incidencia. Se recomienda que usted o SAP investiguen la causa del bloqueo de los usuarios en el nodo principal cuando se produce un error en la conexión del usuario del nodo secundario.

2. Una vez ejecutado el script de registro previo, la información del usuario se actualiza con una nueva contraseña en el nodo principal. A continuación, se volverá a establecer la conexión para intentar realizar la copia de seguridad. No obstante, es posible que vuelva a experimentar el mismo escenario.

3. Además, las copias de seguridad (copias de seguridad completas) que no se pueden realizar en el nodo secundario crean alertas.

Para evitar los problemas anteriores, se recomienda detener la protección de un nodo cuando se convierta en secundario (para que las conexiones no se intenten y el usuario no se bloquee) y reanudar la protección una vez que se convierta en principal. Si no se enfrenta a esta situación de bloqueo en sus configuraciones de HSR y se encuentra cómodo con las alertas que se están generando, puede configurar las copias de seguridad en ambos nodos para que el servicio administre la toma de control y la conmutación por recuperación.

Consulte el rendimiento de las copias de seguridad y restauraciones que ofrece Azure Backup para las cargas de trabajo de HANA.

Para configurar el sistema HANA a fin de aprovechar el rendimiento mejorado, use los siguientes recursos:

• Selección de un tipo de disco para máquinas virtuales IaaS de Azure: discos administrados
• Niveles de rendimiento de discos administrados de Azure
• Serie M
• Configuraciones de almacenamiento de máquinas virtuales de Azure en SAP HANA

Actualmente, Azure Backup para SAP HANA acepta 1 como valor de la propiedad parallel_backup_using_backint. Sin embargo, Azure Backup divide esa secuencia única en varias secuencias para mejorar el rendimiento.

Actualmente, solo se admiten copias de seguridad basadas en Backint para HSR. Las instantáneas aún no están.

Debe ejecutar la nueva detección de la instancia en el servidor marcado como "No listo" para actualizar su estado.

Puede realizar un máximo de 10 restauraciones por sistema o instancia de HANA en un día. Tenga en cuenta que si una restauración se cancela o produce un error, también se considera un intento de restauración.

Compruebe si se cumplen todos los requisitos previos para la restauración en la instancia de SAP HANA de destino. Para más información, consulte Requisitos previos: restauración de bases de datos de SAP HANA en máquinas virtuales de Azure.

Asegúrese de que la opción Forzar sobrescritura está seleccionada durante la restauración.

Consulte la Nota 1642148 de SAP HANA para ver qué tipos de restauración se admiten actualmente.

Sí, puede usar las copias de seguridad de streaming desencadenadas en una base de datos de HANA que se ejecuta en SLES para restaurarla en un sistema RHEL HANA y viceversa. Es decir, la restauración entre sistemas operativos es posible mediante copias de seguridad de streaming. Sin embargo, tendrá que asegurarse de que el sistema HANA en el que desea realizar la restauración y el sistema HANA que usará para la restauración sean compatibles con la restauración de acuerdo con SAP. Consulte la nota 1642148 de SAP HANA para ver qué tipos de restauración son compatibles.

Sí, puede descargar archivos parcialmente como se documenta aquí.

Sí, debe deshabilitar la replicación del sistema de HANA (HSR) en el sistema de destino y, a continuación, realizar la restauración. No se puede restaurar un sistema habilitado para HSR, según SAP.

Antes de crear una directiva, debe tener claros los requisitos de RPO y RTO, así como sus costos asociados pertinentes.

El RPO (objetivo de punto de recuperación) indica cuánta pérdida de datos es aceptable para el usuario o el cliente. Esto lo determina la frecuencia de copia de seguridad de registros. Las copias de seguridad de registros más frecuentes indican un RPO inferior, y el valor mínimo admitido por el servicio Azure Backup es de 15 minutos. Por lo tanto, la frecuencia de copia de seguridad de registros puede ser de 15 minutos o más.

El RTO (objetivo de punto de recuperación) indica la rapidez con la que se deben restaurar los datos al último momento disponible después de un escenario de pérdida de datos. Esto depende de la estrategia de recuperación empleada por HANA, que suele depender del número de archivos necesarios para la restauración. Esto también genera costos asociados, y la tabla siguiente debería ayudarle a comprender todos los escenarios y sus implicaciones.

Por lo tanto, puede seleccionar la variante de directiva en función de los objetivos de RPO y RTO y las consideraciones de costos.

Deben tenerse en cuenta algunos principios a la hora de determinar el impacto de cambiar la directiva de un elemento de copia de seguridad de la directiva 1 (P1) a la directiva 2 (P2), o de la directiva de edición 1 (P1).

• Todos los cambios también se aplican de forma retroactiva. La directiva de copia de seguridad más reciente se aplica también a los puntos de recuperación que se realizaron anteriormente. Por ejemplo, supongamos que la retención completa diaria es de 30 días y que se realizaron 10 puntos de recuperación según la directiva activa actualmente. Si la retención diaria completa se cambia a 10 días, la hora de expiración del punto anterior también se vuelve a calcular como la hora de inicio + 10 días, y se elimina si ha expirado.
• El ámbito del cambio también incluye el día de la copia de seguridad y el tipo de copia de seguridad junto con la retención. Por ejemplo: Si se cambia una directiva de completa diaria a completa semanal todos los domingos, todas las copias completas anteriores no realizadas en domingo se marcarán para su eliminación.
• No se elimina un elemento primario hasta que el elemento secundario está activo o no haya expirado. Cada tipo de copia de seguridad tiene una hora de expiración de acuerdo con la directiva activa actualmente. Sin embargo, un tipo de copia de seguridad completa se considera como primario para las copias "diferenciales", "incrementales" y los "registros" posteriores. Una copia "diferencial" y un "registro" no son elementos primarios de ningún otro. Una copia "incremental" puede ser un elemento primario de la copia "incremental" posterior. Incluso si un elemento "primario" está marcado para su eliminación, no se elimina realmente si las copias "diferenciales" o los "registros" secundarios no han expirado. Por ejemplo, si se cambia una directiva de completa diaria a completa semanal todos los domingos, todas las copias completas anteriores no realizadas en domingo se marcarán para su eliminación. Sin embargo, no se eliminan realmente hasta que no expiran los registros diarios realizados anteriormente. En otras palabras, se conservan en función de la duración del último registro. Una vez que expiren los registros, se eliminarán los registros y las copias completas.

Con estos principios, puede leer la siguiente tabla para comprender las implicaciones de un cambio de directiva.

Puede administrar el espacio en la carpeta raíz mediante una de las opciones siguientes:

• Cree un LV propio para /opt/msawb.
• Cree un vínculo / simbólico a otra ubicación o carpeta en el mismo disco o en otro diferente.
• Aumente el espacio en la partición raíz.

Pasos siguientes

• Obtenga información sobre cómo hacer copias de seguridad de bases de datos de SAP HANA que se ejecutan en máquinas virtuales de Azure.
• Aprenda a Solucionar problemas de copia de seguridad de bases de datos de SAP HANA.