A ideia desse artigo é mostrar passo a passo uma forma simplificada e rápida de fazer deploy do K3s com Longhorn e usar o Veeam Kasten para proteger a carga de trabalho que está sendo executada no Kubernetes. É importante frisar que todas as escolhas de design e arquitetura aqui descritas foram pensadas para ser o mais simples possível, com o objetivo bem claro de ter um ambiente funcional para testes da solução de proteção de dados para Kubernetes da Veeam. Não recomendo repetir esses passos para ambientes produtivos.

Para facilitar a leitura, separei o artigo em três partes.

Parte 1 – Instalação e configuração do K3s e Longhorn
Parte 2 – Instalação e configuração básica do Veeam Kasten
Parte 3 – Configuração de politicas de backup no Veeam Kasten (você está aqui)

---

Agora que já temos o básico para que o Veeam Kasten funciona corretamente, vamos criar uma aplicação para efetuar os testes de backup e restore. A ideia é manter o mesmo padrão e criar um deploy de apache bem simples. Quero proteger o artefato de forma completa, desde o deployment e serviço, até o volume persistente, ingress, secrets, namespace etc. Basta executar o comando abaixo para fazer deploy desse apache. Lembre-se de ajustar com os detalhes pertinentes ao seu ambiente.

kubectl create namespace apache-test

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: apache-html-pvc
  namespace: apache-test
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 200Mi
  storageClassName: longhorn-single-replica
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: apache-test
  namespace: apache-test
spec:
  selector:
    matchLabels:
      app: apache-test
  template:
    metadata:
      labels:
        app: apache-test
    spec:
      containers:
      - name: apache
        image: httpd:2.4
        ports:
        - containerPort: 80
        volumeMounts:
        - name: apache-html
          mountPath: /usr/local/apache2/htdocs
      volumes:
      - name: apache-html
        persistentVolumeClaim:
          claimName: apache-html-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: apache-test
  namespace: apache-test
spec:
  selector:
    app: apache-test
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: apache-test-ingress
  namespace: apache-test
spec:
  ingressClassName: traefik
  rules:
  - host: test1.caverna.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: apache-test
            port:
              number: 80
EOF

Só para enfeitar um pouco, vamos personalizar a página inicial do apache com o comando abaixo:

kubectl exec -n apache-test -it deploy/apache-test -- bash -c 'echo "<h1>Veeam Kasten</h1>" > /usr/local/apache2/htdocs/index.html'

Se tudo foi criado corretamente, então basta abrir o endereço no navegador.

Se navegar no menu esquerdo Application no Veeam Kasten, provavelmente verá o apache-test, default e longhorn-system, todos com a coluna compliance Unmaneged. Ou seja, não está sendo protegido pelo Kasten. No apache-test, clique no três pontos e Create a Policy.

Para testar, vamos manter quase tudo no padrão. Vamos alterar apenas a opção Enable Backups via Snapshot Exports, onde o objetivo é que todos os snapshots sejam enviados para o repositório NFS e use a mesma retenção aplicada ao snapshot.

Esse é um ponto interessante, pois existem configurações de retenção para o snapshot e para os backups que vão para o repositório em si. Sem marcar essa opção e selecionar o repositório, como resultado você teria apenas snapshots e não backups. Após criar a politica ela fica disponível no menu Policies. É esperado que você veja Valid no campo Validation, que o recurso protegido esteja correto e que a ação (Snapshot + Export) esteja correta também.

Agora navegando no menu Applications é possível observar que o apache-test está Compliant, ou seja, está sendo protegido pelo Veeam Kasten.

Perfeito, agora temos uma politica que protege o apache-test. Podemos restaurar a partir do snapshot ou a partir do backup que está armazenado no NFS. Como mostra a imagem abaixo, já concluimos com sucesso o primeiro backup.

Muito bonito, tudo verdinho 🙂 mas eu quero validar se consigo restaurar tudo no caso de perder a minha aplicação inteira. Afinal de contas, é isso que a Veeam faz de melhor. Então, vamos destruir o apache-test por completo: deployment, services, namespace, tudo. Basta executar o código apocalíptico abaixo:

kubectl delete all --all -n apache-test
kubectl delete ingress apache-test-ingress -n apache-test
kubectl delete pvc apache-html-pvc -n apache-test
kubectl delete namespace apache-test

Se eu navegar até Applications não consigo mais ver o apache-test, mas se for até Restore Points, é possível ver dois tipos: Exported e Snapshot. Adivinha qual dos dois vai me salvar agora?

Se você falou exported, acertou em cheio! É esse o ponto de restauração que está armazenado no NFS e que não foi removido junto com a aplicação. Então vamos iniciar o processo de restauração. Obs: o cadeado aberto ao lado do nome do repositório serve para nos lembrar que o repositório não é imutável, ou seja, não recomendado para ambientes produtivos (sim, vou repetir isso mais mil vezes se for preciso).

Ao iniciar o restore, a primeira coisa que vemos é uma caixa verde informando que o restore point em questão está fora do cluster (ufaaa) e que a restauração pode precisar de mais tempo para trazer os dados, importar e fazer a restauração em si.

O que importa mesmo está aqui. Eu posso escolher exatamente o que eu quero restaurar. No meu caso não tenho muita escolha porque eu removi TUDO. Então eu seleciono todos os itens e restauro. Mas em outra situação, eu poderia selecionar granularmente apenas um volume, service, ingress etc.

E é isso, restauração concluida com sucesso. Minha aplicação foi restaurada exatamente como estava anteriormente. Com isso temos um ambiente completamente funcional para testar o Veeam Kasten, fazer backups e restaurações e ter a possibilidade de conhecer um pouco mais sobre esta fantastica solução de proteção para ambientes Kubernetes.

É isso aí, pessoal. O artigo ficou longo, mas o objetivo era fazer algo bem completo. Até a próxima!