Copia de seguridad y recuperación ante desastres para sitios web PHP: Una guía práctica

Cada sitio web PHP se sustenta sobre una pila de componentes móviles: un servidor web, el runtime de PHP, una base de datos MySQL o PostgreSQL, archivos de configuración, activos subidos y, a menudo, cientos de pequeños trabajos cron. Cualquiera de esas piezas puede fallar — una tabla corrupta, un rm -rf descontrolado, un ransomware — y si solo tienes una copia de seguridad de la base de datos de la semana pasada, estás en problemas. En DigiForge, hemos recuperado más sitios PHP de los que nos gustaría contar, y la diferencia entre una recuperación de cuatro horas y una pesadilla de cuatro días siempre se reduce a una cosa: una estrategia de copia de seguridad y recuperación ante desastres bien diseñada.

Por qué la copia de seguridad por sí sola no es suficiente

Muchos equipos confunden la copia de seguridad con la recuperación ante desastres. Una copia de seguridad es una copia periódica de datos. La recuperación ante desastres es el proceso completo de volver a poner en línea tu aplicación: restaurar datos, reconfigurar servicios, redirigir tráfico y validar que todo funcione. Como señala un informe de resiliencia de TI, "proteger tus datos con copias de seguridad ya no es suficiente para sobrevivir" (fuente). Una copia de seguridad sin un plan de recuperación probado es solo un seguro que aún no has leído.

En un contexto PHP, la diferencia es evidente. Tu copia de seguridad de la base de datos puede estar perfectamente intacta, pero si no sabes cómo apuntar Apache o Nginx a la base de datos restaurada, cambiar las credenciales en el .env o reconstruir el opcache de PHP, seguirás fuera de línea. Y el tiempo de inactividad, como todos sabemos, cuesta dinero y confianza. Un plan integral de recuperación ante desastres (DR) debe cubrir cada capa de tu pila de servidores, no solo los datos.

La pila de copia de seguridad y recuperación para sitios PHP

Dividimos la copia de seguridad de una aplicación PHP en cinco capas distintas. La falta de cualquiera de ellas puede hacer que las demás sean inútiles:

1. Código y control de versiones (repositorios Git, incluyendo etiquetas y ramas).
2. Volcados de base de datos (MySQL, PostgreSQL o MariaDB).
3. Configuración del servidor web (hosts virtuales de Nginx/Apache, certificados SSL, pools de PHP-FPM).
4. Configuración de la aplicación (.env, archivos de configuración, credenciales hardcodeadas).
5. Contenido subido por el usuario (imágenes, PDFs, cualquier archivo almacenado fuera de la base de datos).

Repasemos cada capa con recomendaciones prácticas.

1. Código y control de versiones

El código de tu aplicación debe vivir en un repositorio Git, sin excepciones. Pero un push a Git no es una copia de seguridad. Hemos visto equipos que dependen de una sola rama remota y pierden semanas de trabajo cuando ocurre un force push o el repositorio se corrompe. Usa un proveedor de alojamiento Git (GitHub, GitLab, Bitbucket) y configura réplicas automáticas a una segunda ubicación. Para despliegues en producción, etiqueta cada versión. Así, si necesitas revertir a un estado conocido y estable, no tendrás que adivinar qué commit estaba en producción.

2. Copias de seguridad de la base de datos

Las copias de seguridad de la base de datos son las más críticas y las más descuidadas. Un mysqldump diario a un directorio local es mejor que nada, pero hemos visto cómo esos archivos llenan el disco y dejan de ejecutarse silenciosamente. Automatiza tus volcados con un script que rote las copias antiguas, las comprima y las envíe fuera del sitio: a S3, Backblaze o un servidor separado. Usa mysqldump --single-transaction para tablas InnoDB para evitar bloqueos de lectura, y prueba tu restauración periódicamente. Una copia de seguridad que no se puede restaurar no vale nada.

3. Configuración del servidor y del servidor web

Tu sitio PHP funciona con más que código y datos. Los archivos de configuración de Nginx o Apache, la configuración del pool de PHP-FPM, los certificados SSL y las definiciones de tareas cron son exclusivos de tu servidor. Almacenamos estos en un repositorio Git separado (o como parte del repositorio de la aplicación bajo un directorio deploy/) y los respaldamos junto con el resto. Servicios como Certbot renuevan automáticamente los certificados de Let's Encrypt, pero si tu servidor muere, esos certificados se pierden. Respaldar /etc/letsencrypt/ o cambiar a validación basada en DNS que sobrevive a una reconstrucción.

4. Configuración del entorno y de la aplicación

Las aplicaciones PHP suelen tener un archivo .env con credenciales de base de datos, claves de API y secretos. Estos nunca deben estar en el control de versiones. Usamos un gestor de secretos (como HashiCorp Vault o envkey) para producción, pero como mínimo, cifra y guarda una copia de .env en tu sistema de respaldo. Si pierdes este archivo, no restaurarás tu sitio, lo reconstruirás.

5. Cargas de usuarios y medios

Las imágenes, PDFs y otras cargas a menudo se almacenan en un directorio public/uploads. Crecen rápido y pueden inflar las copias de seguridad de la base de datos si se almacenan como BLOBs. La mejor práctica: mantén las cargas en un volumen separado o almacenamiento de objetos (S3, DigitalOcean Spaces). Si están en el sistema de archivos del servidor, incluye ese directorio en tu respaldo externo. Usa rsync o rclone para sincronizar con almacenamiento en la nube a diario.

Automatización y prueba de tu plan de recuperación

Una estrategia de respaldo solo es tan buena como su recuperación. Hemos llegado a demasiadas autopsias donde el cliente decía: "Tenemos respaldos", pero nunca intentaron usarlos. La recuperación ante desastres es un proceso, no un producto. Necesitas escribir —y, más importante, ensayar— cómo recuperarás tu sitio PHP.

• Escribe un runbook. Documenta cada paso: dónde se almacenan los respaldos, cómo restaurar la base de datos, qué comandos reconstruyen el servidor web, cómo actualizar el DNS si cambia tu IP.
• Automatiza las restauraciones. Usa scripts o herramientas de orquestación (Ansible, Puppet, o incluso un script Bash simple) para aprovisionar un nuevo servidor y restaurar tu aplicación desde los respaldos. Si no puedes levantar un clon en menos de una hora, tu plan de DR es demasiado lento.
• Prueba trimestralmente. Restaura toda tu pila PHP en un servidor nuevo (un nuevo VPS o VM local) y verifica que el sitio funcione. Prueba la propagación de DNS, SSL, conexiones a la base de datos, trabajos cron y cada flujo de usuario. Arregla cualquier cosa que falle.

En nuestra experiencia, los fallos más comunes durante un simulacro de recuperación son discrepancias de credenciales (contraseñas de base de datos hardcodeadas que no coinciden con el .env restaurado), extensiones PHP faltantes y cargas incompletas. Cada fallo es un regalo: revela una brecha que puedes corregir antes de un desastre real.

“Un respaldo sin un plan de recuperación probado es solo una esperanza.” — Principio de ingeniería de DigiForge

Elección de ubicaciones y formatos de almacenamiento

La vieja regla 3-2-1 sigue vigente: tres copias de tus datos, en dos medios diferentes, con una copia fuera del sitio. Para sitios web PHP, una configuración común es: (1) el script de respaldo local del servidor en producción, (2) un bucket en la nube fuera del sitio y (3) un archivo de almacenamiento en frío (por ejemplo, Glacier) para instantáneas mensuales. Cifra las copias de seguridad con GPG o cifrado del lado del cliente antes de subirlas a cualquier tercero.

Las copias de seguridad incrementales ahorran ancho de banda y almacenamiento, pero aumentan la complejidad de la restauración. Para un sitio PHP de tráfico medio, un volcado completo diario de la base de datos más registros binarios por hora (si es necesario) ofrece un buen equilibrio. Las copias de seguridad del sistema de archivos pueden ser incrementales mediante rsync; solo asegúrate de que tus herramientas puedan reconstruir un estado coherente a partir de los incrementales.

Cuando ocurre el desastre: el manual de recuperación

Simulemos el peor caso: un ataque de ransomware cifra tu raíz web PHP y tu base de datos. Este es el flujo de recuperación de alto nivel que usamos en DigiForge:

1. Aislar el servidor infectado — cortar todo acceso externo, tomar una instantánea para análisis forense si es necesario.
2. Aprovisionar un servidor limpio — un VPS nuevo con el mismo sistema operativo y versión de PHP.
3. Restaurar el código desde Git — clonar el release etiquetado que se ejecutaba antes del ataque.
4. Restaurar la configuración — copiar .env, configuraciones del servidor web, certificados SSL (o reemitirlos).
5. Restaurar la base de datos — importar el volcado limpio más reciente, luego reproducir los binlogs hasta el momento de la infección (si están disponibles).
6. Restaurar las subidas — rsync desde el almacenamiento de respaldo al directorio de subidas del nuevo servidor.
7. Probar todo — ejecutar comprobaciones de estado, verificar conexiones a la base de datos, asegurarse de que los cron jobs se ejecuten.
8. Cambiar DNS — apuntar tu dominio a la IP del nuevo servidor (bajar el TTL de antemano).
9. Monitorear — revisar logs y tiempo de actividad durante 24 horas. Declarar la recuperación solo después de un período sostenido en verde.

Todo este proceso puede tomar de 2 a 4 horas si tus copias de seguridad están bien organizadas y has practicado. Sin práctica, puede extenderse a días.

Construyendo una cultura de recuperación

La recuperación ante desastres no es un proyecto único, sino una práctica continua. Cada vez que actualices tu versión de PHP, añadas un nuevo cron job o modifiques una directiva del servidor web, actualiza tu runbook y vuelve a probar. Hemos visto a demasiados equipos tratar las copias de seguridad como un elemento de lista de verificación. Una verdadera estrategia de DR está integrada en tu pipeline de despliegue, tu monitoreo y la memoria muscular de tu equipo.

Si eres responsable de un sitio web PHP, empieza hoy. Revisa tu cobertura de copias de seguridad para las cinco capas, automatiza lo que puedas y programa tu primer simulacro de recuperación. Y si deseas una segunda opinión sobre tu estrategia, ponte en contacto con DigiForge. Hemos construido y recuperado suficientes sitios PHP para saber qué funciona y qué no.