Matriz de asistencia: servicio de copia de seguridad y recuperación tras desastres

Política de fin de la vida útil del servicio de copia de seguridad y recuperación tras fallos

La política de fin de la vida útil del servicio de copia de seguridad y recuperación tras fallos ("EOSL") cubre el proceso y los detalles relacionados con el fin de la asistencia del servicio de copia de seguridad y recuperación tras fallos para sistemas y software de terceros, así como para software y hardware de copia de seguridad y recuperación tras fallos.

El hardware y el software de terceros incluyen plataformas de hardware, sistemas operativos y software de aplicaciones protegidos por dispositivos de copia de seguridad o recuperación. Cuando un proveedor anuncie que la configuración de hardware, sistema operativo o software de aplicación de terceros ha llegado al final de su ciclo de vida, la asistencia de Backup and DR para dichas configuraciones se limitará a la asistencia comercialmente razonable.

Backup and DR no publicará más correcciones ni actualizaciones para admitir sistemas de software y hardware que hayan superado el fin del periodo de asistencia de sus respectivos proveedores.

Protocolos de red admitidos

La copia de seguridad y la recuperación ante desastres admiten la transferencia de datos a través de:

  • Dispositivo de bloque de red (NBD): este modo de transporte se usa para crear copias de seguridad de máquinas virtuales de VMware Engine de Google Cloud.

  • NFS: Copia de seguridad y recuperación tras fallos admite NFS V3 (solo) para capturar y presentar datos en las siguientes configuraciones de implementación:

    • Presentar copias de seguridad a hosts de VMware Engine de Google Cloud mediante un almacén de datos NFS

    • Presentar un disco de almacenamiento provisional para la captura de datos basada en agentes en una máquina virtual de Compute Engine o VMware Engine de Google Cloud

Entornos compatibles con las copias de seguridad

El agente se admite en estos entornos.

Copias de seguridad basadas en agentes

El agente de copia de seguridad y recuperación tras fallos puede crear copias de seguridad y recuperar bases de datos y sistemas de archivos compatibles de los sistemas operativos Microsoft Windows y Linux compatibles en los siguientes entornos.

Tipo de aplicación Ejecutar en instancias de Compute Engine Ejecutar en VMs de VMware Engine de Google Cloud
Bases de datos
Sistemas de archivos

Copias de seguridad sin agentes

El servicio de copia de seguridad y recuperación ante desastres admite copias de seguridad de máquinas virtuales en los siguientes entornos sin necesidad de un agente en la máquina virtual:

  • Instancias de Compute Engine y Cloud SQL (aprovecha las APIs de instantáneas de discos persistentes)
  • Bases de datos SAP HANA e IBM Db2 de las que se han creado copias de seguridad en discos persistentes
  • Máquinas virtuales de VMware Engine de Google Cloud (aprovecha las APIs de almacenamiento de VMware vSphere - Protección de datos, antes conocidas como APIs de vStorage para la protección de datos o VADP)

Compatibilidad con el almacenamiento de objetos de OnVault

OnVault admite el siguiente almacenamiento: Google Cloud

  • Standard Storage
  • Nearline Storage
  • Coldline Storage
  • Almacenamiento de archivado

Virtualización de datos de aplicaciones con el agente de copia de seguridad y recuperación tras fallos

El agente de Backup y DR (también conocido como conector) es un archivo ejecutable ligero que ofrece las siguientes funciones avanzadas durante los procesos de captura y recuperación de datos.

  • Detección de aplicaciones: el agente de Backup and DR permite detectar en profundidad las bases de datos y los sistemas de archivos configurados en un host de producción.

  • Integración de APIs: cuando es posible, los agentes de Backup y DR se integran con las APIs o los comandos específicos de la aplicación para capturar los datos de la aplicación de forma eficiente.

  • Cambiar el seguimiento de bloques: en situaciones en las que las aplicaciones de producción no tienen un seguimiento de bloques de cambios integrado, Backup and DR introduce el seguimiento de bloques de cambios en determinadas plataformas.

  • Recuperación o montaje con Application Awareness: los agentes de Backup y DR tienen Application Awareness integrada. El agente de copia de seguridad y recuperación ante desastres te permite crear instancias utilizables de aplicaciones durante las operaciones de montaje de recuperación, lo que elimina la necesidad de realizar acciones manuales con secuencias de comandos después del montaje.

  • Framework de captura de datos de aplicaciones genéricas (LVM): los agentes de copia de seguridad y recuperación tras fallos proporcionan un framework genérico para capturar datos de cualquier aplicación que se ejecute en sistemas operativos Linux compatibles. Este framework proporciona hooks para llamar a secuencias de comandos personalizadas con el fin de conseguir una captura de datos coherente de la aplicación y una instanciación de la aplicación a partir de los datos de la copia de seguridad.

Soporte de Microsoft Windows Server

El agente de Backup and DR es compatible con los siguientes sistemas operativos Microsoft Windows.

Versión del sistema operativo Asistencia básica para agentes de Backup y DR Compatibilidad con el seguimiento de bloques modificados en SQL Server
Windows Server 2025 Datacenter
Windows Server 2025 Datacenter Core
Windows Server 2022 Datacenter
Windows Server 2022 Datacenter Core
Windows Server 2019 Datacenter
Windows Server 2019 Datacenter Core
Windows Server 2016 Datacenter
Windows Server 2016 Datacenter Core

Asistencia para sistemas operativos Linux

El agente de copias de seguridad y recuperación ante desastres es compatible con los siguientes sistemas operativos Linux (x86).

La asistencia básica incluye la compatibilidad con sistemas de archivos y bases de datos de Oracle.

La compatibilidad con el seguimiento de bloques modificados (CBT) incluye la función de copia de seguridad incremental permanente para otras bases de datos.

SO Versión Asistencia básica para agentes de Backup y DR Compatibilidad con el seguimiento de bloques modificados Versión mínima requerida del agente de copia de seguridad y recuperación tras fallos
RHEL1,4 8.4 V11.0.1
8,5 V11.0.1
8.6 V11.0.4
8.7 V11.0.5
8.8 No V11.0.8
8.9 No V11.0.9
8.10 No V11.0.15
9,0 No V11.0.4
9.2 No V11.0.8
9.4 No V11.0.15
9.5 No V11.0.15
RHEL para SAP 1 8.4 V11.0.1
8.6 V11.0.4
8.8 No V11.0.8
9,0 No V11.0.8
9.2 No V11.0.8
9.4 No V11.0.15
SLES 1, 3 12 SP5 V11.0.1
15 SP2 V11.0.1
15 SP3 V11.0.1
15 SP4 V11.0.4
15 SP5 V11.0.9
15 SP6 V11.0.13
SLES para SAP 1, 3 12 SP5 V11.0.1
15 SP2 V11.0.1
15 SP3 V11.0.1
15 SP4 V11.0.4
15 SP5 V11.0.9
Rocky Linux 9.3 No V11.0.9
Rocky Linux optimizado para Google Cloud 9.3 No V11.0.9
Ubuntu 20.04 LTS No V11.0.1
22.04 LTS No V11.0.1
Oracle Linux 1, 2 7,0-7,6 No V11.0.1
7,7 No V11.0.1
7,8 No V11.0.1
7,9 No V11.0.1
8,0-8,1 No V11.0.1
8.2 No V11.0.1
8,3 No V11.0.1
8.4 No V11.0.1
8,5 No V11.0.1
8.6 No V11.0.1
8.7 No V11.0.4
8,85 No V11.0.8
9,0 No V11.0.4
9.15 No V11.0.8
9,25 No V11.0.8

1 NO se admite la función de rutas múltiples dinámicas (DMP) de Symantec (Veritas).

2 Solo se admite en máquinas virtuales de VMware Engine de Google Cloud y no en instancias o máquinas virtuales de Compute Engine.

3 Durante la actualización "sin conexión" de SuSE (actualización desde ISO), el instalador de SuSE no ejecuta una reconfiguración en paquetes externos, incluidos el módulo CBT y DLKM. Por lo tanto, cuando el sistema se inicia con el kernel actualizado, el dlkm no se puede cargar porque los archivos de configuración antiguos siguen apuntando al módulo del kernel anterior. No se admite la actualización del SO desde ISO.

4 El servicio de Backup y DR no es compatible con RHEL HA.

5 Compatible con las versiones de Red Hat Compatible Kernel (RHCK) y Unbreakable Enterprise Kernel (UEK).

Consulta la lista de kernels compatibles.

Microsoft SQL Server

Las versiones 1.0.1 y posteriores de los agentes de copias de seguridad y recuperación ante desastres admiten la captura de datos coherentes de bases de datos (snapshots) de Microsoft SQL Server.

Versión de SQL Server Versión de Windows Server
SQL Server 2022 (independiente) Windows Server 2025
Windows Server 2022
Windows Server 2019
Windows Server 2016
SQL Server 2022 Web Windows Server 2025 Datacenter
Windows Server 2022 Datacenter
Windows Server 2019 Datacenter
SQL Server 2022 Standard Windows Server 2025 Datacenter
Windows Server 2022 Datacenter
Windows Server 2019 Datacenter
SQL Server 2022 Enterprise Windows Server 2025 Datacenter
Windows Server 2022 Datacenter
Windows Server 2019 Datacenter
SQL Server 2019 Web Windows Server 2025 Datacenter
Windows Server 2022 Datacenter
SQL Server 2019 Standalone Windows Server 2025
SQL Server 2019 Standard Windows Server 2025 Datacenter
Windows Server 2022 Datacenter
Windows Server 2019 Datacenter
SQL Server 2019 Enterprise Windows Server 2025 Datacenter
Windows Server 2022 Datacenter
Windows Server 2019 Datacenter
SQL Server 2017 Standalone Windows Server 2025
SQL Server 2017 Web Windows Server 2025 Datacenter
Windows Server 2022 Datacenter
SQL Server 2016 Web Windows Server 2025 Datacenter
Windows Server 2022 Datacenter

IBM Db2

El servicio de copia de seguridad y recuperación tras fallos admite los siguientes métodos de captura de datos:

  • Db2 en Linux se puede capturar a nivel de volumen de forma incremental para siempre con acceso instantáneo y creación de clones virtuales para la gestión de datos de prueba (TDM). Esta opción aprovecha las funciones de LVM de Linux y de seguimiento de bloques modificados de Backup and DR, y es la alternativa recomendada.

  • En el caso de los clientes que no usen LVM o que no puedan usar la captura a nivel de volumen, se puede capturar Db2 en Linux mediante una copia de seguridad completa e incremental. Para ello, se usa la copia de seguridad basada en volcado de la base de datos.

Versiones compatibles de IBM Db2 Sistemas operativos compatibles Versión mínima requerida del agente de copia de seguridad y recuperación tras fallos
10.5 SLES 12 V11.0.1
11.1.0 SLES 12 V11.0.1
11.5.0 SLES 12 V11.0.1
11.5.8.0 RHEL 8.x
SLES 12 y 15
V11.0.4

MariaDB

El servicio de copia de seguridad y recuperación tras fallos admite los siguientes métodos de captura de datos:

  • MariaDB en Linux se puede capturar a nivel de volumen de forma incremental para siempre con acceso instantáneo y creación de clones virtuales para TDM. Esta opción aprovecha las funciones de LVM de Linux y de seguimiento de bloques modificados de Backup and DR, y es la alternativa recomendada.

  • En el caso de los clientes que no usen LVM o que no puedan usar la captura a nivel de volumen, se puede capturar MariaDB en Linux mediante una copia de seguridad completa e incremental. Para ello, se usa la copia de seguridad basada en volcado de la base de datos y, normalmente, se ejecuta como una copia completa semanal y una incremental diaria. La recuperación implica reconstruir los incrementales sobre la última copia de seguridad completa.

Versiones compatibles de MariaDB Sistemas operativos compatibles Versión mínima requerida del agente de copia de seguridad y recuperación tras fallos
10.3.9 RHEL 8.1-8.5 V11.0.1
10.4 RHEL 8.1-8.5 V11.0.1
10.5 RHEL 8.1-8.5 V11.0.1
RHEL 8.6 V11.0.4
RHEL 8.7 V11.0.5
10.11 RHEL 8.1-8.5 V11.0.1
RHEL 8.6 V11.0.4
RHEL 8.7 V11.0.5

MySQL

El servicio de copia de seguridad y recuperación tras fallos admite los siguientes métodos de captura de datos:

  • MySQL en Linux se puede capturar a nivel de volumen de forma incremental para siempre con acceso instantáneo y creación de clones virtuales para TDM. Esta opción aprovecha las funciones de LVM de Linux y de seguimiento de bloques modificados de Backup and DR, y es la alternativa recomendada.

  • Los clientes que no usen LVM o que no puedan usar la captura a nivel de volumen pueden capturar MySQL en Linux mediante una copia de seguridad completa e incremental. Este método usa la copia de seguridad basada en volcado de la base de datos y, por lo general, se ejecuta como una copia completa semanal y una incremental diaria. La recuperación implica reconstruir los incrementales sobre la copia de seguridad completa más reciente.

Versiones de MySQL compatibles Sistemas operativos compatibles Versión mínima requerida del agente de copia de seguridad y recuperación tras fallos
5,7 RHEL 8.1-8.5 V11.0.1
8.x RHEL 8.1-8.5 V11.0.1
RHEL 8.6 V11.0.4
RHEL 8.7 V11.0.5

Oracle

Los agentes de copia de seguridad y recuperación tras fallos permiten capturar datos coherentes de bases de datos Oracle. Oracle debe ejecutarse en el modo ARCHIVELOG. La captura de datos admite la captura de datos en discos de almacenamiento provisional formateados como sistemas de archivos o presentados como destinos de grupos de discos de ASM.

La protección de bases de datos de Oracle es la misma para las bases de datos que se ejecutan en servidores de la solución Bare Metal o en una instancia de Compute Engine.

Los datos también se pueden obtener de configuraciones de Oracle Non Active Data Guard y Active Data Guard.

Familia Oracle Tipos de configuración Sistemas operativos compatibles Versión mínima requerida del agente de copia de seguridad y recuperación tras fallos
Oracle 21c
Todas las versiones
Independiente RHEL 8.4
Rocky Linux 8.7
Windows 2016 y 2019
V11.0.7
RAC RHEL 8.4
Rocky Linux 8.7
Windows 2016 y 2019
V11.0.7
Exadata 1 RHEL 8.4
Rocky Linux 8.7
Windows 2016 y 2019
V11.0.7
Non Active Data Guard 2 RHEL 8.4
Rocky Linux 8.7
Windows 2016 y 2019
V11.0.7
Active Data Guard 2 RHEL 8.4
Rocky Linux 8.7
Windows 2016 y 2019
V11.0.7
Oracle 19c 3
Todas las versiones
Independiente OEL 7.x, 8.x y 9.0
RHEL 8.x y SLES 12 y 15
Windows 2016 y 2019
RHEL 8.10 con kernel 4.18.0-553.40.1
RHEL 9.5 con kernel 5.14.0-503.23.1
V11.0.1


V11.0.15
Rocky Linux 8.7 V11.0.7
RAC OEL 7.x, 8.x y 9.0
RHEL 8.x
SLES 12 y 15
Windows 2016 y 2019
V11.0.1
Rocky Linux 8.7 V11.0.7
Exadata 1 OEL 7.x, 8.x y 9.0
RHEL 8.x
SLES 12 y 15
Windows 2016 y 2019
V11.0.1
Rocky Linux 8.7 V11.0.7
Non Active Data Guard 2 OEL 7.x, 8.x y 9.0
RHEL 8.x
SLES 12 y 15
Windows 2016 y 2019
V11.0.1
Rocky Linux 8.7 V11.0.7
Active Data Guard 2 OEL 7.x, 8.x y 9.0
RHEL 8.x
SLES 12 y 15
Windows 2016 y 2019
V11.0.1
Rocky Linux 8.7 V11.0.7
Oracle 18c 3
Todas las versiones
Independiente OEL 7.x, 8.x y 9.0
RHEL 8.x
SLES 12 y 15
Windows 2016 y 2019
V11.0.1
RAC OEL 7.x, 8.x y 9.0
RHEL 8.x
SLES 12 y 15
Windows 2016 y 2019
V11.0.1
Exadata 1 OEL 7.x, 8.x y 9.0
RHEL 8.x
SLES 12 y 15
Windows 2016 y 2019
V11.0.1
Non Active Data Guard 2 OEL 7.x, 8.x y 9.0
RHEL 8.x
SLES 12 y 15
Windows 2016 y 2019
V11.0.1
Active Data Guard 3 OEL 7.x, 8.x y 9.0
RHEL 8.x
SLES 12 y 15
Windows 2016 y 2019
V11.0.1

1 El sistema Oracle Exadata es compatible con iSCSI y NFS

2 El seguimiento de bloques modificados de RMAN de la base de datos Oracle solo está disponible en Active Data Guard

3 La captura de datos de Oracle 18c y versiones posteriores se realiza a nivel de contenedor (incluidas todas las PDBs). El montaje de aplicaciones en un destino se realiza a nivel de contenedor. Se pueden añadir PDBs virtuales a un contenedor que ya exista mediante secuencias de comandos personalizadas.

Métodos de captura y presentación de datos admitidos

El servicio de copia de seguridad y recuperación ante desastres admite varios métodos de captura y presentación para bases de datos Oracle en diferentes configuraciones. Esto incluye las operaciones de copia de seguridad, recuperación y montaje de bases de datos Oracle con TDE (cifrado de datos transparente) que tienen en cuenta las aplicaciones. En las bases de datos de Oracle con TDE, la cartera de TDE se puede obtener configurando la ubicación del archivo de configuración de Oracle en la configuración avanzada de la aplicación Oracle. Para las bases de datos con TDE habilitado, se requiere que la cartera se copie en la ubicación adecuada del host de montaje.

También ten en cuenta que dNFS con Oracle es compatible con sistemas operativos Linux.

Configuración de la base de datos de producción Formato de captura1 Formato de presentación
Archivos de base de datos en ASM o RAC Sistema de archivos (dispositivo de bloque) Sistema de archivos independiente
Sistema de archivos (NFS) Sistema de archivos independiente (NFS)
Sistema de archivos (NFS) Sistema de archivos RAC (NFS)
Grupo de discos ASM 3, 5 ASM independiente
Grupo de discos ASM 3, 5 ASM RAC (uno o varios nodos)
Archivos de base de datos en el sistema de archivos Sistema de archivos (dispositivo de bloque) Sistema de archivos independiente
Sistema de archivos (NFS) Sistema de archivos independiente (NFS)
Grupo de discos de ASM 3, 4 y 5 ASM independiente
Grupo de discos de ASM 3, 4 y 5 ASM RAC (uno o varios nodos)

1 El formato de captura es el formato resultante de la copia gestionada por Backup y DR.

3 La captura de ASM a ASM y la presentación de copias de seguridad en formato ASM no son compatibles con los sistemas operativos Windows

4 Se requiere una instancia de ASM de Oracle en el sistema de origen para este método de captura

5 No se admite la combinación de disco ASM (formato de captura) cuando los datos se capturan a través de NFS

Formatos de captura de datos admitidos Usar el sistema de archivos Usar un grupo de discos de ASM
Asistencia para copias de seguridad Datos de HCC o no HCC
Recuperación de Oracle con RMAN HCC o no HCC
Soporte con detección de aplicaciones 1 De Exadata a un sistema que no es Exadata

1 Para acceder a los datos de copias virtuales de datos comprimidos con HCC, estos deben descomprimirse antes de acceder.

Compatibilidad con Oracle Exadata

El servicio de copias de seguridad y recuperación ante desastres admite las siguientes configuraciones de Oracle Exadata.

  • Versiones de Exadata Database Machine: X4 y posteriores

  • Versiones de Oracle: 18c y 19c

PostgreSQL

El servicio de copia de seguridad y recuperación tras fallos admite los siguientes métodos de captura de datos:

  • PostgreSQL en Linux se puede capturar a nivel de volumen de forma incremental para siempre, con acceso instantáneo y creación de clones virtuales para TDM. Esta opción aprovecha las funciones de LVM de Linux y de seguimiento de bloques modificados de Backup and DR, y es la alternativa recomendada.

  • En el caso de los clientes que no usen LVM o que no puedan usar la captura a nivel de volumen, se puede capturar PostgreSQL en Linux mediante una copia de seguridad completa e incremental. Para ello, se usa el comando "pg_dump" de la base de datos, que no admite copias de seguridad incrementales, por lo que cada copia de seguridad será un volcado completo de la base de datos.

  • Debido a las limitaciones de PostgreSQL, la recuperación de avance no se admite en la operación de restauración de copias de seguridad completas e incrementales.

Versiones de PostgreSQL compatibles Sistemas operativos compatibles Versión mínima requerida del agente del servicio de Backup y DR
10.23 RHEL 8.1-8.5 V11.0.1
RHEL 8.6 V11.0.4
RHEL 8.7 V11.0.5
11.x RHEL 8.1-8.5 V11.0.1
RHEL 8.6 V11.0.4
RHEL 8.7 V11.0.5
12.x RHEL 8.1-8.5 V11.0.1
RHEL 8.6 V11.0.4
RHEL 8.7 V11.0.5
13.x RHEL 8.1-8.5 V11.0.1
RHEL 8.6 V11.0.4
RHEL 8.7 V11.0.5
14.x RHEL 8.1-8.5 V11.0.1
RHEL 8.6 V11.0.4
RHEL 8.7 V11.0.5
15.x RHEL 8.1-8.5 V11.0.1
RHEL 8.6 V11.0.4
RHEL 8.7 V11.0.5
16.x RHEL 8.10 V11.0.13-14 con paquetes de revisiones

SAP

El servicio de copia de seguridad y recuperación tras fallos es compatible con SAP en todas las bases de datos que se indican en este documento.

SAP ASE (antes Sybase ASE)

El servicio de copia de seguridad y recuperación tras fallos admite los siguientes métodos de captura de datos:

  • SAP ASE en Linux se puede capturar a nivel de volumen de forma incremental e indefinida con acceso instantáneo y creación de clones virtuales para TDM. Esta opción aprovecha las funciones de LVM de Linux y de seguimiento de bloques modificados de Backup and DR, y es la alternativa recomendada.

  • En el caso de los clientes que no usen LVM o que no puedan usar la captura a nivel de volumen, SAP ASE en Linux se puede capturar de forma alternativa mediante una copia de seguridad completa e incremental. Este método usa la copia de seguridad basada en volcado de la base de datos y, por lo general, se ejecuta como una copia completa semanal y una incremental diaria. La recuperación implica reconstruir los incrementales sobre la copia de seguridad completa más reciente.

Versiones compatibles de SAP ASE Sistemas operativos compatibles Versión mínima requerida del agente de copia de seguridad y recuperación tras fallos
16.0.x SLES 12 SP5
SLES 15 SP3
V11.0.1
SLES 15 SP4 V11.0.4
SLES 15 SP5 V11.0.9

SAP HANA

El agente de copia de seguridad y recuperación ante desastres admite la captura de SAP HANA en las siguientes configuraciones.

Configuración compatible API SavePoint de SAP HANA 2 SAP basado en archivos (HDBSQL/Backint) 3 Sistemas operativos compatibles Versión mínima requerida del agente de copia de seguridad y recuperación tras fallos
Escalabilidad horizontal de HANA 2.0, almacenamiento no compartido Sí (opción preferida) 1 RHEL 8.1-8.5
SLES 12 SP5
SLES 15 SP3
V11.0.1
Sí (opción preferida) 1 RHEL 8.6
SLES 15 SP4
V11.0.4
Sí (opción preferida) 1 RHEL 8.7 V11.0.5
Sí (opción preferida) 1 RHEL 8.10 V11.0.14, kernel 4.18.0-553.40.1
Sí (opción preferida) 1 RHEL 9.2 V11.0.14 con paquetes de revisiones
Sí (opción preferida) 1 RHEL 9.5 V11.0.14, kernel 5.14.0-503.23.1
Sí (opción preferida) 1 SLES 15 SP5 V11.0.9
Escalabilidad horizontal de HANA 2.0, almacenamiento compartido 4 No admitida RHEL 8.1-8.5
SLES 12 SP5
SLES 15 SP3
V11.0.1
No admitida RHEL 8.6
SLES 15 SP4
V11.0.4
Sí (opción preferida) 1 RHEL 8.7 V11.0.5
Sí (opción preferida) 1 SLES 15 SP5 V11.0.9
SAP HANA 2.0 independiente o de alta disponibilidad (1+1) Sí (opción preferida) 1 RHEL 8.1-8.5
SLES 12 SP5
SLES 15 SP3
V11.0.1
Sí (opción preferida) 1 RHEL 8.6
SLES 15 SP4
V11.0.4
Sí (opción preferida) 1 RHEL 8.7 V11.0.5
Sí (opción preferida) 1 SLES 15 SP5 V11.0.9
Sistema de un solo contenedor (HANA 1.0) 5 Sí (opción preferida) RHEL 8.1-8.5
SLES 12 SP5
SLES 15 SP3
V11.0.1
Sí (opción preferida) RHEL 8.6
SLES 15 SP4
V11.0.4
Sí (opción preferida) 1 RHEL 8.7 V11.0.5
Sí (opción preferida) 1 SLES 15 SP5 V11.0.9

1 Requiere SAP HANA 2.0 SPS 04 o versiones posteriores

2 La API SavePoint de SAP HANA aprovecha la tecnología CBT de Backup and DR y admite la función de montaje instantáneo incremental y consciente de la aplicación con la opción de avance de registro. El servicio de copias de seguridad y recuperación tras fallos admite CBT con HANA en RHEL 7.2 y versiones posteriores. Para ver la lista completa de versiones de RHEL aptas para CBT, consulta Compatibilidad con sistemas operativos Linux.

3 El modo Backint de SAP HANA solo admite copias de seguridad completas semanales con incrementales diarias. Admite la recuperación de HANA mediante comandos de HANA HDBSQL o Backint. Además, no se admite la función de montaje instantáneo de aplicaciones con la API basada en archivos de HANA (HDBSQL/Backint).

4 Solo admite la opción de asignación de discos NFS de Backup y DR. El disco NFS siempre se asigna a todos los nodos de HANA.

5 Admite las opciones de asignación de discos de bloques y NFS de copia de seguridad y recuperación tras desastres

SAP MaxDB

El servicio de copia de seguridad y recuperación tras fallos admite los siguientes métodos de captura de datos:

  • SAP MaxDB en Linux se puede capturar a nivel de volumen de forma incremental para siempre con acceso instantáneo y creación de clones virtuales para TDM. Esta opción aprovecha las funciones de LVM de Linux y de seguimiento de bloques modificados de Backup and DR, y es la alternativa recomendada.

  • En el caso de los clientes que no usen LVM o que no puedan usar la captura a nivel de volumen, MaxDB en Linux se puede capturar mediante una copia de seguridad completa e incremental. Este método usa la copia de seguridad basada en volcado de la base de datos y, por lo general, se ejecuta como una copia completa semanal y una incremental diaria. La recuperación implica reconstruir los incrementales sobre la copia de seguridad completa más reciente.

Versiones compatibles de SAP MaxDB Sistemas operativos compatibles Versión mínima requerida del agente de copia de seguridad y recuperación tras fallos
7.9.09 RHEL 8.1-8.5
SLES 12 SP5
SLES 15 SP3
V11.0.1
7.9.10 RHEL 8.1-8.5 V11.0.1
RHEL 8.6
SLES 15 SP4
V11.0.4
RHEL 8.7 V11.0.5
SLES 15 SP5 V11.0.9

SAP IQ (antes Sybase IQ)

El servicio de copia de seguridad y recuperación tras fallos admite la captura de SAP IQ a nivel de volumen de forma incremental y permanente, con acceso instantáneo y creación de clones virtuales para TDM. Esta opción aprovecha las funciones de LVM de Linux y de seguimiento de bloques modificados de Backup and DR, y es la alternativa recomendada.

Versiones compatibles de SAP IQ Sistemas operativos compatibles Versión mínima requerida del agente de copia de seguridad y recuperación tras fallos
SAP IQ 16.x (completa e incremental) RHEL 8.1-8.5
SLES 12 SP5
SLES 15 SP3
V11.0.1
SAP IQ 16.x (LVM + CBT) RHEL 8.1-8.5
SLES 12 SP5
SLES 15 SP3
V11.0.1
RHEL 8.6
SLES 15 SP4
V11.0.4
RHEL 8.7 V11.0.5
SLES 15 SP5 V11.0.9

Sistemas de archivos

Los agentes de copia de seguridad y recuperación ante desastres detectan cada volumen en un punto de montaje de red como una aplicación protegible. En cada una de estas aplicaciones detectadas, el agente de Backup and DR coordina el proceso para lograr la coherencia (mediante las copias de seguridad de VSS o LVM), presenta un disco de almacenamiento provisional que se formateará con un sistema de archivos del mismo tipo que el de origen o con un tipo de sistema de archivos compatible, tal como se describe en este artículo.

Sistema operativo FS de origen Sistema de archivos de disco de almacenamiento provisional Versión mínima requerida del agente de copia de seguridad y recuperación tras fallos
Windows NTFS NTFS V11.0.1
Pymes NTFS V11.0.1
ReFS ReFS V11.0.1
Linux1 EXT2 EXT2 o NFS4 V11.0.1
EXT3 EXT3 o NFS4 V11.0.1
EXT4 EXT4 o NFS4 V11.0.1
XFS XFS o NFS4 V11.0.1
ReiserFS ReiserFS o NFS4 V11.0.1
NFS EXT3 o NFS4 V11.0.1
BTRFS EXT3 o NFS4 V11.0.1

Se usa la captura de LVM 1 como origen, si está presente. Se admite el montaje de LVM en el mismo servidor

2 Solo versiones integradas

3 Cifrado no admitido

4 Solo se admite la versión 3 del protocolo NFS

Gestión de datos de prueba con contenedores

Copia de seguridad y recuperación tras fallos usa volúmenes NFS para que los datos de las aplicaciones capturados estén disponibles como recursos compartidos de NFS para los contenedores. Esto permite crear clones virtuales de bases de datos compatibles a los que se puede acceder desde el entorno contenedorizado.

Virtualización de datos para entornos virtuales

Backup and DR admite la virtualización de datos en entornos virtuales con los siguientes métodos:

VMware Engine de Google Cloud

El servicio de copia de seguridad y recuperación tras fallos admite la captura de datos de máquinas virtuales de VMware mediante llamadas a las APIs de almacenamiento de VMware vSphere - Protección de datos (antes conocidas como APIs de vStorage para la protección de datos o VADP) para capturar un servidor virtual completo. En concreto, las llamadas a la API pueden:

  • Realiza un seguimiento de los bloques modificados: hace una captura completa inicial de una base de datos y, después, solo captura los cambios que se producen en la base de datos, lo que permite usar la estrategia de captura incremental continua de Backup and DR.

  • Poner en reposo las aplicaciones: asegura la coherencia de las aplicaciones durante la captura.

vCenter 1, 6 7.0, 7.0 U1, 7.0 U2, 7.0 U3, 8.0 7
ESX Server 6 7.0, 7.0 U1, 7.0 U2 y 7.0 U3
Hardware virtual 2 De 7 a 15 y de 17 a 19
Sistema operativo invitado Todos los sistemas operativos compatibles con VMware Engine de Google Cloud
Suspender aplicaciones 3 Sí, en función de VMware Tools
Compatibilidad con vSAN 4 vSAN 7.0 U1, vSAN 7.0 U2, vSAN 7.0 U3
Seguimiento de cambios de bloque5 Aprovecha las APIs de almacenamiento de VMware vSphere (anteriormente conocidas como APIs de vStorage para la protección de datos o VADP).

1 Utiliza la versión 7.0 de VMware VDDK.

No se admiten los tipos de controlador NVME 2 (disponibles en ESX 7.0 y versiones posteriores). Las versiones 14 y posteriores de hardware virtual solo son compatibles con ESX 7.0 (y versiones posteriores).

3 Capacidad aplicable a cualquier aplicación con un escritor de VSS o scripts previos y posteriores para conseguir una captura coherente con la aplicación.

4 Como VMware vSAN no admite funciones de acceso a dispositivos RDM, Backup and DR no admite el montaje de una máquina virtual cuando se usan RDMs. Se admiten restauraciones y clonaciones de máquinas virtuales. Sin embargo, se admite el montaje de una máquina virtual en Backup and DR cuando se usa el transporte NFS en lugar de RDM.

5 No se admite en discos presentados a VMs de producción como pRDM.

6 No se admite la configuración del modo de transporte SAN para crear copias de seguridad del disco de almacenamiento provisional (copias de seguridad basadas en agentes) ni el montaje y la restauración de copias de seguridad mediante iSCSI.

7 VMware vCenter Server 8.0 es compatible con el servicio de Backup y DR 11.0.15 y versiones posteriores.