Olá pessoal. Quando alguém me pede ajuda para começar um projeto de proteção de dados, a primeira coisa que muita gente espera ouvir é o nome de um produto ou o tamanho do repositório. Só que quem já passou por um projeto de verdade sabe que começar pelo produto é começar pelo fim. A ideia desse post é mostrar como eu uso a metodologia que estudei para o VCAP-DCV Design para desenhar uma solução de backup do zero.
Aqui no blog eu já mostrei na prática como migrar aplicações entre clusters, como gerenciar vários clusters e como testar o DR com o Veeam Kasten. Hoje a ideia é falar sobre o motivo que isso é importante. Quando uma aplicação precisa mudar de casa, o backup deixa de ser apenas proteção e vira, basicamente, uma ferramenta de migração.
Lá em 2017 eu escrevi o post Alta Disponibilidade e Recuperação de Desastre para explicar a diferença entre HA e DR e relendo hoje, a explicação continua valendo. O que mudou foi o cenário: naquela época a grande preocupação era perder um hypervisor ou o data center inteiro, hoje a preocupação é chegar de manhã e encontrar tudo criptografado. O intuito deste post é falar sobre a terceira disciplina que entrou nessa conversa, a recuperação cibernética.
O job terminou com sucesso, ficou verde na console e o relatório chegou por e-mail. Pronto, todo mundo dorme tranquilo. O problema é que o job verde prova apenas que os dados foram copiados para o repositório, e não que a restauração vai funcionar quando for necessária. A ideia desse post é falar um pouco sobre isso e sobre como o Veeam Backup & Replication ajuda a resolver esse problema.
Todos nós sabemos da importância de garantir que todas as soluções estejam atualizadas e isso as vezes gera um pouco de trabalho para os times de TI devido a complexidade que algumas soluções podem trazer. Com o Veeam Kasten isso não acontece, o processo é tão simples que este artigo nem seria necessário, de qualquer forma, vou usa-lo como
Recentemente escrevi alguns artigos sobre o Veeam Kasten onde o objetivo foi mostrar como testar algumas funcionalidades. A ideia geral consiste em construir um ambiente bem simples (o mais simples possível) e este artigo mantém a mesma ideia. Aqui podemos seguir os artigos anteriores para construir
Recentemente escrevi um artigo separado em três partes sobre como testar o Veeam Kasten com K3s e Longhorn, nesse caso, poderia existir a persistência dos dados dos pods, visto que o Longhorn seria o responsável por cuidar dos volumes dos pods. Entretanto, existem cenários onde o cliente não precisa de persistência no pod e por este motivo