Como Fazer Backup e Restore de Projetos no OpenShift

Gerenciar a persistência de dados e a integridade de configurações em um ambiente de contêineres como o OpenShift exige uma estratégia robusta. Diferente de servidores tradicionais onde basta copiar arquivos do sistema de arquivos, no Kubernetes e seus derivados, os dados efêmeros são geridos por volumes dinâmicos, e as configurações estão espalhadas entre ConfigMaps, Secrets e recursos do próprio cluster. Neste tutorial, abordaremos como realizar o backup completo de um projeto (namespace) no OpenShift e como restaurá-lo em outro ambiente, garantindo a continuidade dos negócios e a segurança contra perda de dados.

Entendendo o Escopo do Backup no OpenShift

Antes de executar qualquer comando, é fundamental compreender o que compõe um "projeto" no OpenShift. Um projeto corresponde a um namespace no Kubernetes, mas com recursos adicionais de segurança e gerenciamento. O backup não se limita apenas aos dados armazenados em bancos de dados ou sistemas de arquivos; ele deve incluir:

• Recursos da Aplicação: Deployments, StatefulSets, ReplicaSets, Services, Routes, ConfigMaps e Secrets.
• Dados Persistentes: Volumes atrelados a PersistentVolumeClaims (PVCs). Este é o ponto crítico. O backup dos recursos do cluster não copia os dados dentro dos discos; ele apenas referencia o volume. Para um restore fiel, os dados em disco devem ser preservados separadamente ou por meio de snapshots do storage backend.
• Políticas e Permissões: Roles, RoleBindings e ServiceAccounts específicos do projeto.

O OpenShift oferece uma ferramenta nativa chamada oc adm backup (agora integrada ao comando oc export em versões mais recentes ou via plugins) que facilita a exportação desses recursos para arquivos YAML ou JSON. No entanto, para ambientes de produção, recomenda-se o uso da interface gráfica do Console OpenShift ou ferramentas compatíveis com Velero.

Pré-requisitos e Acesso ao Cluster

Para executar os comandos abaixo, você precisa ter acesso administrativo ao cluster OpenShift. Utilize a ferramenta de linha de comando oc. Certifique-se de estar logado no cluster correto e selecionado o namespace (projeto) alvo.

# Login no cluster OpenShift
oc login https://api.seu-cluster.example.com:6443 -u admin_user -p senha_secreta

# Selecionar o projeto específico
oc project meu-projeto-critico

Verifique se você possui permissões suficientes para listar e exportar recursos. Geralmente, a role admin ou cluster-admin é necessária.

Método 1: Backup via Linha de Comando (Exportação de Recursos)

O método mais direto para backup de configurações e definições de aplicação é utilizar o comando oc export. Este comando serializa os recursos do namespace em um arquivo YAML, que pode ser versionado ou armazenado em repositórios seguros.

Exportando Recursos Específicos

Recomenda-se exportar os recursos de forma granular para evitar conflitos e facilitar a manutenção. Comece pelos objetos essenciais:

# Exportar ConfigMaps
oc get configmaps -o yaml > configmaps.yaml

# Exportar Secrets (Cuidado: dados sensíveis)
oc get secrets -o yaml > secrets.yaml

# Exportar Deployments e StatefulSets
oc get deployments,statefulsets -o yaml > workloads.yaml

# Exportar Services e Routes
oc get services,routes -o yaml > networking.yaml

Ao exportar secrets, tenha em mente que os dados estão codificados em Base64. Se você restaurar o backup em um cluster diferente, os pods tentarão usar essas credenciais. Certifique-se de que as senhas e tokens ainda são válidos no ambiente de destino ou atualize os Secrets manualmente após o restore.

Exportação Completa do Namespace

Se desejar um backup único de todos os recursos suportados, utilize:

# Exportar tudo no namespace atual
oc export all -o yaml > backup-completo-namespace.yaml

Observe que o comando oc export pode gerar arquivos muito grandes. Além disso, ele não captura o estado atual dos dados nos PVCs. Ele captura apenas a "receita" da aplicação.

Método 2: Backup de Dados Persistentes (PVCs)

A parte mais delicada do backup em Kubernetes é garantir que os dados dentro dos discos persistentes sejam preservados. O OpenShift utiliza drivers de storage (como Ceph, NFS, AWS EBS, Azure Disk) para provisionar volumes. A estratégia de backup depende do driver utilizado.

Identificando os Volumes

Primeiro, liste todos os PersistentVolumeClaims no projeto:

oc get pvc

Você verá uma lista de volumes solicitados pelas aplicações. Para cada PVC, é necessário realizar o backup dos dados subjacentes.

Estratégias de Backup de Dados

1. Snapshots do Storage: Se seu cluster OpenShift estiver rodando em infraestrutura cloud (AWS, Azure, GCP) ou com Ceph RBD, a melhor prática é tirar snapshots dos volumes brutos. Isso garante uma cópia consistente dos dados em um ponto específico no tempo. No AWS, por exemplo, você pode usar o EBS Snapshot API via scripts de automação.
2. Backup com Containers (Sidecar): Para bancos de dados como PostgreSQL ou MySQL rodando dentro do OpenShift, a maneira mais segura é executar um container temporário que monta o PVC, realiza o dump lógico (ex: pg_dump) e envia o arquivo para um bucket S3 ou armazenamento externo. Isso evita backups físicos inconsistentes.
3. Ferramentas como Velero: O Velero é a ferramenta padrão da indústria para backup e restore de clusters Kubernetes. Ele orquestra snapshots de volumes e exportação de recursos simultaneamente. Se sua organização utiliza Velero, consulte a documentação específica do plugin OpenShift correspondente ao seu driver de storage.

Exemplo conceitual de script de backup para PostgreSQL usando oc exec:

# Executar dump dentro do pod que tem acesso ao PVC
oc exec -it postgres-pod-name -- pg_dump -U usuario -d nome_db > /tmp/backup.sql

# Copiar o arquivo para fora do cluster (requer acesso SSH ou volume compartilhado)
oc cp postgres-pod-name:/tmp/backup.sql ./local-backup.sql

Método 3: Backup via Console OpenShift (Recomendado para Operadores)

Para administradores que preferem interfaces gráficas, o Console OpenShift oferece funcionalidades de exportação integradas.

1. Acesse o Console OpenShift.
2. Navegue até o projeto desejado no menu lateral esquerdo.
3. Vá para a aba Workloads > PersistentVolumeClaims.
4. Se houver suporte nativo de snapshot habilitado pelo administrador do cluster, você poderá clicar em "Actions" e selecionar "Create Snapshot".
5. Para exportar configurações, vá em YAML View na aba superior e copie o conteúdo ou utilize a opção de download se disponível no seu painel.

Este método é menos flexível para automação, mas reduz o risco de erro humano na digitação de comandos complexos.

Restaurando o Projeto no OpenShift

O processo de restore (restauração) deve seguir a ordem inversa da dependência. Em muitos casos, é necessário criar os recursos de infraestrutura antes dos dados.

1. Preparação do Ambiente de Destino

Certifique-se de que o cluster de destino tenha os mesmos drivers de storage e configurações de rede básicas. Crie um novo namespace ou reutilize um existente:

oc new-project projeto-restaurado --display-name="Projeto Restaurado"

2. Restore de Configurações e Recursos

Aplique os arquivos YAML exportados anteriormente. A ordem recomendada é:

1. ServiceAccounts e Roles: Permissões necessárias.
2. ConfigMaps e Secrets: Configurações da aplicação.
3. PersistentVolumeClaims: Solicitação dos volumes (o storage provisioner criará os discos).
4. Workloads (Deployments/StatefulSets): Início dos pods que montarão os volumes.

# Aplicar recursos
oc apply -f configmaps.yaml
oc apply -f secrets.yaml
oc apply -f workloads.yaml
oc apply -f networking.yaml

Se você usou oc export all, pode aplicar diretamente:

oc apply -f backup-completo-namespace.yaml

Atenção: Ao restaurar Secrets, se as senhas mudaram no ambiente original, os pods podem falhar na inicialização devido a credenciais inválidas. Verifique logs com oc logs pod-name.

3. Restauração dos Dados Persistentes

Este é o passo mais crítico e varia conforme a estratégia usada no backup.

• Se usou Snapshots: Crie novos PVCs no cluster de destino apontando para os snapshots restaurados ou volumes clonados. Atualize os volumeClaimTemplates nos StatefulSets se necessário, ou recrie os PVCs manualmente vinculados aos volumes corretos.
• Se usou Dumps Lógicos (ex: SQL): Após os pods da aplicação estarem rodando e os novos PVCs montados, execute o restore dos dados. Para PostgreSQL:

</pre>

<p>No caso de arquivos estáticos (ex: WordPress uploads, anexos), você deve copiar os dados para o novo PVC:</p>

<pre><code># Copiar dados do arquivo local para o volume do pod
oc cp ./dados-do-backup.zip postgres-restaurado-pod:/var/www/html/wp-content/uploads/

Melhores Práticas e Considerações Finais

A administração de backups no OpenShift não é um evento único, mas um ciclo contínuo. Considere os seguintes pontos para manter a integridade do seu ambiente:

Teste de Restore Regular: Um backup sem teste de restauração é apenas uma ilusão de segurança. Periodicamente, tente restaurar o projeto em um namespace de staging ou sandbox para validar a integridade dos dados e das configurações.

Versionamento de Configurações: Mantenha os arquivos YAML de exportação em um repositório Git (GitOps). Isso permite que você rastreie mudanças na infraestrutura ao longo do tempo e recupere versões específicas se necessário.

Gestão de Segredos: Nunca armazene backups de Secrets em repositórios públicos ou desprotegidos. Os dados Base64 são facilmente decodificados. Utilize ferramentas como HashiCorp Vault integrado ao OpenShift para gerenciar credenciais, minimizando a necessidade de backup manual de Secrets.

Automatização: Para clusters em produção, evite o backup manual via oc export. Implemente pipelines CI/CD ou utilize operadores como Velero para agendar backups automáticos, garantindo consistência e reduzindo a carga operacional da equipe de DevOps.

Lembre-se: no OpenShift, a infraestrutura é imutável e os dados são persistentes. Seu plano de contingência deve tratar esses dois pilares com estratégias distintas, mas integradas, para garantir a resiliência total do seu projeto.