> ## Documentation Index
> Fetch the complete documentation index at: https://ai-kb.automationanywhere.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Guia de Recuperação de Desastres e RTO/RPO

> Estratégia de DR, objetivos RTO/RPO, sistemas de backup, mecanismos de auto-recuperação e procedimentos de recuperação para a infraestrutura EKB AWS/EKS.

Este documento descreve a estratégia de recuperação de desastres (DR), Objetivo de Tempo de Recuperação (RTO) e Objetivo de Ponto de Recuperação (RPO) para a infraestrutura EKB AWS/EKS. Ele cobre capacidades HA integradas, sistemas de backup ativos, procedimentos de recuperação e lacunas conhecidas.

<Info>
  Para instruções de implantação, consulte o [Guia de Implantação Terragrunt](/offerings/on-premise/kubernetes-deployment/terragrunt-deployment).
</Info>

***

## Resumo da Arquitetura e Alta Disponibilidade

### Componentes da Infraestrutura

| Componente                       | Implementação                        | Modelo HA                                   |
| -------------------------------- | ------------------------------------ | ------------------------------------------- |
| Computação                       | EKS (Kubernetes 1.33) + Karpenter    | Nós Multi-AZ, Spot + On-Demand              |
| Escalonamento automático de pods | KEDA                                 | Baseado em CPU/Memória, mín. 2 réplicas     |
| Ingress / SSL                    | ALB + ACM                            | Multi-AZ, roteamento via health-check       |
| Cache                            | ElastiCache Redis (condicional)      | Multi-AZ com failover automático            |
| Fila de mensagens                | Amazon MQ / RabbitMQ (condicional)   | Instância única ou active/standby           |
| Banco de dados (auto-hospedado)  | Cluster HA CloudNativePG + PgBouncer | Primário + réplicas, failover automático    |
| Banco de dados (cloud)           | Supabase Cloud                       | Gerenciado, entre regiões pelo provedor     |
| Observabilidade                  | SigNoz + k8s-infra (condicional)     | Dentro do cluster, sem ponto único de falha |
| Estado IaC                       | S3 (versionado) + lock DynamoDB      | Criptografado, versionado                   |
| Volumes persistentes             | EBS (via EBS CSI Driver)             | Snapshots via AWS Data Lifecycle Manager    |

### Capacidades HA Atuais

| Capacidade                           | Tempo de Recuperação | Perda de Dados   | Status                    |
| ------------------------------------ | -------------------- | ---------------- | ------------------------- |
| Falha de AZ (pods)                   | 0–5 min              | Nenhuma          | Ativo                     |
| Falha/crash de pod                   | 0–2 min              | Nenhuma          | Ativo                     |
| Roteamento via health-check do ALB   | 0–1 min              | Nenhuma          | Ativo                     |
| Failover Multi-AZ do Redis           | \< 1 min             | Nenhuma          | Ativo (quando habilitado) |
| Substituição de nó pelo Karpenter    | 0–10 min             | Nenhuma          | Ativo                     |
| Restauração de snapshot EBS          | 15–30 min            | Até 24 h         | Ativo                     |
| Restauração PITR do CloudNativePG    | 15–60 min            | Até o lag do WAL | Ativo (quando habilitado) |
| Recriação completa da infraestrutura | 30–60 min            | Nenhuma (IaC)    | Via Terragrunt            |

***

## Objetivos RTO / RPO

| Cenário                       | Objetivo RTO | Objetivo RPO                    | Capacidade Atual                    |
| ----------------------------- | ------------ | ------------------------------- | ----------------------------------- |
| Falha de pod único            | \< 2 min     | 0                               | Atendido (réplicas mín. KEDA)       |
| Falha de nó único             | \< 10 min    | 0                               | Atendido (substituição Karpenter)   |
| Falha de AZ                   | \< 5 min     | 0                               | Atendido (distribuição Multi-AZ)    |
| Falha do Redis                | \< 1 min     | 0                               | Atendido (failover Multi-AZ)        |
| Falha do primário do Postgres | \< 5 min     | 0–segundos de lag do WAL        | Atendido (failover automático CNPG) |
| Perda de volume EBS           | 15–30 min    | \< 24 h                         | Parcial — snapshots DLM diários     |
| Falha de região completa      | > 60 min     | Depende da frequência de backup | Atualmente não automatizado         |

***

## Sistemas de Backup

### 1. Estado Terraform / Terragrunt — S3

**O que é feito backup:** Todo o estado da infraestrutura (EKS, rede, IAM, releases Helm).

**Implementação:**

* Bucket S3 por ambiente: `ekb-terraform-state-<nome-do-ambiente>` (inicializado via `terragrunt/environments/<nome-do-ambiente>/state/`)
* Versionamento habilitado — qualquer versão anterior do estado pode ser restaurada
* Criptografia no lado do servidor (AES-256)
* Tabela DynamoDB para lock de estado

**Recuperação:** Reverta para qualquer versão anterior do estado no S3 e, em seguida, execute novamente `terragrunt apply`.

**RPO:** A cada commit de `terragrunt apply` — contínuo.

***

### 2. Volumes Persistentes EBS — AWS Data Lifecycle Manager

**O que é feito backup:** Volumes EBS anexados a pods (PostgreSQL do Automator, Supabase MinIO, quaisquer cargas de trabalho estatais).

**Implementação:** Política do AWS Data Lifecycle Manager (DLM) direcionada a tags de ambiente.

```bash theme={null}
# Marque os volumes EBS com o nome do seu ambiente e, em seguida, crie uma política DLM:
# - Recurso: Volumes EBS
# - Tag alvo: Environment=<nome-do-seu-ambiente>
# - Agendamento: Diariamente às 02:00 UTC
# - Retenção: 7 snapshots
```

**Recuperação:**

```bash theme={null}
# 1. Identifique o snapshot a ser restaurado
aws ec2 describe-snapshots --filters "Name=tag:Environment,Values=<nome-do-seu-ambiente>"

# 2. Crie um volume a partir do snapshot
aws ec2 create-volume \
  --snapshot-id snap-xxxxxxxxxxxxxxxxx \
  --availability-zone <sua-az> \
  --volume-type gp3

# 3. Atualize o PersistentVolume no Kubernetes para referenciar o novo ID do volume
kubectl patch pv <pv-name> -p '{"spec":{"awsElasticBlockStore":{"volumeID":"<novo-vol-id>"}}}'
```

**RPO:** Até 24 horas (snapshots diários). Reduza aumentando a frequência do agendamento DLM.

***

### 3. CloudNativePG (HA Supabase DB) — Backups Barman Cloud

**Aplica-se a:** Ambientes com `ENABLE_CNPG=true` e `ENABLE_HA_SUPABASE_DB=true`.

**O que é feito backup:** O cluster Postgres CloudNativePG (`ha-supabase-db`), incluindo streaming WAL (Write-Ahead Log) contínuo para S3 ou MinIO e backups base completos agendados via CRD `ScheduledBackup` do CNPG.

**Implementação** (configurado em `values/ha-supabase-db.yaml`):

```yaml theme={null}
postgres:
  backup:
    enabled: true                    # alternar backups barman-cloud
    # barmanObjectStore aponta para o bucket S3 ou endpoint MinIO
    # IRSA / service account deve ter s3:PutObject, s3:GetObject, s3:ListBucket
    retentionPolicy: "30d"           # manter backups por 30 dias
    compression: gzip
```

**Verificar status do backup:**

```bash theme={null}
# Listar todos os backups do cluster
kubectl get backup -n ha-supabase-db

# Verificar um backup específico
kubectl describe backup <backup-name> -n ha-supabase-db

# Acionar um backup sob demanda
kubectl cnpg backup ha-supabase-db -n ha-supabase-db
```

**Recuperação no ponto no tempo (PITR):**

```yaml theme={null}
# Criar um novo CNPG Cluster restaurando a partir de um backup
# (em um novo namespace ou após remover o original)
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: ha-supabase-db-restored
  namespace: ha-supabase-db-restore
spec:
  instances: 3
  bootstrap:
    recovery:
      source: ha-supabase-db
      recoveryTarget:
        targetTime: "2026-03-19T03:00:00.000000+00:00"  # ponto alvo no tempo
  externalClusters:
    - name: ha-supabase-db
      barmanObjectStore:
        # mesma configuração S3/MinIO do cluster de origem
        serverName: ha-supabase-db
```

**RPO:** Quase zero para clusters com WAL habilitado (segundos de lag, limitado pelo intervalo de upload do WAL).

***

### 4. ElastiCache Redis — Replicação Multi-AZ

**Aplica-se a:** Ambientes com `ENABLE_AWS_SERVICES=true`.

O Redis não é um armazenamento de dados primário — ele armazena cache transitório e dados de sessão. O foco da DR está em um failover rápido em vez de backup/restauração.

**Implementação:**

* Multi-AZ habilitado com failover automático
* Criptografia em repouso e em trânsito
* Uma falha de nó primário promove uma réplica automaticamente (\< 1 min)

**RPO:** Os dados do Redis são efêmeros por design. Falhas de cache após o failover são esperadas; a aplicação repopula a partir do banco de dados.

***

### 5. Amazon MQ (RabbitMQ) — Fila de Mensagens

**Aplica-se a:** Ambientes com `ENABLE_AWS_SERVICES=true`.

**Implementação:**

* Implantação instância única (padrão) ou active/standby
* Mensagens em trânsito podem ser perdidas durante uma reinicialização do broker; projete consumidores para serem idempotentes
* Interface de gerenciamento disponível na porta 15671 (SSL)

**RPO:** Instância única — mensagens em trânsito no momento da falha podem ser perdidas. Use o modo de implantação active/standby para reduzir este risco.

***

## Mecanismos de Auto-Recuperação

### Karpenter — Provisionamento e Recuperação de Nós

* **Consolidação:** `WhenEmptyOrUnderutilized` — nós ociosos são terminados automaticamente
* **Tratamento de interrupção de Spot:** Escuta eventos de interrupção SQS; drena e substitui nós Spot antes da terminação
* **Drift de nó:** Nós usando AMIs ou configurações desatualizadas são substituídos automaticamente quando `enable_drift = true`
* **Tempo de recuperação:** Novo nó provisionado em 0–10 minutos

### KEDA — Escalonamento Automático de Pods

* **Réplicas mínimas:** 2 para todos os serviços (Web, API, Celery, Automator) — previne ponto único de falha
* **Limite de CPU:** 60–70% aciona escalonamento para cima
* **Limite de memória:** 80% aciona escalonamento para cima
* **Estabilização de scale-down:** 30 segundos — evita oscilação
* **Tempo de recuperação:** Pods com falha são reagendados em 0–2 minutos

### Anti-Afinidade de Pods do Kubernetes

Todos os serviços sem estado usam anti-affinité `preferredDuringSchedulingIgnoredDuringExecution` em `kubernetes.io/hostname` para distribuir pods entre nós e AZs.

```yaml theme={null}
affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values: ["web", "fastapi-backend", "celery-worker", "automator"]
        topologyKey: kubernetes.io/hostname
```

***

## Procedimentos de Recuperação

### Cenário 1: Falha de AZ

**Comportamento esperado:** O Karpenter provisiona nós de substituição nas AZs restantes; o KEDA reagenda pods; o ALB para de rotear para targets não saudáveis.

**Verificação:**

```bash theme={null}
kubectl get nodes -o wide     # confirmar que nós estão em AZs saudáveis
kubectl get pods -A -o wide   # confirmar que pods estão em execução
kubectl get ingress            # confirmar que o ALB está roteando corretamente
```

<Info>
  Nenhuma intervenção manual é necessária sob circunstâncias normais.
</Info>

***

### Cenário 2: Falha do Nó Primário do Postgres (CloudNativePG)

O CloudNativePG promove automaticamente uma réplica a primário.

```bash theme={null}
# Monitorar o failover
kubectl get cluster ha-supabase-db -n ha-supabase-db -w

# Confirmar o novo primário
kubectl cnpg status ha-supabase-db -n ha-supabase-db

# Verificar se o pooler PgBouncer está apontando para o novo primário
kubectl get svc -n ha-supabase-db | grep pooler
```

As aplicações se reconectam via PgBouncer — nenhuma alteração de string de conexão necessária.

***

### Cenário 3: Restaurar Volume EBS a partir de Snapshot

```bash theme={null}
# 1. Encontrar snapshots para o ambiente
aws ec2 describe-snapshots \
  --filters "Name=tag:Environment,Values=<nome-do-seu-ambiente>" \
  --query 'Snapshots[*].[SnapshotId,StartTime,VolumeSize]' \
  --output table

# 2. Criar um novo volume a partir do snapshot escolhido
aws ec2 create-volume \
  --snapshot-id snap-xxxxxxxxxxxxxxxxx \
  --availability-zone <az-destino> \
  --volume-type gp3 \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=Environment,Value=<nome-do-seu-ambiente>}]'

# 3. Reduzir a carga de trabalho afetada
kubectl scale deployment <carga-trabalho> --replicas=0

# 4. Atualizar o PV para referenciar o novo volume EBS e, em seguida, escalar novamente
kubectl patch pv <pv-name> -p '{"spec":{"csi":{"volumeHandle":"<novo-volume-id>"}}}'
kubectl scale deployment <carga-trabalho> --replicas=2
```

***

### Cenário 4: Recriação Completa da Infraestrutura

Usado após falha catastrófica ou ao reconstruir uma região.

```bash theme={null}
# 1. Inicializar o bucket de estado (se não existir)
cd terragrunt/environments/<nome-do-seu-ambiente>/state
terragrunt apply

# 2. Recriar o cluster EKS e infraestrutura principal
cd terragrunt/environments/<nome-do-seu-ambiente>
terragrunt apply

# 3. Implantar serviços em ordem (veja Guia de Implantação Terragrunt § Fase 6)
ENABLE_CNPG=true terragrunt apply --target='helm_release.local["cloudnative-pg"]'
ENABLE_HA_SUPABASE_DB=true terragrunt apply --target='helm_release.local["ha-supabase-db"]'
ENABLE_SUPABASE=true terragrunt apply --target='helm_release.local["supabase"]'
```

**RTO estimado:** 30–60 minutos para o cluster completo; 60–120 minutos se os dados EBS/CNPG precisarem ser restaurados.

***

### Cenário 5: Reversão de Estado Terragrunt

```bash theme={null}
# Listar versões de estado no S3
aws s3api list-object-versions \
  --bucket ekb-terraform-state-<nome-do-seu-ambiente> \
  --prefix <chave-do-estado>

# Restaurar uma versão específica
aws s3api get-object \
  --bucket ekb-terraform-state-<nome-do-seu-ambiente> \
  --key <chave-do-estado> \
  --version-id <versao-id> \
  terraform.tfstate

# Reimportar ou aplicar com o estado restaurado
```

***

## Observabilidade e Alertas (SigNoz)

Quando `ENABLE_SIGNOZ=true`, o SigNoz é implantado no namespace `monitoring` e fornece:

* Rastreamento distribuído para todos os serviços EKB
* Métricas do cluster via agente DaemonSet k8s-infra (CPU, memória, status do pod)
* Agregação de logs de todos os pods
* Alertas — configure regras de alerta no SigNoz para notificar sobre loops de crash de pods, altas taxas de erro ou pressão de nós

Para fins de DR, os painéis do SigNoz são a principal ferramenta para diagnosticar e confirmar a recuperação após um incidente. Os próprios dados do SigNoz são armazenados em volumes PV EBS e são cobertos pela política de snapshots EBS.

***

## Lacunas e Recomendações

| Lacuna                            | Risco                                                              | Recomendação                                                                                    |
| --------------------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------- |
| Sem replicação entre regiões      | Falha de região completa = RTO estendido                           | Considere réplica de leitura RDS entre regiões ou replicação S3 entre regiões para backups CNPG |
| Snapshots EBS são diários         | Até 24 h de perda de dados para cargas de trabalho baseadas em EBS | Aumente a frequência DLM para horária para volumes críticos                                     |
| RabbitMQ instância única (padrão) | Mensagens em trânsito perdidas na falha do broker                  | Mude para modo de implantação `ACTIVE_STANDBY_MULTI_AZ` para produção                           |
| Sem DR drill automatizado         | Procedimentos de recuperação não testados até serem necessários    | Agende drills trimestrais de recuperação; teste restauração PITR do CNPG em ambiente de staging |
| SigNoz no mesmo cluster           | Observabilidade perdida durante falha do cluster                   | Considere um endpoint de monitoramento leve separado ou alertas de fallback CloudWatch          |