Emanuel Almeida
6b3a6f2698
- All SKILL.md files now <500 lines (avg reduction 69%) - Detailed content extracted to references/ subdirectories - Frontmatter standardised: only name + description (Anthropic standard) - New skills: brand-guidelines, spec-coauthor, report-templates, skill-creator - Design skills: anti-slop guidelines, premium-proposals reference - Removed non-standard frontmatter fields (triggers, version, author, category) Plugins affected: infraestrutura, marketing, dev-tools, crm-ops, gestao, core-tools, negocio, perfex-dev, wordpress, design-media Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
5.0 KiB
5.0 KiB
name, description
| name | description |
|---|---|
| backup-strategies | 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:
- Producao: Servidor CWP (176.9.3.158)
- Backup local: NAS Synology ou disco externo
- Backup offsite: Google Drive + S3 (Wasabi)
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:
Inclui:
- Backup MySQL com
--single-transactione 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 | Scripts MySQL/PostgreSQL/WordPress/CWP, rotacao GFS, cron, rclone, teste restore, runbook DR |