Cómo Restaurar un Backup de WordPress Paso a Paso

Saber que tienes backups y saber restaurarlos bajo presión son dos cosas muy distintas. El peor momento para aprender el proceso de restauración es precisamente cuando ya lo necesitas con urgencia, con tu web caída y el reloj corriendo.

Esta guía te da el proceso completo de restauración, para que cuando llegue el momento (si llega), sepas exactamente qué hacer sin improvisar.

Para entender qué backups deberías tener antes de necesitar restaurar nada, consulta Backups y Recuperación de WordPress: Guía Completa.

Antes de restaurar: identifica el punto correcto

No siempre conviene restaurar el backup más reciente. Si el problema ya estaba presente cuando se generó ese backup (por ejemplo, una infección de malware que llevaba días activa), restaurarlo simplemente trae de vuelta el mismo problema. Identifica el backup más reciente que sea anterior al origen del problema, no el más reciente en términos absolutos.

Para localizar ese punto, ayuda tener claro cuándo empezó el síntoma: cuándo dejó de funcionar el checkout, cuándo apareció el mensaje raro en la home, cuándo un plugin marcó una alerta. Ese momento es tu línea divisoria: quieres el backup inmediatamente anterior, no el de justo después. Si dudas entre dos copias, empieza por la más antigua de las candidatas; siempre puedes avanzar hacia una más reciente si esa resultó estar sana, pero no puedes deshacer haber traído de vuelta el problema.

Paso previo imprescindible: haz un backup del estado actual

Este es el paso que casi todo el mundo se salta con las prisas, y el que más veces convierte una incidencia recuperable en un desastre. Antes de sobrescribir nada, haz una copia del estado actual de la web, por roto que esté. ¿Por qué guardar algo que no funciona? Por dos razones concretas:

• Si el backup que vas a restaurar resulta estar corrupto o ser el punto equivocado, sin la copia del estado actual te quedas sin web y sin backup, el peor de los mundos.
• El estado actual, aunque roto, puede contener datos posteriores al backup que quieras rescatar después (pedidos, comentarios, un formulario recibido esta mañana). Una vez sobrescribes, eso desaparece.

Además, antes de empezar: pon la web en modo mantenimiento si sigue accesible (para que nadie compre ni registre datos que vas a perder al restaurar) y avisa a tu equipo de que va a haber una ventana de indisponibilidad. Restaurar en producción con usuarios entrando en mitad del proceso es pedir problemas.

Restaurar con un plugin de backup

La mayoría de instalaciones usan un plugin específico de backup, que suele seguir este flujo:

1. Accede al panel del plugin de backup desde wp-admin (si el panel sigue accesible) o desde una instalación limpia temporal de WordPress apuntando al mismo backup si el sitio está completamente caído.
2. Selecciona el backup correspondiente a la fecha identificada como punto de restauración correcto.
3. Elige restaurar tanto archivos como base de datos, salvo que tengas un motivo específico para restaurar solo uno de los dos componentes.
4. Confirma la restauración y espera a que el proceso complete, no interrumpas el proceso a mitad, ya que puede dejar la instalación en un estado inconsistente.

Restaurar manualmente vía FTP y base de datos

Si no tienes un plugin de backup activo, o el panel de WordPress no es accesible, la restauración manual requiere más pasos:

Restaurar los archivos

Sube los archivos del backup a tu servidor vía FTP/SFTP, sobrescribiendo la instalación actual. Asegúrate de mantener la misma estructura de carpetas que tenía la instalación original.

Dos detalles que fallan a menudo en la restauración manual de archivos:

• Permisos y propietario. Tras subir por FTP, los archivos pueden quedar con permisos o dueño incorrectos y WordPress dar errores o directamente no cargar. El patrón habitual es 755 para directorios y 644 para archivos, con wp-config.php más restrictivo (640 o 600). Si tienes SSH, puedes normalizarlos de golpe:

find /ruta/al/wordpress -type d -exec chmod 755 {} \;
find /ruta/al/wordpress -type f -exec chmod 644 {} \;

• Restaura lo que cambia, no siempre todo. El núcleo de WordPress es idéntico en cualquier instalación de la misma versión: puedes descargarlo limpio de wordpress.org en lugar de subirlo del backup. Lo que de verdad es único de tu web vive en wp-content (tema, plugins, subidas) y en wp-config.php. Si el backup solo trae eso, no pasa nada: reinstala el core limpio y coloca encima tu wp-content.

Restaurar la base de datos

mysql -u usuario -p nombre_base_datos < backup.sql

Este comando (ejecutado con acceso SSH) importa el archivo de backup de la base de datos, sobrescribiendo el contenido actual. Verifica antes que el archivo de backup corresponde a la versión correcta y no está corrupto, un archivo .sql incompleto puede fallar a mitad de la importación, dejando la base de datos en un estado parcial.

Un matiz que provoca restauraciones “a medias”: importar sobre una base de datos que ya tiene tablas no siempre las reemplaza limpiamente. Si el volcado no incluye instrucciones de tipo DROP TABLE, puedes acabar con datos mezclados del estado anterior y del backup. Lo más seguro es importar sobre una base de datos vacía: vaciar la actual (o crear una nueva) y luego importar el .sql. Con WP-CLI el flujo es más limpio, porque resetea antes de importar:

wp db reset --yes
wp db import backup.sql

Otro punto que rompe importaciones grandes: el tamaño. Subir un .sql de varios cientos de MB por phpMyAdmin suele chocar contra los límites de subida o el tiempo máximo de ejecución de PHP, y la importación muere a mitad. Para bases de datos grandes, importa siempre por SSH con mysql o WP-CLI, no por la interfaz web. Si tampoco tienes SSH, .sql comprimido y herramientas del panel pensadas para archivos grandes son la alternativa.

También conviene comprobar que el prefijo de tablas del backup (por defecto wp_, pero muchas instalaciones lo cambian por seguridad) coincide con el que espera tu wp-config.php. Si no coincide, WordPress importa los datos pero no los encuentra, y ves una instalación “vacía” pese a que las tablas están ahí.

Actualizar wp-config.php si es necesario

Si estás restaurando en un servidor distinto al original (por ejemplo, tras un fallo completo del hosting anterior), verifica que las credenciales de base de datos en wp-config.php coinciden con las del nuevo entorno:

define('DB_NAME', 'nombre_base_datos');
define('DB_USER', 'usuario_bd');
define('DB_PASSWORD', 'contraseña_bd');
define('DB_HOST', 'localhost');

Verificación posterior: no des la restauración por completa sin comprobar

Tras restaurar, verifica sistemáticamente:

• La home y páginas clave cargan correctamente
• El contenido corresponde a la fecha esperada del backup restaurado
• Los formularios funcionan y envían correctamente
• Si hay WooCommerce, el catálogo de productos y el checkout funcionan
• No hay errores en el log de PHP tras la restauración
• Los enlaces internos y el menú principal funcionan correctamente

Qué método de restauración elegir

No hay un único camino: el método depende de qué backup tengas y de si aún puedes entrar a WordPress. Esta tabla resume cuándo usar cada uno:

Método	Cuándo es la mejor opción	Requiere	A tener en cuenta
Plugin de backup	Tienes el plugin instalado y wp-admin accesible	Acceso a wp-admin	Es el más simple; automatiza archivos + base de datos a la vez
Manual por FTP + SQL	No hay plugin, o wp-admin no carga	FTP/SFTP y acceso a la base de datos	Más pasos y más control; cuidado con permisos y prefijo de tablas
Snapshot del hosting	La cuenta está muy dañada o WordPress no arranca	Panel del hosting (cPanel/Plesk)	Restaura toda la cuenta; menos granular, puede sobrescribir más de lo que quieres
Soporte del hosting	No tienes acceso técnico ni SSH	Abrir un ticket	Dependes de sus tiempos; útil como último recurso

Caso WooCommerce: cuidado con lo que se pierde entre backup y ahora

Restaurar una tienda tiene un matiz que no tiene un blog: entre el momento del backup y el momento de restaurar pueden haber entrado pedidos reales. Al restaurar un backup anterior, esos pedidos desaparecen de la base de datos, con todo lo que implica (clientes que han pagado y cuyo pedido ya no consta). Antes de restaurar una tienda, revisa qué pedidos hay desde la fecha del backup y guárdalos aparte (exportándolos o anotándolos) para poder reintroducirlos después. Es justo el escenario por el que en una tienda la frecuencia de backup de base de datos debe ser mucho mayor que en una web informativa. Lo tratamos en detalle en Backup de WooCommerce sin perder pedidos.

Qué hacer si la restauración no soluciona el problema

Si tras restaurar el problema persiste, puede indicar que:

• El backup restaurado ya contenía el problema (elige un punto anterior).
• El problema no estaba en el contenido de WordPress sino en la configuración del servidor (versión de PHP, configuración de Apache/Nginx), que un backup de WordPress no cubre.
• Hay un problema de compatibilidad entre el backup y el entorno actual (por ejemplo, restaurar en una versión de PHP muy distinta a la que tenía el backup original).

Restaurar en un entorno distinto al original

Si estás restaurando por haber cambiado de hosting o por una migración de emergencia, ten en cuenta que las URLs internas de la base de datos pueden seguir apuntando al dominio o servidor original. Herramientas como WP-CLI permiten corregir esto:

wp search-replace 'https://dominio-original.com' 'https://nuevo-dominio.com' --path=/ruta/al/wordpress

Sin este paso, los enlaces internos, las imágenes y las llamadas a recursos seguirán apuntando a la ubicación original, generando errores o contenido roto tras la restauración.

Aquí hay un error clásico que conviene evitar: no hagas ese reemplazo con un buscar-y-reemplazar sobre el .sql a mano ni con una consulta SQL genérica. WordPress guarda muchos ajustes (opciones de tema, widgets, configuraciones de plugins) en formato serializado, y ese formato incluye la longitud exacta de cada cadena. Si cambias dominio-original.com por otro dominio de distinta longitud con un reemplazo bruto, esos contadores dejan de cuadrar y los datos serializados se corrompen: widgets que desaparecen, ajustes que se pierden. wp search-replace entiende la serialización y recalcula las longitudes; por eso es la vía correcta. Si no tienes WP-CLI, existen scripts específicos de búsqueda-y-reemplazo serialization-safe para hacer exactamente esto.

Después de restaurar: limpia lo que quedó cacheado

Una restauración puede dejar rastros de la configuración anterior en cachés que muestran una web “rota” que en realidad ya está bien. Antes de dar nada por perdido, limpia:

• La caché de la web (plugin de caché y, si hay, caché de objetos como Redis/Memcached). Contenido viejo servido desde caché es la causa número uno de “he restaurado y sigo viendo lo mismo”.
• Los permalinks: entra en Ajustes → Enlaces permanentes y pulsa Guardar (sin cambiar nada) para regenerar las reglas de reescritura. Tras una restauración es habitual que las entradas den 404 hasta hacer esto.
• La caché de tu CDN, si usas una, para que no siga sirviendo assets de antes.

Preguntas Frecuentes

¿Cuánto tiempo tarda una restauración completa? Depende del tamaño de la web y del método usado, pero para una instalación de tamaño medio suele oscilar entre 15 minutos y varias horas si se hace manualmente.

¿Puedo restaurar solo la base de datos sin tocar los archivos? Sí, si el problema es específicamente de contenido y los archivos (plugins, tema) siguen intactos y funcionando correctamente.

¿Qué pasa si mi backup no incluye la base de datos, solo los archivos? La restauración recuperará el diseño y la estructura, pero no el contenido, es precisamente el motivo por el que un backup debe incluir siempre ambos componentes de forma coordinada.

¿Debo avisar a mi equipo antes de restaurar en producción? Sí, si la web está en uso activo, la restauración puede requerir una breve ventana de indisponibilidad, y el contenido posterior al backup restaurado se perderá si no se ha guardado aparte.

¿Restaurar un backup antiguo hace perder el contenido publicado después de esa fecha? Sí, cualquier contenido creado después de la fecha del backup restaurado se pierde, salvo que lo hayas guardado o documentado aparte antes de la restauración.

¿Puedo automatizar completamente el proceso de restauración? Parcialmente, muchos plugins de backup automatizan gran parte del proceso técnico, pero la decisión de qué backup restaurar y la verificación posterior siempre requieren criterio humano.

¿Qué hago si no tengo acceso SSH y el panel de WordPress no funciona? Contacta con el soporte de tu hosting, la mayoría puede ayudarte a restaurar backups directamente desde su panel de control, incluso sin acceso a wp-admin.

¿Es necesario probar la restauración en staging antes de hacerlo en producción? Si el tiempo lo permite, sí, reduce el riesgo de que la restauración introduzca un problema nuevo. En una emergencia con la web completamente caída, puede no haber tiempo para este paso intermedio.

He restaurado y sigo viendo la web rota igual que antes. ¿Falló la restauración? No necesariamente. Lo primero es descartar caché: limpia la caché del plugin, la de objetos (Redis/Memcached) y la del CDN si usas uno. Es muy habitual que la restauración funcionara y estés viendo la versión antigua servida desde caché. Si tras limpiar sigue igual, entonces sí revisa si el backup era el punto correcto.

Las entradas dan error 404 después de restaurar. ¿Qué hago? Entra en Ajustes → Enlaces permanentes y pulsa Guardar sin cambiar nada. Eso regenera las reglas de reescritura, que a menudo quedan desincronizadas tras una restauración y provocan justo ese 404 en las entradas.

¿Por qué mis widgets y ajustes del tema aparecen vacíos tras cambiar de dominio? Casi seguro que el reemplazo de URLs se hizo con un buscar-y-reemplazar bruto sobre el SQL, que corrompe los datos serializados de WordPress. Hay que rehacerlo con wp search-replace o una herramienta serialization-safe, que recalcula bien las longitudes de las cadenas.

¿Puedo restaurar solo wp-content sin tocar el resto? Sí, y a menudo es lo más limpio: el núcleo de WordPress es reinstalable desde cero, así que restaurar wp-content (tema, plugins, subidas) más la base de datos suele bastar. Eso sí, asegúrate de que la versión de WordPress del core coincide con la que esperaban ese tema y esos plugins.

Conclusión

Restaurar un backup no es solo “subir archivos viejos”: es un proceso con pasos concretos que, hechos en el orden correcto, marcan la diferencia entre recuperar tu web en minutos o pasar horas resolviendo problemas adicionales generados por una restauración mal hecha.

Si prefieres no tener que ejecutar este proceso bajo presión la primera vez que lo necesites, en Avantys lo llevamos con backups verificados y un protocolo de restauración probado dentro de Gestión WordPress.

Artículos relacionados

• Backups y recuperación de WordPress: guía completa
• Backups automáticos vs manuales en WordPress
• Qué hacer si pierdes tu web WordPress y no tienes backup
• Errores críticos de WordPress y cómo solucionarlos
• Cómo migrar WordPress a otro hosting sin perder SEO

---