Como fazer backup do Kubernetes?

Embora a suposição de que o Kubernetes era usado principalmente por equipes DevOps possa ter sido um pouco correta, muitas empresas estão agora implantando ativamente containers em ambientes operacionais. Elas também estão escolhendo cada vez mais abordagens centradas nos containers, em vez das tradicionais VMs. Isso se deve às várias vantagens de flexibilidade, desempenho e custo que os containers muitas vezes podem proporcionar. Entretanto, à medida que os containers se movem para o lado operacional do ambiente de TI, há uma preocupação crescente com os aspectos de segurança dos containers em um ambiente de missão crítica, incluindo seus dados persistentes no contexto dos processos de backup e restauração.

Originalmente, a esmagadora maioria dos aplicativos de containers eram independentes, permitindo-lhes ter um processo de implantação muito mais fácil em uma nuvem pública. Mas isso mudou com o tempo, com aplicações muito mais estatais sendo implantadas em containers do que antes. Essa mudança é o motivo pelo qual o backup e a recuperação do Kubernetes é agora um tópico importante para muitas organizações.

Características importantes de uma solução de backup para Kubernetes competente

A natureza dinâmica dos ambientes Kubernetes torna mais difícil para os sistemas e técnicas de backup mais tradicionais trabalhar bem no contexto dos nós e aplicações Kubernetes. Tanto o RPO quanto o RTO podem precisar ser muito mais rigorosos, já que as aplicações precisam estar constantemente em funcionamento, ou serem especialmente críticas, e assim por diante.

Isso nos leva a classificar três características diferentes que são altamente recomendadas para cada empresa em geral, e uma clara necessidade quando se trata de melhores práticas de backups para Kubernetes:

• Recuperação de desastres;
• Fazer backup e restaurar;
• Alta disponibilidade local.

Em um ambiente Kubernetes, o contexto desses três aspectos do backup pode mudar ligeiramente em relação à sua definição normal:

Alta disponibilidade local como uma característica se trata mais da prevenção/proteção de falhas dentro de um data center específico ou através de zonas de disponibilidade (se estivermos falando da nuvem, por exemplo). Uma falha “local” é aquela que ocorre na infraestrutura/nó/app usado para executar a aplicação. Em um cenário perfeito, sua solução de backup Kubernetes deve ser capaz de reagir a essa falha mantendo o aplicativo funcionando, o que essencialmente significa que não haverá tempo de inatividade para o usuário final. Um dos exemplos mais comuns de uma falha local é um volume de nuvem que trava depois de uma falha do nó.

Nessa perspectiva, a alta disponibilidade local como característica pode ser considerada um fundamento do sistema geral de proteção de dados. Para que se possa realizar tal tarefa, sua solução precisa oferecer algum tipo de sistema de replicação de dados localmente e, em primeiro lugar, também tem que estar no caminho dos dados. É importante mencionar que o fornecimento de disponibilidade local via restauração de backup ainda é considerado “backup e restauração” e não alta disponibilidade local, devido ao tempo total de recuperação.

O backup e restauração é outra parte importante de um sistema de backup para Kubernetes. Na maioria dos casos de uso, ele faz backup de toda a aplicação externamente a partir de um cluster local do Kubernetes. O contexto do Kubernetes também traz outra consideração importante: o software de backup precisa “entender” o que está incluído em um aplicativo Kubernetes, como por exemplo:

• Configuração do aplicativo;
• Recursos do Kubernetes;
• Dados

Um backup correto do Kubernetes precisa salvar todas essas partes acima como uma única unidade para que seja útil ao sistema Kubernetes depois de restaurá-lo. Ter como alvo VMs, servidores ou discos específicos não significa que um software “entenda” as aplicações Kubernetes. Idealmente, um software para Kubernetes deve ser capaz de fazer backup de aplicações específicas, de grupos específicos de aplicações, bem como de todo o namespace Kubernetes. Isso não quer dizer que seja completamente diferente do processo de backup comum. Os backups do Kubernetes também podem se beneficiar muito de alguns dos recursos normais de um backup usual, incluindo retenção, agendamento, criptografia, camadas, e assim por diante.

A capacidade de recuperação de desastres (RD) é provavelmente essencial para qualquer organização que use o Kubernetes num contexto de missão crítica, da mesma forma que acontece com qualquer outra tecnologia. Primeiro, a RD precisa “entender” o contexto dos backups do Kubernetes, assim como os backups e restaurações propriamente ditos. Ela também pode ter diferentes níveis de RTO e RPO, e também de proteção, de acordo com esses níveis. Por exemplo, poderia haver uma exigência estrita de RPO zero, que implica em tempo de inatividade estritamente zero, ou poderia haver um RPO de 15 minutos, com exigências um pouco menos estritas. Também não é raro que aplicações diferentes tenham RTO e RPO completamente distintos dentro do mesmo banco de dados.

Outra distinção importante de um sistema de recuperação de desastres específico para Kubernetes é que ele também deve ser capaz de trabalhar com metadados até certo ponto (rótulos, réplicas de aplicativos, etc.). A incapacidade de fornecer essa característica poderia facilmente levar a uma recuperação desarticulada em geral, bem como a uma perda geral de dados ou a um tempo adicional de inatividade.

Tipos de dados que precisam de backup no Kubernetes

Assim como qualquer sistema complexo, o Kubernetes e o Docker têm uma série de tipos de dados específicos que eles precisarão para reconstruir adequadamente toda o banco de dados em caso de desastre. Para facilitar, é possível dividir todos os dados e configurar os tipos de arquivos em duas categorias diferentes: configuração e dados persistentes.

A configuração (e as informações sobre o estado desejado) inclui:

• etcd de banco de dados do Kubernetes
• Arquivos do Docker
• Imagens dos arquivos do Docker

Dados persistentes (alterados ou criados pelos próprios containers) são:

• Banco de dados
• Volumes persistentes

etcd de banco de dados do Kubernetes

Essa é uma parte integrante do sistema que contém as informações sobre os estados do cluster. Pode ser feito backup manual ou automaticamente, dependendo de sua solução de backup. O método manual é feito através do comando etcdctl snapshot save db, que cria um único arquivo com o nome snapshot.db.

Outro método de fazer a mesma coisa é acionar esse mesmo comando logo antes de criar um backup do diretório em que esse arquivo estaria. Essa é uma das maneiras de integrar esse backup específico em todo o ambiente.

Arquivos do Docker

Uma vez que os próprios containers Docker são feitos a partir de imagens, essas imagens devem ser baseadas em algo, e elas são criadas a partir dos arquivos Docker. Para uma configuração correta do Docker é recomendável usar uma espécie de repositório como um sistema de controle de versão para todos os seus arquivos Docker (GitHub, por exemplo). Para facilitar a extração de versões anteriores, todos os arquivos Docker devem ser armazenados em um repositório específico que permita aos usuários extrair versões mais antigas desses arquivos, se necessário.

Um repositório adicional também é recomendado para os arquivos YAML que estão associados com todos as implantações Kubernetes, os quais existem na forma de arquivos de texto. O backup desses repositórios também é uma obrigação, seja usando as ferramentas de terceiros ou as funcionalidades integradas de algo como o GitHub.

É importante mencionar que você ainda pode gerar os arquivos Docker a serem copiados, mesmo que esteja executando containers a partir de imagens sem seus arquivos Docker. Há um comando específico que é o docker image history, que permite a você criar um arquivo Docker a partir de sua imagem atual. Há também várias ferramentas de terceiros que podem fazer o mesmo.

Imagens dos arquivos Docker

Também é preciso fazer backup das próprias imagens do Docker em um repositório. Tanto um repositório privado, quanto um público podem ser usados exatamente para esse fim. Vários provedores de nuvens tendem a fornecer repositórios privados para seus clientes, também. Se você não tiver a imagem a partir da qual seu container funciona, o comando docker commit deve ser capaz de criar essa imagem para você.

Bancos de dados

A integridade também é crucial quando se trata de bancos de dados que os containers usam para armazenar seus dados. Em alguns casos, é possível fechar o container em questão antes de criar um backup dos dados, porém, mais uma vez, o tempo de inatividade necessário provavelmente resultará em muitos problemas para uma empresa.

Outro método de fazer backups do banco de dados dentro dos containers é através da conexão com a própria engine do banco de dados. Nesse caso, um bind mount deve ser usado anteriormente para anexar um volume do qual pode ser feito backup, e então você pode usar o comando mysqldump para criar um backup. O arquivo de backup em questão também deve ser copiado posteriormente usando seu sistema de backup.

Volumes persistentes

É justo dizer que existem múltiplos métodos diferentes para que os containers tenham acesso a uma espécie persistente de armazenagem. Se se trata dos volumes tradicionais Docker. Esses residem em um diretório que está abaixo da configuração do Docker. Os bind mounts, por outro lado, poderiam estar em qualquer diretório que esteja montado dentro de um container. Apesar do fato de que os volumes tradicionais são mais preferíveis na comunidade Docker, ambos são relativamente iguais quando se trata de backup de dados. Uma terceira maneira de fazer a mesma operação é montando um diretório NFS ou um único objeto como um volume dentro de um container.

Todos esses três métodos têm o mesmo problema quando se trata de fazer backup de dados: a consistência do backup não é completa se os dados dentro de um container mudarem no meio do processo. É claro que é sempre possível ganhar consistência através do fechamento do volume antes de fazer o backup, mas na maioria dos casos o tempo de inatividade para tais sistemas está basicamente fora de questão, por causa da continuidade dos negócios.

Há algumas maneiras de fazer o backup de dados dentro dos containers que são específicas para cada método. Por exemplo, os volumes tradicionais Docker poderiam ser montados em outro container que não estaria mudando nenhum dos dados até que o processo de backup estivesse completo. Ou, se você estiver usando um volume montado com bind mount, é possível criar uma imagem tar de um volume inteiro e depois fazer o backup da imagem.

Infelizmente, todas essas opções são realmente difíceis de serem feitas quando se trata dp Kubernetes. Por essa mesma razão, é sempre recomendável armazenar informações de estado no banco de dados e fora do sistema de arquivos de containers.

Dito isto, se você estiver usando um diretório bind-mounted ou um sistema de arquivos montado no NFS como um armazenamento persistente, também é possível fazer o backup desses dados usando os métodos comuns, como um snapshot. Isso deve lhe dar muito mais consistência do que o tradicional backup a nível de arquivo do mesmo volume.

Soluções de backup para Kubernetes

No contexto desses três importantes fatores/características, vejamos mais alguns exemplos de solução de backup e recuperação para Kubernetes. Os exemplos que usamos aqui são o Kasten, Portworx, Cohesity, OpenEBS e Rancher Longhorn.

Kasten K10

O Kasten K10 (recentemente adquirido pelo Veeam) é uma solução de backup e restauração que também se orgulha da sua mobilidade e de seus sistemas de recuperação de desastres. Com o Kasten, o processo de backup é simplificado graças à sua capacidade de descobrir automaticamente aplicações, assim como muitas outros recursos, tais como criptografia de dados, controle de acesso baseado em funções e uma interface de fácil utilização. Ao mesmo tempo, ele pode trabalhar com muitos serviços de dados diferentes, tais como MySQL, PostgreSQL, MongoDB, Cassandra, AWS, e assim por diante.

A alta disponibilidade local não é oferecida, já que o Kasten não suporta diretamente a replicação dentro de um único cluster e depende dos sistemas de armazenamento de dados subjacentes. A recuperação de desastres também é disponibilizada apenas parcialmente, uma vez que o Kasten não pode alcançar um RPO zero devido à falta de um componente de caminho de dados. Também é digno de nota o fato de que os backups do Kasten são apenas assíncronos, o que normalmente gera um tempo adicional de inatividade entre as operações.

Portworx

O Portworx PX-Backup é uma empresa de gerenciamento de dados que desenvolve uma plataforma de armazenamento baseada em nuvem para gerenciar e acessar o banco de dados dos projetos Kubernetes. É outro exemplo de uma solução de gestão de dados e, apesar de suas limitações como tal, um dos principais benefícios do uso do Portworx é a alta disponibilidade dos dados.

Operações de backup e recuperação, compreensão das aplicações Kubernetes, alta disponibilidade local, recuperação de desastres, entre outros recursos, tudo isso faz do Portworx uma boa solução de backup para o Kubernetes se você estiver procurando uma que seja especializada em tarefas relacionadas à essa plataforma.

Outra parte significativa do PX-Backup é sua escalabilidade, permitindo backups on-demand/agendados de centenas de aplicações de uma só vez. A solução também suporta configurações de vários bancos de dados e pode restaurar aplicações diretamente nos serviços de nuvem, tais como Amazon, Google, Microsoft, etc.

Cohesity

O Cohesity é um concorrente relativamente popular na área do backup e da recuperação, mas suas funcionalidades relacionadas ao Kubernetes ainda têm algum espaço para crescer. Primeiro de tudo, o Kubernetes é uma adição relativamente nova para eles, e eles acrescentaram o “entendimento” das aplicações Kubernetes desde o começo, mas ao mesmo tempo, ele só funciona para todas as aplicações dentro do mesmo namespace, e não se pode proteger aplicações específicas dentro desse namespace.

Por outro lado, ele também possui funcionalidades de recuperação rápida, backups incrementais de aplicativos baseados em políticas, consolidação do estado dos dados e muitas outras coisas.

OpenEBS

O OpenEBS é outro exemplo de uma solução que conseguiu obter alguns resultados com apenas uma das três características da nossa lista, e neste caso se trata de alta disponibilidade local.

Ao mesmo tempo, o OpenEBS também pode se integrar com o Velero, criando uma solução combinada para Kubernetes que se destaca na migração de dados. O OpenEBS, por si só, só pode fazer backup de aplicações individuais (algo totalmente oposto ao que o Cohesity faz). Ele também possui vários recursos, como armazenamento multi-nuvem, sua natureza é de código aberto e ele suporta uma lista gigantesca de plataformas Kubernetes, desde AWS e Digital Ocean até Minikube, Packet, Vagrant, GCP, e muito mais.

No entanto, essa solução pode não suprir as necessidades dos usuários, uma vez que alguns deles podem precisar de backups de namespace em casos de uso específicos.

Rancher Longhorn

O Rancher Longhorn é provavelmente o exemplo menos conhecido da nossa lista. Sua comunidade é relativamente pequena para uma solução de código aberto, e não permite que os backups completos do Kubernetes com metadados e recursos façam com que a recuperação de app-aware aconteça. No entanto, ele possui um recurso único que se destaca: o DR Volume. O DR Volume pode ser estabelecido como uma fonte e um destino, tornando o volume ativo em um novo cluster que é baseado nos últimos dados de backup.

A capacidade do Rancher de trabalhar com muitos tipos diferentes de plataformas de containers e permitir diferentes métodos de backup é o que o difere do resto, e ele já consegue suportar as distribuições Kubernetes Engine, Docker e K3. Os containers Docker, por exemplo, têm que criar um tarball que poderia funcionar como backup para o Rancher.

Rubrik

Muitos outros players maiores na área de backup e recuperação começaram a oferecer seus próprios serviços em termos de backup e restauração para Kubernetes, e o Rubrik é um bom exemplo disso. Ele permite que os usuários implementem o vasto conjunto de recursos de gestão do Rubrik na área das implantações Kubernetes.

Ele permite flexibilidade em termos de destino da restauração, bem como a proteção dos objetos Kubernetes, e também possui uma plataforma unificada que fornece insights e visão geral de todo o sistema. Há também recursos como automatização de backup, recuperação granular, replicação de snapshots, e muito mais. O Rubrik também pode trabalhar com volumes persistentes e é capaz de replicar namespaces, lhe oferecendo variedade quando se trata de desenvolvimento e/ou testes antes da implantação.

Druva

O Druva fornece uma solução de backup e restauração para Kubernetes bastante simples, mas eficaz, com todas os recursos básicos esperados: snapshots, backup e restauração, automatização, e algumas funcionalidades adicionais. O Druva também pode restaurar aplicações inteiras dentro do Kubernetes, com muita mobilidade quando se trata do destino da restauração.

Além disso, o Druva suporta múltiplas funções administrativas, pode criar cópias de cargas de trabalho para fins de solução de problemas, e fazer backup de áreas específicas, como namespaces ou grupos de aplicativos. Há também uma variedade de opções de retenção, proteção abrangente de dados do Kubernetes, e suporte para o Amazon EC2 e EKS (cargas de trabalho personalizadas de containers).

Zerto

O Zerto é também uma boa escolha se você estiver procurando uma plataforma de gestão de backup multifuncional com backup nativo para Kubernetes. Ele oferece tudo o que você desejaria de uma solução moderna de backup e restauração para Kubernetes: CDP (proteção contínua de dados), replicação de dados via snapshots, e o mínimo de aprisionamento tecnológico graças ao suporte para todas as plataformas Kubernetes na área empresarial.

O Zerto também oferece proteção de dados como uma de suas estratégias centrais, oferecendo às aplicações a possibilidade de serem geradas com segurança desde o início. O Zerto também tem muitas funcionalidades de automatização, é capaz de fornecer insights abrangentes, e pode trabalhar com diferentes armazenamentos em nuvem ao mesmo tempo.

Como ficou claro neste artigo, o tema Kubernetes ainda é relativamente novo e o mercado ainda está tentando alcançar a lista completa de recursos que qualquer sistema baseado em Kubernetes exige. Toda a natureza do Kubernetes transforma as aplicações em algo muito distinto, e isso nos leva à atual lista de soluções que se destacam em uma coisa e lutam para alcançar outra.

Evidentemente, o Kubernetes é uma área tecnológica em rápido crescimento, por isso é seguro dizer que em breve haverá mais soluções, e as atuais provavelmente se tornarão ainda melhores do que são neste momento. Um exemplo de uma nova e poderosa solução para Kubernetes é o Bacula Enterprise.

Bacula Enterprise: A solução de backup para Kubernetes

A própria natureza dos ambientes Kubernetes o torna, ao mesmo tempo, muito dinâmico e potencialmente complexo. Fazer backup de um cluster do Kubernetes é algo que não deve aumentar desnecessariamente a complexidade. E é claro que é geralmente importante (se não crítico) que os administradores de sistema e outros funcionários de TI tenham controle centralizado sobre todo o sistema de backup e recuperação de toda a organização, incluindo quaisquer ambientes Kubernetes. Dessa maneira, fatores como conformidade, capacidade de gerenciamento, rapidez, eficiência e continuidade dos negócios tornam-se muito mais realistas. Ao mesmo tempo, a abordagem ágil das equipes de desenvolvimento não deve ser comprometida de forma alguma.

O Bacula Enterprise é único nesse espaço porque é uma solução corporativa abrangente para ambientes completos de TI (não apenas Kubernetes) que também oferece backup e recuperação para Kubernetes nativamente integrados, incluindo múltiplos clusters, quer as aplicações ou dados residam fora ou dentro de um cluster específico. O Departamento de Operações de cada empresa reconhece a necessidade de ter uma estratégia adequada quando se trata de recuperação de clusters, atualizações e outras situações. Um cluster que esteja em estado irrecuperável pode ser revertido para um estado estável com o Bacula se tanto os arquivos de configuração, como os volumes persistentes do cluster tiverem sido previamente copiados corretamente.

A imagem abaixo ilustra melhor os métodos de trabalho do Bacula:

Uma das principais vantagens do módulo Kubernetes do Bacula é a capacidade de fazer backup de vários recursos Kubernetes, inclusive:

• Pods;
• Serviços;
• Implantações;
• Volumes persistentes.

Recursos do módulo Kubernetes do Bacula Enterprise

A maneira como esse módulo funciona é que a solução em si não faz parte do ambiente Kubernetes, mas sim acessa os dados relevantes dentro do cluster através dos pods Bacula que estão ligados a um único nó do Kubernetes em um cluster. A implantação desses pods é automática e funciona “conforme necessário”.

Alguns outros recursos que o módulo de backup para Kubernetes fornece são:

• Backup e restauração do Kubernetes para volumes persistentes;
• Restauração de um único recurso de configuração do Kubernetes;
• A capacidade de restaurar arquivos de configuração e/ou dados de volumes persistentes para o diretório local;
• A capacidade de fazer backup da configuração de recursos dos clusters do Kubernetes.

Vale a pena observar também que o Bacula suporta múltiplas plataformas de armazenamento em nuvem simultaneamente, incluindo plataformas como AWS, Google, Glacier, Oracle Cloud e Azure, a nível de integração nativa. Dessa maneira, as funcionalidades híbridas das nuvens são incorporadas, incluindo gerenciamento avançado de nuvens e recursos automatizados de cache, permitindo uma fácil integração de serviços públicos ou privados de armazenamento em nuvem para suportar várias tarefas.

A flexibilidade das soluções é algo particularmente importante hoje em dia, com muitas empresas e organizações se tornando cada vez mais complexas em termos de diferentes famílias de hypervisors e containers. Ao mesmo tempo, isso aumenta significativamente a demanda por flexibilidade para todos os fornecedores de banco de dados. A capacidade do Bacula nesse aspecto é substancialmente alta, combinando sua ampla lista de compatibilidade com várias tecnologias para alcançar padrões de flexibilidade incrivelmente altos sem se prender a um único fornecedor.

A complexidade nos diferentes aspectos do trabalho de qualquer organização está sempre aumentando, e na maioria das vezes é mais fácil e mais econômico usar uma solução para todo o ambiente de TI, e não várias soluções ao mesmo tempo. O Bacula foi projetado para fazer exatamente isso, e também é capaz de fornecer tanto uma interface tradicional baseada na web para suas necessidades de configuração, como também o tipo clássico de controle por linha de comando. Essas duas interfaces podem até ser usadas simultaneamente.

O plugin de backup para Kubernetes do Bacula permite dois tipos principais de restauração:

• Restaurar para um diretório local;
• Restaurar para um cluster.

Backups regulares e/ou automatizados são altamente recomendados para assegurar o melhor ambiente possível de backup e recuperação de containers. Testar seus backups de tempos em tempos também deve ser algo obrigatório para o administrador de seu sistema. Na próxima imagem, você verá uma parte do processo de restauração (a seleção de restauração), na qual é possível escolher quais arquivos e/ou diretórios você deseja restaurar:

Outra parte do processo de restauração que você encontrará é a página de opções avançadas, que é assim:

Aqui você pode especificar várias opções diferentes, tais como formato de saída, caminho do arquivo de configuração do KBS, porta do endpoint, e mais.

Também é fácil monitorar todo o processo de restauração depois que a personalização estiver completa, graças à página de log da tarefa de restauração que escreve cada uma das ações:

Outra funcionalidade importante do módulo Kubernetes é o recurso Plugin Listing, que oferece muitas informações úteis sobre seus recursos Kubernetes disponíveis, inclusive namespaces, volumes persistentes, e assim por diante. Para fazer isso, o módulo usa um comando especial .ls com um parâmetro específico plugin=<plugin>.

O módulo Kubernetes do Bacula oferece uma variedade de recursos, algumas das quais são:

• Rápida e eficiente redistribuição dos recursos do cluster;
• Salvaguarda do estado do cluster do Kubernetes;
• Configurações de economia a serem usadas em outras operações;
• Manter as configurações alteradas o mais seguro possível e restaurar exatamente o mesmo estado que antes.

Embora isso aconteça com frequência, é altamente recomendável evitar pagar a seu fornecedor com base no volume de dados. Não faz sentido ficar preso a um fornecedor que esteja disposto a tirar vantagem de sua organização dessa maneira. Em vez disso, examine atentamente os modelos de licenciamento da Bacula Systems, que retira seus clientes da exposição aos encargos de crescimento de dados, ao mesmo tempo em que torna muito mais fácil para os departamentos de compras prever custos futuros. Essa abordagem mais razoável da Bacula vem de suas raízes de código aberto e tem boa repercussão em um ambiente DevOps.

Velero e Bacula Enterprise: Qual é a diferença?

Isso não quer dizer que não haja outras soluções no mercado, tanto premium como gratuitas. Por exemplo, o Velero.

O Velero (anteriormente chamado de Heptio Ark) é uma solução gratuita de backup e restauração de código aberto que se concentra principalmente no trabalho com cluster do Kubernetes/volumes persistentes. Ele tem a capacidade de trabalhar com uma série de diferentes plataformas de nuvem através de plugins específicos, e você pode escolher se deseja executá-lo nas instalações ou dentro da plataforma de nuvem pública de sua escolha.

Os três principais campos-alvos das funcionalidades do Velero são:

• Replicação do cluster de produção para fins de teste ou desenvolvimento;
• Backup geral e restauração das funcionalidades dos clusters de Kubernetes;
• Recurso de migração do cluster.

A ideia por trás de como o Velero trabalha tem a ver com duas partes principais: um servidor trabalhando dentro de seu cluster e um cliente local representado por uma linha de comando para suas necessidades operacionais. Ele é também bastante singular na maneira como trabalha com os clusters do Kubernetes.

A maneira como funciona é que a API do Kubernetes é usada para capturar o estado específico dos clusters e executar o processo de restauração quando necessário. Isso é diferente do que a maioria das outras soluções faz: elas acessam diretamente o etcd de bancos de dados do Kubernetes e interagem com os dados através dele (os Pods Bacula é um desses exemplos). As vantagens de fazer tudo via API são as seguintes:

• Mesmo que os recursos que são expostos via API sejam armazenados em um banco de dados separado, ainda é possível fazer backup ou restaurá-los de maneira rápida e eficiente.
• Os backups podem ser um tanto seletivos, capturando subconjuntos específicos dos recursos de um cluster, filtrados por tipo de recurso, namespace, etc., o que proporciona muito mais flexibilidade em relação aos dados que você deseja fazer backup;
• Não é uma ocorrência rara para os usuários de ofertas Kubernetes administradas não terem acesso ao etcd de banco de dados subjacente, o que torna backups diretos e restaurações basicamente impossíveis e força a utilização de várias soluções de trabalho.

Podemos também comparar o Velero com um dos exemplos premium de soluções de backup para Kubernetes da lista anterior: o Kasten K10. O primeiro ponto de comparação entre o Velero e o Kasten seria o fato de que um é uma solução grátis e de código aberto, enquanto que o outro é uma solução premium que você tem que pagar.

Há um pacote regular de benefícios e vantagens para ambos os sistemas, com o Velero sendo inicialmente mais acessível por ser gratuito, mas ele também requer um nível de conhecimento necessário muito mais alto, combinado com um backup menos rápido e preciso quando comparado com soluções pagas.

O Kasten, por outro lado, provavelmente custaria mais do que o Velero para montar (qualquer coisa acima de zero significa “mais”!), mas teria o benefício de um backup em tempo real 24 horas por dia e, portanto, um nível de conhecimento mais baixo para montar tudo corretamente. Sendo uma solução “premium”, o Kasten também tem mais recursos do que o Velero, como a já mencionada recuperação de desastres (embora não seja uma solução perfeita, ela ainda está lá se você precisar).

O tema da escolha entre Velero e Kasten se resume principalmente a um caso específico que a empresa em questão tem, sendo dois dos maiores obstáculos o preço da solução e a escala na qual ela teria que trabalhar, incluindo todos os tipos de recursos populares e/ou incomuns.

Então, quando se trata de comparação direta entre Velero e Bacula, é seguro dizer que cada um tem suas próprias vantagens e benefícios.

O Bacula é muito mais abrangente em termos de ser uma solução ampla de backup e restauração corporativos, e oferece uma grande variedade de recursos e tecnologias que você esperaria de uma solução de grande porte, de nível empresarial. Portanto, o Bacula oferece uma solução completa de backup de plataforma única para médias e grandes empresas. O Bacula também tem o “BWeb”, que é uma interface web abrangente para os muitos recursos que ele oferece. O Bacula é provavelmente a solução que um Diretor de TI escolheria quando precisasse fazer backup de ambientes complexos e em constante mudança, usando uma plataforma única e moderna.

O Velero, por outro lado, é específico no sentido de que não tenta abranger todos os aspectos de backup de todas as aplicações, dados e tipos de armazenamento. Em vez disso, ele se concentra apenas em trabalhar com o Kubernetes. Alguns usuários podem achar isso mais atraente do que uma solução completa. Depois há também a abordagem única que Velero usa para trabalhar com dados e backups: via API. E o último ponto, mas não menos importante: ele é gratuito e de código aberto. Apesar de todas as vantagens que o Bacula tem, ele foi concebido para ser uma solução de alto nível para médias e grandes empresas, algo que, naturalmente, não representa todos os usuários do Kubernetes.