El hosting migró de servidor y perdió dos meses de datos

En junio de 2025 Gustavo lanzó un aviso en el grupo: «Os recuerdo hacer copias de seguridad en vuestro ordenador». Un hosting había cambiado de servidor a un cliente suyo y, al terminar, la tienda tenía datos de hacía más de un mes. Al final se confirmó: dos meses perdidos. Lo contamos porque todos los fallos eran evitables.

Qué pasó

1. El hosting hizo una primera prueba de migración y no volvió a sincronizar los datos.
2. Un domingo cambió el servidor sin avisar a nadie que pudiera comprobarlo.
3. El servidor viejo caducó y se eliminó sin confirmar antes que el nuevo estaba bien.
4. Tampoco se actualizaron las DNS: la tienda estuvo unas 24 horas sin web.

El cliente tenía copias, pero eran las internas del panel, en el mismo servidor que desapareció. Gustavo conservaba una de dos meses antes. Su conclusión, cuando se aclaró todo: no fue solo culpa del hosting, sino un cúmulo de fallos de comunicación entre el hosting, el informático del cliente y las demás partes, de no conocer los pasos y de dejar pasar el tiempo hasta que el servidor viejo caducó.

Las copias del panel no son una copia

Una copia que vive en el mismo servidor que la tienda se pierde con él. Necesitas al menos una copia fuera del servidor: descargada por FTP a tu ordenador o enviada a otro almacenamiento. Gustavo manda a sus clientes vídeos que explican cómo hacer sus propias copias, para que no dependan de nadie.

En mayo otro compañero había compartido un guion de copia de la base de datos y las imágenes que avisaba por Telegram al terminar. Si usas algo así, que esté fuera de la carpeta pública, con las contraseñas en un fichero aparte y con permisos restringidos, y que borre las copias antiguas para no llenar el disco.

Antes de que el hosting migre tu servidor

• Pide la fecha y la hora del cambio, por escrito.
• Haz tu propia copia completa (ficheros y base de datos) justo antes, y guárdala fuera.
• Si puedes, congela los cambios en el back-office durante el traslado.
• Después, comprueba que el último pedido y el último cliente están en el servidor nuevo.
• No dejes que borren el servidor viejo hasta haberlo comprobado. Fue lo que más le extrañó a Gustavo.
• Revisa que las DNS apuntan al servidor nuevo.

Quién se encarga de las copias

Gustavo daba soporte de PrestaShop a ese cliente, pero no las copias: el cliente era muy estricto con las horas y no quería pagar trabajos que no hubiera pedido. Aun así, alguien podía pensar que era cosa suya. Déjalo por escrito: quién hace las copias, cada cuánto y dónde se guardan. Y si el hosting avisa de un cambio de servidor, que avise también a quien lleva la tienda.

Y enterarte cuando la web se cae

Por las mismas fechas otro compañero contaba que un cliente estuvo unas siete horas con un error 503 un sábado sin que nadie se enterase. Empezó a probar un monitor de disponibilidad (UptimeRobot; de momento le bastaba el plan gratuito). Lo importante es que el aviso te llegue a ti antes que la queja del cliente.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación