¿Cómo realizar una copia de seguridad de Kubernetes? Soluciones de copia de seguridad para Kubernetes

Introducción

Kubernetes (también conocido como K8s) es una plataforma de orquestación de contenedores que ayuda a gestionar y escalar aplicaciones; a menudo, es la opción preferida por las empresas que pueden sacar partido de la arquitectura de aplicaciones en contenedores. La flexibilidad de Kubernetes hace que muchas implementaciones sean muy diferentes entre sí. Sin embargo, las estructuras únicas suelen traer consigo retos específicos en materia de recuperación y tiempo de actividad, los cuales forman parte del desafío que supone utilizar Kubernetes en la infraestructura de TI de su empresa.

Si bien la suposición de que Kubernetes era utilizado anteriormente principalmente por equipos de DevOps puede haber sido en cierta medida correcta, muchas empresas están ahora implementando activamente contenedores en entornos operativos. Además, cada vez confían más en los contenedores para implementar aplicaciones en lugar de utilizar máquinas virtuales tradicionales. Esto se debe a las diversas ventajas en cuanto a flexibilidad, rendimiento y coste que pueden ofrecer los contenedores. Sin embargo, a medida que los contenedores se incorporan al ámbito operativo del entorno de TI, existe una creciente preocupación por los aspectos de seguridad de los contenedores en los sistemas de producción que deben permanecer disponibles, incluyendo sus datos persistentes en el contexto de los procesos de copia de seguridad y restauración.

En un principio, la inmensa mayoría de las aplicaciones en contenedores eran sin estado, lo que les permitía tener un proceso de implementación mucho más sencillo en una nube pública. Pero eso cambió con el tiempo, y ahora se implementan en contenedores muchas más aplicaciones con estado que antes. Este cambio es la razón por la que la copia de seguridad y la recuperación en Kubernetes son ahora un tema importante para muchas organizaciones.

Conceptos importantes para un proceso de copia de seguridad de Kubernetes

• La importancia de las copias de seguridad de Kubernetes gira en torno a la seguridad de los datos, ya que la información es el recurso más importante de cualquier empresa moderna y casi siempre requiere que estos datos se mantengan a salvo, seguros y privados. En el contexto de Kubernetes, la información valiosa suele incluir también sus configuraciones, secretos, la base de datos etcd, los volúmenes persistentes, etc.
• Una configuración adecuada de la estrategia de copias de seguridad puede ofrecer una gran versatilidad y funcionalidad a un entorno de Kubernetes, incluyendo copias de seguridad a nivel de aplicación, copias de seguridad a nivel de espacio de nombres, instantáneas, validación de copias de seguridad, control de versiones, políticas de copias de seguridad y muchas otras.
• Una configuración correcta de la restauración es igual de importante, teniendo en cuenta la cantidad de partes diferentes del proceso que pueden fallar potencialmente. Las pruebas rigurosas de las copias de seguridad, el asesoramiento en materia de documentación y la vigilancia constante durante la recuperación forman parte de lo que hay que mantener para que los procesos de recuperación tengan éxito.
• Las copias de seguridad de Kubernetes pueden encontrarse con una serie de retos, ya sean problemas de consistencia de los datos, normas de cumplimiento, seguridad de los datos o compatibilidad de versiones, entre otros. La buena noticia es que la mayoría de estos escollos pueden evitarse o mitigarse con un cierto nivel de preparación.

¿Por qué son necesarias las copias de seguridad de K8s?

Un entorno de Kubernetes es dinámico, distribuido y intrínsecamente más propenso a la pérdida de datos que una infraestructura convencional. Esta sección aborda los diversos factores de fallo que hacen que las copias de seguridad sean indispensables, las diferentes categorías de fallo, las estrategias de recuperación correspondientes y la necesidad de que las necesidades de copia de seguridad se documenten explícitamente en los SLA y los runbooks.

¿A qué riesgos se enfrentan los clústeres de Kubernetes sin copias de seguridad?

En un entorno de Kubernetes, existen peligros que van más allá de los problemas habituales de la infraestructura.

• Los ataques dirigidos a la cadena de suministro contra imágenes de contenedores o repositorios Helm pueden introducir fácilmente código malicioso que es difícil de detectar antes de que cause daños
• Los roles de IAM en la nube que se han configurado incorrectamente pueden exponer —o, lo que es peor, dañar— los recursos del clúster a gran escala
• Los eventos de autoescalado pueden pillar rápidamente desprevenidas a las cargas de trabajo con estado, causando una corrupción de datos invisible pero permanente

Riesgos como estos pueden multiplicarse con extrema rapidez en sistemas distribuidos, donde el alcance de un solo evento puede extenderse a docenas de cargas de trabajo en docenas de espacios de nombres.

¿En qué se diferencian los fallos de aplicaciones, clústeres y datos?

Los fallos de Kubernetes suelen producirse en diferentes capas y, en consecuencia, tienen estrategias de recuperación diferentes. El fallo puede afectar solo a una única carga de trabajo, puede afectar a todo el clúster o puede afectar a los datos almacenados externamente a ambos. Las secciones siguientes abordarán cada uno de estos fallos con más detalle, pero conocer esta distinción de antemano también sienta las bases para comprender por qué una estrategia de «una copia de seguridad para todo» rara vez tiene éxito.

¿Cuándo deben formar parte las copias de seguridad de sus SLA y guías de procedimientos?

Las copias de seguridad deben ser obligatorias cuando una carga de trabajo tiene un RTO y/o un RPO definidos. Si se ha comprometido con un objetivo de tiempo de recuperación, esa métrica debe ir acompañada de un proceso de restauración documentado y probado, lo que significa que la frecuencia de las copias de seguridad, la retención y el proceso de restauración deben documentarse antes de que se produzca un incidente, no después.

Las cargas de trabajo que figuran en un manual de procedimientos de guardia deben estar contabilizadas con una titularidad explícita y una política de copias de seguridad documentada. Los entornos regulados por normas de cumplimiento añaden su propia capa al proceso, exigiendo pruebas de que las copias de seguridad existen, se prueban y cumplen las políticas de retención documentadas necesarias.

El valor de las copias de seguridad de Kubernetes

La propia naturaleza de los entornos de Kubernetes dificulta que los sistemas y técnicas de copia de seguridad más tradicionales funcionen bien en el contexto de los nodos y aplicaciones de Kubernetes. Tanto el RPO como el RTO pueden ser, de hecho, mucho más críticos, ya que las aplicaciones que forman parte de una implementación operativa deben estar constantemente en funcionamiento, especialmente los elementos de infraestructura crítica.

Esto nos lleva a identificar elementos clave de continuidad del negocio que son prácticamente necesarios para toda empresa en general y una clara necesidad en lo que respecta a las mejores prácticas de copia de seguridad de K8s: copia de seguridad y recuperación, alta disponibilidad local, recuperación ante desastres, protección contra el ransomware, error humano, etc. En un entorno de Kubernetes, el contexto de estos aspectos de la copia de seguridad puede variar ligeramente con respecto a su definición habitual.

Alta disponibilidad local

La alta disponibilidad local, como característica, se refiere más bien a la prevención de fallos o la protección desde dentro de un centro de datos específico o entre zonas de disponibilidad (si hablamos de la nube, por ejemplo). Un fallo «local» se produce en la infraestructura, el nodo o la aplicación utilizados para ejecutar la aplicación. En un escenario ideal, su solución de copia de seguridad de Kubernetes debería ser capaz de reaccionar ante este fallo manteniendo la aplicación en funcionamiento, lo que esencialmente significa que no se produzca ningún tiempo de inactividad para el usuario final. Uno de los ejemplos más comunes de fallo local es un volumen en la nube bloqueado que se produce tras un fallo de nodo.

Desde esta perspectiva, la alta disponibilidad local como característica puede considerarse una parte fundamental de la estrategia de protección de datos. Por un lado, para llevar a cabo dicha tarea, su solución debe ofrecer algún tipo de sistema de replicación de datos a nivel local, y además debe estar en la ruta de datos en primer lugar. Es importante mencionar que proporcionar disponibilidad local mediante la restauración de copias de seguridad sigue considerándose copia de seguridad y restauración, y no alta disponibilidad local, debido al tiempo de recuperación total.

Copia de seguridad y restauración

La copia de seguridad y la restauración son otro elemento importante de un sistema Kubernetes operativo. En la mayoría de los casos de uso, se realiza una copia de seguridad de toda la aplicación desde un clúster local de Kubernetes a una ubicación externa. El contexto de Kubernetes también plantea otra consideración importante: si el software de copia de seguridad «entiende» o no lo que incluye una aplicación de Kubernetes, como por ejemplo:

• Configuración de la aplicación;
• Recursos de Kubernetes;
• Datos

Una copia de seguridad correcta de Kubernetes debe guardar todas las partes anteriores como una sola unidad para que resulte útil en el sistema Kubernetes tras su restauración. Centrarse en máquinas virtuales, servidores o discos específicos no significa que el software «entienda» las aplicaciones de Kubernetes. Lo ideal es que el software de Kubernetes sea capaz de realizar copias de seguridad de aplicaciones específicas, de grupos específicos de aplicaciones, así como de todo el espacio de nombres de Kubernetes. Esto no quiere decir que sea completamente diferente del proceso de copia de seguridad habitual: las copias de seguridad de Kubernetes también pueden beneficiarse enormemente de algunas de las características habituales de una copia de seguridad convencional, como la retención, la programación, el cifrado, la organización en niveles, etc.

Recuperación ante desastres

La capacidad de recuperación ante desastres (DR) es esencial para cualquier organización que utilice Kubernetes en una situación de misión crítica, al igual que lo es al emplear cualquier otra tecnología. En primer lugar, la DR debe «comprender» el contexto de las copias de seguridad de Kubernetes, al igual que la copia de seguridad y la restauración. También puede tener diferentes niveles tanto de RTO como de RPO y diferentes niveles de protección según estos niveles. Por ejemplo, podría existir un requisito estricto de RPO cero que implique un tiempo de inactividad estrictamente nulo, o podría haber un RPO de 15 minutos con requisitos algo menos estrictos. Tampoco es infrecuente que diferentes aplicaciones tengan RTO y RPO completamente distintos dentro de la misma base de datos.

Otra distinción importante de un sistema de recuperación ante desastres específico para Kubernetes es que también debería ser capaz de trabajar con metadatos hasta cierto punto (etiquetas, réplicas de aplicaciones, etc.). La incapacidad de proporcionar esta característica podría conducir fácilmente a una recuperación inconexa en general, así como a una pérdida general de datos o a un tiempo de inactividad adicional.

Protección contra el ransomware

La importancia de las copias de seguridad de los sistemas Kubernetes (especialmente aquellos que generan datos persistentes) rivaliza con la de las copias de seguridad de datos habituales. Los datos valiosos deben protegerse para evitar riesgos inaceptables. La información es invaluable, y Bacula Systems recomienda encarecidamente contar con un plan específico (o varios) para situaciones en las que los datos empresariales se corrompan o se vean comprometidos de cualquier otra forma.

Muchas de estas medidas de protección funcionan eficazmente tanto contra incidentes accidentales como contra ataques maliciosos. Los ataques intencionados que provocan filtraciones de datos mediante ransomware, suplantación de identidad y otras medidas se han vuelto demasiado habituales, y es totalmente irrealista pensar que su empresa nunca será objeto de un incidente de este tipo. Por ello, prepararse para estas situaciones puede ofrecer ventajas en lo que respecta a una serie de factores extremadamente importantes, como el cumplimiento normativo, la protección de la reputación personal y empresarial, la protección de clientes y empleados y, sobre todo, evitar en general daños graves a una empresa o organización.

Error humano

La gravedad de un solo error humano puede ser significativa (eliminaciones accidentales, configuraciones incorrectas, implementación involuntaria de actualizaciones). Si bien la automatización de algunas funciones puede mitigar en cierta medida los errores humanos, suele ser imposible automatizar todos y cada uno de los procesos en la mayoría de las empresas.

En este contexto, los planes de copia de seguridad y recuperación ante desastres sirven para garantizar que una empresa pueda continuar con su actividad de manera eficaz tras un incidente relacionado con un comando incorrecto o un error de configuración.

Las ventajas de las operaciones de copia de seguridad de Kubernetes

Las copias de seguridad de Kubernetes presentan múltiples ventajas, a menudo similares a las operaciones de copia de seguridad habituales en cualquier otro tipo de datos. Constituyen una excelente forma de mantener la fiabilidad, la disponibilidad y la integridad de las aplicaciones y los datos de Kubernetes. A continuación se presentan algunas de las ventajas más comunes.

Mitigación del impacto de los fallos de hardware

Desde el punto de vista técnico, los fallos de hardware son inevitables y pueden producirse prácticamente en cualquier momento; ya sea un fallo de red, un corte de suministro eléctrico, un mal funcionamiento de una unidad de almacenamiento o cualquier otro tipo de incidente que provoque la corrupción o la pérdida de datos. Las copias de seguridad de Kubernetes pueden ofrecer un alto nivel de protección frente a tales situaciones al proporcionar una copia redundante de la información que puede restaurarse en cualquier otro entorno si el hardware original ya no está disponible, minimizando así el tiempo de inactividad y mejorando la continuidad del negocio.

Recuperación ante desastres

La mayoría de los desastres naturales son capaces de destruir por completo toda la infraestructura física de una empresa, incluidos sus clústeres de Kubernetes y, posiblemente, incluso las copias de seguridad primarias de dichos clústeres. La existencia de una copia de seguridad externa es, por lo tanto, una de las muchas ventajas que la estrategia de recuperación ante desastres ofrece a sus usuarios, proporcionando una forma de reconstruir rápidamente toda la red de clústeres para reanudar las operaciones en un plazo de tiempo aceptable.

Prevención de la pérdida de datos

Los errores accidentales y la mala gestión siguen siendo sorprendentemente comunes a día de hoy, al margen del creciente número de violaciones de datos maliciosas. Todo ser humano puede cometer errores, y la imposibilidad de revertir una determinada acción, eliminación o modificación aumenta drásticamente la probabilidad de una pérdida permanente de datos en el caso de la información confidencial. Las copias de seguridad periódicas de K8s ayudan a garantizar que los accidentes causados de forma involuntaria puedan recuperarse de una forma u otra.

Defensa contra ciberataques

Las amenazas cibernéticas llevan varios años aumentando de forma significativa, y se prevé de forma casi unánime que la situación se deteriore aún más. Toda infraestructura de TI está constantemente expuesta al riesgo de un ciberataque, y la existencia de medidas de copia de seguridad definidas y seguras es fundamental para proteger a las empresas en su conjunto. No hacerlo supone un riesgo significativo para la propia continuidad de la empresa.

Asistencia para entornos de pruebas y desarrollo

Las copias de seguridad periódicas de los clústeres de Kubernetes suelen tener un valor añadido: también pueden ser de gran ayuda en los procesos de pruebas y desarrollo, simplificando considerablemente la creación de réplicas de clústeres con fines de desarrollo sin afectar a los datos originales. De este modo, la experimentación puede resultar mucho más fructífera y eficiente, ofreciendo numerosas oportunidades de desarrollo para la propia empresa.

Tipos de datos de Kubernetes que deben incluirse en las copias de seguridad

La razón habitual por la que se emplea la contenedorización es crear y ejecutar un entorno de ejecución seguro, fiable y ligero para las aplicaciones, creando un sistema que sea coherente de un host a otro. Por lo general, estos sistemas generan datos persistentes y, cuando esto ocurre, dichos datos suelen ser valiosos y, por lo tanto, deben incluirse en las copias de seguridad. Además, todo el sistema de contenedores en sí mismo debe protegerse y respaldarse para que, si se produce algún tipo de pérdida o corrupción, el sistema pueda recuperarse rápidamente, minimizando la pérdida de sistemas y servicios —y el potencial negocio— para una organización.

Kubernetes es la tecnología de contenedores más popular en uso hoy en día. Como tal, el tema de los diferentes tipos de datos de Kubernetes que deben respaldarse requiere un examen exhaustivo.

Al igual que cualquier sistema complejo, Kubernetes y Docker cuentan con una serie de tipos de datos específicos que serán necesarios para reconstruir correctamente toda la base de datos en caso de desastre. Para simplificar, es posible dividir todos los tipos de datos y archivos de configuración en dos categorías diferentes: configuración y datos persistentes.

La configuración (y la información sobre el estado deseado) incluye:

• Base de datos etcd de Kubernetes
• Archivos Docker
• Imágenes de archivos Docker

Los datos persistentes (modificados o creados por los propios contenedores) son:

• Bases de datos
• Volúmenes persistentes

Base de datos etcd de Kubernetes

Es una parte integral del sistema que contiene información sobre el estado de los clústeres. Se puede realizar una copia de seguridad de forma manual o automática, dependiendo de su solución de copia de seguridad. El método manual se realiza mediante el comando etcdctl snapshot save db, que crea un único archivo con el nombre snapshot.db.

Otro método para lograr lo mismo consiste en ejecutar ese mismo comando justo antes de crear una copia de seguridad del directorio en el que aparecería este archivo. Esta es una de las formas de integrar esta copia de seguridad específica en todo el entorno.

Archivos Docker

Dado que los propios contenedores Docker se ejecutan a partir de imágenes, estas imágenes deben basarse en algo, y estas, a su vez, se crean a partir de archivos Docker. Para una configuración correcta de Docker, se recomienda utilizar un repositorio como sistema de control de versiones para la totalidad de sus archivos Docker (GitHub, por ejemplo). Con el fin de facilitar la recuperación de versiones anteriores, todos los archivos Docker deben almacenarse en un repositorio específico que permita a los usuarios recuperar versiones anteriores de dichos archivos si fuera necesario.

También se recomienda un repositorio adicional para los archivos YAML asociados a todas las implementaciones de Kubernetes; estos existen en forma de archivos de texto. Realizar copias de seguridad de estos repositorios es igualmente imprescindible, ya sea utilizando herramientas de terceros o las capacidades integradas de plataformas como GitHub.

Es importante mencionar que aún puede generar los archivos Docker de los que desea realizar una copia de seguridad, incluso si está ejecutando contenedores a partir de imágenes sin sus archivos Docker. Existe un comando específico, docker image history, que le permite crear un archivo Docker a partir de su imagen actual. También hay varias herramientas de terceros que pueden hacer lo mismo.

Imágenes a partir de archivos Docker

Las propias imágenes de Docker también deben guardarse en un repositorio. Tanto el repositorio privado como el público pueden utilizarse para ese fin concreto. Varios proveedores de nube también suelen ofrecer repositorios privados a sus clientes. Si le falta la imagen desde la que se ejecuta su contenedor, un comando específico llamado docker commit debería permitirle crear dicha imagen.

Bases de datos

La integridad también es crucial cuando se trata de las bases de datos que los contenedores utilizan para almacenar sus datos. En algunos casos, es posible apagar el contenedor en cuestión antes de crear una copia de seguridad de los datos, pero, de nuevo, el tiempo de inactividad necesario probablemente acarreará muchos problemas para la empresa en cuestión.

Otro método para realizar copias de seguridad de bases de datos dentro de contenedores consiste en conectarse al propio motor de la base de datos. Se debe utilizar previamente un montaje vinculado (bind mount) para adjuntar un volumen del que se pueda realizar una copia de seguridad, y a continuación puede utilizar el comando mysqldump (o similar) para crear una copia de seguridad. Posteriormente, también se debe realizar una copia de seguridad del archivo de copia de seguridad en cuestión utilizando su sistema de copias de seguridad.

Volúmenes persistentes

Existen diferentes métodos para que los contenedores obtengan acceso a algún tipo de almacenamiento persistente. Por ejemplo, si se trata de volúmenes tradicionales de Docker, estos residen en un directorio situado bajo la configuración de Docker. Los montajes vinculados, por otro lado, pueden ser cualquier directorio que se monte dentro de un contenedor. A pesar de que los volúmenes tradicionales son preferibles en la comunidad de Docker, ambos son relativamente iguales en lo que respecta a la copia de seguridad de los datos. Una tercera forma de realizar la misma operación consiste en montar un directorio NFS o un único objeto como volumen dentro de un contenedor.

Estos tres métodos comparten el mismo problema a la hora de realizar copias de seguridad de los datos: la coherencia de la copia de seguridad no es completa si los datos dentro del contenedor cambian durante el proceso. Por supuesto, siempre es posible garantizar la coherencia apagando el volumen antes de realizar la copia de seguridad, pero en la mayoría de los casos, el tiempo de inactividad de dichos sistemas no es viable en aras de la continuidad del negocio.

Existen algunas formas de realizar copias de seguridad de datos dentro de contenedores que son específicas de cada método. Por ejemplo, los volúmenes tradicionales de Docker podrían montarse en otro contenedor que no modificara ninguno de los datos hasta que el proceso de copia de seguridad se completara. O si utiliza un volumen montado mediante bind, es posible crear una imagen tar de todo el volumen y, a continuación, realizar una copia de seguridad de dicha imagen.

Lamentablemente, todas esas opciones pueden resultar muy difíciles de llevar a cabo cuando se trata de Kubernetes. Precisamente por ese motivo, siempre se recomienda almacenar la información con estado en la base de datos y fuera del sistema de archivos del contenedor.

Dicho esto, si utiliza un directorio montado mediante bind o un sistema de archivos montado mediante NFS como almacenamiento persistente, también es posible realizar una copia de seguridad de esos datos utilizando métodos habituales, como una instantánea. Esto debería proporcionarle mucha más coherencia que la copia de seguridad tradicional a nivel de archivo del mismo volumen.

¿Qué debe copiar en un entorno de Kubernetes?

Existen diferentes tipos de datos en un entorno de Kubernetes, y cada tipo requiere sus propias consideraciones de recuperación. Es fácil comprender qué hay que respaldar; donde la mayoría de los equipos tienen dificultades es en determinar qué componentes deben respaldarse y por qué. Comprender qué hay que respaldar es la parte fácil; sin embargo, a la mayoría de los equipos les cuesta decidir qué componentes deben tener prioridad y por qué.

¿Qué recupera y qué no recupera realmente una copia de seguridad de etcd?

Etcd es la única fuente de verdad sobre el estado de todo su clúster. Como tal, es lo más importante que hay que respaldar y, al mismo tiempo, el componente más malinterpretado. Una instantánea de etcd le permite revertir el estado de todo su clúster a un momento determinado, pero si su clúster en producción se ha adelantado demasiado a su instantánea, acabará encontrando inconsistencias entre lo que etcd indica que está en ejecución y lo que realmente hay.

Una instantánea de etcd por sí sola es insuficiente para recuperar completamente su clúster en un escenario de desastre, ya que, aunque contiene el estado del clúster, no contiene ningún dato de la aplicación (que se almacena en volúmenes persistentes) y no garantiza que el estado revertido coincida con el estado del clúster que ha reconstruido. Las copias de seguridad a nivel de aplicación son las que proporcionan esa información que falta, y es importante tratar las instantáneas de etcd como un complemento de las copias de seguridad a nivel de aplicación, en lugar de como un sustituto de estas.

¿Es necesario realizar copias de seguridad de los volúmenes persistentes (PV) y de las reclamaciones de volumen persistente (PVC)?

Sí, es necesario realizar copias de seguridad tanto de los PV como de los PVC, pero su prioridad depende de lo que contengan exactamente. Algunos PV contienen datos mucho más valiosos que otros: un PV que proporciona persistencia a una base de datos con estado no presenta el mismo factor de riesgo que un PV que almacena contenido en caché.

Antes de elegir la frecuencia de las copias de seguridad, es recomendable clasificar los PV por nivel de criticidad de recuperación para garantizar que su plan de copias de seguridad refleje las necesidades del negocio y no conceda la misma importancia a todos los volúmenes.

¿Qué metadatos del clúster (manifiestos, RBAC, CRD, mapas de configuración, secretos) son esenciales?

Todos estos metadatos son importantes, pero no al mismo nivel cuando se trata de escenarios de recuperación en los que el tiempo es un factor crítico.

Perder la configuración de RBAC y los CRD es la opción más perjudicial en este caso, ya que definen lo que se le permite hacer y lo que el resto del clúster utiliza como definiciones de recursos. Sin esta información, es muy probable que las aplicaciones que restaure vuelvan a estar en un estado inaccesible o defectuoso.

ConfigMaps y secretos también definen cómo funcionan sus aplicaciones, y suelen ser los elementos más olvidados en una estrategia de copia de seguridad manual. Los manifiestos también son muy importantes, pero si dispone de un sistema GitOps, debería ser relativamente sencillo recuperarlos del control de código fuente, lo que los sitúa un poco más abajo en la lista de prioridades.

¿Cómo debe tratar los datos efímeros y los registros?

Datos efímeros: cualquier elemento que solo exista durante la vida útil de un pod no suele requerir copia de seguridad, y tratar de hacerlo añade complejidad sin aportar un valor significativo para la recuperación.

Los registros suelen encontrarse en una situación similar: no se supone que deban incluirse en una estrategia de copia de seguridad de Kubernetes. La opción más recomendable es disponer de un canal de observabilidad dedicado que envíe estos registros a un almacenamiento externo, independientemente del proceso de copia de seguridad.

Una pregunta más adecuada en este caso sería si algún dato que actualmente considere efímero necesitaría persistir. Si es así, debería transferirse a un volumen persistente en lugar de incluirse en el ámbito de la copia de seguridad.

¿Cómo afecta GitOps a su estrategia de copias de seguridad de Kubernetes?

GitOps es un modelo operativo en el que el repositorio Git almacena el estado completo de un entorno de Kubernetes, con todos los manifiestos, definiciones de recursos y configuraciones. La información en cuestión también se reconcilia continuamente con el clúster en vivo con la ayuda de una herramienta dedicada. En lugar de aplicar los cambios directamente a su clúster, estos pasan primero por Git, lo que convierte al repositorio en cuestión en una única fuente de verdad sobre cómo debería verse el clúster en cualquier momento.

Se ha convertido rápidamente en un patrón generalizado en entornos de Kubernetes, cambiando la ecuación de las copias de seguridad de maneras específicas, y las implicaciones de esto tampoco son siempre sencillas. Es esencial saber dónde ayuda y dónde se detiene antes de decidir cuánta cobertura de copia de seguridad añadirle.

¿Cómo cambia GitOps su enfoque de la copia de seguridad de la configuración?

Si sus manifiestos de Kubernetes, configuraciones RBAC y definiciones de recursos se almacenan en Git y se concilian continuamente mediante una herramienta como ArgoCD o Flux, ya dispone de una forma de copia de seguridad de la configuración con control de versiones.

Cualquier recurso declarativo que resida en su repositorio de Git puede reaplicarse a un clúster nuevo o recuperado sin necesidad de una copia de seguridad independiente de dicho recurso. Esto supone una simplificación significativa del proceso de configuración de copias de seguridad, ya que los manifiestos y las descripciones de recursos del clúster que ya se gestionan con GitOps pueden pasar a ser elementos de menor prioridad en su estrategia de copias de seguridad dedicada.

¿Qué es lo que no cubre GitOps y en qué casos siguen siendo necesarias las copias de seguridad dedicadas?

GitOps gestiona el estado deseado, no el estado en tiempo de ejecución ni los datos. Como tal, los volúmenes persistentes, los secretos no confirmados en Git, el contenido de las bases de datos y los estados que solo existen dentro de un clúster en ejecución son invisibles para él.

Un clúster gestionado íntegramente por GitOps puede sufrir igualmente una pérdida masiva de datos si los volúmenes persistentes no se respaldan de forma independiente. Los secretos suelen excluirse explícitamente de los repositorios debido a implicaciones de seguridad, por lo que también requieren una cobertura de respaldo independiente.

GitOps no es una alternativa a una estrategia de copias de seguridad; por el contrario, son complementarios, y reconocer la frontera entre ambos ayuda a evitar suposiciones erróneas sobre lo que está cubierto.

Prácticas recomendadas para las operaciones de copia de seguridad de Kubernetes

Existen varias prácticas recomendadas que pueden utilizarse para mejorar el estado general de las copias de seguridad de K8s, incluyendo la resiliencia del clúster, la seguridad de los datos y la fiabilidad de la recuperación.

Realice copias de seguridad de los datos persistentes y del estado del clúster

El estado del clúster incluye componentes clave para un entorno de Kubernetes, como secretos, ConfigMaps, etcd y otros. Los volúmenes de datos persistentes constituyen la mayor parte del tamaño de los datos, con archivos normales, bases de datos, datos de usuario, registros, etc.

Configure la automatización de las copias de seguridad

La automatización de las copias de seguridad reduce la probabilidad de error humano e introduce un elemento de coherencia y previsibilidad en el proceso de copia de seguridad. Existen numerosas soluciones de copia de seguridad de terceros que ofrecen capacidades avanzadas de automatización, como la posibilidad de planificar programas de copia de seguridad teniendo en cuenta RTO y RPO específicos.

Utilice diferentes tipos de copia de seguridad siempre que sea posible

Los datos de Kubernetes pueden copiarse utilizando diferentes enfoques de copia de seguridad, si el software lo permite. Por ejemplo, las copias de seguridad incrementales pueden ofrecer una reducción significativa del espacio de almacenamiento total ocupado, ya que solo capturan la información que ha sido modificada de alguna manera desde la última copia de seguridad.

Compruebe los datos respaldados

Los respaldos no se vuelven invulnerables tan pronto como se crean, y existe la posibilidad de que la información se haya dañado o perdido de alguna manera durante el proceso. Realizar pruebas de restauración de forma regular facilita la detección de dichos errores y su resolución antes de que se produzca cualquier tipo de desastre.

Implemente el cifrado de respaldos

Se debe implementar el cifrado de respaldos, cuando sea necesario, tanto para la información en tránsito como en reposo, a fin de garantizar el mayor nivel de seguridad posible. El cifrado ayuda a proteger los datos contra filtraciones y accesos no autorizados. Existen numerosos algoritmos de cifrado entre los que elegir, siempre que la solución de copia de seguridad los admita.

Considere el uso de almacenamiento inmutable

El uso de estrategias de inmutabilidad de datos puede ser un componente importante de una estrategia de copia de seguridad. Algunas soluciones de copia de seguridad ofrecen inmutabilidad de software, mientras que otras proporcionan opciones de hardware dedicadas, como WORM (write-once-read-many), para proteger la información contra las amenazas cibernéticas.

Tenga en cuenta las políticas de retención y el control de versiones

El control de versiones es el proceso de almacenar copias anteriores de su información por motivos de cumplimiento normativo o por conveniencia. Una política de retención correctamente configurada debe especificar cuál va a ser el periodo de retención para encontrar el equilibrio entre el consumo de almacenamiento y el cumplimiento de todos los requisitos necesarios.

Compruebe las capacidades de copia de seguridad multiclúster

Si su entorno actual utiliza varios clústeres de Kubernetes, puede ser fundamental asegurarse de que su solución de copia de seguridad ofrezca copias de seguridad centralizadas. La capacidad de gestionar varios entornos a la vez puede simplificar enormemente el proceso de copia de seguridad y mejorar la comodidad general de trabajar en un entorno de este tipo.

Implemente un software de copia de seguridad nativo de la nube

La compatibilidad con infraestructuras dinámicas en la nube es una característica importante para cualquier solución de copia de seguridad de Kubernetes competente. Una de las razones es que los servicios en constante evolución que ofrece la computación en la nube pueden aportar beneficios de seguridad adicionales a una organización. Asegurarse de que el software de copia de seguridad que elija sea nativo de la nube y pueda integrarse con diferentes servicios de almacenamiento en la nube puede ser fundamental.

Reflexione sobre su estrategia completa de recuperación ante desastres

Las estrategias de copia de seguridad suelen ser mejores si se diseñan teniendo en cuenta la recuperación ante desastres, y Kubernetes no es una excepción. Por ejemplo, asegurarse de que las copias de seguridad se puedan restaurar en diferentes clústeres cubriría situaciones como la migración o un fallo completo del clúster. Por otra parte, la compatibilidad con copias de seguridad entre nubes y entre regiones permite resolver problemas centrados en la nube o cortes de suministro regionales.

Garantice la seguridad de los secretos de Kubernetes

Los secretos de Kubernetes incluyen gran cantidad de información confidencial que merece la pena proteger: contraseñas, claves API, certificados, etc. Este tipo de información debe recibir la máxima prioridad en materia de seguridad de datos, con cifrado completo, inmutabilidad de los datos, etc.

Intente optimizar el coste del almacenamiento de copias de seguridad

Si es posible, suele ser importante implementar diversas técnicas de gestión del almacenamiento para reducir el tamaño total de las copias de seguridad en su entorno de almacenamiento. La compresión y la deduplicación son igualmente eficaces para ello, pero ambas tienen sus propias desventajas. Lo mismo podría decirse de la mayoría de las estrategias de ahorro de almacenamiento específicas de la nube.

Supervise los procesos de copia de seguridad de forma regular

Quizás no sea razonable esperar que alguien vigile los procesos de copia de seguridad automatizados las 24 horas del día, los 7 días de la semana. Por ello, deben implementarse sistemas dedicados de supervisión y notificación para garantizar que todo funcione correctamente. La mayoría de las soluciones cuentan incluso con una opción para enviar una notificación específica a una persona concreta si se detecta algún tipo de irregularidad durante el proceso de copia de seguridad.

Implemente copias de seguridad a nivel de espacio de nombres para clústeres multitenant

Los entornos multitenant mencionados anteriormente pueden gestionarse con la ayuda de copias de seguridad a nivel de espacio de nombres. De ese modo, la información de cada tenant dispondría de un archivo de copia de seguridad independiente, lo que limitaría la posible exposición de datos entre tenants al tiempo que ofrecería una gran flexibilidad para los procesos de recuperación.

Proporcione documentación para todo el proceso de copia de seguridad y recuperación

Todo el proceso de copia de seguridad y recuperación debe estar bien documentado, incluyendo instrucciones detalladas sobre cómo se configura, supervisa y verifica una copia de seguridad, entre otros aspectos. La misma lógica se aplica a los procesos de restauración. Dicha documentación también debe abarcar las funciones y responsabilidades de los empleados encargados de las tareas de administración de copias de seguridad.

¿Cómo debe diseñar los calendarios de copia de seguridad y las políticas de retención de Kubernetes?

Saber qué hay que copiar es solo la mitad del camino. La otra mitad consiste en decidir con qué frecuencia realizar las copias de seguridad y durante cuánto tiempo conservar los datos copiados. Los calendarios de copia de seguridad y las políticas de retención que no están vinculados a un objetivo de recuperación tangible acaban siendo invariablemente demasiado agresivos (lo que da lugar a un desperdicio de recursos de almacenamiento y computación) o demasiado infrecuentes (lo que da lugar a periodos irrecuperables tras un fallo).

¿Con qué frecuencia debe realizar copias de seguridad de etcd, PV y datos de aplicaciones?

No es necesario realizar copias de seguridad de cada componente con la misma frecuencia, ya que se trata de un error común. Etcd cambia constantemente junto con el estado del clúster, por lo que una instantánea cada hora es suficiente en la mayoría de entornos de producción. Sin embargo, un clúster que cambia rápidamente y con una alta rotación en las implementaciones o configuraciones podría requerir instantáneas más frecuentes.

Los volúmenes persistentes que contienen datos transaccionales o generados por el usuario deben ser objeto de instantáneas al menos con la frecuencia que permita su RPO, ya que es ahí donde residen los datos más significativos desde el punto de vista operativo. Las copias de seguridad a nivel de aplicación pueden ser menos frecuentes en la mayoría de los casos, siempre que la propia aplicación tenga un cierto grado de tolerancia para la reproducción de eventos o la reconstrucción del estado. Sin embargo, esa tolerancia debe validarse exhaustivamente con respecto al RPO actual antes de incorporarla a su programación, en lugar de tratarla como una suposición segura.

¿Qué ventanas de retención se ajustan a los requisitos de RPO y RTO?

Dos preguntas deben guiar la retención:

• ¿Hasta cuándo realmente necesita recuperar los datos?
• ¿Con qué rapidez necesita poder recuperar los datos?

Un RPO bajo no implica una retención prolongada, por lo que conservar instantáneas por hora durante 30 días rara vez resulta práctico y suele ser costoso. Una práctica más recomendable sería utilizar la retención por niveles: copias de seguridad de menor duración y alta frecuencia para la recuperación operativa, combinadas con copias de seguridad de mayor duración pero menos frecuentes con fines de auditoría o cumplimiento normativo. La clave es que las ventanas de retención deben ser aprobadas explícitamente por quien sea responsable del SLA de recuperación, y no decididas unilateralmente por el equipo que realiza las copias de seguridad.

¿Cómo pueden el ciclo de vida y la clasificación por niveles reducir los costes de las copias de seguridad?

El coste del almacenamiento de copias de seguridad para clústeres de Kubernetes puede dispararse rápidamente, especialmente cuando se trabaja con grandes volúmenes persistentes o se realizan instantáneas con frecuencia. La implementación de una política de ciclo de vida ayuda a reducir los costes de forma drástica sin mermar su capacidad de recuperación.

Las políticas de ciclo de vida archivan automáticamente las copias de seguridad en niveles de almacenamiento más económicos a medida que envejecen, pasando, por ejemplo, del almacenamiento en bloques de alto rendimiento al almacenamiento de objetos tras un determinado periodo. Sin embargo, esto conlleva una contrapartida, ya que los niveles de almacenamiento más económicos suelen conllevar tiempos de recuperación más largos.

Antes de implementar políticas de ciclo de vida, es importante revisar los tiempos de recuperación de cada uno de los niveles más económicos y comprobar si se ajustan a su RTO para los puntos de recuperación más antiguos. La mayoría de los principales proveedores de nube incluyen soporte nativo para políticas de ciclo de vida dentro de sus soluciones de almacenamiento de objetos, por lo que la implementación de dichas políticas debería suponer poca o ninguna dificultad en la mayoría de los casos, una vez que haya determinado su período de retención.

¿Cómo se protegen las copias de seguridad de Kubernetes y se cumplen los requisitos de cumplimiento normativo?

Programar las copias de seguridad es solo una pieza del rompecabezas operativo. Proteger realmente las propias copias de seguridad y demostrar el cumplimiento de la legislación de gobernanza pertinente son dos retos distintos que a menudo se abordan demasiado tarde en el ciclo de vida. El mero valor de los datos de copia de seguridad —como imagen completa de la infraestructura— los convierte en un objetivo atractivo, y cada vez se presta más atención a los requisitos de gobernanza que los afectan.

¿Cómo deben cifrarse los datos de copia de seguridad en reposo y en tránsito?

La decisión arquitectónica crítica en este contexto no se refiere realmente a qué algoritmo de cifrado utilizar (ya que la mayoría de los productos de copia de seguridad actuales tienen un valor predeterminado que debería mantener de todos modos), sino más bien a asegurarse de que el cifrado se aplique de extremo a extremo.

Si los datos en reposo están cifrados, pero el tránsito entre el clúster y el destino de almacenamiento no lo está, los datos no estarán seguros durante la transferencia. Si las claves de cifrado se almacenan muy cerca de los datos de copia de seguridad que están cifrando, es probable que tampoco sean seguras.

Las claves de cifrado deben almacenarse separadamente del destino de la copia de seguridad, ya sea con la ayuda de un servicio de gestión de claves o de un módulo de seguridad de hardware. El acceso a dichas claves también debe gestionarse únicamente por una entidad que tenga permiso para acceder a la propia copia de seguridad.

¿Quién debe tener acceso a las funciones de copia de seguridad y restauración?

El acceso a la restauración se equipara con frecuencia al acceso a la copia de seguridad, pero tienen implicaciones de riesgo completamente diferentes. La capacidad de restaurar una copia de seguridad, potencialmente en un clúster o espacio de nombres independiente, equivale a poder reubicar datos confidenciales y, por lo tanto, conlleva un requisito de control mayor que el de la simple creación de la propia copia de seguridad.

En la práctica, la creación de copias de seguridad puede automatizarse de forma razonable y permitirse de manera generalizada, mientras que las operaciones de restauración deben requerir una autorización explícita —idealmente con un segundo aprobador para los entornos de producción—. Esa distinción debe reflejarse en su configuración de RBAC y documentarse con suficiente claridad como para sobrevivir a los cambios de equipo.

¿Qué funciones de auditoría, registro y inmutabilidad son necesarias para el cumplimiento normativo?

Además de garantizar la existencia de las copias de seguridad, los marcos de cumplimiento también exigirán que una empresa pueda demostrar su existencia. Cada operación de copia de seguridad, intento de acceso y solicitud de restauración deberá ser auditable y conservarse de acuerdo con las necesidades de su marco, lo que significa que los registros deben redactarse de manera que sean a prueba de manipulaciones.

El almacenamiento inmutable, que impide la eliminación o modificación de los datos de copia de seguridad durante un periodo de tiempo específico, se está convirtiendo rápidamente en algo obligatorio en lugar de opcional en entornos que gestionan información privada o financiera, y tanto la HIPAA como la SOC 2 mencionan específicamente su necesidad.

Esto también significa que tanto al registro de auditoría como a los datos de los que se realiza la copia de seguridad se les debe otorgar la misma importancia: los datos de los que no se puede demostrar el cumplimiento ofrecen menos valor cuando los auditores llaman a la puerta.

Metodología para elegir la mejor solución de copia de seguridad de Kubernetes posible

Existe un buen número de soluciones de terceros que ofrecen capacidades de copia de seguridad de Kubernetes de una forma u otra. La copia de seguridad de K8s es una tarea muy importante, por lo que el tema de elegir una solución de copia de seguridad es igual de importante. En consecuencia, podemos ofrecer una metodología detallada sobre cómo elegir la mejor solución de copia de seguridad de Kubernetes posible para su organización específica.

Tipos de datos cubiertos por la solución

Comprobar si la solución de copia de seguridad ofrece la capacidad de admitir un tipo de datos requerido es una prioridad para cualquier empresa o negocio que busque una solución de copia de seguridad para Kubernetes. Por ello, hemos añadido información sobre de qué tipos de datos puede crear una copia de seguridad cada una de las soluciones de nuestra lista. El resultado general de esta comparación se presenta a continuación en una tabla (la tabla en cuestión se divide en dos partes para facilitar su visualización).

Tabla nº 1

Tabla #2

Cabe señalar que la compatibilidad con diferentes tipos de datos es un factor importante, pero no es un factor decisivo la mayoría de las veces, por lo que se recomienda encarecidamente considerarlo como uno de varios factores en esta comparación.

Valoraciones de los clientes

Las valoraciones de los clientes pueden interpretarse de muchas maneras: la calidad de la solución en su trabajo, su competencia con los comentarios de los clientes, su capacidad (o no) para evolucionar con el tiempo, etc. En nuestro caso, las valoraciones de clientes de terceros son un factor importante, pero no son determinantes la mayoría de las veces. En nuestro caso, las valoraciones de clientes de sitios web de terceros existen para mostrar la competencia general de la solución utilizando varios sitios web de recopilación de opiniones como Capterra, TrustRadius y G2.

Capterra es una plataforma agregadora de reseñas que ofrece reseñas verificadas, orientación, perspectivas y comparaciones de soluciones. Se comprueba minuciosamente que sus clientes son, de hecho, clientes reales de la solución en cuestión, y no existe la opción de que los proveedores eliminen las reseñas de los clientes. Capterra cuenta con más de 2 millones de opiniones verificadas en casi mil categorías diferentes, lo que la convierte en una gran opción para encontrar todo tipo de opiniones sobre un producto específico.

TrustRadius es una plataforma de opiniones que proclama su compromiso con la verdad. Utiliza un proceso de varios pasos para garantizar la autenticidad de las opiniones, y el propio equipo de investigación de la empresa comprueba que cada una de ellas sea detallada, profunda y exhaustiva. No hay forma de que los proveedores oculten o eliminen las reseñas de los usuarios de una forma u otra.

G2 es otro buen ejemplo de plataforma agregadora de reseñas que cuenta con más de 2,4 millones de reseñas verificadas hasta la fecha con más de 100.000 vendedores diferentes presentados. G2 tiene su propio sistema de validación de las opiniones de los usuarios, que se considera muy eficaz para demostrar que cada opinión es auténtica y genuina. G2 también ofrece servicios independientes con fines de marketing, así como de inversión, seguimiento y mucho más.

Características principales (así como ventajas/desventajas)

La lista de factores importantes que debe tener una solución de copia de seguridad de Kubernetes competente incluye los siguientes:

• Alta disponibilidad de datos para una mejor recuperación ante desastres y una mayor tolerancia a diversos problemas con clústeres y contenedores.
• Diferentes tipos de copia de seguridad, incluyendo copias de seguridad incrementales y app-aware.
• Granularidad de las copias de seguridad, con la capacidad de crear copias de seguridad de objetos específicos, y no sólo de namestates enteros (volúmenes, pods, PVs, etc.).
• Programación de copias de seguridad para simplificar las operaciones diarias.
• Integración con proveedores de almacenamiento en la nube (Azure Blob, GCP, S3, etc.) para un proceso de copia de seguridad más sencillo y más variedad en términos de almacenamiento de copias de seguridad.
• Capacidades de cifrado de datos para una mejor protección de la información.
• Soporte para cargas de trabajo personalizadas que permite la posibilidad de ampliar la funcionalidad de copia de seguridad a través de plugins e integraciones.

Esto también está representado por la categoría «ventajas/desventajas» (si procede), que muestra tanto los aspectos positivos como los negativos de la solución recogidos de multitud de opiniones de usuarios.

Precios

Las características de una solución son importantes para el usuario final, pero el tema del precio es igual de importante. Algunas empresas tienen un presupuesto muy limitado, y otras necesitan un conjunto de funciones específicas a pesar de un precio potencialmente elevado. Sin embargo, la mayoría de los clientes potenciales se sitúan entre estos dos ejemplos. Se recomienda encarecidamente comprobar tanto el precio como el conjunto de funciones de la solución y sopesarlos entre sí: aunque la solución se ajuste a su presupuesto, puede que no sea tan buena oferta por función como la de la competencia.

Una opinión personal del autor

La única parte completamente subjetiva de esta metodología es la opinión del autor sobre el tema (solución de copia de seguridad de Kubernetes, en nuestro caso). Hay un montón de casos de uso diferentes para esta categoría en particular, incluyendo información interesante sobre la solución que no encajaba en ninguna de las categorías anteriores o simplemente la opinión personal del autor sobre este tema específico.

Mercado de soluciones de backup para Kubernetes

En el contexto de estos tres importantes factores o características, veamos algunos ejemplos más de una solución de copia de seguridad y recuperación para K8s.

Kasten K10

Kasten K10 (recientemente adquirida por Veeam) es una solución de copia de seguridad y restauración que también se enorgullece de sus sistemas de movilidad y recuperación ante desastres. El proceso de copia de seguridad con Kasten se simplifica gracias a su capacidad para descubrir automáticamente las aplicaciones, así como a muchas otras características, como el cifrado de datos, el control de acceso basado en roles y una interfaz fácil de usar. Al mismo tiempo, puede trabajar con muchos servicios de datos diferentes, como MySQL, PostgreSQL, MongoDB, Cassandra, AWS, etc.

La alta disponibilidad local no está disponible con él, ya que Kasten no admite directamente la replicación dentro de un único clúster y, en su lugar, se basa en los sistemas de almacenamiento de datos subyacentes. La recuperación ante desastres también está solo parcialmente «ahí», ya que Kasten no puede lograr casos de RPO cero debido a la falta de un componente de ruta de datos. También cabe destacar el hecho de que las copias de seguridad de Kasten son únicamente asíncronas, lo que suele suponer un tiempo de inactividad adicional entre operaciones.

Tipos de datos cubiertos por Kasten K10:

Kasten K10 puede crear copias de seguridad de -usualmente- todos los datos que genera Kubernetes, incluyendo Servicios, Despliegues, PVs, Namespaces, etc. La cobertura de aplicaciones de Kasten también puede ampliarse y mejorarse a través de integraciones con otras soluciones de copia de seguridad y recuperación.

Valoraciones de los clientes:

• (Kasten) G2 – 4,7/5 estrellas basado en 10 reseñas de clientes.
• (Veeam) Capterra – 4,8/5 estrellas basado en 69 reseñas de clientes
• (Veeam) TrustRadius – 8,8/10 estrellas basadas en 1.237 opiniones de clientes
• (Veeam) G2 – 4,6/5 estrellas basadas en 387 opiniones de clientes

Características principales:

• Escalabilidad y eficacia impresionantes
• Protección contra ransomware altamente eficaz
• Creada utilizando principios arquitectónicos nativos de la nube.

Precios (en el momento de redactar este documento):

• La página de precios de Kasten K10 afirma que hay tres Ediciones del programa (aunque solo hay una Edición real, y las otras dos son la versión gratuita y la versión de prueba, respectivamente).
  • «Free» es una versión muy limitada de Kasten K10 con capacidades mínimas de copia de seguridad de Kubernetes, incluyendo hasta 5 nodos como máximo, así como operaciones de copia de seguridad/restauración, recuperación de desastres, protección contra ransomware y la mayoría de las otras capacidades de Kasten.
  • «Enterprise Trial» es la versión de Kasten de una prueba gratuita temporizada, que ofrece el conjunto completo de características de Kasten, un límite superior de 50 nodos, así como soporte al cliente, implementación asistida por Kasten y evaluación de protección de datos.
  • «Enterprise» es el único nivel de suscripción real que tiene Kasten K10; elimina por completo la limitación del «número de nodos» y ofrece el conjunto completo de funciones de copia de seguridad y recuperación de Kasten.
• Cabe destacar que no hay información sobre precios disponible en el sitio web oficial de Kasten, lo que significa que la única forma de recibir dicha información es solicitar un presupuesto personalizado a la empresa en cuestión.

Mi opinión personal sobre Kasten K10:

Kasten K10 es una solución de copias de seguridad bastante competente que funciona con diversos tipos de entornos, entre los que se incluyen Kubernetes, Cassandra, PostgreSQL, MySQL y otros. Además, recientemente ha sido adquirida por Veeam, una de las soluciones de copias de seguridad de nivel empresarial más conocidas del mercado. Hasta ahora, Kasten ha conservado su nombre, presentándose en la mayoría de los casos como «Kasten by Veeam». No es una mala solución en sí misma, pero sus capacidades relacionadas con Kubernetes son bastante básicas y limitadas. Aplica la mayor parte de sus capacidades generales a las copias de seguridad de Kubernetes, como el cifrado de datos y el RBAC, pero la creación de estas copias de seguridad no es un proceso sencillo. Kasten no ofrece alta disponibilidad local para Kubernetes, su implementación de recuperación ante desastres es solo parcial (RPO distintos de cero) y todas las copias de seguridad son estrictamente asíncronas.

Portworx

Portworx PX-Backup es una empresa de gestión de datos que desarrolla una plataforma de almacenamiento basada en la nube para gestionar y acceder a la base de datos de los proyectos Kubernetes. Es otro ejemplo de solución de gestión de datos y, a pesar de sus limitaciones como tal, una de las principales ventajas de utilizar Portworx es la alta disponibilidad de los datos.

Operaciones de copia de seguridad y recuperación, comprensión de aplicaciones Kubernetes, alta disponibilidad local y recuperación ante desastres, entre otras características, hacen de Portworx una buena solución para la copia de seguridad de Kubernetes. Teniendo en cuenta lo variadas que son las soluciones de copia de seguridad de Kubernetes de terceros, Portworx también puede ser interesante para un usuario que busque específicamente capacidades de copia de seguridad de Kubernetes.

Otra parte significativa de PX-Backup es su escalabilidad, permitiendo copias de seguridad bajo demanda / copias de seguridad programadas de cientos de aplicaciones a la vez. La solución también soporta configuraciones multi-base de datos y puede restaurar aplicaciones directamente a los servicios en la nube, como Amazon, Google, Microsoft, etc.

Tipos de datos cubiertos por Portworx:

Portworx soporta la creación de copias de seguridad para Namespaces, PVs, DaemonSets, Deployments, etc. Sin embargo, T-I no ha podido encontrar información sobre si puede o no soportar backups de Aplicaciones o de Infraestructura de Almacenamiento.

Valoraciones de los clientes:

• G2 – 4,4/5 estrellas basadas en 16 opiniones de clientes.

Ventajas:

• Solución de copia de seguridad fiable y de alto rendimiento.
• Infraestructura escalable y fiable
• Encriptación de datos y control de acceso detallado

Carencias:

• La configuración del programa en su conjunto puede resultar algo complicada
• La experiencia de asistencia al cliente es desigual
• Las capacidades de seguridad son limitadas en el contexto de los despliegues de grandes empresas

Precios (en el momento de redactar este documento):

• El modelo de precios de Portworx es bastante simple – hay una versión gratuita disponible para todos los usuarios que creen una cuenta Portworx; esta versión está limitada a 1 clúster y hasta 1 TB de datos de aplicaciones.
• También hay una versión de pago del programa con un conjunto completo de características, incluyendo copias de seguridad app-aware, restauración con un solo clic, protección contra ransomware, etc. Lamentablemente, no hay precios oficiales disponibles en el sitio web de Portworx; sólo se pueden obtener poniéndose en contacto directamente con la empresa para obtener un presupuesto personalizado.

Mi opinión personal sobre Portworx:

Portworx se promociona como una Plataforma de Servicios de Datos, ofreciendo un montón de capacidades que se centran principalmente en Kubernetes y sus contenedores. La Plataforma Portworx puede ofrecer un montón de servicios, incluyendo copias de seguridad, recuperación de desastres, almacenamiento, DevOps y base de datos. Las copias de seguridad de Portworx ofrecen alta disponibilidad, conocimiento de la aplicación y un montón de características que normalmente no están disponibles en las ofertas de copia de seguridad de Kubernetes. Es una solución rápida y escalable, pero también tiene sus desventajas. Un ejemplo de estos inconvenientes es una presencia general bastante limitada en el mercado, lo que crea un montón de factores incómodos, como la falta de tutoriales detallados en Internet. La solución en cuestión también puede ser bastante complicada, lo que dificulta el trabajo a los recién llegados a este campo.

Cohesity

Cohesity es un competidor relativamente popular en el campo de la copia de seguridad y recuperación general, pero sus capacidades relacionadas con Kubernetes todavía tienen algo de espacio para crecer. En primer lugar, Kubernetes es una adición relativamente nueva para ellos, en el sentido de que ha añadido la comprensión para aplicaciones Kubernetes. Sin embargo, sólo funciona para todas las aplicaciones dentro del mismo espacio de nombres, y no se pueden proteger aplicaciones específicas dentro de ese espacio de nombres.

Por otro lado, también hay capacidades de recuperación rápida, copias de seguridad incrementales de app-tier basadas en políticas, consolidación del estado de los datos y muchas otras capacidades.

Tipos de datos cubiertos por Cohesity:

La solución de Cohesity admite copias de seguridad de espacios de nombres, copias de seguridad de servicios, copias de seguridad de despliegues, etc. Hay soporte para copias de seguridad de Infraestructura de Almacenamiento, y el único factor notable para esta categoría es que la copia de seguridad de Aplicaciones de Cohesity también puede cubrir Bases de Datos en las que las aplicaciones están trabajando, así como sistemas de Mensajería desplegados en Kubernetes.

Valoraciones de los clientes:

• Capterra – 4,6/5 estrellas basadas en 48 reseñas de clientes.
• TrustRadius – 8,9/10 estrellas basadas en 59 opiniones de clientes
• G2 – 4,4/5 estrellas basadas en 45 opiniones de clientes

Ventajas:

• Gestión de copias de seguridad y recuperación sencilla y cómoda.
• Proceso de instalación y configuración inicial sencillo y fácil
• Fácil programación con la ayuda de la creación de perfiles que permite una mayor automatización
• Copias de seguridad incrementales conscientes de las aplicaciones, capacidades de recuperación rápida para aplicaciones Kubernetes y mucho más.

Carencias:

• Algunas de las actualizaciones tienen que instalarse manualmente mediante una línea de comandos, lo que supone un marcado contraste con la habitual instalación automática de actualizaciones basada en GUI.
• Las «copias de seguridad inmutables» de Cohesity aún pueden ser modificadas o eliminadas por un usuario con credenciales de nivel de administrador
• El soporte al cliente se basa mucho en respuestas estándar y puede ser menos que útil
• La función de copia de seguridad de Kubernetes es relativamente nueva para Cohesity, y puede ser un poco áspera alrededor de los bordes

Precios (en el momento de escribir esto):

• La información de precios de Cohesity no está disponible públicamente en su sitio web oficial y la única manera de obtener dicha información es poniéndose en contacto con la empresa directamente para una prueba gratuita o una demostración guiada.
• La información no oficial sobre los precios de Cohesity afirma que sólo sus dispositivos de hardware tienen un precio inicial de 110.000 dólares.

Mi opinión personal sobre Cohesity:

Cohesity es una sólida solución de copia de seguridad y recuperación que admite diferentes tipos de almacenamiento y, al mismo tiempo, ofrece muchas funciones con las que trabajar. Toda la solución se construye utilizando una estructura inusual similar a un nodo que hace que Cohesity sea extremadamente fácil de escalar en ambos sentidos. Es rápido, versátil y una gran opción para crear copias de seguridad de infraestructuras de aplicaciones. En cuanto a sus capacidades relacionadas específicamente con Kubernetes – definitivamente podrían necesitar algo de trabajo en el futuro ya que el soporte de Kubernetes es una adición relativamente nueva a Cohesity, y algunos matices todavía se están puliendo de forma regular. Sólo puede proteger los datos de aplicaciones del mismo espacio de nombres, y no hay opción para proteger aplicaciones específicas, así – sólo todo el espacio de nombres. Al mismo tiempo, Cohesity puede ofrecer bastantes de sus propias capacidades que ahora son aplicables a las copias de seguridad de Kubernetes, incluida la consolidación del estado de los datos, el soporte de copias de seguridad incrementales y mucho más.

OpenEBS

OpenEBS es otro ejemplo de una solución que ha logrado algunos resultados con sólo una de las tres características de nuestra lista, y en este caso se trata de alta disponibilidad local.

Al mismo tiempo, OpenEBS también puede integrarse con Velero, creando una solución combinada de Kubernetes que destaca en la migración de datos de Kubernetes. Por sí solo, OpenEBS solo puede realizar copias de seguridad de aplicaciones individuales (justo lo contrario de lo que hace Cohesity). También cuenta con características como el almacenamiento multicloud, su naturaleza de código abierto y una amplia lista de plataformas Kubernetes compatibles, desde AWS y Digital Ocean hasta Minikube, Packet, Vagrant, GCP y muchas más.

Sin embargo, esto puede no cubrir las necesidades de un usuario, ya que algunos usuarios podrían necesitar esas copias de seguridad de espacios de nombres en casos de uso específicos.

Tipos de datos cubiertos por OpenEBS:

OpenEBS es una solución bastante versátil; puede crear copias de seguridad de despliegues completos, así como Pods, ConfigMaps, StatefulSets, etc. Sin embargo, es bastante limitado en comparación con otros, incluyendo la falta de copia de seguridad de la infraestructura de almacenamiento, no hay copia de seguridad de aplicaciones, y la ausencia de copias de seguridad a nivel de espacio de nombres y a nivel de PV.

Características principales:

• Utiliza patrones de Container Attached Storage para mejorar la eficiencia de las copias de seguridad.
• Permite que las aplicaciones con estado tengan un acceso rápido y sencillo tanto a los PV replicados como a los PV locales dinámicos.
• Simplifica la gestión de aplicaciones entre nubes, incluida la replicación del almacenamiento y el aprovisionamiento automatizado

Precios (en el momento de redactar este documento):

• OpenEBS es una solución gratuita y de código abierto, pero también hay terceras personas y empresas que pueden proporcionar servicios o productos relacionados con OpenEBS de alguna manera o forma.

Mi opinión personal sobre OpenEBS:

OpenEBS supone un gran contraste con Cohesity en este sentido: se trata de una solución de gestión de datos relativamente pequeña que se centra específicamente en entornos de Kubernetes, al tiempo que dedica la mayor parte de sus capacidades a la alta disponibilidad de datos a nivel local como característica principal. El software en cuestión se puede integrar fácilmente con Velero, otro software gratuito y de código abierto a pequeña escala que ofrece muchas más posibilidades en cuanto a copias de seguridad de Kubernetes. Este tipo de integración da lugar a una oferta de copias de seguridad y gestión de datos bastante potente (y gratuita) que funciona con diversas plataformas de Kubernetes, ofrece compatibilidad con almacenamiento multicloud, proporciona capacidades de migración de datos, etc. Al igual que ocurre con prácticamente cualquier solución gratuita de esa envergadura, el mayor inconveniente de OpenEBS (y Velero) es una curva de aprendizaje bastante pronunciada que dificulta el acceso inicial y aumenta drásticamente el tiempo necesario para dominar todas las capacidades de la solución.

Veritas

Veritas es un proveedor de programas de copia de seguridad bien establecido que lleva varias décadas en el mercado; es el preferido por las empresas más grandes y antiguas precisamente por esa razón. Puede ofrecer un montón de características y capacidades diferentes, al tiempo que admite una variedad de tipos de almacenamiento de destino que van desde el almacenamiento físico a las máquinas virtuales, bases de datos, almacenamiento en la nube y más. En cuanto a sus capacidades Kubernetes – Veritas puede ofrecer amplias capacidades de registro, administración simple pero eficaz, soporte RBAC, alta disponibilidad de datos, replicación de datos, y muchos otros. Es una gran opción para las tareas de copia de seguridad y recuperación en su conjunto, aportando protección de datos y riqueza de características en un solo paquete.

Tipos de datos cubiertos por Veritas:

Las capacidades de Veritas en el ámbito de las copias de seguridad de Kubernetes son bastante impresionantes, incluyendo cobertura para Namespaces, Deployments, Secrets, Pods, etc. Sin embargo, no tiene la capacidad de realizar copias de seguridad de aplicaciones, y lo mismo podría decirse de las copias de seguridad de la infraestructura de almacenamiento.

Valoraciones de los clientes:

• Capterra – 4.0/5 estrellas basadas en 7 opiniones de clientes.
• TrustRadius – 6,8/10 estrellas basadas en 150 opiniones de clientes
• G2 – 4,1/5 estrellas basadas en 230 opiniones de clientes

Ventajas:

• Un conjunto de funciones extremadamente amplio y variado, que a menudo se considera uno de los más completos del mercado.
• El estado visual relativamente anticuado de la interfaz no cambia el hecho de que es fácil trabajar con ella para todo tipo de clientes, incluidos los completos recién llegados a este campo.
• La experiencia del servicio de atención al cliente ha recibido muchas críticas positivas a lo largo de los años, ya que el equipo de asistencia ofrece respuestas rápidas y concisas a una gran variedad de problemas.

Carencias:

• El sistema de gestión de informes es algo rígido, no hay forma de personalizar la ruta del archivo de destino para los informes creados automáticamente.
• La integración de la biblioteca de cintas LTO está disponible hasta cierto punto, pero funciona con una serie de defectos graves hasta el momento.
• La exportación de informes en su conjunto es bastante difícil de realizar.

Precios (en el momento de escribir este artículo):

• No hay información oficial sobre precios que pueda encontrarse en el sitio web de Veritas, la única forma de obtener dicha información es ponerse en contacto directamente con la propia empresa.

Mi opinión personal sobre Veritas:

Veritas suele ser elogiada como una de las soluciones de copia de seguridad y recuperación más antiguas del mercado, que sigue en forma y compitiendo con otras soluciones destacadas. Eso no quiere decir que la edad sea la única ventaja que puede ofrecer Veritas: también tiene un conjunto de características extremadamente amplio, una interfaz impresionantemente fácil de usar y un equipo de atención al cliente extremadamente servicial. Veritas también se las arregla para simplificar y mejorar en gran medida diversos aspectos de la gestión de contenedores Kubernetes – incluyendo las capacidades de copia de seguridad y recuperación de datos de contenedores, conmutación por error automática y failback, la distribución del tráfico a través de instancias, el descubrimiento automático de espacio de nombres, y mucho más. Veritas ofrece operaciones de copia de seguridad y recuperación fáciles y accesibles para aplicaciones en contenedores, lo que la convierte en una solución de copia de seguridad de Kubernetes bastante conveniente. Veritas tiene algunos problemas con su sistema de informes en su conjunto, y su integración de cinta LTO es bastante problemática, pero ninguno de estos problemas afecta a las capacidades relacionadas con Kubernetes lo suficiente como para ser un problema real para los usuarios actuales y futuros. En general, el precio puede ser un obstáculo.

Stash

Stash es una solución de copia de seguridad y recuperación de desastres que fue construida específicamente para Kubernetes en primer lugar. Puede restaurar datos de Kubernetes en varios niveles diferentes, incluyendo bases de datos (MongoDB, MySQL, PostgreSQL), volúmenes (conjuntos con estado, despliegues, volúmenes independientes), e incluso recursos regulares de Kubernetes (secretos, configuraciones YAML, etc.). Admite varias opciones de automatización, puede integrarse con varios proveedores de almacenamiento en la nube, admite cargas de trabajo personalizadas y mucho más. También es una solución relativamente nueva en este campo, por lo que tiene algunos dolores de crecimiento aquí y allá.

Tipos de datos cubiertos por Stash:

Stash es una solución de copia de seguridad relativamente pequeña, pero su cobertura de Kubernetes sigue siendo bastante impresionante, con soporte para Deployments, Services, Pods, DaemonSets e incluso copias de seguridad de Storage Infrastructure. Sin embargo, no puede crear copias de Kubernetes a nivel de espacio de nombres, y tampoco es compatible con copias de seguridad de aplicaciones.

Características principales:

• El soporte para la funcionalidad CSI VolumeSnapshotter permite ampliar de forma bastante significativa las opciones de copia de seguridad de Kubernetes de Stash.
• La capacidad de integrarse con la herramienta Restic aporta funciones como deduplicación, cifrado, copias de seguridad incrementales y mucho más.
• Stash puede trabajar con un número de proveedores de almacenamiento en la nube como almacenamiento de copia de seguridad – Azure Blob, GCP, AWS S3, etc.
• Hay un montón de opciones de programación disponibles, todos los cuales se pueden personalizar de múltiples maneras.

Precios (en el momento de escribir esto):

• No hay información oficial de precios disponibles en el sitio web de Stash, pero hay un «contáctenos» prompt, lo que significa que toda la información de precios es altamente personalizada y no se puede obtener a través de medios públicos.

Mi opinión personal sobre Stash:

Stash podría ser la solución de copia de seguridad menos conocida de esta lista. Es una solución de copia de seguridad y recuperación de desastres a muy pequeña escala para Kubernetes específicamente y nada más. Stash puede trabajar con recursos Kubernetes, volúmenes e incluso bases de datos, ofreciendo la posibilidad de crear copias de seguridad de un montón de entornos y tipos de datos – desde MongoDB y PostgreSQL a configuraciones YAML de despliegues. Es una solución rápida con un montón de capacidades centradas en Kubernetes que son una rareza en otras soluciones de copia de seguridad. Por ejemplo, Stash es compatible con la funcionalidad CSI VolumeSnapshotter, y también puede integrarse con la herramienta Restic para mejorar y hacer más versátiles las operaciones de protección de datos. Todavía está en fase de desarrollo, pero promete bastante de cara al futuro, y la complejidad general de la solución es probablemente el mayor problema en estos momentos, un problema que puede solucionarse con tiempo y esfuerzo.

Rubrik

Rubrik es un buen ejemplo: permite a los usuarios implementar el amplio conjunto de funciones de gestión de Rubrik en el ámbito de las implementaciones de Kubernetes.

Permite flexibilidad en cuanto al destino de la restauración, así como la protección de objetos Kubernetes y una plataforma unificada que proporciona información y una visión general de todo el sistema. También dispone de funciones como automatización de copias de seguridad, recuperación granular, replicación de instantáneas, etc. Rubrik también puede trabajar con Persistent Volumes y es capaz de replicar espacios de nombres, ofreciéndole variación cuando se trata de desarrollo y pruebas antes del despliegue.

Tipos de datos cubiertos por Rubrik:

Rubrik es una de las mejores opciones de esta lista en lo que respecta a todos los tipos de datos de Kubernetes de los que puede crear una copia de seguridad. Esto incluye Despliegues, Namespaces, Infraestructura de Almacenamiento, Servicios, Pods, StatefulSets, y prácticamente todo lo demás. El único factor digno de mención aquí es que Druva puede cubrir tanto las Aplicaciones como las Bases de Datos que utilizan.

Valoraciones de los clientes:

• Capterra – 4,7/5 estrellas basadas en 45 reseñas de clientes.
• TrustRadius – 9,1/10 estrellas basadas en 198 opiniones de clientes
• G2 – 4,6/5 estrellas basadas en 59 opiniones de clientes

Ventajas:

• Una solución versátil de copia de seguridad y recuperación con un alto rendimiento.
• Una variedad de integraciones con otros servicios y tecnologías, como SQL Server, VMware, M365, etc.
• Capacidades fiables de protección de datos con un buen cifrado, seguridad sólida y ransomware.
• Soporta un montón de características para aplicaciones Kubernetes, incluyendo replicación de instantáneas, automatización de copias de seguridad, recuperación granular y muchas otras.

Carencias:

• La implementación de RBAC es algo básica y carece de muchas de las características necesarias que tienen los competidores
• Personalización de auditoría/informes muy limitada y no hay suficientes detalles en los informes, en general.
• El coste global de la solución puede ser excesivo para empresas y negocios pequeños o medianos
• Escalabilidad limitada

Precios (en el momento de escribir este artículo):

• La información sobre precios de Rubrik no está disponible públicamente en su sitio web oficial y la única forma de obtener dicha información es poniéndose en contacto directamente con la empresa para una demostración personalizada o una de las visitas guiadas.
• La información no oficial afirma que hay varios dispositivos de hardware diferentes que Rubrik puede ofrecer, tales como:
  • Nodo Rubrik R334 – desde 100.000 dólares por un nodo de 3 con procesos Intel de 8 núcleos, 36 TB de almacenamiento, etc.
  • Nodo Rubrik R344 – desde 200.000 dólares para un 4-nodos con parámetros similares al R334, 48 TB de almacenamiento, etc.
  • Nodo Rubrik Serie R500 – desde 115.000 dólares para un 4-nodos con procesadores Intel de 8 núcleos, 8×16 de memoria DIMM, etc.

Mi opinión personal sobre Rubrik:

Las capacidades de Rubrik en términos de Kubernetes específicamente pueden no ser particularmente extensas, pero la solución en sí es bien conocida y respetada en la industria, proporcionando una sofisticada plataforma de copia de seguridad y recuperación con un número masivo de capacidades. Rubrik puede ofrecer protección, migración de datos y soporte general para instancias de Kubernetes, principalmente ampliando sus propias funciones existentes para cubrir entornos Kubernetes. Rubrik puede replicar namespaces y puede trabajar con Persistent Volumes, por lo que es una oferta bastante interesante a considerar para las grandes empresas. Sin embargo, sería justo mencionar que Rubrik tiene su propia cuota de desventajas que aún no se han solucionado, incluyendo una escalabilidad algo básica, un sistema de informes/auditoría rígido y un precio bastante elevado en su conjunto.

Druva

Otra variante de este tipo de solución es la presentada por Druva, que proporciona una solución de copia de seguridad y restauración de Kubernetes bastante simple pero eficaz, con todas las características básicas esperadas: instantáneas, copia de seguridad y restauración, automatización y algunas funcionalidades adicionales. Druva también puede restaurar aplicaciones enteras dentro de Kubernetes, con mucha movilidad cuando se trata del destino de la restauración.

Además, Druva soporta múltiples roles de administrador, puede crear copias de cargas de trabajo para la solución de problemas, y puede realizar copias de seguridad de áreas específicas como espacios de nombres o grupos de aplicaciones. También hay una variedad de opciones de retención, protección completa de datos de Kubernetes y soporte para Amazon EC2 y EKS (cargas de trabajo de contenedor personalizadas).

Tipos de datos cubiertos por Druva:

No hay información sobre si Druva es compatible con las copias de seguridad de la infraestructura de almacenamiento de Kubernetes. Aparte de eso, soporta prácticamente todo lo demás – Namespaces, Pods, DaemonSets, StatefulSets, ConfigMaps, e incluso Persistent Volumes. También puede cubrir Aplicaciones y Bases de Datos que están asociadas a estas aplicaciones.

Valoraciones de los clientes:

• Capterra – 4,7/5 estrellas basadas en 17 opiniones de clientes.
• TrustRadius – 9,3/10 estrellas basadas en 419 opiniones de clientes
• G2 – 4,6/5 estrellas basadas en 416 opiniones de clientes

Ventajas:

• La interfaz de usuario, en su conjunto, recibe muchos elogios.
• La inmutabilidad de la copia de seguridad y el cifrado de datos son sólo ejemplos de lo serio que es Druva cuando se trata de la seguridad de los datos.
• El soporte al cliente es rápido y útil.
• Protección de datos, instantáneas, copias de seguridad automatizadas y otras funciones para aplicaciones Kubernetes.

Carencias:

• La primera configuración no es fácil de realizar por uno mismo.
• Las instantáneas de Windows y las copias de seguridad de clústeres SQL son simplistas y apenas personalizables.
• Lenta velocidad de restauración desde la nube.
• La escalabilidad puede ser limitada.

Precios (en el momento de escribir esto):

• Los precios de Duva son bastante sofisticados y ofrecen diferentes planes de precios dependiendo del tipo de dispositivo o aplicación que se cubra.
• Cargas de trabajo híbridas:
  • «Empresa híbrida» – 210 dólares al mes por Terabyte de datos después de la deduplicación, ofreciendo una copia de seguridad empresarial sencilla con multitud de funciones como deduplicación global, recuperación a nivel de archivos de VM, compatibilidad con almacenamiento NAS, etc.
  • «Empresa híbrida» – 240 dólares al mes por Terabyte de datos tras la deduplicación, una ampliación de la oferta anterior con funciones LTR (retención a largo plazo), perspectivas/recomendaciones de almacenamiento, caché en la nube, etc.
  • «Élite híbrida» – 300 dólares al mes por Terabyte de datos después de la deduplicación, añade la recuperación de desastres en la nube al paquete anterior, creando la solución definitiva para la gestión de datos y la recuperación de desastres.
  • También hay funciones que Druva vende por separado, como recuperación acelerada de ransomware, recuperación de desastres en la nube (disponible para usuarios de Hybrid elite), security posture & observability, y despliegue para la nube del gobierno de EE.UU.
• Aplicaciones SaaS:
  • «Business» – 2,5 $ al mes por usuario, el paquete más básico de cobertura de apps SaaS (Microsoft 365 y Google Workspace, el precio se calcula por app individual), puede ofrecer 5 regiones de almacenamiento, 10 GB de almacenamiento por usuario, así como protección de datos básica.
  • «Enterprise» – 4 $ al mes por usuario para una cobertura de Microsoft 365 o Google Workspace con funciones como grupos y carpetas públicas, así como cobertura de Salesforce.com por 3,5 $ al mes por usuario (incluye restauración de metadatos, copias de seguridad automatizadas, herramientas de comparación, etc.)
  • «Elite» – 7 $ al mes por usuario para Microsoft 365/Google Workspace, 5,25 $ para Salesforce, incluye comprobación de cumplimiento de GDPR, habilitación para eDiscovery, búsqueda federada, compatibilidad con GCC High y muchas otras funciones.
  • Algunas de estas funciones también se pueden adquirir por separado, como la siembra de Sandbox (Salesforce), el gobierno de datos sensibles (Google Workspace & Microsoft 365), la compatibilidad con GovCloud (Microsoft 365), etc.
• Puntos finales:
  • «Enterprise» – 8 dólares al mes por usuario, puede ofrecer soporte SSO, CloudCache, soporte DLP, protección de datos por fuente de datos y 50 GB de almacenamiento por usuario con administración delegada.
  • «Elite» – 10 dólares al mes por usuario, añade características como búsqueda federada, recopilación de datos adicionales, borrado defendible, capacidades avanzadas de despliegue y mucho más.
  • También hay un montón de características que se podrían comprar por separado aquí, incluyendo capacidades avanzadas de despliegue (disponibles en el nivel de suscripción Elite), recuperación/respuesta de ransomware, gobierno de datos sensibles y soporte GovCloud.
• Cargas de trabajo de AWS:
  • «Freemium» es una oferta gratuita de Druva para la cobertura de cargas de trabajo de AWS; puede cubrir hasta 20 recursos de AWS a la vez (no más de 2 cuentas) a la vez que ofrece funciones como clonación de VPC, DR entre regiones y entre cuentas, recuperación a nivel de archivos, integración de AWS Organizations, acceso a API, etc.
  • «Enterprise» – 7 $ al mes por recurso, a partir de 20 recursos, tiene un límite superior de 25 cuentas y amplía las capacidades de la versión anterior con características como el bloqueo de datos, la búsqueda a nivel de archivo, la posibilidad de importar backups existentes, la posibilidad de evitar el borrado manual, soporte 24/7 con 4 horas de tiempo de respuesta como máximo, etc.
  • «Elite» – 9 dólares al mes por recurso, no tiene limitaciones en recursos o cuentas gestionadas, añade autoprotección por VPC, cuenta AWS, así como soporte GovCloud, y menos de 1 hora de tiempo de respuesta de soporte garantizado por SLA.
  • Los usuarios de los planes de precios Enterprise y Elite también pueden adquirir la capacidad de Druva para guardar copias de seguridad de EC2 con air-gapping en Druva Cloud por un precio adicional.
• Es fácil ver cómo uno puede confundirse con el esquema de precios de Druva en su conjunto. Por suerte, la propia Druva tiene una página web dedicada con el único propósito de crear una estimación personalizada del TCO de una empresa con Druva en tan sólo unos minutos (una calculadora de precios).

Mi opinión personal sobre Druva:

Druva ofrece una solución de copia de seguridad y recuperación nativa de la nube y consciente de las aplicaciones que resuelve uno de los problemas más comunes de Kubernetes: el hecho de que el clúster fallido siempre se restaura en un estado en blanco después de fallar por alguna razón. El programa en sí se proporciona utilizando un modelo de almacenamiento como servicio, y es bastante competente en la protección de entornos Kubernetes (así como un montón de otros tipos de almacenamiento). Druva puede realizar copias de seguridad de datos, restaurar datos, automatizar una serie de tareas, crear copias de seguridad de aplicaciones específicas y realizar copias de seguridad de áreas específicas (grupos de aplicaciones o espacios de nombres, por ejemplo). La solución también es compatible con EKS y Amazon EC2, por lo que es bastante atípica en esta lista – y en el mercado en general. Druva tiene algunos problemas, incluyendo un proceso de configuración inicial bastante complicado y un rendimiento bastante lento cuando se trata de recuperar copias de seguridad del almacenamiento en la nube, pero la solución en general es bastante capaz, especialmente para entornos Kubernetes.

Zerto

Zerto también es una buena opción si buscas una plataforma multifuncional de gestión de copias de seguridad con soporte nativo para Kubernetes. Ofrece todo lo que desearías de una solución moderna de copia de seguridad y restauración de Kubernetes: CDP (protección continua de datos), replicación de datos a través de instantáneas y un bloqueo mínimo de proveedores gracias a que Zerto admite todas las plataformas Kubernetes en el ámbito empresarial.

Zerto también ofrece protección de datos como una de las estrategias centrales desde el primer día, ofreciendo a las aplicaciones la capacidad de generarse con protección desde el principio. Zerto también cuenta con muchas capacidades de automatización, es capaz de proporcionar amplios conocimientos y puede trabajar con diferentes almacenamientos en la nube a la vez.

Tipos de datos cubiertos por Zerto:

La posición de Zerto en términos de cobertura de datos de Kubernetes es simple: no puede trabajar con Aplicaciones o Infraestructuras de Almacenamiento, pero todo lo demás se puede respaldar sin ningún problema, ya sean Implementaciones, Namespaces, Servicios, Pods, etc.

Valoraciones de los clientes:

• Capterra – 4,8/5 estrellas basadas en 25 opiniones de clientes.
• TrustRadius – 8,6/10 estrellas basadas en 113 opiniones de clientes
• G2 – 4,6/5 estrellas basadas en 73 opiniones de clientes

Ventajas:

• Sencillez de gestión para tareas de recuperación ante desastres.
• Facilidad de integración con infraestructuras existentes, tanto locales como en la nube.
• Capacidades de migración de cargas de trabajo y un montón de otras características.
• Las capacidades de Kubernetes de Zerto también son bastante amplias y variadas, e incluyen protección continua de datos, replicación de instantáneas y mucho más

Carencias:

• Solo se puede implementar en sistemas operativos Windows.
• Las funciones de generación de informes son algo rígidas
• Puede ser bastante caro para grandes empresas y negocios

Precios (en el momento de redactar este documento):

• El sitio web oficial de Zerto ofrece tres categorías de licencias diferentes: Zerto para VM, Zerto para SaaS y Zerto para Kubernetes.
• Las licencias de Zerto para Kubernetes específicamente se pueden adquirir de dos formas diferentes
  • «Zerto Data Protection» es un programa de protección de datos que ofrece funciones de copia de seguridad y recuperación continuas en todo el ciclo de vida de implementación de aplicaciones, incluye retención a largo plazo, clonación, replicación local, copias de seguridad orquestadas y mucho más.
  • «Enterprise Cloud Edition» es una versión basada en la nube de la oferta anterior que también ofrece copias de seguridad y recuperación continuas a lo largo de todo el ciclo de vida de desarrollo de aplicaciones, amplía el conjunto de funciones existente con funciones como la recuperación orquestada ante desastres y la replicación remota siempre activa
• No hay información oficial de precios disponible para la solución de Zerto, solo puede adquirirse a través de un presupuesto personalizado o comprarse a través de uno de los socios de ventas de Zerto.

Mi opinión personal sobre Zerto:

Zerto como solución de copia de seguridad es una buena opción para múltiples casos de uso a la vez – es una plataforma integral que soporta una variedad de diferentes tipos de almacenamiento. Zerto puede trabajar con Azure, AWS y Google Cloud como proveedores de almacenamiento en la nube; admite cobertura de máquinas virtuales, cobertura de contenedores y muchos otros casos de uso. Puede ofrecer protección de datos como una de sus características más grandes y completas, y hay un montón de opciones para entornos Kubernetes específicamente – ya sea mínimo proveedor lock-in, capacidades de replicación de datos, soporte CDP, y más. Algunas características de Zerto también son aplicables a todos los diferentes tipos de almacenamiento al mismo tiempo, ya sea el análisis de datos con amplias perspectivas, un montón de opciones de automatización, etc.

Longhorn

Longhorn es probablemente la solución menos conocida de las tratadas en este blog. Su comunidad es relativamente pequeña para tratarse de una solución de código abierto, y no permite realizar copias de seguridad completas de Kubernetes con metadatos y recursos para llevar a cabo una recuperación consciente de las aplicaciones. Sin embargo, hay una característica única que destaca, y se llama DR Volume. DR Volume puede configurarse tanto como fuente como destino, haciendo que el volumen se active en un nuevo clúster basado en los últimos datos respaldados.

Las capacidades de Longhorn para trabajar con muchos tipos diferentes de plataformas de contenedores y permitir diferentes métodos de copia de seguridad es lo que lo diferencia del resto, y ya existe la capacidad de soportar Kubernetes Engine, despliegues Docker y distribuciones K3. Los contenedores Docker, por ejemplo, tienen que crear un tarball que podría actuar como copia de seguridad para Longhorn.

Tipos de datos cubiertos por Longhorn:

Para una solución gratuita, Longhorn puede ofrecer un buen paquete de cobertura de tipos de datos a sus usuarios – incluyendo copias de seguridad para Deployments, StatefulSets, Services, Secrets, Pods, y más. No tiene la capacidad de realizar copias de seguridad de Namespaces, Aplicaciones o Infraestructura de Almacenamiento.

Valoraciones de los clientes:

• Capterra – 4,3/5 estrellas basado en 6 opiniones de clientes
• G2 – 4,8/5 estrellas basadas en 3 opiniones de clientes

Características principales:

• Solución independiente de la infraestructura
• Fácil proceso de despliegue
• Conveniente y útil panel de control
• Personalización sencilla para las políticas de copia de seguridad y recuperación ante desastres

Precios (en el momento de redactar este documento):

• Longhorn es una solución de copia de seguridad de Kubernetes gratuita y de código abierto que fue desarrollada originalmente por Rancher Labs, pero más tarde fue donada a CNCF (Cloud Native Computing Foundation) y ahora se considera un proyecto sandbox independiente.
• Rancher en sí tiene un nivel de precios premium separado llamado Rancher Prime – ofrece una variedad de características para ampliar y mejorar la funcionalidad original de Rancher, pero su precio no está disponible públicamente en el sitio web oficial.

Mi opinión personal sobre Longhorn:

Al igual que varios ejemplos anteriores, Longhorn no ofrece una cobertura completa de Kubernetes, lo que significa que no habría copias de seguridad compatibles con las aplicaciones. Al mismo tiempo, es una opción interesante para pequeñas empresas y compañías con un presupuesto limitado, teniendo en cuenta que Longhorn es gratuito, admite diversas variantes de contenedores e incluso múltiples métodos de copia de seguridad. Longhorn también puede ofrecer su propia característica inusual llamada Volumen DR – un volumen que se puede establecer como destino y origen, por lo que es inmediatamente activo en el clúster que se acaba de crear utilizando los datos de copia de seguridad existentes. También es relativamente sencillo para tratarse de una solución gratuita y de código abierto, aunque cabe esperar cierto grado de curva de aprendizaje.

Velero.io

Velero es una solución de copia de seguridad y recuperación de Kubernetes de código abierto con capacidades de migración. Soporta snapshots para volúmenes persistentes y estados de cluster, haciendo posible tanto la migración como la restauración en diferentes entornos. Es una solución muy conocida en el ámbito de las copias de seguridad de Kubernetes, ya que ofrece capacidades fiables de recuperación ante desastres para clústeres Kubernetes junto con migración de clústeres, retención a largo plazo para fines de cumplimiento, etc.

Características principales:

• Migración de clústeres con diferentes configuraciones.
• Protección en todo el clúster y granularidad en los procesos de copia de seguridad.
• Capacidades extensivas de recuperación de desastres para fines de continuidad del negocio.
• Programación de copias de seguridad con multitud de opciones para elegir.
• Integración con la API para crear instantáneas de volúmenes persistentes para grandes conjuntos de datos.
• Soporte para varios proveedores de almacenamiento en la nube, incluidos Azure Blob, Google Cloud, AWS S3, etc.

Precios (en el momento de escribir este artículo):

• Velero.io es una herramienta completamente gratuita y de código abierto sin precio asociado al programa.

Mi opinión personal sobre Velero.io:

Velero es una opción interesante para tareas de backup y recuperación en entornos Kubernetes, teniendo en cuenta que es gratuita y puede ofrecer una amplia granularidad en sus capacidades. Soporta diferentes proveedores de almacenamiento, puede integrarse con la API de la plataforma para snapshots persistentes, y en general es una solución sorprendentemente conveniente para muchas situaciones. No es particularmente utilizable en la mayoría de los casos de uso de grado empresarial debido al gran alcance de las operaciones necesarias, y la falta de características de seguridad más populares, como el cifrado, haría difícil trabajar con ella para las empresas que manejan información sensible, pero la solución en general es todavía vale la pena mirar, por lo menos.

¿Qué lista de comprobación deben seguir los equipos para garantizar la preparación de las copias de seguridad en Kubernetes?

Tener la estrategia de recuperación sobre el papel no es lo mismo que tenerla lista para su ejecución. Deje que esta lista de comprobación le ayude a garantizar que las decisiones y configuraciones establecidas en este documento se implementen de forma tangible y verificable.

¿Ha inventariado las cargas de trabajo críticas y los ámbitos de datos?

Antes que nada, necesita saber exactamente qué está protegiendo. Sin un inventario claro, las políticas de copia de seguridad tienden a ser demasiado amplias o a presentar numerosas lagunas.

• Todos los espacios de nombres y cargas de trabajo están documentados y clasificados por nivel de criticidad
• Los volúmenes persistentes están categorizados por prioridad de recuperación
• Se identifican los recursos personalizados y los CRD asociados a cada carga de trabajo
• En su inventario se distinguen las aplicaciones con estado de las que no lo tienen
• Se asigna la propiedad de los datos para cada carga de trabajo crítica

¿Están documentadas y aprobadas las políticas de RPO, RTO y retención?

Los requisitos de recuperación que no se han acordado formalmente tienden a cambiar bajo presión. Estos deben fijarse antes de que se produzca un incidente, no negociarse durante el mismo.

• Se definen los objetivos de RPO y RTO para cada nivel de carga de trabajo
• La frecuencia de las copias de seguridad para etcd, PV y datos de aplicaciones refleja dichos objetivos
• Los periodos de retención están documentados y aprobados por quien sea responsable del SLA de recuperación
• Existen políticas de ciclo de vida y de clasificación por niveles para los datos de copias de seguridad más antiguos
• Las políticas se revisan y se vuelven a aprobar tras cualquier cambio significativo en la infraestructura

¿Existen sistemas de supervisión, alertas y control de acceso para las copias de seguridad?

Un proceso de copia de seguridad que se ejecuta y falla de forma silenciosa ofrece una falsa sensación de seguridad. Los controles operativos deben ser tan robustos como el propio proceso de copia de seguridad.

• Las tareas de copia de seguridad se supervisan y los fallos activan alertas dirigidas a las personas adecuadas
• El acceso a la copia de seguridad y la restauración está separado en la configuración RBAC
• Las operaciones de restauración requieren autorización explícita para entornos de producción
• El cifrado se aplica de forma coherente en todo el proceso de copia de seguridad
• La gestión de claves se gestiona independientemente del almacenamiento de copias de seguridad

¿Dispone de guías de procedimientos probadas y contrastadas para los escenarios de restauración habituales?

La documentación que no se ha probado es una hipótesis, no un manual de procedimientos. Las pruebas periódicas son lo que convierte un plan de recuperación en una capacidad de recuperación.

• Existen manuales de procedimientos al menos para los escenarios de restauración más comunes: espacio de nombres único, clúster completo y recuperación de etcd
• Los procedimientos de restauración se han probado de principio a fin en un entorno que no es de producción
• Se ha medido el tiempo de recuperación de cada escenario en comparación con su RTO
• Los guiones de ejecución están controlados por versiones y se revisan tras cada prueba o incidente
• La responsabilidad de cada guión de ejecución está asignada y actualizada

La solución de copia de seguridad para K8s de Bacula Enterprise

La propia naturaleza de los entornos de Kubernetes los hace a la vez muy dinámicos y potencialmente complejos. Realizar una copia de seguridad de un clúster de Kubernetes no debería añadir complejidad innecesaria. Y, por supuesto, suele ser importante —si no crítico— que los administradores de sistemas y demás personal de TI tengan un control centralizado sobre todo el sistema de copia de seguridad y recuperación de la organización, incluidos los entornos de Kubernetes. De este modo, factores como el cumplimiento normativo, la facilidad de gestión, la velocidad, la eficiencia y la continuidad del negocio se vuelven mucho más factibles. Al mismo tiempo, el enfoque ágil de los equipos de desarrollo no debe verse comprometido de ninguna manera.

Bacula Enterprise es único en este ámbito porque es una solución empresarial integral para entornos de TI completos (no solo Kubernetes) que también ofrece copia de seguridad y recuperación de Kubernetes integradas de forma nativa, incluyendo múltiples clústeres, independientemente de si las aplicaciones o los datos residen fuera o dentro de un clúster específico. Bacula aporta otras ventajas, ya que es especialmente seguro, protegido y estable. Estas cualidades se vuelven críticas en el contexto de organizaciones que necesitan garantizar los niveles más altos posibles de seguridad.

Recuperación de clústeres

El departamento de operaciones de toda empresa reconoce la necesidad de contar con una estrategia de recuperación adecuada en lo que respecta a la recuperación de clústeres, actualizaciones y otras situaciones. Un clúster que se encuentre en un estado irrecuperable puede volver a su estado estable con Bacula si tanto los archivos de configuración como los volúmenes persistentes del clúster se han respaldado correctamente de antemano.

Otra forma de mostrar los métodos de trabajo de Bacula es mediante la siguiente imagen:

Una de las principales ventajas del módulo Kubernetes de Bacula es la capacidad de realizar copias de seguridad de varios recursos de Kubernetes, incluyendo:

• Pods;
• Servicios;
• Despliegues;
• Volúmenes persistentes.

Características del módulo Kubernetes de Bacula Enterprise

La forma en que funciona este módulo es que la solución en sí no forma parte del entorno Kubernetes, sino que accede a los datos relevantes dentro del clúster a través de pods de Bacula que se adjuntan a nodos Kubernetes individuales en un clúster. El despliegue de estos pods es automático y funciona en función de las necesidades.

Entre otras características que ofrece el módulo de copias de seguridad de K8s se incluyen las siguientes:

• Copia de seguridad y restauración de Kubernetes para volúmenes persistentes;
• Restauración de un único recurso de configuración de Kubernetes;
• La capacidad de restaurar archivos de configuración y/o datos de volúmenes persistentes al directorio local;
• La capacidad de realizar copias de seguridad de la configuración de recursos de clústeres Kubernetes.

También vale la pena señalar que Bacula soporta fácilmente múltiples plataformas de almacenamiento en la nube simultáneamente, incluyendo AWS, Google, Glacier, Oracle Cloud, Azure y muchos otros, a nivel de integración nativa. Por lo tanto, las capacidades de nube híbrida están integradas, incluyendo la gestión avanzada de la nube y las funciones automatizadas de almacenamiento en caché en la nube, lo que permite una fácil integración de los servicios de nube pública o privada para apoyar diversas tareas.

La flexibilidad de las soluciones es especialmente importante hoy en día, ya que muchas compañías y empresas son cada vez más complejas en términos de diferentes familias de hipervisores y contenedores. Al mismo tiempo, esto aumenta significativamente la demanda de flexibilidad del proveedor para todos los proveedores de bases de datos. Las capacidades de Bacula en este sentido son sustancialmente elevadas, ya que combina su amplia lista de compatibilidad con diversas tecnologías para alcanzar unos estándares de flexibilidad especialmente altos sin bloquearse en un único proveedor.

La complejidad cada vez mayor de los distintos aspectos del trabajo de cualquier organización no deja de aumentar, y la mayoría de las veces resulta más fácil y rentable utilizar una solución para todo el entorno de TI, y no varias soluciones a la vez. Bacula está diseñado para hacer exactamente esto, y también es capaz de proporcionar tanto una interfaz tradicional basada en web para sus necesidades de configuración, así como el tipo clásico de línea de comandos de control. Estas dos interfaces pueden incluso utilizarse simultáneamente.

El plugin de copia de seguridad de Kubernetes de Bacula permite dos tipos de destino principales para las operaciones de restauración:

• Restaurar a un directorio local;
• Restaurar a un clúster.

Las copias de seguridad regulares y/o automatizadas son muy recomendables para asegurar el mejor entorno posible de copia de seguridad y recuperación para contenedores. Probar las copias de seguridad de vez en cuando también debería ser obligatorio para el administrador del sistema. En la siguiente imagen, verás una parte del proceso de restauración, concretamente la parte de Selección de Restauración, en la que puedes elegir qué archivos y/o directorios quieres restaurar:

.

Otra parte del proceso de restauración que encontrarás es la página de opciones avanzadas de restauración, que tiene este aspecto:

.

Aquí puedes especificar varias opciones diferentes, como el formato de salida, la ruta del archivo de configuración de KBS, el puerto del punto final, etc.

También es fácil supervisar todo el proceso de restauración una vez finalizada la personalización, gracias a la página de registro de tareas de restauración en la que se escriben todas las acciones una por una:

Otra capacidad importante del módulo Kubernetes es la función de listado de plugins, que ofrece mucha información útil sobre los recursos Kubernetes disponibles, incluidos los espacios de nombres, los volúmenes persistentes, etcétera. Para ello, el módulo utiliza un comando especial .ls con un parámetro específico plugin=<plugin>.

El módulo Kubernetes de Bacula ofrece una variedad de características, algunas de las cuales son:

• Redespliegue de recursos de clúster rápido y eficiente;
• Salvaguarda del estado del clúster Kubernetes;
• Guardar configuraciones para utilizarlas en otras operaciones;
• Mantener las configuraciones modificadas lo más seguras posible y restaurar exactamente el mismo estado que antes.

Aunque esto ocurre con frecuencia, se recomienda encarecidamente evitar pagar a su proveedor en función del volumen de datos. No tiene sentido verse en una situación de chantaje, ni ahora ni en el futuro, por parte de un proveedor dispuesto a aprovecharse de su organización de esta manera. En su lugar, examine detenidamente los modelos de licencia de Bacula Systems, que liberan a sus clientes de la exposición a los recargos por crecimiento de datos, al tiempo que facilitan enormemente a los departamentos de compras de los clientes la previsión de los costes futuros. Este enfoque más razonable de Bacula proviene de sus raíces de código abierto y puede resultar atractivo para los equipos que trabajan intensamente en entornos DevOps.

Conclusión

Al final del día, los usuarios de Kubernetes tienen un montón de opciones diferentes cuando se trata de software de copia de seguridad y recuperación. Algunos de ellos solo se crean para gestionar datos de Kubernetes, mientras que otras soluciones añaden Kubernetes a su lista existente de funciones.

Las empresas más pequeñas que buscan una solución capaz únicamente de realizar copias de seguridad de Kubernetes pueden considerar que Longhorn u OpenEBS son preferibles al resto de ejemplos de nuestra lista. Por otra parte, las empresas más grandes que cuentan con numerosos tipos de almacenamiento diferentes en su propia infraestructura pueden necesitar una solución de copia de seguridad integral y altamente segura que cubra todos los sistemas de TI de la empresa sin fragmentación y que permita visualizar el estado general de las copias de seguridad y la recuperación desde una interfaz de gestión centralizada, algo para lo que están diseñadas soluciones como Bacula Enterprise. La elección final dependerá en gran medida de las necesidades y prioridades de cada cliente, incluyendo el tamaño de la empresa, las funciones necesarias, etc.

Por qué puede confiar en nosotros

Bacula Systems es todo exactitud y consistencia, nuestros materiales siempre tratan de proporcionar el punto de vista más objetivo sobre diferentes tecnologías, productos y empresas. En nuestras reseñas, utilizamos muchos métodos diferentes, como información sobre productos y opiniones de expertos, para generar el contenido más informativo posible.

Nuestros materiales ofrecen todo tipo de factores sobre cada una de las soluciones presentadas, ya sean conjuntos de características, precios, opiniones de clientes, etc. La estrategia de producto de Bacula es supervisada y controlada por Jorge Gea – el CTO de Bacula Systems de Bacula Systems, y Rob Morrison – el Director de Marketing de Bacula Systems.

Antes de unirse a Bacula Systems, Jorge fue durante muchos años el CTO de Whitebearsolutions SL, donde lideró el área de Backup y Almacenamiento y la solución WBSAirback. En la actualidad, Jorge proporciona liderazgo y orientación en las tendencias tecnológicas actuales, habilidades técnicas, procesos, metodologías y herramientas para el rápido y apasionante desarrollo de los productos Bacula. Responsable de la hoja de ruta de los productos, Jorge participa activamente en la arquitectura, la ingeniería y el proceso de desarrollo de los componentes de Bacula. Jorge es Licenciado en Ingeniería Informática por la Universidad de Alicante, Doctor en Tecnologías de la Computación y Máster en Administración de Redes.

Rob comenzó su carrera en marketing informático en Silicon Graphics, en Suiza, desempeñando un importante papel en diversas funciones de gestión de marketing durante casi 10 años. En los 10 años siguientes, Rob también ocupó varios puestos de gestión de marketing en JBoss, Red Hat y Pentaho, garantizando el crecimiento de la cuota de mercado de estas conocidas empresas. Es licenciado en Comunicación y Medios Digitales por la Universidad de Plymouth.

Bacula Systems es todo exactitud y consistencia, nuestra información siempre trata de proporcionar el punto de vista más objetivo sobre diferentes tecnologías, productos y empresas. En nuestras reseñas, utilizamos muchos métodos diferentes, como información sobre productos y opiniones de expertos, para generar el contenido más informativo posible.

Nuestros materiales ofrecen todo tipo de factores sobre cada una de las soluciones presentadas, ya sean conjuntos de características, precios, opiniones de clientes, etc. La estrategia de producto de Bacula es supervisada y controlada por Jorge Gea – el CTO de Bacula Systems de Bacula Systems, y Rob Morrison – el Director de Marketing de Bacula Systems.

Antes de unirse a Bacula Systems, Jorge fue durante muchos años el CTO de Whitebearsolutions SL, donde lideró el área de Backup y Almacenamiento y la solución WBSAirback. En la actualidad, Jorge proporciona liderazgo y orientación en las tendencias tecnológicas actuales, habilidades técnicas, procesos, metodologías y herramientas para el desarrollo rápido y emocionante de los productos de Bacula. Responsable de la hoja de ruta del producto, Jorge participa activamente en la arquitectura, ingeniería y proceso de desarrollo de los componentes de Bacula. Jorge es Licenciado en Ingeniería Informática por la Universidad de Alicante, Doctor en Tecnologías de la Computación y Máster en Administración de Redes.

Rob comenzó su carrera en marketing informático en Silicon Graphics, en Suiza, desempeñando con solidez diversas funciones de gestión de marketing durante casi 10 años. En los 10 años siguientes, Rob también ocupó diversos puestos de gestión de marketing en JBoss, Red Hat y Pentaho, garantizando el crecimiento de la cuota de mercado de estas conocidas empresas. Es licenciado en Comunicación y Medios Digitales por la Universidad de Plymouth.

Preguntas frecuentes

¿Cuál es el objetivo principal de las copias de seguridad de Kubernetes?

El propósito de una copia de seguridad de Kubernetes es similar a la razón por la que se hacen la mayoría de las copias de seguridad: crear copias seguras de la información para recuperarla en caso de cualquier desastre, accidental o intencionado. Un paquete de copias de seguridad adecuado puede ser la solución a fallos del sistema, pérdida de datos, corrupción de datos, robo de datos y muchas otras situaciones en las que la existencia de toda la empresa depende de si los datos se pueden restaurar o no.

¿Qué tan complejas son las copias de seguridad de Kubernetes en comparación con las copias de seguridad de VM tradicionales?

La naturaleza en contenedores de las cargas de trabajo de Kubernetes es la razón principal por la que estas copias de seguridad se consideran más difíciles y sofisticadas que las copias de seguridad de máquinas virtuales normales. Cada aplicación Kubernetes incluye varios microservicios, con el requisito de realizar copias de seguridad tanto del estado del clúster como del estado de la aplicación para su correcto funcionamiento, lo que dificulta enormemente la restauración adecuada sin perder la continuidad. Además, la naturaleza siempre cambiante de los clústeres Kubernetes añade otra capa de dificultad a todo lo demás, haciendo que los procesos de copia de seguridad y recuperación sean aún más complejos.

¿Qué programa de copia de seguridad es la mejor opción posible para las copias de seguridad de Kubernetes?

Es difícil afirmar que una única solución sea la mejor opción posible para un caso de uso concreto, teniendo en cuenta que cada empresa tiene sus propias circunstancias y requisitos específicos. La mayoría de las empresas también cuentan con un presupuesto ajustado en lo que respecta al software de copias de seguridad, lo que significa que la gama total de funciones tendría una prioridad menor que el precio de la solución. En definitiva, la solución más útil de esta lista será aquella que resulte adecuada para el mayor número y la gama más amplia de posibles casos de uso; en tal situación, Bacula Enterprise sería el ganador indiscutible de esta lista.

¿Qué puede ofrecer Bacula para entornos Kubernetes multi-nube?

Bacula proporciona la flexibilidad de restauración de datos y recuperación de desastres al permitir el almacenamiento de copias de seguridad en diferentes entornos de almacenamiento en la nube. Restaurar información a cualquier clúster compatible en lugar del clúster del que se copiaron los datos también es una opción aquí. La resiliencia y redundancia de un entorno Kubernetes se incrementa drásticamente de esta manera, especialmente cuando se trata de varias interrupciones específicas de la nube. Bacula también permite a sus usuarios restaurar tanto namespaces como clústeres enteros en diferentes entornos de almacenamiento en la nube, proporcionando una amplia continuidad sin atar a los usuarios al mismo almacenamiento en la nube. Un aspecto crítico que los arquitectos de Kubernetes suelen pasar por alto es la necesidad de su organización de obtener los niveles más altos de seguridad posibles. En comparación con prácticamente todos los demás proveedores de copias de seguridad, Bacula tiene mayores niveles de seguridad incorporados en su arquitectura, sus metodologías, sus procesos y sus características individuales.

¿Qué tipo de entornos soporta Bacula?

Bacula no solo puede funcionar con clústeres Kubernetes locales y basados en la nube, sino que también es compatible con entornos híbridos, lo que permite combinar ambas opciones de implementación para obtener el máximo nivel posible de flexibilidad, eficiencia y seguridad en diferentes entornos.