Guía completa de copia de seguridad y restauración de bases de datos Cassandra

Introducción: ¿Por qué son importantes las copias de seguridad para Cassandra?

Cassandra está construido para no caerse nunca. Las copias de seguridad de Cassandra son importantes, ya que sin una copia de seguridad adecuada, los datos importantes pueden correr el riesgo de perderse. Aunque la replicación es un componente importante que protege de los fallos de hardware, no protege de la pérdida de datos. Por lo tanto, disponer de una copia de seguridad recuperable y almacenar copias en algún lugar totalmente separado es una necesidad para salvaguardar todos sus datos.

¿Qué tipos de fallos o incidentes requieren un plan de copia de seguridad y restauración?

Los planes de copia de seguridad y restauración son necesarios para los fallos lógicos que la replicación no puede solucionar. Tales problemas incluyen el borrado accidental, la corrupción de datos, el ransomware y las actualizaciones fallidas. Cassandra copia cada operación a cada réplica simultáneamente, lo que significa que en caso de que ocurra alguno de estos problemas, todo el cluster sufre.

A continuación, vamos a explorar los fallos e incidentes típicos que requieren un plan de copia de seguridad y restauración.

• Borrado accidental de datos: Ejecutar DROP TABLE o TRUNCATE en el cluster equivocado, lo que provoca el borrado de sus datos de todas las réplicas.
• Corrupción de datos: Un problema de software, hardware o sistema de archivos que requiere una reversión a un estado estable.
• Actualizaciones fallidas: Una configuración incorrecta de la base de datos o actualizaciones que provocan la corrupción de los datos o dejan los archivos SSTable en un formato incompatible.
• Ransomware: Software malicioso que encripta los directorios de datos de Cassandra, haciendo que sus datos sean ilegibles.
• Insider malicioso: Alguien dentro del equipo borrando o destruyendo datos deliberadamente( un escenario menos raro de lo que la mayoría asume).

¿Cuáles son las consideraciones empresariales y técnicas de RPO (Recovery Point Objective) y RTO (Recovery Time Objective)?

RPO y RTO son dos métricas importantes que determinan directamente la frecuencia con la que deben ejecutarse las copias de seguridad o la rapidez con la que debe completarse la recuperación. Cada decisión de copia de seguridad que toma una empresa se deriva directamente de las dos:

El Objetivo de Punto de Recuperación (RPO) define la cantidad de pérdida de datos que su empresa puede tolerar, expresada en horas. Por ejemplo, un RPO de 4 horas significa que no puede perder más de 4 horas de datos; por tanto, necesitará una copia de seguridad cada 4 horas.

El objetivo de tiempo de recuperación (RTO), por otro lado, define cuánto tiempo se permite que su empresa no esté disponible mientras se centra en el proceso de recuperación. Digamos que su RTO es de 2 horas. En ese caso, dispone de 2 horas para recuperarse; la empresa podría tener serios problemas de salud financiera.

Ambas métricas son importantes porque informan de las decisiones empresariales que pueden afectar directamente a su estrategia de copias de seguridad de Cassandra.

¿Cuáles son los riesgos de no contar con una estrategia fiable de copia de seguridad de los datos de Apache Cassandra?

La replicación por sí sola no es suficiente para realizar copias de seguridad, por lo que supone un enorme riesgo para cualquier empresa. Las consecuencias van más allá de la pérdida de datos, ya que afectan a la continuidad operativa, el cumplimiento normativo y la confianza de los usuarios. He aquí los principales problemas a los que se enfrentan las empresas sin una estrategia fiable de copia de seguridad de Cassandra.

• Pérdida permanente de datos: No tener una estrategia de copia de seguridad o tener una poco fiable significa no tener una vía de recuperación y, en caso de catástrofe, lo que se pierda no podrá recuperarse.
• Tiempo de inactividad prolongado: Sin una estrategia de copias de seguridad y unos RTO y RPO claramente definidos, su empresa puede acabar perdiendo más de lo esperado.
• Cumplimiento y exposición a normativas: Industrias como la sanidad y las finanzas operan bajo estrictas normativas. Sin una estrategia de copia de seguridad de Cassandra adecuada, el incumplimiento puede acarrear importantes sanciones económicas.
• Daños a la reputación: Cuando los datos de los usuarios están en peligro, las empresas pueden sufrir daños duraderos en su reputación, lo que conlleva una pérdida gradual de usuarios y de confianza con el paso del tiempo.

¿Cómo afectan las arquitecturas de despliegue de Apache Cassandra a las necesidades de copias de seguridad?

La arquitectura de despliegue de Cassandra puede dictar en gran medida las necesidades de copia de seguridad. Determina lo arriesgada o compleja que debe ser la estrategia de copia de seguridad. Cada tipo de despliegue introduce retos específicos que un enfoque único no puede abordar.

1. Despliegues multidatacentro

En las implantaciones con varios centros de datos, las operaciones de copia de seguridad suelen ejecutarse desde un centro de datos secundario dedicado en lugar de desde los nodos de producción, lo que evita que la actividad de copia de seguridad degrade el rendimiento en vivo. Este centro de datos dedicado recibe los mismos datos replicados que la producción, pero gestiona todas las cargas de trabajo de copia de seguridad por separado, manteniendo los nodos primarios libres para el tráfico de usuarios.

2. Nube/AWS – EBS vs Instance Store

Las implementaciones en la nube en AWS requieren diferentes enfoques de backup en función del tipo de almacenamiento. Los nodos que se ejecutan en volúmenes EBS pueden aprovechar las capacidades nativas de instantáneas, ya que el almacenamiento EBS persiste independientemente de la instancia. Los nodos que utilizan el almacenamiento de instancias, sin embargo, requieren copias de seguridad cada hora y cada día en un almacenamiento externo como S3, ya que los datos del almacenamiento de instancias se pierden de forma permanente e irreversible en el momento en que una máquina se detiene o se reinicia.

3. Despliegues Kubernetes/Híbridos

Los despliegues de Cassandra basados en Kubernetes requieren copias de seguridad de algo más que los datos de SSTable. También dependen de los Secretos Kubernetes, ConfigMaps y definiciones StatefulSet que definen la configuración e identidad del cluster. Sin ellos, los datos restaurados no tienen un entorno válido en el que ejecutarse.

4. Clústeres de producción multinodo

En los clústeres de producción multinodo, las instantáneas deben activarse simultáneamente en todos los nodos para producir un punto de recuperación coherente. Una copia de seguridad escalonada corre el riesgo de crear lagunas en los datos que imposibiliten una restauración limpia.

5. Archivo de registros Commit

El archivado del registro de commit conserva el registro de escritura secuencial de Cassandra junto con las instantáneas regulares, lo que permite una recuperación puntual. Para los despliegues en los que incluso las pequeñas ventanas de pérdida de datos son inaceptables, el archivo del registro de commit es un componente esencial de la estrategia de copia de seguridad.

¿Qué objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO) debe considerar para la copia de seguridad y restauración de la base de datos Cassandra?

El RPO y el RTO adecuados para un despliegue de Cassandra dependen del valor empresarial de los datos y de la complejidad del clúster. Estas dos cifras deben definirse antes de diseñar cualquier estrategia de copia de seguridad.

Por el lado del RPO, cuanto más críticos sean sus datos, más ajustado deberá ser su punto de recuperación. El RPO define la pérdida de datos aceptable y determina la frecuencia de las copias de seguridad. Considere que tiene una plataforma de procesamiento de pagos que registra transacciones en directo, que puede necesitar un RPO de minutos.

En cuanto al RTO, Cassandra requiere expectativas honestas. A diferencia de una base de datos de un solo servidor, en la que la restauración puede tardar minutos, restaurar un clúster Cassandra distribuido implica volver a copiar los datos en varios nodos, reiniciar los servicios y ejecutar operaciones de reparación para sincronizar las réplicas.

¿Cómo encaja la copia de seguridad de Cassandra en una estrategia de protección de datos empresarial más amplia?

Para las pequeñas empresas que operan en sus sectores designados, basta con utilizar la estrategia de copia de seguridad Cassandra. Sin embargo, en el caso de las grandes corporaciones y empresas, el backup de Cassandra no funciona de forma aislada, sino que se integra en un marco de protección de datos más amplio.

¿Por qué el backup a nivel de base de datos no es suficiente para la resiliencia empresarial?

A diferencia de las startups y las empresas medianas, las empresas manejan un gran volumen de datos. En tales escenarios, es difícil que todos los equipos gestionen su propia copia de seguridad de forma independiente, ya que

• Las organizaciones pierden la pista de lo que realmente están protegiendo
• Problemas graves o catástrofes, como un ataque de ransomware, que afectan a varios sistemas simultáneamente.

La capacidad de recuperación de la empresa es más que una copia de seguridad a nivel de base de datos. Aunque cada equipo hace lo que puede de forma aislada, sigue siendo necesario un sistema universal que lo gestione todo y lo mantenga bajo control en caso de que surja algún imprevisto. Así, para las grandes empresas, Cassandra no opera por separado, sino que lo hace junto a otros sistemas importantes que requieren protección bajo políticas coherentes.

¿Cómo se integran las copias de seguridad de Cassandra con las plataformas de copia de seguridad empresarial?

Las copias de seguridad de Cassandra se integran con las plataformas de copia de seguridad empresariales a través de sus plugins designados, que posteriormente pasan a formar parte del patrimonio unificado de la empresa. A continuación, vamos a cubrir las características y lo que puede hacer una vez que se integra con la plataforma de copia de seguridad empresarial.

• Gestión automática de instantáneas: La plataforma programa y ejecuta automáticamente el comando de instantáneas nodetool en todos los nodos a la vez.
• Coordinación entre nodos: El complemento de copia de seguridad de Cassandra coordina todos los nodos en todo el clúster.
• Almacenamiento centralizado: Los archivos se transfieren de los nodos individuales a una ubicación de almacenamiento centralizada.
• Sin limpieza manual: La plataforma elimina automáticamente los archivos antiguos que no sirven.
• Supervisar y alertar: En caso de cualquier problema, las plataformas identifican y alertan al equipo, lo que conduce a resoluciones tempranas.
• Gestionar el proceso de restauración: Cuando se necesita la recuperación, la plataforma lo gestiona todo de la A a la Z.

¿Cómo reducen el riesgo operativo los sistemas de copia de seguridad centralizados?

Utilizar un sistema centralizado de copias de seguridad puede afectar positivamente a la eficacia operativa de la empresa. Con la tabla siguiente, vamos a explorar los riesgos típicos que las copias de seguridad individuales suponen para las empresas y cómo disponer de un sistema de copia de seguridad centralizado puede reducir significativamente los riesgos operativos.

¿Qué estrategias de copia de seguridad de Cassandra hay disponibles?

La copia de seguridad de Cassandra por sí sola no basta para cubrir las necesidades de las empresas. Sólo se ocupa de un sistema a la vez, mientras que las empresas necesitan múltiples sistemas con una protección coordinada y coherente. Una única copia de seguridad aislada no puede proteger un entorno empresarial. Necesita una estrategia de protección de datos centralizada que unifique todo bajo un mismo marco y que implemente políticas, supervisión, alertas y procedimientos de recuperación coherentes.

¿Qué es la copia de seguridad instantánea de Cassandra y cuándo debe utilizarla?

La copia de seguridad instantánea de Cassandra crea una copia puntual de todas las SSTables, ejecutada por el comando nodetool snapshot. No requiere ningún almacenamiento adicional, sino que crea enlaces duros para ese momento concreto que se congelan, y que más tarde se pueden utilizar para recuperar la información que se tenía en caso de que algo vaya mal, o se pierdan los datos.

Antes de cualquier operación de alto riesgo, debe utilizarse la copia de seguridad instantánea de Cassandra. Tales escenarios incluyen

• Actualizaciones a gran escala
• Cambios de esquema
• Eliminación masiva de datos

Importante: Es muy recomendable realizar instantáneas a diario o de vez en cuando. Una vez creada, transfiérala a un almacenamiento externo. La copia de seguridad de Cassandra en S3 es la más utilizada. Puede transferirla a Amazon S3, que protegerá sus instantáneas y garantizará la seguridad de todos sus datos.

¿Cuál es la diferencia entre las copias de seguridad completas, incrementales y diferenciales?

Cassandra ofrece tres categorías principales de copias de seguridad:

• Copia de seguridad completa
• Copia de seguridad incremental
• Copia de seguridad diferencial

1. Una copia de seguridad completa captura una copia completa de todo el conjunto de datos (haya habido o no cambios). Aunque es la opción más sencilla, requiere mucho tiempo, por lo que no es la más utilizada.
2. La copia de seguridad incremental captura sólo lo que ha cambiado desde la última copia de seguridad.
3. La copia de seguridad diferencial captura sólo los datos recién añadidos y modificados desde la última copia de seguridad completa.

NOTA: Cassandra no soporta de forma nativa el backup diferencial.

¿Cómo funciona el backup incremental de Cassandra y cuándo debería habilitarlo?

La copia de seguridad incremental de Cassandra captura sólo los nuevos archivos SSTable a medida que se escriben en el disco, lo que la hace más eficiente en términos de almacenamiento que las copias de seguridad completas. Las copias de seguridad incrementales reducen la sobrecarga de almacenamiento al capturar sólo los datos nuevos desde la última copia de seguridad. La activación de esta característica requiere un cambio de una línea en Cassandra.yaml

Una vez activada, no hay más trabajo manual: el resto se gestiona automáticamente.

Paso 1: Se reciben nuevos datos

Los nuevos datos se reciben en la memtable, que es un búfer temporal de escritura en memoria

Paso 2: Los datos se vuelcan de la memtable al disco

Una vez que la memtable está llena y fuera de almacenamiento, Cassandra descarga sus datos como un archivo SSTable permanente .

Paso 3: Se crean enlaces duros

Tan pronto como se crean las SStables, Cassandra crea automáticamente enlaces duros para esos datos en las copias de seguridad designadas.

Paso: 4: Los agentes de copia de seguridad barren y transfieren

Las herramientas de copia de seguridad como Medusa, integradas con Cassandra, comprueban y transfieren regularmente los archivos nuevos al almacenamiento externo.

Paso 5: El ciclo se repite

Este proceso se repite continuamente cada vez que entran nuevos datos en el clúster.

Las copias de seguridad incrementales de Cassandra deben activarse cuando

• Los datos cambian con frecuencia
• Hay un gran volumen de datos
• Su RPO requiere puntos de recuperación con una frecuencia superior a 24 horas
• Las instantáneas completas diarias ocupan demasiado almacenamiento o tardan demasiado tiempo

¿Cómo afectan los registros de commit y las consideraciones de recuperación de puntos temporales a las copias de seguridad y restauración de Cassandra?

El archivo de registros de commit es una característica importante en la arquitectura de despliegue de Cassandra cuando se trata de restaurar las bases de datos.

Al realizar la copia de seguridad de Cassandra, los pasos son los siguientes:

• Escribir llega
• Commit Log (disco) + Memtable (RAM)
• Memtable se llena → FLUSH
• SSTable (disco)
• Se elimina el segmento de Commit log

Aunque ésta es una secuencia ideal en circunstancias normales de funcionamiento, el archivo del registro de commit cambia este patrón. En lugar de borrar los segmentos del commit log al final, guarda copias en un almacenamiento externo, lo que permite acceder a los datos perdidos. Las instantáneas regulares combinadas con los archivos de registro de commit hacen posible la recuperación puntual (PITR). Sin el archivo del registro de commit, la recuperación se limita únicamente a la última instantánea.

Para hacernos una idea mejor, consideremos el siguiente ejemplo. Se tomó una instantánea a las 11 de la mañana y se produjo un borrado accidental a las 3:34 de la tarde. Sin el archivo del registro de confirmaciones, sólo podría acceder a los datos hasta las 11:00 horas, lo que le costaría 4 horas y 34 minutos de pérdida de datos. Con el archivo de registros de commit, todos sus datos pueden ser reemplazados, reduciendo la cantidad de su pérdida de datos.

En tales escenarios, en los que el RPO es cercano a cero, el archivo de registros de commit no se convierte en algo opcional, sino en una obligación.

¿Cuáles son los pros y los contras de las copias de seguridad a nivel de clúster frente a nivel de nodo?

Las copias de seguridad de Cassandra se realizan a nivel de nodo o a nivel de clúster, cada uno con distintas ventajas y desventajas.

Copia de seguridad a nivel de nodo: Es más sencillo en comparación con el backup a nivel de clúster, ya que no requiere una orquestación especial y se realiza el backup en cada nodo de forma independiente. Sin embargo, si se realizan copias de seguridad de los nodos de forma independiente se corre el riesgo de que los datos no sean coherentes en todo el clúster, especialmente en el caso de clústeres > 50 nodos, ya que la recuperación puede resultar complicada y causar problemas relacionados con la integridad de los datos.

Copia de seguridad a nivel de clúster: A diferencia de la copia de seguridad a nivel de nodo, es mucho más compleja y requiere una orquestación especial. Realiza la copia de seguridad en todos los nodos del mismo clúster simultáneamente. Esto garantiza que la integridad de los datos no se vea comprometida.

¿Qué herramientas y servicios soportan el backup y la restauración de Cassandra?

Cassandra ofrece un amplio conjunto de herramientas y servicios para realizar copias de seguridad y restauraciones. Elegir la adecuada es tan esencial como las propias estrategias, y esa elección depende en gran medida de múltiples factores, como el tamaño del clúster y los requisitos de recuperación. En esta sección, cubriremos a fondo los principales tipos de herramientas y servicios que soportan la copia de seguridad y restauración de Cassandra, y discutiremos las ventajas e inconvenientes de cada uno.

¿Cuáles son los pros y los contras de los métodos nativos de copia de seguridad de Cassandra?

¿Cuáles son los pros y los contras de los métodos nativos de copia de seguridad de Cassandra.

Los métodos nativos de copia de seguridad de Cassandra son las herramientas que están integradas directamente en Cassandra, y no hay necesidad de una integración de software de terceros, como Medusa y Bacula. Los dos tipos principales de métodos nativos de copia de seguridad de Cassandra son los siguientes:

1. Instantánea Nodetool
2. Copia de seguridad incremental incorporada

Ambas opciones son ampliamente utilizadas por Cassandra, y el método específico que elija depende en gran medida de múltiples factores. Los métodos de copia de seguridad nativos de Cassandra pueden ser una opción ideal para despliegues pequeños debido a su practicidad. No conllevan costes adicionales de instalación ni de licencias.

Sin embargo, también tienen sus limitaciones. Se concentran en gran medida en el trabajo manual, que incluye la transferencia de archivos a un externo uno por uno, y la limpieza manual de las instantáneas antiguas. Para grandes despliegues, puede que no sea la opción ideal, ya que no hay supervisión centralizada, ni alertas automáticas en caso de fallo, entre otras muchas características.

Pros:

• fácil de entender
• ideal para despliegues pequeños
• no requiere instalación
• gratuito e integrado

Contras:

• no apto para grandes producciones
• sin supervisión ni alertas
• sin gestión de la retención
• sin programación

¿Cómo funciona la copia de seguridad S3 de Cassandra y cuándo debe utilizarla?

Cassandra backup S3 es una de las soluciones de backup más utilizadas, ya que ofrece un amplio conjunto de ventajas:

• Capacidad de almacenamiento ilimitada
• Redundancia de ubicación geográfica
• Control de acceso
• Políticas automáticas de ciclo de vida

Para ayudarle a tomar una decisión mejor informada e identificar si se adapta a sus necesidades, exploremos paso a paso cómo funciona.

Paso 1: Se activa una instantánea en cada nodo, produciendo archivos SStable

Paso 2 : A continuación, estos archivos se comprimen, cifran y cargan en el cubo de S3 asignado, utilizando una herramienta de copia de seguridad de terceros como Medusa

Paso 3: Una vez en S3, los archivos de instantáneas locales pueden eliminarse

La copia de seguridad de Cassandra en S3 debe utilizarse cuando

• El clúster se ejecuta en un entorno de nube con acceso a S3
• Necesita un almacenamiento de copias de seguridad geográficamente separado y rentable
• Desea una gestión de retención automática a través de políticas de ciclo de vida de S3
• Utiliza herramientas de terceros, como Bacula Enterprise, Medusa y OpsCenter que se integran de forma nativa con S3

¿Cómo se comparan los métodos manuales basados en instantáneas con las herramientas automatizadas de copia de seguridad de Cassandra?

En términos de practicidad, las herramientas automatizadas de copia de seguridad de Cassandra son una mejor opción, especialmente para las empresas. A continuación, vamos a discutirlos y compararlos por separado.

Método manual basado en instantáneas

Este método se basa en gran medida en el trabajo manual, incluyendo la ejecución de sus instantáneas nodetool, escribir sus propios scripts para transferir manualmente los archivos a S3 SStable, la creación de cron jobs, y barrer manualmente las instantáneas antiguas que ya no son necesarias. Los métodos manuales no son muy eficientes para las empresas y grandes corporaciones, ya que dependen de las personas, carecen de supervisión y coordinación, y aumentan el riesgo de error.

Las herramientas automatizadas de copia de seguridad de Cassandra se integran automáticamente a través de herramientas de terceros, como Medusa y Bacula Enterprise. Las funciones típicas incluyen la programación automatizada, la coordinación, la transferencia, la compresión y el cifrado, la gestión de la retención, la supervisión y las alertas.

¿Cómo se pueden utilizar de forma segura las instantáneas a nivel de sistema de archivos para la copia de seguridad de la base de datos Cassandra?

En un escenario típico, la copia de seguridad de la BD Cassandra simplemente crea y almacena datos en la base de datos Cassandra. Una instantánea a nivel de sistema de archivos ofrece un enfoque alternativo a esto, permitiendo la captura de todo el disco en la capa de almacenamiento. Se integra con herramientas de copia de seguridad de Cassandra de terceros, como las instantáneas de AWS EBS, para capturar archivos SSTable, registros de commit y archivos de configuración.

Aunque estas herramientas son bastante rápidas y completas, y pueden funcionar de forma independiente en la capa de almacenamiento, pueden causar graves problemas si no se utilizan correctamente. Si Cassandra se encuentra en medio de su proceso de escritura, y se dispara una instantánea del sistema de archivos mientras los datos se encuentran en la memtable, podría resultar complicado restaurar los datos dados con claridad.

NOTA IMPORTANTE: Para mitigar el riesgo de tal escenario, ejecute la herramienta nodetool flush antes de disparar la instantánea del sistema de archivos. Esto es lo que puede hacer para mitigar el riesgo de tal escenario.

¿Existen herramientas de copia de seguridad y restauración de Cassandra de terceros y qué funciones ofrecen?

Existe un amplio conjunto de herramientas de copia de seguridad y restauración de Cassandra que son opciones ideales para satisfacer las necesidades de los despliegues de producción a gran escala. Las ventajas típicas que ofrecen dichas herramientas incluyen, entre otras

• Eficiencia operativa
• Compatibilidad con almacenamiento en la nube
• Flexibilidad de las copias de seguridad
• Recuperación más rápida en caso de desastre

Herramientas de copia de seguridad y restauración de Cassandra de terceros líderes

• Bacula Enterprise

Bacula Enterprise se distingue de todas las demás soluciones de copia de seguridad porque está diseñada específicamente para entornos grandes y complejos. Es la herramienta de copia de seguridad y restauración de nivel empresarial más completa disponible para las implantaciones de Cassandra.

• OpsCenter

OpsCenter es una herramienta de copia de seguridad de Cassandra de terceros que forma parte de la plataforma oficial de gestión de clústeres de DataStax. La copia de seguridad y restauración es sólo un componente de una plataforma más amplia que cubre. Esta herramienta almacena los datos de las copias de seguridad para garantizar que no haya archivos duplicados, y admite tanto el almacenamiento local como Amazon S3 como destinos de las copias de seguridad.

OpsCenter se integra directamente con el ecosistema DataStax Enterprise y gestiona la complejidad adicional de restaurar estas cargas de trabajo junto con los datos estándar de Cassandra. Su función de clonación de clústeres permite restaurar los datos de las copias de seguridad en un clúster diferente, lo que respalda los flujos de trabajo de migración y recuperación ante desastres.

• Medusa

Medusa es una de las herramientas de copia de seguridad y restauración de código abierto más utilizadas que se ha creado específicamente para Apache Cassandra. Las características típicas que ofrece Medusa incluyen el soporte de copias de seguridad completas e incrementales, la gestión automática de retenciones y la integración con varios servicios de almacenamiento en la nube como Amazon S3, Google Cloud Storage y Azure Blob Storage.

Medusa está construido para la arquitectura distribuida de Cassandra; entiende cómo coordinar copias de seguridad a través de nodos, gestionar archivos SSTable, y manejar cadenas de copias de seguridad incrementales sin scripts personalizados.

¿Cómo se puede integrar la copia de seguridad de Cassandra con Bacula Enterprise para la protección de la empresa?

Las herramientas de copia de seguridad de Cassandra pueden tratar la base de datos de forma aislada, lo que constituye una opción ideal para pequeñas implantaciones. Para clústeres > 50 nodos, la copia de seguridad de Cassandra por sí sola no es suficiente, ya que carece de la coordinación y visibilidad de una infraestructura completa. Bacula Enterprise integra la copia de seguridad de Cassandra en una estrategia de protección de datos más amplia para toda la organización.

A diferencia de la copia de seguridad instantánea de Cassandra, que realiza la copia de seguridad de cada nodo uno a uno, Bacula permite coordinar todos los nodos del clúster a la vez en un mismo momento concreto. Gestiona automáticamente una copia de seguridad completa sin ninguna intervención manual. Esto incluye la activación de las instantáneas, la transferencia de los SStables al almacenamiento centralizado correspondiente, la gestión de las cadenas de copias de seguridad y el posterior archivo de los registros de commit para una recuperación puntual (PITR).

Esto convierte a Bacula Enterprise en una opción práctica para las organizaciones que necesitan un control centralizado sobre Cassandra junto con otros sistemas de su infraestructura.

¿Cómo realizar una copia de seguridad segura para diferentes topologías de Cassandra?

Realizar una copia de seguridad segura de Cassandra requiere algo más que eso: requiere una ejecución cuidadosamente planificada, que a menudo se pasa por alto. Prestar atención a los detalles operativos es tan importante como las propias herramientas y estrategias, ya que es lo que garantiza la coherencia de los datos en todo momento.

¿Cómo hacer una copia de seguridad de un clúster Cassandra multinodo sin afectar a la disponibilidad?

Realizar copias de seguridad de un clúster Cassandra multinodo sin afectar a la disponibilidad requiere escalonar las operaciones de copia de seguridad entre los nodos, programarlas durante las horas de menor actividad y estrangular el uso de los recursos. Las siguientes prácticas abordan directamente cada uno de estos requisitos.

• Haga copias de seguridad de un nodo a la vez

Cassandra replica los datos en varios nodos, y esto puede afectar a su disponibilidad. Para minimizar este riesgo, es una buena práctica agrupar sólo un clúster a la vez, mientras el resto puede cumplir sus funciones diarias, como servir peticiones.

• Ejecute copias de seguridad sólo durante las horas de menor actividad

Durante las horas punta, especialmente los días laborables y las horas de trabajo, la competencia por los recursos es relativamente mayor. Realizar copias de seguridad durante los fines de semana resuelve este problema, ya que la competencia por los recursos es escasa o nula.

• Estrangulamiento de las operaciones de copia de seguridad

Las operaciones de copia de seguridad y el tráfico en directo compiten por los mismos recursos. Herramientas como Bacula Enterprise o Medusa ayudan a estrangular las operaciones de copia de seguridad. Esto asegurará que las operaciones de copia de seguridad no consuman suficientes recursos, y tendrá un impacto en el rendimiento en vivo.

¿Cómo se coordina la copia de seguridad de instantáneas de Cassandra en nodos distribuidos?

La coordinación de la copia de seguridad instantánea de Cassandra a través de nodos distribuidos es sencilla siempre que cada nodo del cluster distribuido sea capturado simultáneamente.

Los escenarios opuestos pueden causar serios problemas. En un clúster distribuido, cada nodo alberga una porción diferente del conjunto total de datos. Incluso una diferencia mínima puede dar lugar a puntos diferentes en el tiempo, lo que en última instancia puede conducir a un punto de recuperación incoherente que es difícil o apenas posible restaurar con claridad.

Deberían existir herramientas o scripts de orquestación eficaces para gestionar esto de forma nativa. La integración de Cassandra con herramientas de terceros como Bacula Enterprise permite conectar todos los nodos al mismo tiempo, esperar a que se completen todas las instantáneas y transferir posteriormente los archivos al almacenamiento externo. Este proceso garantiza la coordinación fluida de las copias de seguridad de las instantáneas de Cassandra en todos los nodos distribuidos, sin ningún tipo de compromiso.

¿Cómo se garantiza que las copias de seguridad sean coherentes entre las réplicas y los centros de datos?

Las copias de seguridad pueden resultar incoherentes entre réplicas y centros de datos cuando los nodos mantienen versiones ligeramente diferentes de los mismos datos en el momento de la instantánea. Hay dos pasos previos a la copia de seguridad y dos prácticas a nivel de copia de seguridad que abordan directamente este problema.

• Ejecute nodetool repair

Al ejecutar una reparación nodetool, se llevará a cabo la sincronización de réplicas en todo el clúster y cada nodo tendrá la última versión de los mismos datos. Una vez realizado este proceso, no habrá ninguna incoherencia cuando comience la instantánea.

• Desactivar la compactación

Ejecute nodetool disableautocompaction para evitar que los nodos estén a mitad de la compactación cuando se ejecute la instantánea, evitando así archivos SSTable parcialmente fusionados en la copia de seguridad.

Una vez realizados estos pasos, puede pasar al proceso de copia de seguridad. Esto es lo que puede hacer para mantener la coherencia entre centros de datos.

• Utilice la coherencia LOCAL_QUORUM

Esto le permitirá tener sólo datos totalmente confirmados y actualizados del centro de datos local que se capturen durante las operaciones de copia de seguridad.

• Realice copias de seguridad desde un solo centro de datos

Realizar copias de seguridad desde varios centros de datos puede causar incoherencias debido a la diferencia horaria. Realizar copias de seguridad desde un solo centro de datos elimina las incoherencias, ya que una copia de seguridad completa del centro de datos ya captura el conjunto de datos completo a través de la replicación.

¿Cuáles son los pasos para restaurar Cassandra a partir de copias de seguridad?

Hacer una copia de seguridad de Cassandra es sólo la mitad del proceso: es igual de importante equiparse con información sobre cómo restaurar Cassandra a partir de una copia de seguridad. El proceso de restauración puede variar dependiendo de múltiples factores, incluyendo el alcance y los métodos utilizados a lo largo del proceso.

La siguiente sección cubre todos los escenarios de restauración con los que se puede encontrar.

¿Cómo realizar el backup y la restauración de Cassandra de forma segura para tablas, espacios de claves o clusters completos?

La copia de seguridad y restauración de Cassandra puede realizarse en tres niveles diferentes, y cada uno de ellos puede conllevar un alcance distinto de pérdida de datos. Discutámoslos uno a uno.

• Restauración a nivel de tabla

Este es el nivel más sencillo para la recuperación. En la restauración a nivel de tabla, no necesita recuperarlo todo, sino sólo una tabla que se haya caído o borrado accidentalmente. El proceso es sencillo: copiar de nuevo el archivo de instantánea dado en el directorio correcto y ejecutar nodetool refresh para cargar los datos.

• Restauración a nivel de espacio clave

La restauración a nivel de espacio de claves se refiere al proceso de restaurar todas las tablas que se encuentran dentro del mismo espacio de claves. Sigue el mismo proceso que la restauración a nivel de tabla, pero se aplica a todas las tablas, y se realiza cuando todo el espacio de claves se elimina o corrompe simultáneamente.

• Una restauración de cluster completo

Este tipo abarca todo lo que se encuentra en el mismo cluster; por lo tanto, es el más complejo y el que más tiempo consume. Por lo general, la restauración de clúster completo se produce después de eventos catastróficos importantes, como un ransomware. El proceso para una restauración de cluster completo incluye detener Cassandra en cada nodo, barrer todos los directorios de datos, restaurar los archivos snapshot y posteriormente reiniciar el cluster.

¿Cómo se restaura a partir de una copia de seguridad de una instantánea de Cassandra y se devuelven los nodos al servicio?

La restauración de un nodo Cassandra es un proceso meticuloso y requiere atenerse a unos pasos claramente definidos. A continuación, vamos a explorar la ruta exacta de pasos que deberá seguir para restaurar su nodo Cassandra.

Paso 1: Detener Cassandra

Deberá detener Cassandra ya que los archivos de datos no se pueden reemplazar mientras Cassandra está en ejecución

Paso 2: Borre el directorio de datos

Borre todos los archivos corruptos del directorio de datos, ya que esos son los archivos que serán reemplazados por la copia de seguridad

Paso 3: Copie los archivos de la instantánea

Una vez que el directorio de datos esté limpio de los archivos borrados o corruptos, puede copiar los archivos de la instantánea, y devolverla a la ruta correcta del directorio de datos

Paso 4: Corregir permisos

Tan pronto como los datos correctos estén en el lugar correcto, arregle los permisos de los archivos, y asegúrese de que Cassandra es su propietario; de lo contrario, no podrá leer la versión correcta

Paso 5 – Reinicie Cassandra

El nodo vuelve a estar en línea, leyendo los archivos SSTable restaurados.

Paso 6 – Ejecute nodetool repair. Esto sincroniza el nodo restaurado con sus vecinos para que reciba cualquier escritura que se haya producido en otros nodos mientras estaba desconectado.

NOTA IMPORTANTE: Si está realizando la restauración de un cluster completo, deberá repetir esta secuencia en todos sus nodos.

¿Cómo se utilizan los datos de la copia de seguridad incremental de Cassandra durante la recuperación?

La recuperación de una copia de seguridad incremental de Cassandra es mucho más compleja en comparación con la recuperación de una copia de seguridad instantánea. Hay dos cosas importantes a tener en cuenta al iniciar una recuperación con una copia de seguridad incremental de Cassandra.

• La incremental debe aplicarse en orden cronológico
• No se puede saltar ningún archivo de la cadena.

La recuperación de una copia de seguridad incremental comprende dos fases principales, que son las siguientes:

1. Restaurar la línea de base de la instantánea completa: Es IMPOSIBLE recuperar su copia de seguridad incremental sin restaurar la copia de seguridad instantánea completa, ya que le sirve de base.
2. Aplique sus incrementos en orden cronológico: Cada incremento se construye sobre la línea de base, del más antiguo al más reciente. Si no se sigue el orden cronológico, la recuperación de la copia de seguridad no será correcta.

Analicemos un ejemplo y veamos cómo funciona

Supongamos que tiene una instantánea completa el martes, e incrementales todos los días hasta el sábado. Para recuperar la copia de seguridad incremental del sábado, tendrá que aplicar las instantáneas del martes, luego las incrementales del miércoles, jueves, viernes y sábado en el mismo orden cronológico.

¿Cómo se manejan los desajustes de versión entre la copia de seguridad y las versiones de Cassandra de destino?

¿Cómo se manejan los desajustes de versión entre la copia de seguridad y las versiones de Cassandra de destino?

Las copias de seguridad de Cassandra pueden cambiar de vez en cuando. Cuando la que se utiliza para crear y la que se utiliza para restaurar la copia de seguridad no coinciden, no se produce una restauración limpia adecuada. Dependiendo de las circunstancias, hay dos soluciones que debe considerar.

1. Ejecute la misma versión de Cassandra que se utilizó para crearla y, a continuación, actualícela a la versión de destino. Esta es la más utilizada de las dos opciones. Esto minimiza la complejidad de todo el proceso y elimina los riesgos de compatibilidad de formatos.
2. Convierta los archivos antiguos y, a continuación, restáurelos a la nueva versión. Si la primera solución no funciona, puede convertir los archivos de la versión antigua utilizando la herramienta sstableupgrade y, posteriormente, restaurarlos a la nueva versión.

Ambas opciones son manejables. No se trata de cuál elija, sino de que los desajustes de versión se gestionen adecuadamente y los datos se restauren correctamente.

¿Cómo automatizar y programar las copias de seguridad de Cassandra de forma fiable?

Los procesos manuales de copia de seguridad, que son ideales para despliegues pequeños, siguen teniendo sus inconvenientes. Son propensos a errores humanos, programaciones olvidadas y características que no se detectan hasta que se produce una catástrofe grave. La automatización y la programación están diseñadas específicamente para resolver este problema: garantizar que los errores se gestionan a tiempo antes de que se conviertan en graves, e identificar los fallos a tiempo para tomar las precauciones necesarias. Esta sección cubre de forma exhaustiva todo lo que necesita saber para automatizar y programar de forma fiable sus copias de seguridad de Cassandra.

¿Qué patrones de programación minimizan la carga y cumplen su RTO/RPO?

A la hora de elegir la programación de copias de seguridad adecuada, debe tener en cuenta dos requisitos

• Cumplir los requisitos RPO/RTO
• Minimizar la carga de su clúster

Hay dos patrones principales de programación de copias de seguridad que puede considerar

• Instantáneas completas diarias + copias de seguridad incrementales cada hora

Ejecute una instantánea completa una vez al día e incrementales cada hora para capturar los cambios que se produzcan a lo largo del día. Esta combinación le ayudará a satisfacer su RPO de una hora sin tener que ejecutar instantáneas completas repetidamente.

NOTA IMPORTANTE: Programe sus instantáneas completas durante las horas de menor actividad para minimizar la competencia del tráfico en directo.

• Instantáneas completas semanales + incrementales diarias

Mientras que para la mayoría de los despliegues, las instantáneas completas diarias satisfacen el RPO de 24 horas, no es el caso de los clústeres > 50 nodos, ya que consumen mucho tiempo. En tales escenarios, programar instantáneas completas semanales combinadas con incrementales diarias puede ser una mejor opción, que le permitirá reducir los gastos generales y mantener un RPO de 24 horas.

A continuación, vamos a discutir los requisitos de RPO más utilizados y cuáles son los patrones recomendados para ellos.

¿Cómo hacer que los scripts, las herramientas de orquestación o los cron jobs sean resilientes e idempotentes?

Los scripts de copia de seguridad no rinden adecuadamente en muchos aspectos, y solucionar esto a tiempo es fundamental. Crear resiliencia e idempotencia es la solución definitiva, ya que garantiza que cada proceso de copia de seguridad se maneje con cuidado.

He aquí los pasos concretos que debe seguir para que su automatización de copias de seguridad sea resiliente e idempotente.

Paso 1: Realice una comprobación previa antes de ejecutar

Antes de intentar crear una nueva instantánea, verifique y asegúrese de que no existe ninguna otra instantánea para la misma ventana.

Paso 2: Utilice archivos de bloqueo

Una vez iniciada la automatización de la copia de seguridad, cree un archivo de bloqueo y elimínelo posteriormente. Este paso garantizará que no se ejecuten simultáneamente dos archivos de copia de seguridad

Paso 3: Compruebe cada paso

Verifique cada detalle y compruebe el código de salida de cada comando, incluidas las instantáneas, la compresión y las cargas. Esto ayudará a identificar el fallo a lo largo de todo el proceso y a mantener todo bajo control

Paso 4: Regístrelo todo

Anote todas las actividades, incluidos los éxitos, los fracasos y las advertencias, en un archivo de registro, lo que le ayudará a asegurarse de que los scripts son resistentes

Paso 5: Limpie en caso de fallo

Barra automáticamente las instantáneas parciales o las cargas incompletas, en caso de que su script de copia de seguridad falle a mitad del proceso

Paso 6: Añada lógica de reintento

Reintente automáticamente los fallos transitorios hasta un límite definido

Paso 7: Utilice las herramientas de orquestación

En lugar de utilizar cron jobs, utilice herramientas de orquestación como Bacula Enterprise, que le permitirán gestionar todo el ciclo de vida de la copia de seguridad

¿Cómo supervisar los trabajos de copia de seguridad y alertar de los fallos?

A lo largo de su proceso de copia de seguridad de Cassandra, pueden producirse fallos en cualquier momento. Monitorizar los trabajos de copia de seguridad y alertar sobre los fallos son dos componentes importantes que deben tenerse en cuenta durante los fallos.

Cuando inicie la monitorización de su copia de seguridad, tenga en cuenta estas preguntas para que sea efectiva.

• ¿Se ejecutó la copia de seguridad?
• ¿Se completó con éxito?
• ¿Cuánto tiempo tardó en ejecutarse?
• ¿Qué tamaño tenía el resultado?
• ¿Es posible restaurar la copia de seguridad?

Para supervisar sus trabajos de copia de seguridad, tenga en cuenta lo siguiente:

1. Compruebe los registros de Cassandra

Analice system.log después de cada trabajo de copia de seguridad en busca de errores o advertencias que muestren que algo no se completó limpiamente.

2. Utilice nodetool para verificar sus instantáneas

Ejecute nodetool listsnapshots para asegurarse de que su instantánea existe realmente

3. Rastree las salidas de los trabajos

Asegúrese de registrar el código de salida, el tamaño del archivo y la duración de su script de copia de seguridad para compararlo posteriormente con versiones anteriores

Cuando ejecute su copia de seguridad de Cassandra, la alerta es tan importante como la monitorización, ya que le ayuda a tomar las precauciones necesarias a tiempo. Dependiendo de la gravedad del problema, las alertas de fallo deben dirigirse a su canal designado.

• PagerDuty para una respuesta inmediata de guardia
• Slack para la visibilidad del equipo
• correo electrónico para notificaciones no urgentes

También puede utilizar herramientas de terceros como Bacula Enterprise, que ofrece copias de seguridad y supervisión unificadas, así como alertas, para asegurarse de que todo está bajo control.

¿Cómo afectan la seguridad y el cumplimiento a las prácticas de copia de seguridad de Cassandra?

Utilizar la estrategia de copia de seguridad de Cassandra adecuada es importante, pero eso es sólo la mitad de la ecuación. La seguridad y el cumplimiento son la segunda mitad. La seguridad garantiza que los archivos estén protegidos de cualquier acceso o restricción autorizados. El cumplimiento, por su parte, garantiza que las prácticas de copia de seguridad cumplen todos los requisitos normativos.

¿Cómo deben cifrarse las copias de seguridad de Cassandra en reposo y en tránsito?

Las copias de seguridad de Cassandra deben cifrarse tanto en reposo como en tránsito. Se trata de dos requisitos de protección distintos que abordan diferentes puntos de vulnerabilidad.

La encriptación en reposo es el proceso de almacenar sus archivos de copia de seguridad de forma encriptada en el disco o en el almacenamiento de copias de seguridad. Garantiza que los archivos estén protegidos y no se puedan leer, incluso si se roba el almacenamiento físico.

La encriptación en tránsito, por otro lado, se refiere al proceso de transferencia de su copia de seguridad desde el nodo Cassandra al almacenamiento de copias de seguridad. Este proceso impide la interceptación durante la transferencia, lo que garantiza la protección de los datos importantes.

He aquí lo que las empresas y los negocios deben hacer para proteger adecuadamente las copias de seguridad Cassandra.

• Utilice estándares de encriptación fuertes como AES-256 para la encriptación en reposo.
• Protocolos seguros como HTTPS para el cifrado en tránsito
• Almacene y gestione las claves de cifrado mediante el servicio de gestión de claves (KMS)
• Restrinja el acceso a los archivos de copia de seguridad

¿Cómo controlar el acceso a las copias de seguridad y aplicar el mínimo privilegio?

Controlar el acceso a todo para todos es una de las prácticas menos utilizadas en las copias de seguridad de Cassandra. Esta práctica requiere hacer cumplir el privilegio mínimo, lo que significa dar a cada sistema y persona el permiso mínimo para su función. Las cuentas de servicio o roles típicos incluyen:

1. Agentes de copia de seguridad que tienen acceso de sólo escritura al almacenamiento de copias de seguridad, pero no pueden leer ni borrar las copias de seguridad existentes.
2. Agentes de restauración que sólo tienen acceso de lectura, y no pueden borrar ni cambiar nada
3. Administrador de copias de seguridad que tiene acceso completo a todo.

Muchas empresas implementan políticas de IAM (Gestión de Identidad y Acceso) y de cubos S3 para controlar el acceso a las copias de seguridad y aplicar el mínimo privilegio. Dichas políticas incluyen, entre otras, denegar operaciones a cuentas que no sean de administrador, restringir el acceso a un rango de IP desconocido, exigir cifrado en todas las cargas y auditar los registros de entrada.

Separar estas funciones entre sistemas y personas, e identificar quién puede hacer qué y cuándo, garantiza que todo esté bajo control y que nada se vea comprometido.

¿Cómo afectan las políticas de retención y los requisitos de eliminación de datos a la estrategia de copia de seguridad de Cassandra?

Las políticas de retención y los requisitos de eliminación de datos son dos retos distintos que afectan a la estrategia de copia de seguridad de Cassandra. Las políticas de retención son las que determinan la duración de conservación de las copias de seguridad de Cassandra antes de borrarlas si ya no se utilizan.

• Copias de seguridad diarias – Retenidas durante 30 días
• Copias de seguridad semanales – Retenidas durante 3 meses
• Copias de seguridad mensuales – Conservadas durante un año
• Copias de seguridad anuales – Conservadas durante 7 años

Para resolver este problema, las organizaciones implementan un enfoque de retención por niveles, lo que significa aplicar diferentes periodos de retención a diferentes tipos de copias de seguridad simultáneamente. Esto garantiza que las empresas y los negocios puedan equilibrar sus costes de almacenamiento y el cumplimiento de la normativa sin tener que guardarlo todo para siempre.

Los requisitos de eliminación de datos plantean otro reto, ya que no es posible borrar los datos de usuarios específicos de los archivos de copia de seguridad binarios. Para resolver este problema, las empresas mantienen un periodo de retención lo suficientemente corto como para que los datos borrados caduquen de forma natural en un plazo documentado y defendible.

¿Cómo se aplican las copias de seguridad inmutables y la protección contra ransomware a las copias de seguridad y restauración de Cassandra?

El ransomware es el mayor y más catastrófico fallo que se produce durante el proceso de copia de seguridad de Cassandra. En caso de un ataque de este tipo, el ransomware sigue un patrón predecible, que es el siguiente:

• Cifrado de los datos en vivo
• Apuntar al archivo de copia de seguridad para eliminar la recuperación

Las copias de seguridad inmutables abordan directamente este problema. Garantiza que los archivos de copia de seguridad no puedan ser modificados después de ser escritos, e incluso una cuenta administrativa totalmente comprometida no puede borrar o cifrar una copia de seguridad inmutable.

El bloqueo de objetos de S3 implementa la inmutabilidad en el nivel de almacenamiento de AWS:

• Los archivos escritos en un bucket bloqueado no pueden modificarse ni eliminarse durante el periodo de retención definido.
• El modo de conformidad elimina toda capacidad de anulación
• El modo de gobernanza permite a los administradores autorizados anular bajo condiciones específicas

¿Cómo pueden reducir el impacto de las infracciones las copias de seguridad fuera de línea o con bloqueo aéreo?

En la mayoría de los escenarios, los ataques de ransomware van más allá de la mera encriptación de datos en directo: buscan constantemente opciones para destruir las copias de seguridad en línea y minimizar las posibilidades de opciones de recuperación. El mejor mecanismo de defensa que los ataques de ransomware no pueden superar son las copias de seguridad air-gapped y offline.

Las copias de seguridad air-gapped están completamente desconectadas físicamente de todas las redes. Esto significa que las copias de seguridad air-gapped no pueden ser alcanzadas, borradas o encriptadas, ya que no hay conexión a Internet ni acceso remoto.

Las copias de seguridad fuera de línea son más amplias y no están conectadas activamente a los sistemas activos en el momento de una violación. Sin embargo, todavía pueden ser accesibles a través de otros medios.

¿Cuáles son las mejores prácticas para las copias de seguridad de Cassandra en producción?

Una estrategia de copias de seguridad Cassandra de producción parece un camino interminable, que requiere políticas coherentes, mediciones continuas y una documentación clara, para seguir siendo fiable a lo largo del tiempo. La siguiente sección cubre las mejores prácticas para las copias de seguridad de Cassandra en producción, definiendo la línea de base y discutiendo todo lo que necesita saber.

¿Qué políticas mínimas debe tener todo despliegue de producción?

Lo mínimo que todo despliegue de Cassandra en producción debería tener, independientemente del tamaño de su empresa, presupuesto o complejidad del cluster, es lo siguiente:

1. Instantáneas diarias automatizadas. La automatización elimina la dependencia humana de la operación más crítica de protección de datos.
2. Almacenamiento externo. Cada instantánea debe transferirse inmediatamente a un almacenamiento externo, completamente separado del clúster.
3. Política de retención definida. Debe documentar durante cuánto tiempo se conserva cada tipo de copia de seguridad y aplicarse automáticamente.
4. Supervisión y alerta. La supervisión y las alertas automatizadas son imprescindibles, lo que le permitirá tomar las precauciones necesarias a tiempo y evitar fallos importantes.
5. Proceso de restauración probado. Las copias de seguridad deben probarse regularmente para garantizar la seguridad de sus datos.
6. Cifrado. Todos sus archivos de copia de seguridad deben estar cifrados en reposo y en tránsito sin excepción.
7. Control de acceso. Se debe aplicar el mínimo privilegio en todo su almacenamiento de copias de seguridad.
8. Documentación de versiones. Cada copia de seguridad debe estar etiquetada con la versión de Cassandra en la que fue creada.
9. Libro de ejecución documentado. Debe disponer de un libro de ejecución documentado que incluya procedimientos de restauración detallados que puedan utilizarse en caso de catástrofe grave.
10. Copias de seguridad incrementales. Debería utilizar copias de seguridad incrementales combinadas con copias de seguridad instantáneas completas que tengan un RPO inferior a 24 horas.

¿Cómo se documentan los procedimientos de copia de seguridad y restauración de Cassandra para los equipos de guardia?

Para documentar los procedimientos de copia de seguridad y restauración de Cassandra para el equipo de guardia, las empresas disponen de un runbook, que es un documento que sirve de guía paso a paso. Un runbook ideal debería estar escrito de tal forma que incluso un especialista junior que nunca haya realizado copias de seguridad de Cassandra pueda leerlo y ejecutarlo todo con éxito. He aquí lo que debería cubrir un runbook de este tipo:

• Recuperación de tablas individuales
• Recuperación de espacios clave
• Recuperación de cluster completo
• Expectativas de tiempo para cada paso necesario
• Datos de contacto de expertos en Cassandra y soporte de herramientas de copia de seguridad

NOTA IMPORTANTE: Debe haber una guía para que las personas no familiarizadas entiendan cuál de esos procedimientos se aplica a una situación determinada.

Estos runbooks cumplen una función extremadamente importante para las empresas y los negocios. Deben actualizarse después de cada actualización, restauración o cuando cambie alguna herramienta de copia de seguridad.

¿Qué métricas y SLA deben seguirse para la salud de las copias de seguridad?

El seguimiento de la salud de las copias de seguridad requiere supervisar métricas específicas y medir su rendimiento y si éste se está degradando.

Métricas clave que es importante tener en cuenta para la salud de sus copias de seguridad:

1. Tasa de éxito. Esta métrica representa el porcentaje de trabajos que han tenido éxito dentro del periodo definido.
2. Duración. Esta métrica define cuánto tiempo puede durar cada trabajo. Por ejemplo, decidir que una instantánea completa se realice en una semana.
3. Tamaño. Investigue las caídas o picos inesperados que señalan anomalías.
4. Tiempo de restauración. Medido mediante pruebas regulares de restauración, esta métrica confirma que el RTO real es alcanzable en la práctica.
5. Antigüedad de la copia de seguridad. Identificar la antigüedad de la copia de seguridad satisfactoria más reciente en este momento.
6. Tiempo de respuesta a las alertas: rapidez con la que se reconocen los fallos y se actúa en consecuencia. SLA: todas las alertas de copia de seguridad reconocidas en 15 minutos.

Para supervisar estas métricas e identificar la salud de sus copias de seguridad, puede utilizar herramientas de terceros como Bacula Enterprise, Medusa u OpsCenter que ofrecen una plataforma unificada para hacer todo esto a la vez.

Puntos clave

• Defina su RPO y RTO antes de diseñar su estrategia, ya que sin ellos, su estrategia de copias de seguridad no tiene un objetivo medible.
• Almacene siempre sus instantáneas fuera de las instalaciones una vez creadas.
• Realice copias de seguridad incrementales y comprometa el archivo de registros, ya que reducirá la sobrecarga de almacenamiento
• La automatización, la supervisión y las alertas son imprescindibles, ya que reducen la probabilidad de errores y fallos.
• Disponga siempre de cifrado, control de acceso, almacenamiento inmutable y copias de seguridad air-gapped. El cifrado y el control de acceso impiden el acceso no autorizado. Las copias de seguridad inmutables y air-gapped garantizan que el ransomware no pueda destruir su ruta de recuperación.
• Pruebe sus copias de seguridad ya que los simulacros de restauración regulares confirman su plan de trabajo de recuperación.

Preguntas frecuentes

¿Pueden las copias de seguridad de Cassandra permanecer consistentes a través de arquitecturas de aplicaciones distribuidas?

Sí, las copias de seguridad de Cassandra pueden permanecer consistentes a través de canales de aplicaciones distribuidas. Sin embargo, se implementa a través de instantáneas coordinadas y archivo de registros de commit que producen copias de seguridad fiables y restaurables.

¿Cómo se realizan copias de seguridad de despliegues Cassandra multi-tenant de forma segura?

Realizar copias de seguridad seguras de despliegues Cassandra multi-tenant requiere instantáneas a nivel de espacio clave para mantener aislados los datos de los tenants. Asegúrese de aplicar estrictos controles de acceso y cifrado durante el almacenamiento de las copias de seguridad para evitar la exposición de los datos entre inquilinos.

¿Cómo cambian los despliegues de Cassandra en contenedores y basados en Kubernetes la estrategia de copia de seguridad?

Los despliegues de Cassandra en contenedores requieren instantáneas de volumen persistentes en lugar de confiar únicamente en la instantánea de nodetool. En Kubernetes, puede utilizar herramientas como Medusa para gestionar la orquestación de copias de seguridad a través de pods.