---
name: backup-strategies
description: Planeamento e implementacao de estrategias de backup -- bases de dados, ficheiros e configuracoes com RPO/RTO e regra 3-2-1.
---

# /backup-strategies - Backup e Disaster Recovery

Implementacao de estrategias de backup completas seguindo best practices de RPO/RTO e regra 3-2-1.

---

## Quando usar

- Planear estrategia de backup para novo projecto
- Implementar backup automatizado
- Configurar disaster recovery
- Definir politicas de retencao
- Testar procedimentos de restore
- Auditar backups existentes
- Recuperar de falha/corrupcao

---

## Conceitos core

### RPO vs RTO

```
RPO (Recovery Point Objective)
= Maximo de dados que pode perder
= Frequencia minima de backups

RTO (Recovery Time Objective)
= Tempo maximo para restaurar
= Define tipo de solucao DR
```

**Tabela de decisao:**

| Criticidade | RPO | RTO | Solucao | Custo |
|-------------|-----|-----|---------|-------|
| **Critico** | 0 | <1h | Replicacao real-time + hot standby | Alto |
| **Alto** | 1h | <4h | Backup horario + warm standby | Medio-alto |
| **Medio** | 24h | <24h | Backup diario + cold backup | Medio |
| **Baixo** | 7d | <72h | Backup semanal | Baixo |

### Regra 3-2-1

- **3** copias dos dados (producao + backup local + backup offsite)
- **2** tipos de media diferentes (disco local + cloud)
- **1** copia offsite (protege contra desastres locais)

**Implementacao Descomplicar (estado real — fonte de verdade: `Hub/05-Projectos/SistemaBackups/`):**
1. **Producao:** Servidor CWP (VM 100) + EasyPanel (VM 101) no cluster Proxmox
2. **Backup:** Proxmox vzdump → PBS (6TB) + MySQL hourly + rsync servidores → cluster
3. **Offsite:** **pendente** (regra 3-2-1 em 2-1-0; decisao Hetzner Storage Box / Backblaze B2 / Wasabi). Insync/rclone→GDrive estao mortos — nao assumir como activos.

> Esta skill cobre conceitos genericos (RPO/RTO, GFS, 3-2-1). Para o estado e topologia reais do sistema Descomplicar, consultar sempre `Hub/05-Projectos/SistemaBackups/AUDITORIA-Backups-2026-06-08.md`.

---

## Workflow principal

### Passo 1: Definir RPO/RTO

Classificar cada sistema pela tabela de criticidade acima.

### Passo 2: Implementar scripts

Scripts prontos para MySQL, WordPress, CWP e rotacao GFS:

**-> [references/scripts.md](references/scripts.md)**

Inclui:
- Backup MySQL com `--single-transaction` e compressao
- Backup PostgreSQL com `pg_dump`
- Backup incremental MySQL com binlog
- Backup WordPress completo (com exclusoes inteligentes)
- Backup incremental com rsync
- Backup contas e configuracoes CWP
- Rotacao GFS (Grandfather-Father-Son)
- Cron schedule completo
- Cloud sync com rclone
- Script teste de restore
- Runbook disaster recovery

### Passo 3: Configurar retencao GFS

| Tipo | Retencao | Frequencia | Slots |
|------|----------|------------|-------|
| **Horario** | 24h | A cada hora | 24 |
| **Diario** | 7 dias | 1x/dia (00:00) | 7 |
| **Semanal** | 4 semanas | 1x/semana (domingo) | 4 |
| **Mensal** | 12 meses | 1x/mes (dia 1) | 12 |
| **Anual** | 7 anos | 1x/ano (1 janeiro) | 7 |

**Total:** 54 backups simultaneos

### Passo 4: Automatizar com cron

Ver schedule completo em `references/scripts.md` (seccao Cron Schedule).

### Passo 5: Configurar cloud sync

Configurar rclone para sync automatico. Ver detalhes em `references/scripts.md`.

### Passo 6: Testar restore (mensal obrigatorio)

Executar script de teste de restore mensalmente. Ver script em `references/scripts.md`.

---

## Disaster recovery

### Checklist DR

- [ ] Backups testados (restore funciona?)
- [ ] Documentacao actualizada (runbook)
- [ ] Runbook de recovery acessivel offline
- [ ] Contactos de emergencia definidos
- [ ] Acesso offsite confirmado (credenciais)
- [ ] Teste DR trimestral agendado
- [ ] RTO/RPO documentados
- [ ] Plano de comunicacao (clientes/equipa)

### Runbook

Ver runbook completo passo-a-passo em `references/scripts.md` (seccao Runbook Disaster Recovery).

**RTO total estimado:** 4-6 horas

---

## Anti-patterns

| Anti-pattern | Problema | Solucao |
|--------------|----------|---------|
| Backup sem teste | Pode falhar no restore | Teste mensal obrigatorio |
| Apenas local | Perda em desastre | Regra 3-2-1 (offsite obrigatorio) |
| Sem encriptacao | Dados expostos | Encriptar backups sensiveis |
| Manual | Esquecimento humano | Automatizar via cron |
| Sem alertas | Falhas nao detectadas | Monitorizacao + notificacoes |
| Password no comando | Inseguro (history, ps) | Usar .my.cnf ou variaveis ENV |
| Backup sem rotacao | Disco cheio | Script de rotacao automatico |
| Sem documentacao | Caos em emergencia | Runbook DR actualizado |

---

## Checklist de implementacao

### Planeamento
- [ ] RPO/RTO definidos por sistema
- [ ] Regra 3-2-1 implementada
- [ ] Politica de retencao GFS
- [ ] Budget aprovado (storage, cloud)

### Automacao
- [ ] Scripts de backup criados
- [ ] Cron jobs configurados
- [ ] Rotacao automatica activa
- [ ] Cloud sync activo (rclone)

### Seguranca
- [ ] Encriptacao em backups sensiveis
- [ ] Permissoes correctas (600/700)
- [ ] Passwords em .my.cnf
- [ ] Offsite com autenticacao 2FA

### Monitorizacao
- [ ] Logs de backup centralizados
- [ ] Alertas de falha (email/Slack)
- [ ] Relatorio semanal automatico

### Validacao
- [ ] Primeiro restore teste executado
- [ ] RTO medido (tempo real)
- [ ] RPO validado (dados perdidos)
- [ ] Runbook ajustado conforme teste

---

## Ficheiros de referencia

| Ficheiro | Conteudo |
|----------|----------|
| [references/scripts.md](references/scripts.md) | Scripts MySQL/PostgreSQL/WordPress/CWP, rotacao GFS, cron, rclone, teste restore, runbook DR |

---

## Healing Log

Registo de erros conhecidos e como evitá-los. Lido automaticamente antes de executar.

```jsonl
{"date":"","issue":"","fix":"","source":"user|auto"}
```

*Adicionar nova linha após cada erro corrigido.*
