Una copia de seguridad correcta no demuestra por sí sola que una aplicación pueda volver a prestar servicio. Puede faltar una clave, una dependencia externa, los archivos que acompañan a la base de datos o un procedimiento que indique en qué orden recuperarlos. Las pruebas de restauración ante desastres en aplicaciones PHP permiten comprobar el proceso completo antes de que una pérdida o corrupción de datos obligue a ejecutarlo bajo presión.
El objetivo no es asegurar que nunca habrá interrupciones, sino obtener evidencia sobre qué se puede recuperar, cuánto tarda y qué obstáculos quedan pendientes. Para que el ejercicio sea útil, hay que definir su alcance, aislar el entorno, validar tanto la infraestructura como el comportamiento de la aplicación y asignar responsables a las mejoras necesarias.
Verificar una copia no es recuperar el servicio
Una comprobación de copia de seguridad puede confirmar que un archivo existe, que su tamaño parece razonable o que una herramienta puede leerlo. Es un control valioso, pero distinto de restaurar los componentes necesarios y demostrar que la aplicación funciona con ellos.
La recuperación completa puede incluir una base de datos, archivos subidos por usuarios, código y configuración, además de servicios como colas de trabajo, almacenamiento de objetos, caché o tareas programadas. También puede depender de DNS, certificados, permisos, extensiones de PHP y servicios externos. Si uno de estos elementos falta o no coincide con el resto, la copia puede ser válida y, aun así, el servicio no estar recuperado.
Conviene definir qué significa «recuperado» para cada aplicación. Puede implicar que el proceso PHP arranca, que los usuarios autorizados pueden iniciar sesión y completar un flujo crítico, o que los trabajos en segundo plano vuelven a procesarse. Una página de inicio visible no basta como único criterio.
Definir alcance y criterios de éxito antes de empezar
Documenta el escenario que se va a probar: por ejemplo, pérdida de una base de datos, corrupción de archivos o indisponibilidad de un entorno completo. No es necesario simular todos los incidentes en una sola sesión. Delimitar el escenario permite identificar qué componentes deben restaurarse y qué queda expresamente fuera del ejercicio.
Acuerda criterios verificables con las áreas de negocio, tecnología y operaciones. Entre las preguntas prácticas están:
- ¿Qué funciones deben volver a estar disponibles y cuáles pueden esperar?
- ¿Hasta qué momento se aceptaría recuperar los datos y qué pérdida de cambios sería tolerable?
- ¿Cuánto tiempo puede estar interrumpido el servicio antes de que el impacto sea inaceptable?
- ¿Qué dependencias forman parte de la recuperación y cuáles se representarán mediante sustitutos seguros?
- ¿Quién autoriza la ejecución, valida el resultado y comunica los problemas?
Los objetivos de punto de recuperación (RPO) y de tiempo de recuperación (RTO) pueden servir para expresar tolerancias de pérdida de datos e interrupción. Deben acordarse según las necesidades y capacidades de cada servicio; no existe un valor universal. La prueba permite comparar los tiempos y el estado de los datos observados con esos objetivos, sin convertir un resultado aislado en una garantía futura.
Preparar un entorno aislado y seguro
Haz la restauración en un entorno separado de producción, con controles para impedir que el ejercicio altere datos reales o envíe mensajes a clientes. Aísla las redes cuando sea posible y bloquea o sustituye integraciones que podrían ejecutar cobros, enviar correos, publicar eventos o modificar sistemas externos. Informa a los participantes de que se trata de una prueba.
Los datos restaurados pueden contener información sensible. Aplica las políticas de acceso, conservación y protección de datos correspondientes; limita quién puede entrar al entorno y durante cuánto tiempo. Evita reutilizar credenciales de producción. Gestiona los secretos de prueba de manera controlada y verifica que los archivos restaurados no los expongan en registros, repositorios o directorios accesibles públicamente.
Registra las condiciones iniciales: fecha y punto de la copia, versiones de código y configuración necesarias, recursos disponibles y diferencias entre el entorno de prueba y el de producción. Una versión de PHP distinta, extensiones ausentes o permisos diferentes pueden afectar al resultado. Esos desajustes deben quedar anotados, no confundirse con un éxito o un fallo de la copia.
Ejecutar la recuperación de todos los componentes necesarios
Sigue el procedimiento documentado, incluso si conoces una forma más rápida. Precisamente se está comprobando si las instrucciones son suficientes para que otra persona pueda recuperar el servicio. Anota el orden y la duración de cada paso, los comandos manuales, las decisiones tomadas y cualquier intervención que no estuviera prevista.
Una secuencia posible, que debe adaptarse a cada arquitectura, es restaurar la infraestructura y la configuración, recuperar la base de datos y los archivos, desplegar la versión de código compatible y conectar las dependencias necesarias. En PHP, revisa, según corresponda, la configuración del servidor web y PHP-FPM, las extensiones requeridas, las variables de entorno, los permisos de escritura y las tareas programadas. Comprueba también colas, almacenamiento de objetos y procesos trabajadores si la aplicación depende de ellos.
No ejecutes migraciones ni procesos de reconstrucción de datos de forma automática sin conocer su efecto en una copia restaurada. Verifica que las credenciales apuntan exclusivamente a servicios de prueba y que las tareas de cron no producen efectos externos. Si la recuperación exige una intervención manual, regístrala como parte del tiempo real y como posible punto de mejora.
Validar integridad y comportamiento, no solo el arranque
Las comprobaciones deben cubrir datos y recorridos funcionales. Empieza con verificaciones técnicas: conectividad con la base de datos, estado de procesos, espacio disponible, registros de errores y respuesta de los servicios internos. Después, valida que los archivos y referencias almacenados concuerdan, y que las relaciones o restricciones importantes de la base de datos siguen siendo coherentes.
Elige consultas y flujos representativos acordes con el uso real de la aplicación. Por ejemplo, comprobar que se puede localizar una entidad conocida, iniciar sesión con una cuenta de prueba y completar una operación que no tenga efectos externos. Si hay archivos subidos, valida que se pueden recuperar y asociar a sus registros. Si existen colas, comprueba que los trabajos pendientes tienen un comportamiento previsto y no se procesan dos veces por error.
Conserva evidencia suficiente para repetir la evaluación: resultados de consultas, pasos realizados, errores observados y hora de inicio y fin. No basta con registrar «funciona». Define de antemano qué comprobaciones aprueban el ejercicio y cuáles son bloqueantes. Una aplicación que responde, pero muestra datos incompletos o no procesa operaciones críticas, no debe considerarse recuperada según criterios más exigentes.
Medir, corregir y repetir con una cadencia útil
Mide el tiempo desde el inicio acordado hasta que se cumplen los criterios de recuperación, no solo el tiempo de restauración de una base de datos. Separa, si ayuda al análisis, la espera, el trabajo automático, los pasos manuales y la validación. Compara el resultado con los objetivos acordados e identifica supuestos que no se cumplieron, como permisos que no estaban disponibles o documentación desactualizada.
El informe debe incluir alcance, punto restaurado, resultado de cada comprobación, tiempos observados, incidencias, decisiones y responsables de las acciones correctivas. Prioriza las medidas que reducen bloqueos: automatizar pasos repetibles, actualizar instrucciones, corregir permisos, revisar dependencias o mejorar la estrategia de copias. Asigna fechas de seguimiento y repite la parte afectada para comprobar si la corrección resolvió el problema.
La cadencia depende del riesgo, los cambios de arquitectura y la capacidad operativa. Puede combinarse una restauración parcial frecuente —por ejemplo, de una base de datos o de archivos— con ejercicios de recuperación completa y escenarios distintos. También conviene repetir la prueba después de cambios relevantes en el sistema de copias, la infraestructura o las dependencias. Una prueba satisfactoria aporta evidencia sobre un escenario y unas condiciones concretas: no garantiza el resultado de todos los incidentes futuros.
