Por que um plano de Disaster Recovery para Affilentra é indispensável
Affilentra integra tracking, cálculo de comissões e faturação numa plataforma PHP/MySQL self‑hosted. Enquanto operador, você é responsável pela integridade dos dados, pelo histórico de pagamentos e pela confiança dos parceiros. Um plano de Disaster Recovery direcionado garante que dados perdidos (transações, configurações, materiais promocionais) possam ser rapidamente e de forma reproduzível restaurados — sem surpresas relativas a funções, permissões ou faturação.
Visão geral rápida: Objetivos deste guia
- Cópia consistente da base de dados, do sistema de ficheiros e da configuração.
- Configuração de Point‑in‑Time‑Recovery (PITR) com MySQL‑Binlogs.
- Automação, encriptação e regras de retenção.
- Processos de restauração definidos, testados e verificações regulares.
1. Arquitetura e pré‑requisitos
Analise primeiro a sua instalação: onde estão os ficheiros PHP, os uploads, os cron‑jobs, os ficheiros de configuração (por exemplo config.php) e a base de dados MySQL? Separe as funções: operadores de software (infraestrutura/backups), comerciantes (gestão de produtos) e parceiros (links de tracking) necessitam de objetivos de recuperação e direitos de acesso diferentes.
Pré‑requisitos recomendados:
- Acesso root/administrador ao servidor e à instância MySQL.
- Armazenamento de exportação fiável (local + offsite, por exemplo Object‑Storage ou sistema de backup externo).
- Ferramentas de encriptação (gpg, age) e um conceito de gestão de chaves.
2. Estratégia de backup: O que pertence a cada lugar?
As três pilares são:
- Base de dados (MySQL): dumps completos mais Binlogs para PITR.
- Sistema de ficheiros: código PHP, uploads, media, materiais promocionais.
- Configuração & Cron: ficheiros de config, unidades systemd, certificados SSL.
Backups da base de dados
Faça backups completos consistentes regulares (por exemplo usando mysqldump --single-transaction para tabelas InnoDB) ou use backups físicos (Percona XtraBackup) para instalações grandes. Adicionalmente, os MySQL‑Binlogs devem estar ativados para que possa reconstruir ao nível das transacções.
Configuração MySQL importante (my.cnf):
log_bin = mysql-binserver-id = 1(ou ID única)binlog_format = ROW(recomendado para replicação/PITR fiáveis)- Opcional:
expire_logs_daysou rotação própria via script
Point‑in‑Time‑Recovery (PITR)
PITR complementa backups completos: faça backup contínuo dos binlogs e registre timestamps ou GTIDs em cada backup completo. Em caso de recuperação, restaure o último backup completo e aplique os binlogs com mysqlbinlog --start-datetime / --stop-datetime | mysql até o momento desejado antes do incidente.
Backups do sistema de ficheiros e de configuração
Faça backup de:
- Diretório do código‑fonte (ficheiros PHP, bibliotecas).
- Uploads/Media/Assets (imagens de tracking, materiais publicitários).
- Ficheiros de configuração, certificados SSL, scripts Cron e ficheiros systemd/Unit.
Crie arquivos atómicos (por exemplo tar + gzip) ou utilize ferramentas baseadas em ficheiros (rsync) para backups incrementais. Atenção às permissões de ficheiros e a SELinux/ACLs durante a restauração.
3. Automatização, armazenamento e encriptação
Automatização
Use Cron ou systemd‑Timers para tarefas recorrentes:
- Dump Full da BD diário (à noite, fora de horários de pico).
- Recolha e arquivamento contínuo dos binlogs (por exemplo, a cada 5–15 minutos).
- Snapshots diários/múltiplos do sistema de ficheiros ou jobs incrementais Rsync.
Registe cada backup com timestamp, checksum SHA256 e tamanho do ficheiro para verificação de integridade.
Política de retenção
Defina uma política de retenção adequada à sua conformidade e objetivos de tempo de recuperação. Uma estrutura de exemplo para orientação:
- Backups diários: 14 dias
- Backups semanais: 12 semanas
- Backups mensais: 12 meses
Armazene backups pelo menos num local externo (offsite). Object‑Storage (compatível com S3) ou um fornecedor de backup separado reduzem riscos de falhas de hardware.
Encriptação e gestão de chaves
Encripte os backups em repouso com chaves GPG/age. Separe os locais de armazenamento do material de chaves (por exemplo, chaves num HSM dedicado ou gestor de passwords com controlo de acesso). Planeie a rotação de chaves e documente os acessos de recuperação.
4. Processos de restauração e testes regulares
Checklist de recuperação (fluxo básico)
- Isole o ambiente para evitar sobregravação de dados.
- Restaure o backup Full apropriado da BD MySQL.
- Importe os binlogs até ao ponto de paragem desejado (PITR).
- Restaure o backup do sistema de ficheiros (código e media).
- Verifique configurações, permissões e segredos.
- Execute testes de integridade e funcionais (tracking, login, cálculo de comissões).
- Documente duração e desvios; ajuste a estratégia conforme necessário.
Testes regulares de restauração
Teste pelo menos mensalmente um restauro completo numa ambiente de teste isolado. Pratique cenários PITR em diferentes pontos no tempo (p. ex. erro pouco antes do dia de faturação). Valide especialmente:
- Integridade do histórico de transacções e dos registos de pagamentos.
- Funcionalidade dos links de tracking e validação de conversões.
- Constituição de papéis e permissões (operador do software vs. comerciante vs. parceiro).
5. Exemplo: Restauração passo a passo com PITR
1) Seleccione o último full‑backup consistente (p. ex. full_2026-10-01.sql.gz). 2) Descomprima e importe-o para uma instância MySQL vazia. 3) Determine os pontos de início/fim dos binlogs (p. ex. com base no momento do incidente). 4) Utilize mysqlbinlog para aplicar os binlogs por ordem. 5) Em seguida, restaure os arquivos do sistema de ficheiros, corrija caminhos e permissões, e inicie os serviços Web/cron.
Em caso de dúvidas, mantenha um ficheiro playbook com comandos, nomes de utilizador e caminhos exactos — armazenado separado do servidor e acessível apenas a operadores autorizados.
6. Governança, papéis e responsabilidades
Defina tarefas claras:
- Operador do software: infraestrutura, backups, testes de restauração.
- Comerciante: verificação de plausibilidade dos dados de produto e condições após a restauração.
- Parceiro: verificação dos links de tracking e do histórico de pagamentos.
Plano de comunicação: indique contactos, níveis de escalonamento e canais de comunicação para uma falha.
Conclusão e próximo passo
Um plano de recuperação de desastres fiável para a sua instância Affilentra self‑hosted combina backups de BD consistentes, PITR baseado em binlog, armazenamento offsite encriptado e testes de restauração regulares. Comece com um piloto simples: configure full‑backups, active binlogs, automatize a arquivação e execute o primeiro teste de restauro numa ambiente isolado.
Quer começar de imediato ou precisa de apoio na implementação? Escolha uma opção de início: Escolher início
Próximo passo
Experimentar o Affilentra
Plataforma unificada que integra disponibilização de produtos, tracking, validação de conversões, cálculo de comissões e pagamentos, com papéis claramente separados; opção de instalação self‑hosted com licença perpétua sem partilha de receita; os comerciantes mantêm o controlo sobre produtos, condições e materiais promocionais; os parceiros recebem links de tracking pessoais e um histórico de pagamentos rastreável.