Guia completo para backup e restauração de banco de dados Cassandra

Introdução: Por que os backups são importantes para o Cassandra?

O Cassandra foi criado para nunca ficar inativo. O backup do Cassandra é importante, pois sem um backup adequado, dados importantes podem correr o risco de serem perdidos. Embora a replicação seja um componente importante que protege contra falhas de hardware, ela não protege contra a perda de dados. Portanto, ter um backup recuperável e armazenar cópias em um local totalmente separado é uma necessidade para proteger todos os seus dados.

Que tipos de falhas ou incidentes exigem um plano de backup e restauração?

Os planos de backup e restauração são necessários para falhas lógicas que a replicação não pode resolver. Esses problemas incluem exclusão acidental, corrupção de dados, ransomware e upgrades com falha. O Cassandra copia todas as operações para todas as réplicas simultaneamente, o que significa que, caso ocorra algum desses problemas, todo o cluster será prejudicado.

A seguir, vamos explorar as falhas e os incidentes típicos que exigem um plano de backup e restauração.

• Exclusão acidental de dados: Executar DROP TABLE ou TRUNCATE no cluster errado, resultando na exclusão de seus dados de todas as réplicas.
• Corrupção de dados: Um problema de software, hardware ou sistema de arquivos que exige uma reversão para um estado estável.
• Upgrades com falha: Configuração inadequada do banco de dados ou upgrades que resultam em dados corrompidos ou deixam os arquivos SSTable em um formato incompatível.
• Ransomware: Software mal-intencionado que criptografa os diretórios de dados do Cassandra, tornando os dados ilegíveis.
• Usuário interno mal-intencionado: Alguém da equipe que deliberadamente exclui ou destrói dados (um cenário menos raro do que a maioria supõe).

Quais são as considerações técnicas e comerciais sobre RPO (Recovery Point Objective) e RTO (Recovery Time Objective)?

O RPO e o RTO são duas métricas importantes que determinam diretamente a frequência com que os backups devem ser executados ou a rapidez com que a recuperação deve ser concluída. Todas as decisões de backup que uma empresa toma decorrem diretamente dessas duas métricas:

O Recovery Point Objective (RPO) define o volume de perda de dados que sua empresa pode tolerar, expresso em horas. Por exemplo, um RPO de 4 horas significa que o senhor não pode perder mais do que 4 horas de dados; portanto, será necessário fazer um backup a cada 4 horas.

O objetivo de tempo de recuperação (RTO), por outro lado, define quanto tempo sua empresa pode ficar indisponível enquanto o senhor se concentra no processo de recuperação. Digamos que seu RTO seja de 2 horas. Nesse caso, o senhor tem 2 horas para se recuperar; a empresa pode ter sérios problemas de saúde financeira.

Ambas as métricas são importantes porque informam as decisões comerciais que podem afetar diretamente sua estratégia de backup do Cassandra.

Quais são os riscos de não ter uma estratégia confiável de backup de dados do Apache Cassandra?

A replicação por si só não é suficiente para o backup e, portanto, representa um enorme risco para qualquer empresa. As consequências vão além da perda de dados, afetando a continuidade operacional, a conformidade e a confiança do usuário. Veja a seguir os principais problemas que as empresas enfrentam sem uma estratégia confiável de backup do Cassandra.

• Perda permanente de dados: Sem uma estratégia de backup ou com uma estratégia não confiável, não há caminho de recuperação e, em caso de catástrofe, não é possível recuperar o que foi perdido.
• Tempo de inatividade prolongado: Sem uma estratégia de backup e RTO e RPO claramente definidos, sua empresa pode acabar perdendo mais do que o esperado.
• Conformidade e exposição regulatória: Setores como o de saúde e o financeiro operam sob normas rígidas. Sem uma estratégia adequada de backup do Cassandra, a não conformidade pode resultar em penalidades financeiras significativas.
• Danos à reputação: Quando os dados do usuário estão em risco, as empresas podem sofrer danos duradouros à reputação, levando a uma perda gradual de usuários e de confiança ao longo do tempo.

Como as arquiteturas de implantação do Apache Cassandra afetam as necessidades de backup?

A arquitetura de implantação do Cassandra pode ditar fortemente as necessidades de backup. Ela determina quão arriscada ou complexa deve ser a estratégia de backup. Cada tipo de implantação apresenta desafios específicos que uma abordagem única não pode resolver.

1. Implantações em vários data centers

Em implementações com vários data centers, as operações de backup geralmente são executadas a partir de um data center secundário dedicado, em vez de nós de produção, evitando que a atividade de backup prejudique o desempenho ao vivo. Esse data center dedicado recebe os mesmos dados replicados que a produção, mas lida com todas as cargas de trabalho de backup separadamente, mantendo os nós primários livres para o tráfego de usuários.

2. Nuvem/AWS – EBS vs. Armazenamento de instâncias

As implementações de nuvem no AWS exigem abordagens de backup diferentes, dependendo do tipo de armazenamento. Os nós executados em volumes EBS podem aproveitar os recursos nativos de snapshot, pois o armazenamento EBS persiste independentemente da instância. Os nós que usam o armazenamento de instância, no entanto, exigem backups de hora em hora e diários no armazenamento externo, como o S3, porque os dados do armazenamento de instância são perdidos de forma permanente e irreversível no momento em que uma máquina para ou reinicia.

3. Implantações Kubernetes/Híbridas

As implantações do Cassandra baseadas no Kubernetes exigem backup de mais do que apenas dados do SSTable. Elas também dependem das definições Kubernetes Secrets, ConfigMaps e StatefulSet que definem a configuração e a identidade do cluster. Sem elas, os dados restaurados não têm um ambiente válido para serem executados.

4. Clusters de produção com vários nós

Em clusters de produção com vários nós, os snapshots devem ser acionados simultaneamente em todos os nós para produzir um ponto de recuperação consistente. Um backup escalonado corre o risco de criar lacunas nos dados que impossibilitam uma restauração limpa.

5. Arquivamento de log de confirmação

O arquivamento de log de confirmação preserva o log de gravação sequencial do Cassandra juntamente com os snapshots regulares, permitindo a recuperação pontual. Para implementações em que até mesmo pequenas janelas de perda de dados são inaceitáveis, o arquivamento de logs de confirmação é um componente essencial da estratégia de backup.

Que objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO) o senhor deve considerar para o backup e a restauração do banco de dados Cassandra?

O RPO e o RTO corretos para uma implantação do Cassandra dependem do valor comercial dos dados e da complexidade do cluster. Esses dois números devem ser definidos antes que qualquer estratégia de backup seja projetada.

No que diz respeito ao RPO, quanto mais críticos forem os dados, mais rigoroso deverá ser o ponto de recuperação. O RPO define a perda de dados aceitável e determina a frequência do backup. Considere que o senhor tem uma plataforma de processamento de pagamentos que registra transações em tempo real, que pode precisar de um RPO de minutos.

Em relação ao RTO, o Cassandra exige expectativas honestas. Ao contrário de um banco de dados de servidor único, em que a restauração pode levar minutos, a restauração de um cluster distribuído do Cassandra envolve a cópia de dados de volta para vários nós, a reinicialização de serviços e a execução de operações de reparo para sincronizar réplicas.

Como o backup do Cassandra se encaixa em uma estratégia mais ampla de proteção de dados corporativos?

Para pequenas empresas que operam em seus setores designados, utilizar apenas a estratégia de backup do Cassandra é suficiente. No entanto, no caso de grandes corporações e empresas, o backup do Cassandra não funciona isoladamente, mas se integra a uma estrutura mais ampla de proteção de dados.

Por que o backup no nível do banco de dados não é suficiente para a resiliência empresarial?

Ao contrário das startups e das empresas de médio porte, as empresas lidam com um grande volume de dados. Nesses cenários, é difícil para todas as equipes gerenciarem seus próprios backups de forma independente, pois

• As organizações perdem o controle do que estão realmente protegendo
• Grandes problemas ou catástrofes, como um ataque de ransomware, afetam vários sistemas simultaneamente

A resiliência corporativa é mais do que um backup no nível do banco de dados. Embora cada equipe faça o melhor que pode isoladamente, ainda é necessário um sistema universal que gerencie tudo e mantenha o controle caso algo aconteça. Portanto, para as grandes empresas, o Cassandra não opera separadamente, mas sim ao lado de outros sistemas importantes que exigem proteção sob políticas consistentes.

Como os backups do Cassandra se integram às plataformas de backup corporativo?

Os backups do Cassandra se integram às plataformas de backup corporativo por meio de seus plug-ins designados, que posteriormente se tornam parte do patrimônio unificado da empresa. Abaixo, vamos abordar os recursos e o que ele pode fazer quando estiver integrado à plataforma de backup corporativo.

• Gerenciamento automático de instantâneos: A plataforma agenda e executa o comando de instantâneo nodetool automaticamente em todos os nós de uma só vez.
• Coordenação entre os nós: O plug-in de backup do Cassandra coordena todos os nós em todo o cluster.
• Local de armazenamento centralizado: Os arquivos são transferidos de nós individuais para um local de armazenamento centralizado.
• Sem limpeza manual: A plataforma exclui automaticamente os arquivos antigos que não têm mais utilidade
• Monitoramento e alerta: Em caso de qualquer problema, as plataformas identificam e alertam a equipe, o que leva a resoluções antecipadas.
• Lidar com o processo de restauração: Quando a recuperação é necessária, a plataforma gerencia tudo de A a Z.

Como os sistemas de backup centralizados reduzem o risco operacional?

A utilização de um sistema de backup centralizado pode afetar positivamente a eficiência operacional da empresa. Com a tabela abaixo, vamos explorar os riscos típicos que os backups individuais representam para as empresas e como ter um sistema de backup centralizado pode reduzir significativamente os riscos operacionais.

Quais são as estratégias de backup do Cassandra disponíveis?

O backup do Cassandra sozinho não é suficiente para atender às necessidades das empresas. Ele aborda apenas um sistema de cada vez, enquanto as empresas exigem vários sistemas com proteção coordenada e consistente. Um único backup isolado não pode proteger um ambiente corporativo. Ele precisa de uma estratégia centralizada de proteção de dados que unifique tudo em uma única estrutura e que implemente políticas, monitoramento, alertas e procedimentos de recuperação consistentes.

O que é o backup instantâneo do Cassandra e quando o senhor deve usá-lo?

O backup instantâneo do Cassandra cria uma cópia pontual de todos os SSTables, executada pelo comando nodetool snapshot. Ele não requer nenhum armazenamento adicional, mas cria hard links congelados para aquele momento específico, que mais tarde poderão ser utilizados para recuperar as informações que o senhor tinha, caso algo dê errado ou os dados sejam perdidos.

Antes de qualquer operação de alto risco, o backup de snapshot do Cassandra deve ser utilizado. Esses cenários incluem

• Atualizações em grande escala
• Mudanças de esquema
• Exclusão de dados em massa

Importante: É altamente recomendável executar snapshots diariamente ou ocasionalmente. Depois de criado, transfira-o para um armazenamento externo. O backup do Cassandra S3 é a abordagem mais usada. O senhor pode transferi-lo para o Amazon S3, que protegerá seus snapshots e garantirá a segurança de todos os seus dados.

Qual é a diferença entre backups completos, incrementais e diferenciais?

O Cassandra oferece três categorias principais de backups:

• Backup completo
• Backup incremental
• Backup diferencial

1. Um backup completo captura uma cópia completa de todo o conjunto de dados (independentemente de ter havido ou não alguma alteração). Embora seja a opção mais simples, ela consome muito tempo e, portanto, não é a mais usada.
2. O backup incremental captura apenas o que foi alterado desde o último backup.
3. O backup diferencial captura apenas os dados recém-adicionados e alterados desde o último backup completo.

OBSERVAÇÃO: O Cassandra não oferece suporte nativo ao backup diferencial.

Como funciona o backup incremental do Cassandra e quando o senhor deve ativá-lo?

O backup incremental do Cassandra captura apenas os novos arquivos SSTable à medida que são gravados no disco, o que o torna mais eficiente em termos de armazenamento do que os backups completos. Os backups incrementais reduzem a sobrecarga de armazenamento capturando apenas os novos dados desde o último backup. A ativação desse recurso requer uma alteração de uma linha no Cassandra.yaml

Uma vez ativado, não há nenhum outro trabalho manual: o restante é tratado automaticamente.

Etapa 1: Novos dados são recebidos

Os novos dados são recebidos na memtable, que é um buffer temporário de gravação na memória

Etapa 2: Os dados são transferidos da memtable para o disco

Quando a memtable estiver cheia e fora do armazenamento, o Cassandra libera os dados como um arquivo SSTable permanente.

Etapa 3: Os hard links são criados

Assim que os SStables são criados, o Cassandra cria automaticamente hard links para esses dados em backups designados.

Etapa: 4: Os agentes de backup varrem e transferem

Ferramentas de backup como o Medusa, integradas ao Cassandra, verificam e transferem regularmente novos arquivos para o armazenamento externo.

Etapa 5: O ciclo se repete

Esse processo se repete continuamente toda vez que novos dados entram no cluster

Os backups incrementais do Cassandra devem ser ativados quando:

• Os dados são alterados com frequência
• Há um grande volume de dados
• Seu RPO requer pontos de recuperação com mais frequência do que 24 horas
• O instantâneo completo diário ocupa muito espaço de armazenamento ou leva muito tempo

Como os logs de confirmação e as considerações de recuperação point-in-time afetam o backup e a restauração do Cassandra?

O arquivamento de logs de confirmação é um recurso importante na arquitetura de implantação do Cassandra quando se trata de restaurar os bancos de dados.

Ao executar o backup do Cassandra, as etapas são as seguintes:

• A gravação chega
• Commit Log (disco) + Memtable (RAM)
• A memória é preenchida → FLUSH
• SSTable (disco)
• Segmento de registro de compromisso excluído

Embora essa seja uma sequência ideal em circunstâncias normais de operação, o arquivamento do log de confirmação altera esse padrão. Em vez de excluir os segmentos do log de confirmação no final, ele salva cópias no armazenamento externo, o que permite o acesso aos dados perdidos. Os snapshots regulares combinados com os arquivos de log de confirmação possibilitam a recuperação point-in-time (PITR). Sem o arquivamento do log de confirmação, a recuperação é limitada apenas ao último snapshot.

Para ter uma ideia melhor, vamos considerar o exemplo a seguir. Um instantâneo foi tirado às 11 horas da manhã e, em seguida, ocorreu uma exclusão acidental às 15:34 horas. Sem o arquivamento de logs de confirmação, o senhor só conseguiria acessar os dados até as 11h00, o que lhe custaria 4 horas e 34 minutos de perda de dados. Com o arquivamento de logs de confirmação, todos os dados podem ser substituídos, reduzindo a quantidade de perda de dados.

Nesses cenários, em que o RPO é próximo de zero, o arquivamento de logs de confirmação não é opcional, mas obrigatório.

Quais são os prós e os contras dos backups em nível de cluster ou de nó?

Os backups do Cassandra são executados no nível do nó ou no nível do cluster, cada um com diferentes vantagens e desvantagens.

Backup em nível de nó: É mais simples em comparação com o backup em nível de cluster, pois não requer orquestração especial e o backup é feito em cada nó de forma independente. No entanto, fazer o backup dos nós de forma independente pode causar inconsistência de dados em todo o cluster, especialmente no caso de clusters com mais de 50 nós, pois a recuperação pode ser desafiadora, causando problemas associados à integridade dos dados.

Backup em nível de cluster: Ao contrário do backup em nível de nó, ele é muito mais complexo e requer uma orquestração especial. Ele faz o backup em todos os nós do mesmo cluster simultaneamente. Isso garante que a integridade dos dados não seja comprometida.

Quais ferramentas e serviços suportam o backup e a restauração do Cassandra?

O Cassandra oferece um amplo conjunto de ferramentas e serviços para backup e restauração. Escolher a ferramenta certa é tão essencial quanto as próprias estratégias, e essa escolha depende muito de vários fatores, incluindo o tamanho do cluster e os requisitos de recuperação. Nesta seção, abordaremos detalhadamente os principais tipos de ferramentas e serviços que oferecem suporte ao backup e à restauração do Cassandra e discutiremos as vantagens e desvantagens de cada um.

Quais são os prós e os contras dos métodos de backup nativos do Cassandra?

Quais são os prós e os contras dos métodos de backup nativos do Cassandra?

Os métodos de backup nativos do Cassandra são as ferramentas incorporadas diretamente ao Cassandra, sem a necessidade de integração com software de terceiros, como o Medusa e o Bacula. Os dois principais tipos de métodos de backup nativos do Cassandra são os seguintes:

1. Nodetool snapshot
2. Backup incremental incorporado

Ambas as opções são amplamente usadas pelo Cassandra, e o método específico que o senhor escolhe depende muito de vários fatores. Os métodos de backup nativos do Cassandra podem ser uma opção ideal para pequenas implantações devido à sua praticidade. Não há custos adicionais de instalação ou licenciamento.

No entanto, eles também têm suas limitações. Eles se concentram muito no trabalho manual, que inclui a transferência de arquivos para um banco de dados externo, um a um, e a limpeza manual dos snapshots antigos. Para grandes implementações, essa pode não ser a opção ideal, pois não há monitoramento centralizado, nem alerta automático em caso de falha, entre muitos outros recursos.

Prós:

• fácil de entender
• ideal para pequenas implementações
• não requer instalação
• gratuito e incorporado

Contras:

• não é adequado para grandes produções
• sem monitoramento ou alerta
• não há gerenciamento de retenção
• sem agendamento

Como funciona o Cassandra backup S3 e quando o senhor deve usá-lo?

O Cassandra backup S3 é uma das soluções de backup mais usadas, pois oferece um amplo conjunto de vantagens:

• Capacidade de armazenamento ilimitada
• Redundância de localização geográfica
• Controle de acesso
• Políticas automáticas de ciclo de vida

Para ajudá-lo a tomar uma decisão mais bem informada e identificar se ele é adequado às suas necessidades, vamos explorar passo a passo como ele funciona.

Etapa 1: um snapshot é acionado em cada nó, produzindo arquivos SStable

Etapa 2: em seguida, esses arquivos são compactados, criptografados e carregados no bucket S3 alocado, usando uma ferramenta de backup de terceiros, como o Medusa

Etapa 3: Uma vez no S3, os arquivos de snapshot locais podem ser excluídos

O backup do Cassandra no S3 deve ser usado quando o senhor

• O cluster é executado em um ambiente de nuvem com acesso ao S3
• Precisa de um armazenamento de backup econômico e separado geograficamente
• Deseja o gerenciamento automático de retenção por meio de políticas de ciclo de vida do S3
• O usuário usa ferramentas de terceiros, como Bacula Enterprise, Medusa e OpsCenter, que se integram nativamente ao S3

Como os métodos manuais baseados em snapshot se comparam às ferramentas automatizadas de backup do Cassandra?

Em termos de praticidade, as ferramentas automatizadas de backup do Cassandra são uma opção melhor, especialmente para empresas. A seguir, vamos discuti-las e compará-las separadamente.

Método manual baseado em snapshot

Esse método depende muito do trabalho manual, incluindo a execução de instantâneos do nodetool, a criação de seus próprios scripts para transferir manualmente os arquivos para o S3 SStable, a configuração de tarefas cron e a varredura manual de instantâneos antigos que não são mais necessários. Os métodos baseados em manual não são altamente eficientes para empresas e grandes corporações, pois dependem de pessoas, não têm monitoramento e coordenação e aumentam o risco de erros.

As ferramentas automatizadas de backup do Cassandra são integradas automaticamente por meio de ferramentas de terceiros, incluindo o Medusa e o Bacula Enterprise. Os recursos típicos incluem agendamento automatizado, coordenação, transferência, compactação e criptografia, gerenciamento de retenção, monitoramento e alertas.

Como os snapshots no nível do sistema de arquivos podem ser usados com segurança para o backup do Cassandra DB?

Em um cenário típico, o backup do Cassandra DB simplesmente cria e armazena dados no banco de dados do Cassandra. Um instantâneo no nível do sistema de arquivos oferece uma abordagem alternativa a isso, permitindo a captura de todo o disco na camada de armazenamento. Ele se integra a ferramentas de backup do Cassandra de terceiros, como os instantâneos do AWS EBS, para capturar arquivos SSTable, logs de confirmação e arquivos de configuração.

Embora essas ferramentas sejam bastante rápidas e abrangentes e possam operar de forma independente na camada de armazenamento, elas podem causar problemas sérios se não forem usadas corretamente. Se o Cassandra estiver no meio da gravação e um instantâneo do sistema de arquivos for acionado enquanto os dados estiverem na tabela de memória, pode ser difícil restaurar os dados fornecidos com clareza.

OBSERVAÇÃO IMPORTANTE: para reduzir o risco de tal cenário, execute o nodetool flush antes de acionar o instantâneo do sistema de arquivos. Veja a seguir o que o senhor pode fazer para reduzir o risco desse cenário.

Existem ferramentas de backup e restauração do Cassandra de terceiros e quais recursos elas oferecem?

Há um amplo conjunto de ferramentas de backup e restauração do Cassandra que são opções ideais para atender às necessidades de implantações de produção em grande escala. As vantagens típicas oferecidas por essas ferramentas incluem, mas não se limitam a

• Eficiência operacional
• Suporte ao armazenamento em nuvem
• Flexibilidade de backup
• Recuperação de desastres mais rápida

Principais ferramentas de backup e restauração do Cassandra de terceiros

• Bacula Enterprise

O Bacula Enterprise se destaca de todas as outras soluções de backup, pois foi projetado especificamente para ambientes grandes e complexos. É a ferramenta de backup e restauração de nível empresarial mais abrangente disponível para implantações do Cassandra.

• OpsCenter

O OpsCenter é uma ferramenta de backup do Cassandra de terceiros que faz parte da plataforma oficial de gerenciamento de clusters da DataStax. O backup e a restauração são apenas um componente de uma plataforma mais ampla que ele abrange. Essa ferramenta armazena dados de backup para garantir que não haja arquivos duplicados e oferece suporte ao armazenamento local e ao Amazon S3 como destinos de backup.

O OpsCenter se integra diretamente ao ecossistema DataStax Enterprise e lida com a complexidade adicional de restaurar essas cargas de trabalho juntamente com os dados padrão do Cassandra. Seu recurso de clonagem de cluster permite que os dados de backup sejam restaurados em um cluster diferente, dando suporte a fluxos de trabalho de migração e recuperação de desastres.

• Medusa

O Medusa é uma das ferramentas de backup e restauração de código aberto mais usadas, criada especificamente para o Apache Cassandra. Os recursos típicos oferecidos pelo Medusa incluem suporte a backup completo e incremental, gerenciamento automático de retenções e integração com vários serviços de armazenamento em nuvem, como Amazon S3, Google Cloud Storage e Azure Blob Storage.

O Medusa foi desenvolvido para a arquitetura distribuída do Cassandra; ele entende como coordenar backups entre nós, gerenciar arquivos SSTable e lidar com cadeias de backup incrementais sem scripts personalizados.

Como o backup do Cassandra pode ser integrado ao Bacula Enterprise para proteção empresarial?

As ferramentas de backup do Cassandra podem abordar o banco de dados isoladamente, o que é uma opção ideal para pequenas implantações. Para clusters > 50 nós, o Cassandra Backup sozinho não é suficiente, pois não possui a coordenação e a visibilidade de uma infraestrutura completa. O Bacula Enterprise integra o backup do Cassandra em uma estratégia de proteção de dados mais ampla, em toda a organização.

Diferentemente do backup instantâneo do Cassandra, que faz o backup de cada nó um a um, o Bacula permite coordenar todos os nós do cluster de uma só vez em um mesmo momento específico. Ele gerencia um backup completo automaticamente, sem nenhuma intervenção manual. Isso inclui acionar os snapshots, transferir os SStables para o armazenamento centralizado relevante, gerenciar as cadeias de backup e, posteriormente, arquivar os logs de commit para uma recuperação point-in-time (PITR).

Isso torna o Bacula Enterprise uma opção prática para organizações que precisam de controle centralizado sobre o Cassandra juntamente com outros sistemas em sua infraestrutura.

Como o senhor realiza um backup seguro para diferentes topologias do Cassandra?

Fazer o backup do Cassandra com segurança requer mais do que isso: requer uma execução cuidadosamente planejada, que muitas vezes é negligenciada. Prestar atenção aos detalhes operacionais é tão importante quanto as próprias ferramentas e estratégias, pois é isso que garante a consistência dos dados.

Como fazer o backup de um cluster Cassandra de vários nós sem afetar a disponibilidade?

Para fazer o backup de um cluster Cassandra de vários nós sem afetar a disponibilidade, é necessário escalonar as operações de backup entre os nós, programar em horários fora de pico e limitar o uso de recursos. As práticas a seguir abordam diretamente cada um desses requisitos.

• Faça backup de um nó de cada vez

O Cassandra replica dados em vários nós, o que pode afetar sua disponibilidade. Para minimizar esse risco, é uma ótima prática agrupar apenas um cluster de cada vez, enquanto os demais podem desempenhar suas funções diárias, como atender a solicitações.

• Execute backups somente em horários fora de pico

Durante os horários de pico, especialmente nos dias de semana e no horário de trabalho, a concorrência por recursos é relativamente maior. Fazer backup das operações durante os fins de semana resolve esse problema, pois há pouca ou nenhuma concorrência por recursos.

• Limitação das operações de backup

As operações de backup e o tráfego ao vivo competem pelos mesmos recursos. Ferramentas como o Bacula Enterprise ou o Medusa ajudam a limitar as operações de backup. Isso garantirá que as operações de backup não consumam recursos suficientes e afetará o desempenho em tempo real.

Como o senhor coordena o backup de instantâneos do Cassandra em nós distribuídos?

A coordenação do backup de instantâneos do Cassandra em nós distribuídos é simples, desde que todos os nós do cluster distribuído sejam capturados simultaneamente.

Os cenários opostos podem causar sérios problemas. Em um cluster distribuído, cada nó contém uma parte diferente do conjunto total de dados. Mesmo uma diferença mínima pode resultar em pontos diferentes no tempo, o que, em última análise, pode levar a um ponto de recuperação inconsistente que é difícil ou quase impossível de restaurar com clareza.

Ferramentas eficazes ou scripts de orquestração devem ser implementados para lidar com isso de forma nativa. A integração do Cassandra com ferramentas de terceiros, como o Bacula Enterprise, permite conectar todos os nós ao mesmo tempo, aguardar a conclusão de todos os instantâneos e, posteriormente, transferir os arquivos para o armazenamento externo. Esse processo garante a coordenação tranquila do backup de snapshots do Cassandra em nós distribuídos, sem nenhum comprometimento.

Como o senhor garante que os backups permaneçam consistentes entre réplicas e data centers?

Os backups podem se tornar inconsistentes entre réplicas e data centers quando os nós mantêm versões ligeiramente diferentes dos mesmos dados no momento do instantâneo. Há duas etapas de pré-backup e duas práticas de nível de backup que tratam diretamente desse problema.

• Executar o nodetool repair

Quando o senhor executar um nodetool repair, a sincronização da réplica ocorrerá em todo o cluster e cada nó terá a versão mais recente dos mesmos dados. Depois que esse processo for concluído, não haverá inconsistência quando o snapshot começar.

• Desativar a compactação

Execute nodetool disableautocompaction para evitar que os nós estejam no meio da compactação quando o instantâneo for executado, evitando arquivos SSTable parcialmente mesclados no backup.

Depois de concluir essas etapas, o senhor pode passar para o processo de backup. Aqui está o que o senhor pode fazer para manter a consistência entre os datacenters.

• Use a consistência LOCAL_QUORUM

Isso permitirá que o senhor tenha apenas dados totalmente confirmados e atualizados do data center local que são capturados durante as operações de backup

• Faça backup somente de um data center

O backup a partir de vários data centers pode causar inconsistências devido à diferença de horário. Fazer o backup somente de um data center elimina as inconsistências, pois um backup completo do DC já captura o conjunto de dados completo por meio da replicação.

Quais são as etapas para restaurar o Cassandra a partir de backups?

Fazer o backup do Cassandra é apenas metade do processo: é igualmente importante se equipar com informações sobre como restaurar o Cassandra a partir do backup. O processo de restauração pode variar dependendo de vários fatores, incluindo o escopo e os métodos usados em todo o processo.

A seção a seguir aborda todos os cenários de restauração que o senhor pode encontrar.

Como o senhor realiza o backup e a restauração do Cassandra com segurança para tabelas, keyspaces ou clusters completos?

O backup e a restauração do Cassandra podem estar em três níveis diferentes, e cada um deles pode levar a um escopo diferente de perda de dados. Vamos discuti-los um a um.

• Restauração em nível de tabela

Esse é o nível mais simples de recuperação. Na restauração em nível de tabela, o senhor não precisa recuperar tudo, mas apenas uma tabela que foi acidentalmente descartada ou excluída. O processo é simples: copiar o arquivo de snapshot fornecido de volta para o diretório correto e executar o nodetool refresh para carregar os dados.

• Restauração em nível de espaço-chave

A restauração em nível de espaço-chave refere-se ao processo de restauração de todas as tabelas que estão dentro do mesmo espaço-chave. Ela segue o mesmo processo da restauração em nível de tabela, mas se aplica a todas as tabelas e é feita quando todo o espaço de chave é excluído ou corrompido simultaneamente.

• Uma restauração de cluster completo

Esse tipo abrange tudo o que está no mesmo cluster; portanto, é o mais complexo e demorado. Normalmente, a restauração do cluster completo ocorre após grandes eventos catastróficos, como ransomware. O processo de restauração de um cluster completo inclui a interrupção do Cassandra em cada nó, a varredura de todos os diretórios de dados, a restauração dos arquivos de snapshot e, posteriormente, a reinicialização do cluster.

Como restaurar a partir de um backup de snapshot do Cassandra e retornar os nós ao serviço?

A restauração de um nó do Cassandra é um processo meticuloso e exige o cumprimento de etapas claramente definidas. A seguir, vamos explorar o caminho exato das etapas que o senhor precisará seguir para restaurar o nó do Cassandra.

Etapa 1: interromper o Cassandra

O senhor precisará interromper o Cassandra, pois os arquivos de dados não podem ser substituídos enquanto o Cassandra estiver em execução

Etapa 2: Limpar o diretório de dados

Limpe todos os arquivos corrompidos do diretório de dados, pois esses são os arquivos que estão sendo substituídos pelo backup

Etapa 3: Copiar arquivos de snapshot

Depois que o diretório de dados for limpo dos arquivos excluídos ou corrompidos, o senhor poderá copiar os arquivos de instantâneo e trazê-los de volta para o caminho correto do diretório de dados

Etapa 4: Corrigir permissões

Assim que os dados corretos estiverem no lugar certo, corrija as permissões dos arquivos e certifique-se de que o Cassandra seja o proprietário deles; caso contrário, ele não conseguirá ler a versão correta

Etapa 5 – Reiniciar o Cassandra

O nó volta a ficar on-line, lendo os arquivos SSTable restaurados.

Etapa 6 – Execute o nodetool repair. Isso sincroniza o nó restaurado com seus vizinhos para que ele receba todas as gravações que ocorreram em outros nós enquanto ele estava off-line.

OBSERVAÇÃO IMPORTANTE: se estiver fazendo uma restauração completa do cluster, será necessário repetir essa sequência em todos os nós.

Como o senhor usa os dados de backup incremental do Cassandra durante a recuperação?

A recuperação de um backup incremental do Cassandra é muito mais complexa em comparação com a recuperação do backup de instantâneos. Há dois aspectos importantes que o senhor deve ter em mente ao iniciar uma recuperação com um backup incremental do Cassandra.

• O incremental deve ser aplicado em ordem cronológica
• Nenhum arquivo da cadeia pode ser ignorado.

A recuperação de backup incremental compreende duas fases principais, que são as seguintes:

1. Restaurar a linha de base do snapshot completo: É IMPOSSÍVEL recuperar seu backup incremental sem restaurar o backup de instantâneo completo, pois ele serve como base.
2. Aplique os incrementos em ordem cronológica: Cada incremento é criado em cima da linha de base, do mais antigo para o mais recente. Se a ordem não for seguida cronologicamente, a recuperação do backup não será adequada

Vamos discutir um exemplo e ver como isso funciona

Suponha que o senhor tenha feito um snapshot completo na terça-feira e incrementais todos os dias até sábado. Para recuperar o backup incremental no sábado, o senhor precisará aplicar os snapshots de terça-feira e, em seguida, os incrementais de quarta, quinta, sexta e sábado na mesma ordem cronológica.

Como o senhor lida com as incompatibilidades de versão entre as versões de backup e de destino do Cassandra?

Como o senhor lida com as incompatibilidades de versão entre as versões de backup e de destino do Cassandra?

Os backups do Cassandra podem mudar de tempos em tempos. Quando a versão usada para criar e a usada para restaurar o backup não coincidem, não ocorre uma restauração limpa adequada. Dependendo das circunstâncias, há duas soluções que o senhor deve considerar.

1. Executar a mesma versão do Cassandra que foi usada para criá-lo e, em seguida, atualizá-la para a versão de destino. Essa é a mais usada dessas duas opções. Isso minimiza a complexidade de todo o processo e elimina os riscos de compatibilidade de formato.
2. Converta os arquivos antigos e, em seguida, restaure-os para uma nova versão. Se a primeira solução não funcionar, o senhor pode converter os arquivos da versão antiga usando a ferramenta sstableupgrade e, depois, restaurar para a nova versão.

Ambas as opções são gerenciáveis. O que importa não é qual o senhor escolher, mas sim que as incompatibilidades de versão sejam tratadas adequadamente e que os dados sejam restaurados corretamente.

Como automatizar e programar backups do Cassandra de forma confiável?

Os processos de backup manual, que são ideais para pequenas implementações, ainda têm suas desvantagens. Eles são propensos a erros humanos, programações esquecidas e recursos que não são detectados até que ocorra uma catástrofe grave. A automação e o agendamento foram projetados especificamente para resolver esse problema: garantir que os erros sejam tratados a tempo, antes que se tornem graves, e identificar falhas logo no início para tomar as precauções necessárias. Esta seção aborda de forma abrangente tudo o que o senhor precisa saber para automatizar e programar de forma confiável os backups do Cassandra.

Quais padrões de agendamento minimizam a carga e atendem ao seu RTO/RPO?

Ao escolher o agendamento de backup correto, há dois requisitos que o senhor precisa ter em mente

• Atender aos requisitos de RPO/RTO
• Minimizar a carga do cluster

Há dois padrões principais de agendamento de backup que o senhor pode querer considerar

• Instantâneos completos diários + backups incrementais de hora em hora

Execute um instantâneo completo uma vez por dia e incrementos de hora em hora para capturar as alterações que ocorrem ao longo do dia. Essa combinação o ajudará a satisfazer o RPO de uma hora sem executar instantâneos completos repetidamente.

OBSERVAÇÃO IMPORTANTE: programe seus snapshots completos fora dos horários de pico para minimizar a concorrência pelo tráfego ao vivo

• Snapshots completos semanais + incrementos diários

Embora, para a maioria das implementações, os instantâneos completos diários satisfaçam o RPO de 24 horas, esse não é o caso de clusters > 50 nós, pois eles consomem muito tempo. Nesses cenários, programar snapshots completos semanais combinados com incrementos diários pode ser uma opção melhor, o que permitirá que o senhor reduza as despesas gerais e mantenha um RPO de 24 horas.

A seguir, vamos discutir os requisitos de RPO mais usados e quais são os padrões recomendados para eles.

Como os scripts, as ferramentas de orquestração ou os cron jobs podem se tornar resilientes e idempotentes?

Os scripts de backup não funcionam adequadamente de muitas maneiras, e resolver isso a tempo é fundamental. Criar resiliência e idempotência é a solução definitiva, garantindo que cada processo de backup seja tratado com cuidado.

Aqui estão as etapas concretas que o senhor deve seguir para tornar sua automação de backup resiliente e idempotente.

Etapa 1: Faça uma pré-verificação antes de executar

Antes mesmo de tentar criar um novo snapshot, verifique e certifique-se de que não exista outro snapshot para a mesma janela

Etapa 2: Use arquivos de bloqueio

Depois de iniciar a automação do backup, crie um arquivo de bloqueio e exclua-o posteriormente. Essa etapa garantirá que não haja dois arquivos de backup em execução simultaneamente

Etapa 3: Verifique cada etapa

Verifique cada detalhe e verifique o código de saída de cada comando, inclusive instantâneos, compactação e uploads. Isso ajudará a identificar a falha durante todo o processo e manterá tudo sob controle

Etapa 4: Registre tudo

Escreva todas as atividades, inclusive sucessos, falhas e avisos, em um arquivo de registro, o que o ajudará a garantir que os scripts sejam resilientes

Etapa 5: Limpar em caso de falha

Varra automaticamente instantâneos parciais ou uploads incompletos, caso o script de backup falhe no meio do processo

Etapa 6: Adicionar lógica de repetição

Repetir automaticamente as falhas transitórias até um limite definido

Etapa 7: Utilize as ferramentas de orquestração

Em vez de usar cron jobs, utilize ferramentas de orquestração como o Bacula Enterprise, que permitirão que o senhor cuide de todo o ciclo de vida do backup

Como o senhor monitora os trabalhos de backup e alerta sobre falhas?

Durante todo o processo de backup do Cassandra, as falhas podem ocorrer a qualquer momento. Monitorar os trabalhos de backup e alertar sobre falhas são dois componentes importantes que devem ser considerados durante as falhas.

Quando o senhor iniciar o monitoramento de backup, tenha em mente estas perguntas para torná-lo eficaz.

• Seu backup foi executado?
• Ele foi concluído com êxito?
• Quanto tempo demorou para ser executado?
• Qual foi o tamanho do resultado?
• É possível restaurar o backup?

Para monitorar seus trabalhos de backup, considere o seguinte:

1. Verifique os logs do Cassandra

Examine o system.log após cada trabalho de backup em busca de erros ou avisos que mostrem que algo não foi concluído de forma limpa.

2. Use o nodetool para verificar seus snapshots

Execute o nodetool listsnapshots para garantir que o snapshot realmente exista

3. Rastreie os resultados do trabalho

Certifique-se de registrar o código de saída, o tamanho do arquivo e a duração do script de backup para compará-lo posteriormente com versões anteriores.

Ao executar o backup do Cassandra, o alerta é tão importante quanto o monitoramento, o que ajuda o senhor a tomar as precauções necessárias a tempo. Dependendo da gravidade do problema, os alertas de falha devem ser encaminhados para o canal designado.

• PagerDuty para resposta imediata de plantão
• Slack para visibilidade da equipe
• e-mail para notificações não urgentes

Também é possível utilizar ferramentas de terceiros, como o Bacula Enterprise, que oferece backup e monitoramento unificados e alertas, garantindo que tudo esteja sob controle.

Como a segurança e a conformidade afetam as práticas de backup do Cassandra?

Utilizar a estratégia correta de backup do Cassandra é importante, mas isso é apenas metade da equação. A segurança e a conformidade são a segunda metade. A segurança garante que os arquivos sejam protegidos de qualquer acesso ou restrição autorizados. A conformidade, por outro lado, garante que as práticas de backup atendam a todos os requisitos regulamentares.

Como os backups do Cassandra devem ser criptografados em repouso e em trânsito?

Os backups do Cassandra devem ser criptografados em repouso e em trânsito. Esses são dois requisitos de proteção distintos que abordam diferentes pontos de vulnerabilidade.

A criptografia em repouso é o processo de armazenamento dos arquivos de backup em um formato criptografado no disco ou no armazenamento de backup. Isso garante que os arquivos estejam protegidos e não sejam lidos, mesmo que o armazenamento físico seja roubado.

A criptografia em trânsito, por outro lado, refere-se ao processo de transferência do backup do nó Cassandra para o armazenamento de backup. Esse processo impede a interceptação durante a transferência, o que garante a proteção de dados importantes.

Veja a seguir o que as empresas e os negócios devem fazer para proteger adequadamente os backups do Cassandra.

• Usar padrões de criptografia fortes, como o AES-256, para criptografia em repouso
• Protocolos seguros como HTTPS para criptografia em trânsito
• Armazenar e gerenciar chaves de criptografia usando o Key Management Service (KMS)
• Restringir o acesso aos arquivos de backup

Como o senhor controla o acesso aos backups e aplica o privilégio mínimo?

Controlar o acesso a tudo para todos é uma das práticas menos usadas no backup do Cassandra. Essa prática requer a aplicação do privilégio mínimo, o que significa dar a cada sistema e pessoa a permissão mínima para sua função. As contas ou funções de serviço típicas incluem:

1. Agentes de backup que têm acesso somente para gravação ao armazenamento de backup, mas não podem ler ou excluir backups existentes
2. Agentes de restauração que têm acesso somente de leitura e não podem excluir ou alterar nada
3. Administrador de backup, que tem acesso total a tudo.

Muitas empresas implementam políticas de IAM (Identity and Access Management) e de bucket S3 para controlar o acesso aos backups e aplicar o privilégio mínimo. Essas políticas incluem, entre outras coisas, negar operações para contas que não sejam de administradores, restringir o acesso a um intervalo de IP desconhecido, exigir criptografia em todos os uploads e auditar registros de log.

Separar essas tarefas entre sistemas e pessoas e identificar quem pode fazer o quê e quando garante que tudo esteja sob controle e que nada seja comprometido.

Como as políticas de retenção e os requisitos de exclusão de dados afetam a estratégia de backup do Cassandra?

As políticas de retenção e os requisitos de exclusão de dados são dois desafios distintos que afetam a estratégia de backup do Cassandra. As políticas de retenção são as políticas que determinam a duração da manutenção dos backups do Cassandra antes da exclusão, caso não estejam mais em uso.

• Backups diários – mantidos por 30 dias
• Backups semanais – Mantidos por 3 meses
• Backups mensais – Mantidos por um ano
• Backups anuais – mantidos por 7 anos

Para resolver esse problema, as organizações implementam uma abordagem de retenção em camadas, o que significa aplicar diferentes períodos de retenção a diferentes tipos de backup simultaneamente. Isso garante que as empresas e os negócios possam equilibrar seus custos de armazenamento e a conformidade normativa sem manter tudo para sempre.

Os requisitos de exclusão de dados representam outro desafio, pois não é possível excluir dados de usuários específicos de arquivos de backup binários. Para resolver esse problema, as empresas mantêm um período de retenção curto o suficiente para que os dados excluídos expirem naturalmente dentro de um período de tempo documentado e defensável.

Como os backups imutáveis e a proteção contra ransomware se aplicam ao backup e à restauração do Cassandra?

O ransomware é a maior e mais catastrófica falha que ocorre durante o processo de backup do Cassandra. No caso de um ataque desse tipo, o ransomware segue um padrão previsível, que é o seguinte:

• Criptografia de dados ativos
• Direcionar o arquivo de backup para eliminar a recuperação

Os backups imutáveis abordam esse problema diretamente. Ele garante que os arquivos de backup não possam ser modificados depois de gravados, e mesmo uma conta administrativa totalmente comprometida não pode excluir ou criptografar um backup imutável.

O S3 Object Lock implementa a imutabilidade no nível de armazenamento do AWS:

• Os arquivos gravados em um bucket bloqueado não podem ser modificados ou excluídos durante o período de retenção definido
• O modo de conformidade remove todos os recursos de substituição
• O modo de governança permite que os administradores autorizados substituam sob condições específicas

Como os backups com air-gap ou off-line podem reduzir o impacto da violação?

Na maioria dos cenários, os ataques de ransomware são mais do que apenas criptografar dados ativos: eles buscam constantemente opções para destruir backups on-line e minimizar as chances de opções de recuperação. O melhor mecanismo de defesa que os ataques de ransomware não conseguem superar são os backups off-line e air-gapped.

Os backups air -gapped são completamente desconectados fisicamente de todas as redes. Isso significa que os backups de dados com air-gap não podem ser acessados, excluídos ou criptografados, pois não há conexão com a Internet nem acesso remoto.

Os backups off-line são mais amplos e não estão ativamente conectados a sistemas ativos no momento de uma violação. No entanto, eles ainda podem ser acessados por outros meios.

Quais são as práticas recomendadas para backups de produção do Cassandra?

Uma estratégia de backup do Cassandra de produção parece ser um caminho sem fim, que exige políticas consistentes, medições contínuas e documentação clara para permanecer confiável ao longo do tempo. A seção a seguir aborda as práticas recomendadas para o backup do Cassandra de produção, definindo a linha de base e discutindo tudo o que o senhor precisa saber.

Quais são as políticas mínimas que toda implantação de produção deve ter?

O mínimo que toda implantação de produção do Cassandra deve ter, independentemente do tamanho da empresa, do orçamento ou da complexidade do cluster, é o seguinte:

1. Instantâneos diários automatizados. A automação elimina a dependência humana da operação mais importante de proteção de dados.
2. Armazenamento fora do local. Cada snapshot deve ser imediatamente transferido para o armazenamento externo, completamente separado do cluster.
3. Política de retenção definida. O senhor deve documentar por quanto tempo cada tipo de backup é mantido e aplicado automaticamente.
4. Monitoramento e alertas. O monitoramento e os alertas automatizados são obrigatórios, o que permitirá que o senhor tome as precauções necessárias a tempo e evite falhas graves.
5. Processo de restauração testado. Os backups devem ser testados regularmente para garantir a segurança de seus dados.
6. Criptografia. Todos os seus arquivos de backup devem ser criptografados em repouso e em trânsito, sem exceção.
7. Controle de acesso. O privilégio mínimo deve ser aplicado em todo o armazenamento de backup.
8. Documentação da versão. Todo backup deve ser marcado com a versão do Cassandra em que foi criado.
9. Livro de execução documentado. O senhor deve ter um runbook documentado, incluindo procedimentos de restauração detalhados que possam ser utilizados em caso de uma grande catástrofe.
10. Backups incrementais. O senhor deve utilizar backups incrementais combinados com backups de instantâneos completos que tenham um RPO inferior a 24 horas.

Como o senhor documenta os procedimentos de backup e restauração do Cassandra para as equipes de plantão?

Para documentar os procedimentos de backup e restauração do Cassandra para a equipe de plantão, as empresas têm um runbook, que é um documento que serve como um guia passo a passo. Um runbook ideal deve ser escrito de tal forma que até mesmo um especialista júnior que nunca executou o backup do Cassandra possa lê-lo e executar tudo com sucesso. Veja a seguir o que esse runbook deve cobrir:

• Recuperação de tabela única
• Recuperação de espaço-chave
• Restauração completa do cluster
• Expectativas de tempo para cada etapa necessária
• Detalhes de contato dos especialistas do Cassandra e suporte da ferramenta de backup

OBSERVAÇÃO IMPORTANTE: deve haver orientação para que pessoas não familiarizadas entendam qual desses procedimentos se aplica a uma determinada situação.

Esses runbooks têm uma função extremamente importante para empresas e negócios. Eles devem ser atualizados após cada upgrade, restauração ou quando alguma ferramenta de backup for alterada.

Quais métricas e SLAs devem ser monitorados para a integridade do backup?

O rastreamento da integridade do backup requer o monitoramento de métricas específicas e a medição do desempenho e se o desempenho está diminuindo.

Principais métricas que devem ser consideradas para a integridade do backup:

1. Taxa de sucesso. Essa métrica representa a porcentagem de trabalhos que foram bem-sucedidos dentro do período definido.
2. Duração. Essa métrica define quanto tempo cada trabalho pode levar. Por exemplo, decidir que um instantâneo completo será realizado em uma semana.
3. Tamanho. Investigue quedas ou picos inesperados que sinalizam anomalias.
4. Tempo para restauração. Medida por meio de testes regulares de restauração, essa métrica confirma que o RTO real pode ser alcançado na prática.
5. Idade do backup. Identificar a idade do backup bem-sucedido mais recente no momento.
6. Tempo de resposta do alerta – a rapidez com que as falhas são reconhecidas e tratadas. SLA: todos os alertas de backup reconhecidos em 15 minutos.

Para monitorar essas métricas e identificar a integridade do backup, o senhor pode utilizar ferramentas de terceiros, como Bacula Enterprise, Medusa ou OpsCenter, que oferecem uma plataforma unificada para fazer tudo isso de uma só vez.

Principais conclusões

• Defina seu RPO e RTO antes de projetar sua estratégia, pois, sem eles, sua estratégia de backup não tem um objetivo mensurável.
• Sempre armazene os instantâneos fora do local depois que eles forem criados
• Execute backups incrementais e faça o arquivamento de logs, pois isso reduzirá a sobrecarga de armazenamento
• Automação, monitoramento e alertas são essenciais, pois reduzem a probabilidade de erros e falhas.
• Tenha sempre criptografia, controle de acesso, armazenamento imutável e backups air-gapped. A criptografia e o controle de acesso impedem o acesso não autorizado. Os backups imutáveis e air-gapped garantem que o ransomware não possa destruir seu caminho de recuperação.
• Teste seus backups como exercícios de restauração regulares para confirmar seu plano de trabalho de recuperação

Perguntas frequentes

Os backups do Cassandra podem permanecer consistentes em arquiteturas de aplicativos distribuídos?

Sim, os backups do Cassandra podem permanecer consistentes em canais de aplicativos distribuídos. No entanto, isso é implementado por meio de snapshots coordenados e arquivamento de logs de confirmação que produzem backups confiáveis e restauráveis.

Como o senhor faz backup de implantações do Cassandra multilocatário com segurança?

O backup seguro de implantações do Cassandra para vários locatários requer snapshots no nível do espaço-chave para manter os dados do locatário isolados. Certifique-se de aplicar controles de acesso e criptografia rigorosos durante o armazenamento de backup para evitar a exposição de dados entre locatários.

Como as implantações do Cassandra em contêineres e baseadas em Kubernetes alteram a estratégia de backup?

As implantações do Cassandra em contêineres exigem snapshots de volume persistentes em vez de depender apenas do snapshot do nodetool. No Kubernetes, o senhor pode utilizar ferramentas como o Medusa para lidar com a orquestração de backup em pods.