Recuperación ante desastres para Affilentra autohospedado: Copias de seguridad, Recuperación a un punto en el tiempo y procesos de restauración probados

← Todos los artículos

26.10.2026

Por qué un plan de recuperación ante desastres para Affilentra es imprescindible

Affilentra combina seguimiento, cálculo de comisiones y facturación en una plataforma PHP/MySQL autohospedada. Como operador, usted es responsable de la integridad de los datos, el historial de pagos y de la confianza de los socios. Un plan de recuperación ante desastres bien pensado garantiza que los datos perdidos (transacciones, configuraciones, materiales publicitarios) se puedan restaurar rápida y reproduciblemente —sin sorpresas en roles, permisos o facturación—.

Resumen breve: Objetivos de esta guía

• Copia constante de la base de datos, del sistema de archivos y de la configuración.
• Implementación de Recuperación a un punto en el tiempo (PITR) con los binlogs de MySQL.
• Automatización, cifrado y reglas de retención.
• Procesos de restauración definidos y probados y comprobaciones periódicas.

1. Arquitectura y requisitos

Analice primero su instalación: ¿dónde están los archivos PHP, las cargas, los trabajos cron, los archivos de configuración (p. ej. config.php) y la base de datos MySQL? Separe los roles: el operador del software (infraestructura/copias de seguridad), los comerciantes (gestión de productos) y los socios (enlaces de seguimiento) necesitan objetivos de recuperación y derechos de acceso distintos.

Requisitos recomendados:

• Acceso root/administrador al servidor y a la instancia MySQL.
• Almacenamiento de exportación fiable (local + offsite, p. ej. almacenamiento de objetos u otro sistema de copias de seguridad externo).
• Herramientas de cifrado (gpg, age) y un concepto de gestión de claves.

2. Estrategia de copias de seguridad: ¿qué va dónde?

Las tres columnas son:

• Base de datos (MySQL): volcado completo más binlogs para PITR.
• Sistema de archivos: código PHP, cargas, medios y materiales publicitarios.
• Configuración y Cron: archivos de configuración, unidades systemd, certificados SSL.

Copias de seguridad de la base de datos

Realice copias completas consistentes con regularidad (p. ej. usando mysqldump --single-transaction para tablas InnoDB) o utilice copias físicas (Percona XtraBackup) para instalaciones grandes. Además, debe activar los binlogs de MySQL para poder reconstruir a nivel de transacción.

Configuración importante de MySQL (my.cnf):

• log_bin = mysql-bin
• server-id = 1 (o un ID único)
• binlog_format = ROW (recomendado para replicación/PITR fiable)
• Opcional: expire_logs_days o rotación propia mediante script

Recuperación a un punto en el tiempo (PITR)

PITR complementa las copias completas: haga copias continuas de los binlogs y registre marcas temporales o GTIDs en cada Full‑Backup. En caso de recuperación, restaure el último Full‑Backup y reproduzca luego los binlogs con mysqlbinlog --start-datetime / --stop-datetime | mysql hasta el momento deseado antes del incidente.

Copias de seguridad del sistema de archivos y de la configuración

Haga copias de seguridad de:

• Directorio del código fuente (archivos PHP, bibliotecas).
• Uploads/Media/Assets (imágenes de tracking, material publicitario).
• Archivos de configuración, certificados SSL, scripts Cron y systemd/Unit‑Files.

Genere archivos atómicos (p. ej. tar + gzip) o utilice herramientas basadas en archivos (rsync) para copias incrementales. Preste atención a los permisos de archivos y a SELinux/ACLs al restaurar.

3. Automatización, almacenamiento y cifrado

Automatización

Utilice Cron o systemd‑Timers para trabajos recurrentes:

• Daily Full DB Dump (por la noche, fuera de horas punta).
• Recogida y archivado continuo de los binlogs (p. ej. cada 5–15 minutos).
• Snapshots diarios/múltiples del sistema de archivos o trabajos Rsync incrementales.

Registre cada copia con marca temporal, checksum SHA256 y tamaño de archivo para verificación de integridad.

Política de retención

Defina una política de retención acorde con su cumplimiento y objetivos de tiempo de recuperación. Una estructura de ejemplo como orientación:

• Copias diarias: 14 días
• Copias semanales: 12 semanas
• Copias mensuales: 12 meses

Almacene las copias al menos en una ubicación externa (offsite). El object‑storage (S3‑compatible) o un proveedor de backups separado reducen el riesgo de fallos de hardware.

Cifrado y gestión de claves

Cifre las copias en reposo con claves GPG/age. Separe los lugares de almacenamiento del material de claves (p. ej. Keys en un HSM dedicado o en un gestor de contraseñas con control de acceso). Planifique la rotación de claves y documente los accesos de recuperación.

4. Procesos de restauración y pruebas periódicas

Lista de verificación de recuperación (flujo básico)

1. Aísle el entorno para evitar la sobrescritura de datos.
2. Restaure el Full‑Backup correspondiente de la base de datos MySQL.
3. Importe los binlogs hasta el punto de parada deseado (PITR).
4. Restaure la copia del sistema de archivos (código y media).
5. Compruebe configuraciones, permisos y secretos.
6. Realice pruebas de integridad y funcionales (tracking, login, cálculo de comisiones).
7. Documente la duración y las desviaciones; adapte la estrategia en consecuencia.

Pruebas regulares de restauración

Pruebe al menos mensualmente una restauración completa en un entorno de pruebas aislado. Practique escenarios de Point‑in‑Time‑Recovery (PITR) con distintos puntos temporales (p. ej., un fallo poco antes del día de facturación). Valide en particular:

• Integridad del historial de transacciones y de los registros de pagos.
• Funcionamiento de los enlaces de seguimiento y validación de conversiones.
• La configuración de roles y permisos (operador del software vs. comerciante vs. partner).

5. Ejemplo: restauración paso a paso con PITR

1) Seleccione la última copia completa consistente (p. ej. full_2026-10-01.sql.gz). 2) Descomprímala e impórtela en una instancia MySQL vacía. 3) Determine los puntos de inicio/fin de los binlogs (p. ej. a partir del momento del incidente). 4) Use mysqlbinlog para aplicar los binlogs en orden. 5) A continuación, restaure los archivos del sistema de ficheros, corrija rutas y permisos, y arranque los servicios web/cron.

Si hay dudas, mantenga un archivo de playbook con comandos exactos, nombres de usuario y rutas —guardado por separado del servidor y accesible sólo para operadores autorizados.

6. Gobernanza, roles y responsabilidades

Defina tareas claras:

• Operador del software: infraestructura, copias de seguridad, pruebas de restauración.
• Comerciante: comprobación de plausibilidad de los datos de producto y condiciones tras la restauración.
• Partner: verificación de enlaces de seguimiento e historial de pagos.

Plan de comunicaciones: designe contactos, niveles de escalado y canales de comunicación para un incidente.

Conclusión y siguiente paso

Un plan de recuperación ante desastres fiable para su instancia Affilentra self‑hosted combina copias de seguridad de BD consistentes, PITR basado en binlogs, almacenamiento offsite cifrado y pruebas de restauración periódicas. Comience con un piloto sencillo: configure copias completas, habilite binlogs, automatice el archivado y realice la primera prueba de recuperación en un entorno aislado.

¿Quiere empezar de inmediato o necesita ayuda con la implementación? Elija cómo comenzar: Elegir inicio

Siguiente paso

Probar Affilentra usted mismo

Plataforma unificada que integra de forma transparente la publicación de productos, seguimiento, validación de conversiones, cálculo de comisiones y pagos con roles claramente separados; opción de instalación self‑hosted con licencia perpetua sin participación en ingresos; los comerciantes mantienen el control sobre productos, condiciones y materiales publicitarios; los partners reciben enlaces de seguimiento personales y un historial de pagos trazable.

Elegir inicio