Servidor caído: cómo recuperar tus webs desde un backup

Cuando un servidor deja de responder, la prioridad es recuperar servicio sin agravar la incidencia. Tener un backup ayuda, pero hace falta decidir qué versión usar, preparar el destino y comprobar cada aplicación. Esta guía propone una secuencia de recuperación de webs en otro servidor Plesk que puedes adaptar a tu negocio.

Si hay indicios de intrusión, conserva evidencias y coordina la recuperación con la respuesta al incidente. Restaurar los mismos archivos vulnerables sin corregir la causa puede reproducir el problema. Si es una avería, evita sobreescribir discos o copias que todavía puedan servir para recuperar datos.

1. Identifica la última copia útil, no solo la más reciente

Revisa cuándo terminó cada backup y qué sitios contiene. Una copia posterior al inicio de una corrupción o de un ataque puede conservar el problema. Selecciona un punto adecuado y anota qué cambios posteriores podrían perderse.

En una tienda online, esa ventana puede incluir pedidos y pagos que habrá que reconciliar con sistemas externos. Documenta la decisión y quién la autoriza. La planificación de copias de seguridad para empresas ayuda a establecer estas prioridades antes de una emergencia.

2. Prepara el nuevo Plesk y revisa el inventario

Comprueba conectividad con el repositorio, credenciales, espacio para datos restaurados y temporales, y versiones disponibles. Confirma qué suscripciones vas a recuperar primero. No deduzcas el espacio necesario únicamente del tamaño físico del backup: la deduplicación permite que los datos restaurados ocupen más que el repositorio.

El inventario debe relacionar dominios, subdominios, rutas, bases de datos y configuración de hosting. Si necesitas revisar el alcance, consulta qué guardar en una copia de Plesk. Una ruta distinta de httpdocs no es un detalle menor.

3. Evalúa PHP y MySQL antes de restaurar

Compara el entorno original con el destino. Un sitio que dependía de PHP 7 puede necesitar cambios para ejecutarse con PHP 8. Dentro de PHP 8 también existen diferencias entre versiones menores, extensiones y parámetros; un cambio menor no garantiza compatibilidad.

En bases de datos, revisa motor y versión. Importar desde un origen más nuevo a un destino más antiguo puede fallar por sintaxis, características o reglas de comparación no disponibles. Cambiar entre MySQL y MariaDB tampoco debe darse por validado automáticamente.

La comprobación inicial debe señalar riesgos. Después, el informe debe distinguir los avisos de un fallo real: una base de datos que no se ha importado no puede presentarse como restaurada correctamente.

4. Restaura por sitios y registra cada resultado

Un proceso masivo necesita resultados individuales. Si una suscripción encuentra un problema, debe quedar identificada y permitir continuar con las demás cuando sea seguro. Al terminar, separa sitios recuperados, sitios con avisos y operaciones fallidas o incompletas.

El sistema Backup para Plesk de ALMC centraliza la gestión de estas operaciones y su seguimiento. La configuración recuperable depende de lo incluido en la copia; no equivale a clonar íntegramente el sistema operativo del servidor.

No marques el conjunto como «todo correcto» porque el proceso haya llegado al final. Conserva el detalle de lo que se intentó, lo que se completó y lo que necesita intervención.

5. Prueba las aplicaciones antes de devolverles el tráfico

Ver una portada no basta. Usa un entorno o método de previsualización controlado y comprueba, según el sitio:

• La página principal, páginas internas, imágenes y archivos descargables.
• Acceso al administrador y conexión a la base de datos.
• Formularios y envíos, evitando correos o cobros reales durante la prueba.
• Certificado SSL, redirecciones y URLs absolutas.
• Tareas programadas, colas e integraciones que deban reactivarse por separado.

Si hay procesamiento de pagos o sincronizaciones, evita que origen y destino ejecuten a la vez operaciones que puedan duplicarse. Define el momento en que el destino pasa a ser el sistema autorizado para aceptar cambios.

6. Coordina el cambio de DNS fuera de la restauración

La restauración de Backup de ALMC no repone la zona DNS. Si el alojamiento cambia de dirección, el responsable debe preparar y aplicar los ajustes necesarios en el proveedor DNS, tras las comprobaciones. Ten en cuenta cachés y propagación: no todos los visitantes cambiarán de destino al mismo tiempo.

Revisa también servicios externos vinculados a la antigua IP, restricciones de acceso y callbacks. Son tareas de continuidad del servicio, aunque no formen parte del archivo de backup.

7. Cierra la incidencia con un informe y una nueva copia

Entrega un resumen por sitio: punto utilizado, resultado, advertencias de versiones y acciones pendientes. Comprueba que las nuevas copias se ejecutan desde el servidor recuperado y llegan al repositorio previsto. Conserva las copias anteriores según la política acordada; no las retires precipitadamente.

La verificación mediante restauraciones de prueba también forma parte de las recomendaciones de la guía de creación de copias de INCIBE. Ensayar este recorrido permite detectar dependencias que un simple listado de archivos no muestra.

Prepara la recuperación antes de la caída

Conoce Backup de ALMC, revisa sus planes de almacenamiento y solicita una propuesta para tu infraestructura. El alcance, el soporte y los objetivos de recuperación deben quedar acordados para tu entorno; esta guía no supone una garantía de tiempo de restauración.