Vamos imaginar que eu configurei a funcionalidade de Disaster Recovery do Veeam Kasten seguindo este passo a passo. Mas existe um detalhe importante, o ambiente produtivo está com uma distribuição de kubernetes e o ambiente de Disaster Recovery está com outra. Quando decreto o DR, consigo visualizar os pontos de restauração, inicio a restauração, mas…

O ambiente de DR é diferente do produtivo e por isso não é possível apenas restaurar. No meu exemplo, o erro especifico foi sobre o storage class, basicamente “longhorn-single-replica” não existe no kubernetes de destino (DR). Poderia ser qualquer outra coisa.

Para resolver isso de uma forma simples e automatizada, é possível usar uma funcionalidade do Veeam Kasten chamado de Transform Set. Essa funcionalidade permite manipular praticamente qualquer propriedade dos manifestos. Nesse exemplo vou mostrar como substituir um valor por outro, mas poderiamos adicionar novas propriedades, remover, copiar, mover, testar etc.

Na tabela abaixo detalho as diferenças entre o kubernetes da produção para o DR.

	PRODUÇÃO	DISASTER RECOVERY
Kubernetes	K3s	Microk8s
Storage Class	longhorn-single-replica	microk8s-hostpath
Ingress Class	traefik	nginx

Agora que ficou claro que existe uma forma moderna e elegante de resolver essa questão, vamos aos detalhes técnicos. No Kasten, navegue até Transform Sets > Create New Set. Defina o nome do Transform Set (aqui chamado de k3s-to-microk8s) e também o nome da transformação especifica (aqui chamada de ChangeStorageClass).

Basicamente defini que vou alterar valores do recurso persistentvolumeclaims no caminho /spec/storage/ClassName e independente do valor que estiver nesse campo, eu quero alterar para “microk8s-hostpath”. E claro que esta storage class precisa existir no meu cluster de destino 🙂

Inclusive posso testar para garantir que a transformação irá funcionar.

Vou fazer algo similar com o ingress. A origem usa traefik, mas o destino usa nginx. Então seleciono o recurso ingresses e substituo o valor existente na propriedade que está em /spec/ingressClassName para “nginx”.

Por fim, tenho um conjunto de transformação chamado k3s-to-microk8s com duas transformações configuradas.

Quando for iniciar a restauração do backup da aplicação, basta marcar a opção Apply transforms to restored resources e selecionar o conjunto de transformação que acabamos de criar. Com isso, além do Kasten fazer a restauração da aplicação em si, ainda irá realizar as alterações baseado no que foi configurado no conjunto de transformação .

Pronto, a restauração foi concluida com sucesso aplicando as duas transformações (storage class e ingress class) e garantindo que a aplicação receba os valores corretos baseado no cluster atual.

Aqui demonstrei com duas distribuições leves e apenas localmente, de qualquer forma, a mesma lógica se aplica no caso do seu ambiente produtivo ser local e o DR na nuvem, por exemplo. Infinitas possibilidades!

É isso aí, pessoal. Até a próxima!