¿Qué es la copia de seguridad heterogénea?
La copia de seguridad heterogénea es una estrategia que protege diferentes tipos de cargas de trabajo —como servidores físicos, máquinas virtuales, bases de datos, Kubernetes, aplicaciones SaaS y cargas de trabajo en la nube— bajo políticas de recuperación comunes. Los destinos de recuperación comunes no requieren métodos de copia de seguridad idénticos.
Una copia de seguridad satisfactoria no garantiza una recuperación satisfactoria. La copia de seguridad heterogénea protege diferentes tipos de cargas de trabajo bajo unos objetivos de recuperación comunes. Muchos entornos de TI empresariales combinan múltiples sistemas operativos, hipervisores, bases de datos, servicios en la nube y plataformas heredadas. En concreto, es posible encontrar empresas que ejecutan sus operaciones en servidores Windows y Linux y que utilizan máquinas virtuales VMware e Hyper-V. Además, estas empresas pueden utilizar simultáneamente clústeres de Kubernetes, cargas de trabajo en la nube pública, aplicaciones de software como servicio (SaaS), bases de datos, sistemas de almacenamiento conectados a la red y plataformas físicas o Unix más antiguas, como los mainframes IBM System z (z/OS) e IBM AIX en Power Systems (u Oracle Solaris / HP-UX).
Los entornos mixtos pueden ser el resultado de adquisiciones, migraciones a la nube, modernización de aplicaciones, retención de sistemas heredados y compras tecnológicas descentralizadas. Por lo tanto, el problema de las copias de seguridad radica en cómo proporcionar una recuperación fiable en todos los sistemas asociados a diferentes interfaces de programación de aplicaciones (API), mecanismos de consistencia, identidades, metadatos y modos de fallo. Una API representa un conjunto de reglas que permiten que dos componentes de software se comuniquen basándose en un conjunto de definiciones y protocolos.
Una estrategia de copia de seguridad heterogénea utiliza una arquitectura coordinada de protección de datos para proteger múltiples sistemas operativos, aplicaciones, bases de datos, hipervisores, plataformas de almacenamiento y entornos en la nube.
La estrategia de copias de seguridad heterogéneas tiene como objetivo establecer resultados de recuperación comunes, tales como objetivos de punto de recuperación (RPO), objetivos de tiempo de recuperación (RTO), retención, inmutabilidad, control de acceso y pruebas. Las pruebas de recuperación forman parte del diseño de las copias de seguridad.
El RPO es la cantidad máxima aceptable de pérdida de datos que una organización puede tolerar antes de que el negocio se vea perjudicado. El RTO es el período máximo durante el cual una empresa puede permanecer sin operaciones antes de que la interrupción cause un impacto inaceptable.
Las bases de datos, las máquinas virtuales y las aplicaciones de Kubernetes pueden compartir un RPO aunque utilicen diferentes mecanismos de protección. Es esencial estandarizar los resultados de recuperación en lugar de obligar a todas las cargas de trabajo a seguir el mismo proceso de copia de seguridad.
Al mismo tiempo, la estrategia ayuda a preservar los métodos específicos de cada carga de trabajo —como las cargas de trabajo de bases de datos y las máquinas virtuales— necesarios para alcanzarlos.
Es importante destacar que, si todos los trabajos de un panel de control aparecen en verde, esto no significa que una empresa pueda recuperar sus aplicaciones. Una copia de seguridad heterogénea eficaz estandariza las políticas y las pruebas, respetando las diferencias técnicas, como las copias de seguridad de bases de datos consistentes con la aplicación con registros de transacciones para la recuperación en un momento determinado y las copias de seguridad de imágenes a nivel de hipervisor para la recuperación completa de máquinas virtuales.
¿Qué hace que un entorno de copia de seguridad sea heterogéneo?
Un entorno de copia de seguridad es heterogéneo cuando sus cargas de trabajo requieren diferentes métodos de copia de seguridad o recuperación y están sujetas a diferentes métodos de recuperación. Los entornos de TI mixtos requieren métodos de copia de seguridad específicos para cada carga de trabajo.
Un entorno mixto puede incluir:
- macOS, servidores Unix, Linux, Windows físico
- Máquinas virtuales Proxmox, VMware, Nutanix, Hyper-V, máquinas virtuales basadas en el kernel
- Volúmenes persistentes, clústeres de Kubernetes, manifiestos, secretos y metadatos de aplicaciones
- Bases de datos (p. ej., Microsoft SQL Server, Oracle, PostgreSQL, MySQL, SAP HANA, MongoDB)
- Por ejemplo, dispositivos NAS y sistemas de archivos
- Por ejemplo, la nube privada y cargas de trabajo menos comunes o técnicamente complejas
- Por ejemplo, Salesforce y Microsoft 365
- Mainframes, aplicaciones propietarias o sistemas que no admiten un agente moderno
La infraestructura representa una capa. Existen diferentes requisitos de recuperación. Una base de datos transaccional podría perder datos. Sin embargo, un archivo podría permitir un objetivo de punto de recuperación (RPO) de 24 horas. El RPO representa el momento en el que deben recuperarse los datos tras una interrupción del servicio.
En el caso de los sistemas de fabricación que deben seguir funcionando durante las interrupciones de la WAN, puede ser necesaria una infraestructura de recuperación local incluso cuando la red de área amplia (WAN) no esté disponible. Una red de área amplia es la tecnología que conecta sus oficinas, centros de datos, aplicaciones en la nube y almacenamiento en la nube.
Los períodos de retención dependen de la jurisdicción aplicable, el tipo de registro, el contrato y el régimen normativo. Y es posible que solo se necesiten unos pocos puntos de restauración para un entorno de desarrollo de corta duración.
Por eso, «compatible con muchas plataformas» es una definición incompleta de la copia de seguridad heterogénea. Una plataforma puede incorporar datos de muchas fuentes. La recuperación coherente con la aplicación no es habitual en todas las fuentes. Lo mismo ocurre con la recuperación multiplataforma probada, la recuperación de la configuración o la restauración granular.
¿Por qué las diferentes cargas de trabajo necesitan métodos de copia de seguridad distintos?
Las diferentes cargas de trabajo necesitan distintos mecanismos de copia de seguridad porque alcanzan un estado recuperable de formas distintas. Resulta útil estandarizar las diferentes cargas de trabajo, pero existen riesgos ocultos asociados a la uniformidad literal. Las clases de cargas de trabajo alcanzan un estado recuperable de diversas maneras.
Una instantánea del hipervisor puede servir de base para la copia de seguridad de una máquina virtual cuando el producto de copia de seguridad también captura la configuración y el estado requerido de la aplicación. Para una base de datos, puede ser necesaria una API de copia de seguridad nativa, así como la coordinación de los registros de transacciones y el truncamiento de registros. Una aplicación de Kubernetes puede necesitar datos persistentes y manifiestos, recursos personalizados, secretos e información sobre dependencias.
Una plataforma de software como servicio (SaaS) solo expone los objetos y las interfaces de programación de aplicaciones (API) que permite su proveedor. Una API representa reglas y protocolos, lo que permite que diferentes programas de software se comuniquen entre sí. Para un servidor físico pueden ser necesarios archivos, el estado del sistema y datos de recuperación «bare-metal».
Las cargas de trabajo que cuentan con una instantánea diaria y una política de retención de 30 días presentan una configuración coherente. Sin embargo, no tienen necesariamente capacidad de recuperación. El sistema puede continuar su funcionamiento sin dependencias externas, como las dependencias de aplicaciones de Kubernetes, la configuración de identidades y las claves de cifrado. Esto también se refiere a la configuración de identidades o a los metadatos nativos de la nube. Además, es posible que el sistema no se pueda restaurar en una región, un clúster, un hipervisor o una cuenta diferentes.
Las cargas de trabajo que pertenezcan al mismo nivel de negocio deben cumplir el mismo objetivo previsto, incluso si cuentan con mecanismos de copia de seguridad diferentes. Por ejemplo, una política de Nivel 1 podría requerir (el Nivel 1 es una clasificación ilustrativa, no una definición universal del sector):
- Máximo 15 minutos de pérdida de datos
- Restauración del servicio en un plazo de dos horas
- Una copia inalterable que no se encuentre dentro del perímetro de seguridad de producción
- Pruebas de recuperación que se realizarán trimestralmente
- Pruebas que demuestren que la recuperación de las dependencias de las aplicaciones se lleva a cabo correctamente. Estas dependencias pueden incluir dependencias del orden de recuperación, así como infraestructura y servicios de seguridad de nivel superior.
Una base de datos Oracle o una aplicación de Kubernetes pueden utilizar diferentes herramientas o complementos para cumplir con esa política. Entre estas herramientas o complementos se pueden incluir Oracle Recovery Manager y el complemento Dell PowerProtect Data Manager. El control sigue una ruta estandarizada. La implementación está optimizada para la carga de trabajo.
¿Cómo deben los equipos asignar las cargas de trabajo al método de protección adecuado?
Un diseño de copias de seguridad heterogéneo debe basarse en un inventario orientado a la recuperación, en lugar de en una lista de dispositivos. Por regla general, los inventarios de infraestructura identifican los hosts y la capacidad de almacenamiento sin mostrar los elementos que conforman un servicio empresarial completo.
Empiece por asignar las aplicaciones a sus dependencias de computación, datos, configuración, identidad, red, certificados y servicios externos, como pasarelas de pago o API de terceros, bases de datos gestionadas externamente o proveedores de identidad SaaS.
A continuación, clasifíquelas teniendo en cuenta su impacto en el negocio. Por último, defina su objetivo de punto de recuperación (RPO) y su objetivo de tiempo de recuperación (RTO), así como el periodo de retención.
Además, defina sus requisitos legales, como las leyes de soberanía y residencia de datos (p. ej., el Reglamento General de Protección de Datos) y las normas de retención obligatorias (p. ej., Ley de Portabilidad y Responsabilidad del Seguro Médico), la ubicación de recuperación y el responsable.
El RGPD es la ley europea de privacidad y seguridad de los datos. La HIPAA establece normas estrictas para la gestión, la transmisión y el almacenamiento de la información sanitaria protegida.
Considere la posibilidad de utilizar esta tabla como punto de partida:
| Tipo de carga de trabajo | Qué proteger | Método de consistencia preferido | Verificación de la recuperación |
| Servidor físico | Estado del sistema, archivos, datos de arranque, datos de aplicaciones | Integración de agentes y aplicaciones | Prueba de arranque en hardware nuevo o alternativo |
| Máquina virtual | Configuración, discos de la máquina virtual, estado de las aplicaciones | Instantánea del hipervisor más suspensión de aplicaciones | Inicio de máquina virtual aislada y prueba de servicios |
| Base de datos | Registros, archivos de datos, configuración, material de cifrado | API nativa de la base de datos o complemento certificado | Restauración, avance y comprobación de la integridad de la base de datos |
| Aplicación de Kubernetes | Metadatos del clúster/aplicación y volúmenes persistentes | Ganchos de aplicación, instantáneas de la interfaz de almacenamiento de contenedores (CSI) y detección compatible con Kubernetes | Utilizar un espacio de nombres o clúster limpio para la restauración y las pruebas de dependencias |
| Almacenamiento conectado a la red (NAS) o plataforma de archivos | Permisos, recursos compartidos, listas de control de acceso (ACL) y metadatos de archivos | Copia de seguridad a nivel de archivo o integración de instantáneas/API | Prueba de restauración de permisos, archivos y directorios de gran tamaño |
| Servicio en la nube modernizado | Configuración de la gestión de identidades y accesos (IAM), datos del servicio, identidades y referencias, y contexto de región/cuenta | API del proveedor más copia independiente cuando sea compatible | Restauración a una cuenta o región autorizada |
| Aplicación SaaS | Permisos, objetos, archivos adjuntos y relaciones expuestas por la API | Conector específico para SaaS | Restauración granular de objetos y comprobación de relaciones |
Es importante destacar que no todas las dependencias son objetos de copia de seguridad. Los siguientes elementos, que forman parte del plan de recuperación, pueden requerir procedimientos de protección o recreación independientes:
- Entradas del sistema de nombres de dominio (DNS), como los registros A o AAAA y los registros de nombres canónicos
- Repositorios de «infraestructura como código», por ejemplo, repositorios de GitLab/GitHub (que contienen scripts de Terraform o Pulumi) y repositorios de plantillas de Amazon Web Services CloudFormation
- Configuración de proveedores de identidad
- Imágenes de contenedores
- Servidores de licencias, como FlexNet Publisher (FlexLM) y el servidor de Microsoft Key Management Services (KMS)
- Credenciales de API de terceros, como secretos de cliente OAuth, tokens de actualización y claves de API de pasarelas de pago
Un proceso paso a paso para diseñar copias de seguridad heterogéneas
1. Identificar las cargas de trabajo y asignar la responsabilidad
Combina la detección automatizada con entrevistas a los responsables de las aplicaciones, como los análisis de detección de infraestructura (p. ej., ServiceNow Discovery, Device42), cuestionarios y entrevistas sobre continuidad del negocio.
Identifica los sistemas no gestionados, como los servidores de «TI no autorizada» o «TI en la sombra» y las máquinas virtuales de pruebas o de desarrollo, así como las cuentas en la nube, como las cuentas de suscripción ad hoc de AWS o Azure y los espacios de trabajo de proyectos de Google Cloud Platform (GCP).
Además, identifique los espacios de nombres de Kubernetes, como los de entornos de prueba y ramas de características (p. ej., staging-checkout, dev-payments), así como los emplazamientos remotos, como sucursales o almacenes regionales y centros de fabricación o de computación periférica.
Asimismo, identifique las aplicaciones SaaS, como las plataformas de colaboración empresarial (p. ej., Microsoft 365, Google Workspace) y las plataformas heredadas, como los mainframes heredados o los sistemas AS400 y los entornos de TI de filiales adquiridas.
Asigne un responsable técnico y un responsable de negocio a cada servicio protegido.
2. Define los niveles de recuperación antes de seleccionar la tecnología
Agrupa los servicios en función del impacto empresarial. Asigna requisitos medibles de RPO, RTO, retención, ubicación de recuperación y pruebas, como ejecuciones automatizadas trimestrales en entornos de prueba de recuperación y simulaciones semestrales de conmutación por error completa.
No permitas que la programación predeterminada de una herramienta se convierta en el requisito empresarial.
3. Identifica los datos y componentes de cada carga de trabajo que deben capturarse conjuntamente para crear un punto de recuperación utilizable
Decida qué debe capturar para obtener un punto de recuperación utilizable. Por ejemplo, considere la posibilidad de capturar archivos de datos y registros de una base de datos.
Considere la posibilidad de capturar máquinas virtuales, bases de datos, colas de mensajes o recursos de Kubernetes para una aplicación de varios niveles. Registre los «hooks» de la aplicación, como los de congelación previa a la instantánea y de descongelación posterior a la instantánea, así como los requisitos de secuenciación, como las dependencias de arranque ordenadas (Infraestructura – Base de datos – Aplicación – Interfaz de usuario).
4. Adapta los métodos de protección al comportamiento de la carga de trabajo
Opta por la protección basada en agentes, sin agentes, basada en instantáneas, basada en API, nativa de la base de datos o continua. Para ello, debes tener en cuenta las necesidades de la carga de trabajo, como el acceso al hipervisor o al sistema operativo (SO), la sobrecarga de recursos, el volumen de transacciones y las tasas de cambio.
Utilice integraciones nativas, como las API de copia de seguridad nativas de la base de datos —por ejemplo, Oracle Recovery Manager (RMAN) o los escritores del Servicio de Copias de Sombra de Volúmenes (VSS) de Microsoft SQL—, siempre que proporcionen copias de seguridad consistentes con la aplicación, coordinación de registros de transacciones, copias de seguridad incrementales eficientes o recuperación granular.
Además, utilice las API de instantáneas nativas de las matrices de almacenamiento y de la nube, como las API de instantáneas de AWS Elastic Block Store (EBS) o la integración con NetApp ONTAP, siempre que mejoren la consistencia, la gestión de los registros, la eficiencia de las copias de seguridad incrementales o la recuperación granular.
5. Separar el control de las copias de seguridad y el almacenamiento de la producción
Restringir el acceso administrativo, exigir la autenticación multifactorial al gestionar las credenciales de copia de seguridad, aislarlas, por ejemplo, mediante proveedores de identidad independientes dedicados (p. ej., un directorio local independiente o un inquilino de Okta dedicado) y almacenes de gestión de acceso privilegiado (PAM) con acceso «justo a tiempo» (p. ej., CyberArk, HashiCorp Vault).
Mantenga copias inmutables o fuera de línea, como el bloqueo de objetos S3 con almacenamiento de tipo «escribir una vez, leer muchas veces» (WORM) y copias de almacenamiento físico o aisladas (por ejemplo, cintas fuera de línea o redes de almacenamiento aisladas).
Una segunda copia bajo el control del mismo sistema de gestión de identidades y accesos comprometido no ofrece protección independiente frente al compromiso de dicho sistema de identidades.
6. Diseña tanto las rutas de recuperación como las de copia de seguridad
Determina el lugar donde se restaurarán las cargas de trabajo en caso de que no exista la plataforma original. Verifica la capacidad de la red, las cuotas en la nube, los recursos de computación compatibles, las versiones de software, las claves y las competencias.
Si solo se puede restaurar una copia de seguridad en la plataforma de origen que ha fallado, se puede acabar en una dependencia circular.
7. Probar escenarios de fallo representativos
Probar la pérdida de máquinas virtuales, la pérdida de clústeres, la eliminación granular, la corrupción de bases de datos, el ransomware, el compromiso de cuentas en la nube y los fallos asociados a los sitios. Evaluar el RPO y el RTO reales. No se limite a registrar cómo se completó la tarea.
¿Cuáles son los problemas más comunes en las copias de seguridad heterogéneas?
Entre los fallos habituales se incluyen la falta de cargas de trabajo, credenciales caducadas, dependencias de aplicaciones incompletas, acceso administrativo excesivo y recuperaciones entre plataformas no probadas.
Las dependencias entre plataformas pueden provocar fallos relacionados con la identidad, la autenticación, la secuenciación y la compatibilidad de las API. Los fallos pueden incluir desviaciones en la identidad, el acceso y la autenticación entre plataformas, así como incompatibilidades en la secuenciación de microservicios y en los protocolos de las API, entre las plataformas compatibles, no dentro de ellas.
¿Cómo crean las nuevas cargas de trabajo lagunas en la cobertura de las copias de seguridad?
En entornos con cambios frecuentes de aprovisionamiento o configuración, el mantenimiento manual de las políticas de copia de seguridad puede dejar nuevas cargas de trabajo temporalmente desprotegidas. Las políticas de copia de seguridad mantenidas manualmente pueden incluir políticas de auditoría basadas en hojas de cálculo y políticas estáticas de etiquetado sin aplicación automatizada.
Es posible que las nuevas máquinas virtuales (VM), bases de datos, espacios de nombres, inquilinos de SaaS o cuentas en la nube nunca se incluyan en la lista.
Un activo puede seguir siendo visible a través de una consola incluso después de que sus credenciales hayan caducado o de que su método de protección difiera de la política.
Por lo tanto, se debe medir la cobertura de forma continua. Los activos de producción detectados, como las enumeraciones de inventario de API en la nube y los objetos de gestión de hipervisores y clústeres, deben identificarse junto con los activos protegidos.
Los activos protegidos pueden incluir registros activos del catálogo de tareas de copia de seguridad y manifiestos de instantáneas completados. La finalización de una tarea de copia de seguridad demuestra la captura de datos, no la capacidad de recuperación de la aplicación.
Además, se deben destacar las cargas de trabajo desconocidas, excluidas y no conformes, como las bases de datos en la nube huérfanas o desprotegidas y las credenciales caducadas o defectuosas.
Asimismo, se deben utilizar etiquetas y marcadores para automatizar la asignación. Los equipos deben mantener bajo supervisión los metadatos que falten o sean incorrectos, considerándolos un fallo de control.
¿Significa una copia de seguridad satisfactoria que una aplicación es recuperable?
Por regla general, el software de copia de seguridad confirma que ha leído y almacenado los datos. No puede demostrar automáticamente la disponibilidad de todas las dependencias de las aplicaciones, como Active Directory, los proveedores de identidad, los servidores del sistema de nombres de dominio (DNS), los servidores externos de gestión de claves (KMS) y los almacenes de secretos. Además, no puede garantizar automáticamente que el servicio restaurado vaya a funcionar.
Para garantizar la recuperación, confíe en comprobaciones automatizadas de arranque o montaje, compruebe la integridad de las bases de datos, realice análisis en busca de malware, aplique validaciones a nivel de aplicación y obtenga la aceptación periódica del propietario.
Los servicios de alto impacto, como los sistemas bancarios centrales y de procesamiento de transacciones, así como las plataformas de pago y gestión de pedidos de comercio electrónico, también necesitan pruebas completas del flujo de trabajo, no solo pruebas de la infraestructura.
¿Qué riesgos de seguridad plantea la gestión centralizada de copias de seguridad?
Una plataforma unificada puede reducir el número de consolas, catálogos y sistemas de políticas que gestionan los administradores.
Sin embargo, también puede convertirse en un objetivo administrativo de gran valor. Las consecuencias de una brecha de seguridad pueden extenderse por todo el entorno de TI.
Esto ocurre cuando un sistema de gestión central elimina políticas o caduca copias —como los conjuntos de copias de seguridad incrementales diarias programadas que aún no se han replicado en un repositorio externo o aislado físicamente, y las instantáneas de retención a largo plazo destinadas al archivo para el cumplimiento normativo que aún no han alcanzado su fecha de caducidad definida— y, a continuación, accede a todas las cargas de trabajo.
Considera la posibilidad de separar las funciones para reducir este riesgo. Además, aplique el acceso administrativo «justo a tiempo», utilice credenciales separadas, emplee bloqueos de retención fijos, reenvíe las auditorías y utilice hosts de gestión reforzados
Asimismo, utilice dominios de seguridad diferenciados, como cuentas de Amazon Web Services o suscripciones de Azure completamente aisladas y bosques de Active Directory locales aislados o con aislamiento físico, para las copias secundarias, tales como buckets de S3 con bloqueo de objetos WORM fijos y cartuchos de cinta externos con aislamiento físico o dispositivos de almacenamiento aislados.
La visibilidad centralizada no debe implicar una autoridad centralizada sin restricciones.
¿Cómo afecta la deduplicación a los costes de almacenamiento de las copias de seguridad?
Los datos de cargas de trabajo mixtas, como bases de datos SQL transaccionales mezcladas con recursos compartidos de archivos sin comprimir e imágenes de infraestructura de escritorios virtuales mezcladas con almacenamiento de multimedia y vídeo, no se deduplican por igual.
Las bases de datos cifradas, los archivos multimedia comprimidos, los discos virtuales con muchos cambios y los datos en la nube cifrados del lado del cliente pueden generar ratios de reducción bajos.
Aunque la deduplicación global puede ahorrar capacidad, también se puede recurrir a ella por motivos de rendimiento, de dominio de fallos o de residencia de datos, como en el caso de una infraestructura dedicada o segmentada cuyos componentes puedan fallar conjuntamente, así como en el caso de grupos de rendimiento y del aislamiento geográfico y normativo de la residencia de datos.
Los modelos de capacidad deben tener en cuenta las tasas de cambio específicas de cada carga de trabajo, la retención, el comportamiento de las copias de seguridad completas, la sobrecarga fija, la replicación, la salida de datos y el espacio de preparación para la restauración. La planificación de la capacidad no debe basarse en un único ratio de deduplicación para tipos de cargas de trabajo que difieren sustancialmente entre sí.
¿Por qué se debe probar la recuperación entre plataformas?
Las organizaciones suelen recurrir a las copias de seguridad para facilitar la migración a la nube o la recuperación en un hipervisor diferente. En la práctica, la recuperación puede verse bloqueada por diferencias relacionadas con controladores, modos de arranque, formatos de disco, estructuras de red, identidad, características de los servicios gestionados y licencias de aplicaciones.
Por lo tanto, la recuperación en una plataforma diferente debe considerarse un caso de uso independiente que requiere soporte y pruebas documentadas. Exportar datos no equivale a reconstruir una aplicación operativa.
¿Deberías utilizar una única plataforma de copias de seguridad o varias herramientas especializadas?
Ambos modelos pueden funcionar. La elección depende de la compatibilidad con las cargas de trabajo, los requisitos de recuperación, los límites de seguridad, las competencias operativas y los requisitos normativos.
Las copias de seguridad heterogéneas se asocian a dos enfoques habituales. En concreto, las organizaciones pueden utilizar una plataforma unificada para proteger diversos tipos de cargas de trabajo bajo un único catálogo y sistema de políticas.
Un enfoque federado mantiene los productos especializados y añade supervisión, gobernanza o generación de informes compartidos.
| Factor de decisión | Plataforma de copias de seguridad unificada | Múltiples herramientas especializadas |
| Perspectiva operativa | Consola, catálogo e informes comunes | Se requiere agregación o correlación manual |
| Profundidad de la carga de trabajo | Puede variar de una integración a otra | Puede resultar útil para obtener una capacidad nativa más profunda |
| Coherencia de las políticas | Más fácil de definir y auditar de forma centralizada | Las organizaciones deben adaptar las políticas a todos los productos |
| Exposición a riesgos de seguridad | Un sistema de gestión centralizado puede aumentar la exposición a riesgos de seguridad | Más sistemas de gestión centralizados y credenciales que proteger |
| Competencias y soporte | Menos modelos operativos | Más conocimientos especializados y coordinación con los proveedores |
| Riesgo de salida | Mayor dependencia de un único catálogo o formato de copia de seguridad | Mayor complejidad operativa y de integración |
| La opción más adecuada | Entorno de TI con amplio soporte y operaciones centrales sólidas | Cargas de trabajo con necesidades técnicas o normativas variables |
Las organizaciones pueden utilizar un modelo de gobernanza común incluso cuando diferentes cargas de trabajo requieran distintos productos de copia de seguridad. El uso de una herramienta especializada para bases de datos o mainframe puede estar justificado si una plataforma general no ofrece coherencia y no cumple los requisitos de rendimiento o recuperación, como es el caso de los clústeres de Oracle Real Application con alto rendimiento que requieren integración RMAN en un momento determinado, y las cargas de trabajo de mainframe y sistemas operativos heredados (por ejemplo, IBM z/OS o AS/400).
Sin embargo, las organizaciones deben tener en cuenta la cobertura y los fallos, como las cargas de trabajo especializadas no registradas o desprotegidas, las discrepancias en la restauración entre plataformas y los fallos de las API. Además, esto se refiere al cumplimiento de los requisitos de retención y a las pruebas de recuperación asociadas a cada excepción relativa a los procesos operativos comunes.
En primer lugar, prueba las cargas de trabajo periféricas. No te centres únicamente en el entorno de TI convencional de VMware o Windows. A continuación, consolida herramientas, como los agentes de copia de seguridad puntuales dispares que se ejecutan por separado en bases de datos Oracle, clústeres de Kubernetes y sistemas Unix heredados, que actualmente requieren consolas de gestión individuales y acuerdos de licencia independientes.
A continuación, averigua si la plataforma candidata puede restaurar los metadatos de las aplicaciones, los permisos, los registros y las dependencias.
Compruebe si la plataforma candidata es compatible con las versiones implementadas. Averigüe si la recuperación sigue siendo posible en caso de que el plano de control SaaS o el servicio de licencias del proveedor no estén disponibles.
Cómo evaluar si la copia de seguridad heterogénea funciona
La tasa de éxito de los trabajos de copia de seguridad por sí sola no mide la capacidad de recuperación. Puede evaluar la protección y la recuperación utilizando un cuadro de mando más completo:
- Cobertura de activos: porcentaje de activos de producción incluidos en el ámbito de aplicación —como la infraestructura en la nube recién aprovisionada, los espacios de nombres de Kubernetes y los volúmenes persistentes— protegidos por una política aprobada
- Cumplimiento de las políticas: porcentaje que cumple con los requisitos de RPO, retención, copias y controles fijos, como el bloqueo de objetos inmutables (WORM) y las copias secundarias geográficamente separadas o aisladas físicamente
- Validez del punto de recuperación: porcentaje de puntos de restauración muestreados que superan las comprobaciones de integridad y de malware
- Recuperabilidad probada: porcentaje de aplicaciones críticas, como los sistemas de planificación de recursos empresariales (ERP) (p. ej., SAP, Oracle EBS) y las plataformas de comercio electrónico y pasarelas de pago orientadas al cliente, restauradas y validadas dentro del periodo de prueba requerido
- RPO y RTO observados: pérdida real de datos y tiempo de recuperación transcurrido durante pruebas o incidentes, como la diferencia en la restauración de la base de datos a un momento determinado (RPO observado) y el tiempo de restauración completa de la aplicación y de arranque (RTO observado).
- Tiempo de desviación de la cobertura: tiempo que una carga de trabajo nueva o modificada permanece fuera de una política aprobada
- Antigüedad de las excepciones: tiempo que las cargas de trabajo no compatibles o exentas permanecen sin resolver
- Capacidad de recuperación en un entorno aislado tras un incidente de seguridad: si se dispone de credenciales, redes, recursos informáticos, claves y procedimientos para llevar a cabo la recuperación fuera del entorno afectado
La clase de carga de trabajo y el nivel de negocio pueden ayudar a segmentar las métricas, como las cargas de trabajo de nivel 0/críticas para la misión (p. ej., banca central, IAM/Active Directory) y las de nivel 3/no críticas (p. ej., entornos internos de desarrollo/pruebas, recursos compartidos de archivos de archivo). Una tasa de éxito del 98 % puede ocultar fallos repetidos de algunos sistemas que generan la mayor parte del riesgo empresarial.
Cómo Bacula Enterprise da soporte a entornos de copia de seguridad heterogéneos
Bacula Enterprise está diseñado para proteger entornos de TI heterogéneos sin obligar a todas las cargas de trabajo a utilizar el mismo método de copia de seguridad. En su lugar, las organizaciones pueden gestionar cargas de trabajo físicas, virtuales, en contenedores, de bases de datos, SaaS y en la nube a través de una plataforma común de copia de seguridad y recuperación, al tiempo que utilizan integraciones específicas para cada carga de trabajo cuando sea necesario.
Esto es importante en entornos mixtos porque, como se ha comentado anteriormente, una máquina virtual, una base de datos transaccional y una aplicación de Kubernetes pueden compartir los mismos objetivos de recuperación, al tiempo que requieren mecanismos completamente diferentes para crear un punto de recuperación utilizable.
Bacula Enterprise es compatible con este modelo gracias a una arquitectura modular y a una amplia gama de complementos e integraciones específicos. Entre los entornos compatibles se incluyen VMware, Hyper-V, Proxmox, Nutanix, KVM, Xen/XCP-ng, OpenStack, Libvirt, Azure VM y muchos otros, además de sistemas físicos Windows, Linux, macOS y Unix. Bacula también ofrece capacidades específicas para Kubernetes, Docker y Red Hat OpenShift.
Para las cargas de trabajo de aplicaciones y bases de datos, Bacula ofrece integraciones con tecnologías como Microsoft SQL Server, Oracle, PostgreSQL, MySQL, MariaDB, MongoDB, SAP HANA, IBM DB2 y SAP ASE. Las cargas de trabajo SaaS, como Microsoft 365 y Google Workspace, también pueden incorporarse al entorno de copia de seguridad más amplio.
El resultado es que las organizaciones pueden aplicar políticas operativas comunes sin reducir las copias de seguridad heterogéneas a un enfoque de «mínimo común denominador». Por ejemplo, los administradores pueden definir de forma centralizada las programaciones, la retención y las políticas de copia de seguridad, al tiempo que utilizan protección adaptada al hipervisor para máquinas virtuales, métodos específicos para bases de datos en sistemas transaccionales y mecanismos adaptados a Kubernetes para aplicaciones en contenedores.
Bacula Enterprise también puede combinar estas cargas de trabajo con diferentes destinos de almacenamiento de copias de seguridad. Sus integraciones incluyen almacenamiento en disco, cinta y en la nube, así como interfaces compatibles con S3, Microsoft Azure, Google Cloud, Oracle Cloud y Amazon Glacier. Esto permite a las organizaciones diseñar el almacenamiento y la retención en función del nivel de la carga de trabajo, los requisitos de recuperación y las limitaciones de la infraestructura, en lugar de basarse únicamente en la plataforma de origen.
La gestión centralizada se lleva a cabo a través de la BWeb Management Suite, que puede utilizarse para configurar, supervisar y analizar el entorno de copias de seguridad. Esto proporciona a los administradores una visión operativa común de las diferentes tecnologías, al tiempo que se mantienen los métodos especializados de copia de seguridad y recuperación que requiere cada carga de trabajo.
Para las organizaciones que estén considerando la consolidación de varios productos de copia de seguridad, esta amplia compatibilidad puede reducir el número de sistemas de copia de seguridad independientes que es necesario gestionar. No obstante, la cobertura de las cargas de trabajo debe evaluarse en función de las tecnologías y versiones concretas que se utilicen. El objetivo no es simplemente agrupar todas las cargas de trabajo en una única consola, sino verificar que cada sistema crítico cuente con el método de copia de seguridad adecuado y una ruta de recuperación probada.
Preguntas frecuentes
¿Cómo deben incluirse los sistemas heredados no compatibles en una estrategia de copia de seguridad heterogénea?
Inclúyalos en un registro formal de excepciones en el que se indique el responsable, el impacto en el negocio, el método de recuperación actual, los controles compensatorios y la fecha de retirada o corrección. Además, una única estrategia de recuperación puede regir múltiples tecnologías de copia de seguridad.
Puede utilizar medidas como instantáneas a nivel de almacenamiento, volcados de bases de datos, exportaciones de archivos, replicación o aislamiento. Además, pruebe todas las soluciones alternativas. Recuerde que, aunque copie datos propietarios inaccesibles, no dispondrá de una copia de seguridad utilizable.
Una estrategia de copia de seguridad está incompleta hasta que se prueba la recuperación.
¿Puede un único repositorio inmutable almacenar de forma segura las copias de seguridad de todos los entornos?
Un único repositorio inmutable puede simplificar la gestión de la retención y la capacidad. Esto es aplicable cuando el repositorio admite la inmutabilidad, el rendimiento, el aislamiento y los controles normativos requeridos.
Sin embargo, puede concentrar los riesgos operativos y de seguridad. Evalúa la separación de inquilinos, las claves de cifrado, los dominios administrativos, la residencia de los datos, los dominios de fallo, el rendimiento de la recuperación y el efecto de una interrupción del repositorio.
Incluso cuando las organizaciones aplican una gestión unificada, los servicios críticos, como los servicios de identidad y directorio (p. ej., Active Directory/Entra ID, infraestructura de clave pública) y los sistemas centrales de procesamiento financiero y de transacciones (p. ej., SAP, sistema bancario central en mainframe), pueden justificar copias de seguridad o niveles de almacenamiento independientes, basados en una evaluación de riesgos.
¿Con qué frecuencia se debe probar la recuperación heterogénea?
Utilice el nivel de negocio y la tasa de cambios para determinar la frecuencia. Aplique una validación automatizada para los servicios críticos asociados a cada copia de seguridad. No se olvide de los ejercicios programados de recuperación de aplicaciones, como la simulación de conmutación de recuperación ante desastres (DR) de pila completa y la recuperación aislada en «sala limpia» frente al ransomware.
Las cargas de trabajo de niveles inferiores pueden probarse con menor frecuencia. La frecuencia de las pruebas debe derivarse del impacto en el negocio, los requisitos normativos, la frecuencia de los cambios y los objetivos de recuperación.
Sin embargo, es necesario realizar pruebas aleatorias en todos los tipos de plataformas, procesos y destinos relevantes que se utilicen para restaurar una carga de trabajo. Vuelva a realizar pruebas tras actualizaciones importantes, migraciones de datos, cambios de identidad o modificaciones en la arquitectura. Mida el éxito de la restauración, no solo el éxito de la copia de seguridad.
