Política de Backup e Disaster Recovery

1. Objetivo

Definir o processo de backup e recuperação de desastres para os serviços, sistemas, dados e operações da plataforma Jogaê, adequado às suas criticidades.

2. Escopo de Backup

Componente	Criticidade	Frequência	Retenção
Banco de dados MySQL	Crítica	Diário (madrugada)	Diário: 30 dias | Semanal: 3 meses | Mensal: 1 ano
Arquivos de upload (S3/Spaces)	Alta	Replicação contínua	Indefinida (versionamento de objetos)
Logs de auditoria	Alta	Diário	90 dias (arquivo) + indefinido (banco)
Código-fonte	Alta	A cada commit (Git)	Indefinida (histórico Git)
Configurações (.env)	Crítica	A cada alteração	Cópia segura em local separado

3. Armazenamento Seguro

• Backups armazenados em DigitalOcean Spaces (região separada do servidor de produção).
• Backups criptografados em trânsito (HTTPS) e em repouso (server-side encryption).
• Acesso restrito via credenciais específicas (DO_KEY/DO_SECRET), separadas das credenciais de aplicação.
• Segregação lógica: backups de produção em bucket/pasta separada de homologação.

4. RTO e RPO

Métrica	Valor	Descrição
RPO (Recovery Point Objective)	24 horas	Perda máxima aceitável de dados: último backup diário.
RTO (Recovery Time Objective)	4 horas	Tempo máximo para restaurar o serviço após incidente.

5. Procedimento de Restauração

1. Identificar o backup mais recente no DigitalOcean Spaces (bucket de backup).
2. Provisionar ambiente: Criar novo servidor ou usar servidor de contingência.
3. Restaurar banco de dados: mysql -u root -p jogae_db < backup_YYYYMMDD.sql
4. Restaurar código: git clone do repositório + checkout da tag/commit de produção.
5. Configurar ambiente: Restaurar .env de produção a partir da cópia segura.
6. Executar migrações pendentes: php artisan migrate
7. Validar: Executar health check, verificar dados, testar fluxos críticos (login, pagamento).
8. Redirecionar DNS: Apontar domínio para novo servidor se necessário.

6. Testes Periódicos

• Frequência: Teste de restauração trimestral.
• Escopo: Restauração completa do banco em ambiente de teste + validação de integridade.
• Registro: Cada teste é documentado com data, resultado, tempo de restauração e problemas encontrados.
• Próximo teste agendado: Novembro/2026.

7. Alertas de Falha

• Falha de backup gera alerta automático via Slack (canal crítico) e e-mail.
• Falha de backup por 2 dias consecutivos escala para incidente de severidade Alta.

Versão: 1.0 | Aprovação: Agosto/2026 | Próxima revisão: Agosto/2027