Ejemplo de prueba de recuperación ante desastres para servidores
Publicado el 31 de octubre de 2026
Una copia de seguridad que nunca se ha restaurado aún no es un plan de recuperación. Es un archivo lleno de esperanza que está guardado en otro lugar. Este ejemplo de prueba de recuperación ante desastres muestra cómo un pequeño equipo de alojamiento, una agencia o el propietario de un servidor puede probar una falla realista sin convertir un simulacro rutinario en un incidente de producción.
El objetivo es sencillo: demostrar que puedes restaurar los servicios que la gente realmente usa, en un plazo que tu empresa pueda aceptar. Esto incluye sitios web, bases de datos, registros DNS, correo si está alojado en el mismo servidor y el acceso necesario para administrar todo después de la recuperación.
Qué debe demostrar una prueba de recuperación ante desastres
Una prueba útil hace más que confirmar que se completó una tarea de copia de seguridad. Responde preguntas prácticas: ¿puedes encontrar la copia de seguridad correcta? ¿Puedes restaurarla en un servidor limpio? ¿Se carga correctamente el sitio web? ¿La base de datos está lo bastante actualizada? ¿Puede iniciar sesión y tomar el control un miembro autorizado del equipo?
Aquí es donde importan dos objetivos de recuperación. El objetivo de punto de recuperación, o RPO, define cuántos datos puedes permitirte perder. Si las copias de seguridad se ejecutan cada noche, podrías perder hasta un día de cambios. El objetivo de tiempo de recuperación, o RTO, define cuánto tiempo puede estar un servicio sin estar disponible. Un portafolio personal puede tolerar varias horas. Probablemente, una tienda en línea que recibe pedidos no pueda.
Define estos objetivos antes del simulacro. De lo contrario, una restauración puede parecer exitosa simplemente porque al final funcionó, aunque tardara seis horas cuando la empresa necesitaba que estuviera lista en una.
Ejemplo de prueba de recuperación ante desastres: falla de un servidor web
Imagina una agencia que aloja 25 sitios web de clientes en un servidor Linux. El servidor tiene copias de seguridad completas diarias, copias de seguridad de la base de datos cada cuatro horas y almacenamiento de copias de seguridad fuera del servidor de producción. Un lunes por la mañana, una falla del disco deja el servidor fuera de servicio.
Para la prueba, no desconectes el servidor de producción. Crea una simulación controlada en un servidor de recuperación independiente o en una máquina virtual aislada. Para el primer simulacro, elige un sitio web representativo en lugar de los 25. Elige un sitio con una base de datos, cargas de archivos multimedia, SSL, tareas programadas y un inicio de sesión de administrador real. Una página estática básica es demasiado sencilla como para demostrar gran cosa.
El escenario de prueba se puede redactar así:
Incidente: El servidor de producción queda permanentemente fuera de servicio debido a una falla del disco.
Objetivo de recuperación: Restaurar el sitio web seleccionado y su base de datos en un servidor de reemplazo en un plazo de 90 minutos, con una pérdida de datos no superior a cuatro horas.
Criterios de éxito: El sitio web se resuelve mediante un nombre de host temporal o una prueba con el archivo hosts, las páginas se cargan a través de HTTPS, se puede iniciar sesión en el área de administración, hay contenido reciente, las cargas se muestran, los formularios se envían correctamente, las tareas programadas se ejecutan y los registros del servidor no muestran errores críticos de la aplicación.
Esta es una prueba específica, pero pone al descubierto los aspectos que suelen causar retrasos: credenciales faltantes, copias de seguridad incompletas, suposiciones sobre DNS, incompatibilidades de versiones y responsabilidades poco claras.
Antes de la prueba, deja claro el proceso de recuperación
Una prueba de recuperación no debería depender de que una persona recuerde una serie de comandos de hace dos años. Anota dónde están las copias de seguridad, cómo acceder a ellas, quién puede aprobar los cambios de DNS y qué servicios deben restablecerse primero.
Confirma que tu almacenamiento de copias de seguridad esté separado del servidor de producción. Las copias de seguridad almacenadas únicamente en el mismo disco que los sitios web son útiles para recuperar archivos eliminados por accidente, pero no sirven de mucho si se pierde el servidor. Comprueba también que las credenciales de recuperación estén disponibles sin depender del servidor averiado. Esto incluye el acceso al almacenamiento de copias de seguridad, al registrador de dominios y al proveedor de DNS, las claves SSH, los datos de las licencias y los secretos de aplicación necesarios.
Si utilizas un panel de servidor, documenta tanto los pasos que hay que seguir como la configuración técnica. No es un atajo. Es una forma de hacer que la persona que esté disponible cuando ocurra el incidente pueda repetir el proceso de recuperación. FASTPANEL puede ayudar a mantener los sitios web, las bases de datos, las copias de seguridad y la configuración del servidor en un solo lugar fácil de administrar, pero la prueba sigue necesitando responsables claros y evidencias.
Realiza el simulacro siguiendo un orden seguro
Inicia un cronómetro cuando el equipo reciba el aviso del incidente simulado. Anota la hora, quién realiza cada acción y cualquier decisión que impida avanzar. Estas notas forman parte del resultado de la prueba; no son papeleo por el mero hecho de hacerlo.
Primero, prepara el entorno de recuperación. En la medida de lo posible, utiliza las mismas versiones del sistema operativo y de los entornos de ejecución necesarios. No siempre es necesario duplicar el entorno exactamente, pero cambiar a la vez el sistema operativo, la versión de PHP, la versión de la base de datos y la configuración del servidor web dificulta la resolución de problemas. Si el entorno de recuperación es diferente, documenta esa diferencia.
A continuación, recupera la copia de seguridad seleccionada y verifica su fecha. Restaura los archivos del sitio web y la base de datos; luego, añade los valores de configuración que la aplicación necesita para conectarse. No des por sentado que los archivos de configuración lo contienen todo. Muchas aplicaciones dependen de variables de entorno, claves de API, configuraciones de correo, tareas cron o permisos que están fuera del directorio del sitio web.
Pon en línea el sitio restaurado mediante una URL temporal, un dominio de pruebas o una entrada local en el archivo hosts. No dirijas el DNS público al servidor de recuperación hasta que sepas que el sitio funciona. Comprueba la página de inicio, varias páginas internas, las imágenes, los formularios, el inicio de sesión de la cuenta y el área de administración. Si se trata de un sitio de WordPress, comprueba también los enlaces permanentes, los plugins, las cargas y la publicación programada.
Después, inspecciona los servicios relacionados con el sitio. Confirma que el certificado SSL se pueda instalar o renovar, que el correo saliente esté configurado como se espera, que las tareas programadas estén configuradas y que los usuarios de la base de datos tengan únicamente los permisos que necesitan. Que la página de inicio se cargue correctamente es un buen comienzo, no la meta.
Prueba también la decisión de conmutación por error
La restauración técnica es solo la mitad de la recuperación ante desastres. La otra mitad consiste en decidir cuándo y cómo se redirige el tráfico al servidor de reemplazo.
Para este simulacro, simula un cambio de DNS después de que el sitio restaurado supere las comprobaciones. Mide cuánto se tarda en preparar y comunicar el cambio, no solo cuánto tarda la propagación del DNS por Internet. Los valores bajos de TTL de DNS pueden reducir el tiempo de espera, pero deben planificarse antes de una interrupción. Cambiar el TTL durante el incidente rara vez ayuda de inmediato, porque es posible que los resolutores ya tengan almacenado en caché el valor anterior.
Si tu configuración utiliza un balanceador de carga, un proxy inverso o un servicio de conmutación por error en la nube, prueba ese mecanismo en lugar de probar solo el DNS. El enfoque adecuado depende de tu arquitectura. Un solo servidor con unos cuantos sitios web empresariales puede recuperarse perfectamente mediante DNS. Un proveedor de alojamiento o una tienda con un gran volumen de transacciones puede necesitar un diseño de conmutación por error más rápido y un entorno secundario que esté más preparado.
Registra resultados que permitan actuar
Al final del simulacro, no escribas solo «restauración exitosa». Registra el tiempo real de recuperación, la antigüedad de la copia de seguridad, las comprobaciones fallidas y los pasos manuales necesarios. Compara las cifras con tu RTO y tu RPO.
Por ejemplo, el equipo puede restaurar el sitio web en 52 minutos y descubrir que la copia de seguridad más reciente de la base de datos tiene seis horas. La recuperación del servidor cumplió el RTO de 90 minutos, mientras que la recuperación de los datos no cumplió el RPO de cuatro horas. Aun así, es un resultado valioso porque apunta a una solución específica: aumentar la frecuencia de las copias de seguridad de la base de datos o añadir protección a nivel de transacción cuando corresponda.
Entre los problemas habituales se incluyen una retención insuficiente de copias de seguridad, credenciales no probadas, copias de seguridad que excluyen archivos cargados, versiones de software incompatibles y acceso al DNS vinculado a la cuenta de un solo empleado. Soluciona primero el problema de mayor riesgo, asígnale un responsable y fija una fecha límite. Una prueba sin seguimiento es solo un ensayo del mismo problema.
¿Con qué frecuencia debes hacer pruebas?
Para la mayoría de las pequeñas empresas, empezar con una prueba de recuperación trimestral es una opción práctica. Haz pruebas con más frecuencia después de cambios importantes, como una migración de servidor, un nuevo proveedor de copias de seguridad, una actualización de la base de datos, un rediseño de la aplicación o un cambio en quién administra la infraestructura.
Alterna el alcance. Un trimestre, restaura un sitio web esencial y su base de datos. Al siguiente, prueba la reconstrucción completa de un servidor. Más adelante, prueba una falla de acceso a una cuenta o un escenario de eliminación accidental. Cada tipo de falla pone al descubierto puntos débiles distintos, y no hace falta provocar el máximo caos en cada prueba para aprender algo útil.
El mejor plan de recuperación ante desastres es aquel que tu equipo puede ejecutar con calma y con la información que tiene a mano. Programa la próxima prueba antes de que esta caiga en el olvido y, cada vez, haz que el proceso de recuperación sea un poco más breve y claro.