Cómo restaurar WordPress desde un backup sin perder datos

Qué significa restaurar un backup sin perder datos en WordPress

En WordPress, “no perder datos” no significa solo que el sitio vuelva a cargar. Significa conservar el contenido y la operativa que importa: entradas y páginas, medios, usuarios, formularios, pedidos de WooCommerce, configuraciones de plugins, y cambios recientes. La dificultad es que esos datos viven repartidos entre la base de datos y los archivos, y además dependen de la configuración del servidor (PHP, cachés, permisos) y del dominio (URL, SSL, DNS).

Una restauración correcta suele ser una restauración coherente. Es decir, la base de datos y el directorio wp-content deben corresponder al mismo punto en el tiempo, y la configuración debe apuntar al mismo entorno. Si restaura solo una parte, o mezcla copias de fechas distintas, es habitual que “parezca” que faltan datos cuando en realidad hay desajustes de referencias, rutas, URLs o tablas.

• Identifique qué datos son críticos para su negocio: pedidos, leads, reservas, contenidos recientes y usuarios.
• Diferencie entre restauración completa (archivos y base de datos) y restauración parcial (solo base de datos o solo archivos).
• Compruebe el punto temporal del backup y si es completo, incremental o dependiente de otro conjunto.
• Planifique una ventana de intervención y un método de reversión si la restauración falla.
• Evite restaurar directamente en producción si puede validar antes en un entorno de staging.

Diagnóstico inicial y señales útiles antes de restaurar

Antes de restaurar, conviene confirmar si el problema requiere realmente volver atrás o si puede resolverse con una corrección menor. Restaurar sin diagnóstico puede borrar datos recientes o reintroducir un fallo. El diagnóstico inicial debe ser prudente y reversible, y centrarse en señales verificables: errores, cambios recientes y avisos del hosting o de herramientas de monitorización.

Si el sitio está caído, priorice recopilar evidencias y evitar acciones que empeoren la situación, como reinstalar plugins a ciegas o “limpiar” archivos sin copia. Si el sitio funciona pero hay pérdida de datos, determine si la pérdida es real (datos no existen en base de datos) o aparente (caché, URLs, permisos, rutas de medios).

• Registre el síntoma exacto: error 500, 502/504, pantalla en blanco, bucle de login, “Error establishing a database connection”, o mensajes de PHP.
• Revise cambios recientes: actualizaciones de WordPress, tema o plugins, cambios en functions.php, o ajustes de caché.
• Compruebe alertas: avisos del hosting (límite de CPU/IO), caídas, bloqueos por seguridad, o cambios de versión de PHP.
• Consulte Search Console si aplica: avisos de seguridad, problemas de indexación o picos de 404 tras cambios de URLs.
• Haga comprobaciones prudentes: desactivar caché a nivel de plugin si tiene acceso, revisar wp-config.php sin editarlo, y capturar logs si el hosting los ofrece.

Causas habituales de pérdida de datos y cómo confirmarlas

Las pérdidas de datos tras una restauración suelen tener causas repetibles: restauraciones parciales, copias incompletas, desajustes de URL, tablas faltantes o corrupción, y diferencias de entorno. Confirmarlas requiere comparar fechas, tamaños y coherencia entre base de datos y archivos, y validar que el backup contiene lo necesario para su caso.

También es habitual que el backup sea correcto, pero la restauración se haya hecho en un entorno distinto (otro dominio, subdirectorio, cambio de hosting) sin ajustar la URL del sitio o sin regenerar enlaces permanentes. En esos casos, el contenido puede estar, pero no se muestra o no se enlaza bien.

• Backup incompleto: falta la base de datos o falta wp-content/uploads (medios) o el tema activo.
• Desfase temporal: base de datos de una fecha y archivos de otra, típico en copias incrementales mal aplicadas.
• URLs desajustadas: cambio de dominio, http a https, o cambio de ruta; confirme valores de siteurl y home.
• Tablas ausentes o dañadas: especialmente en sitios con WooCommerce o plugins que crean tablas propias.
• Restauración sobre un sitio “vivo”: se pisan datos nuevos (pedidos, formularios) porque no se congeló la operativa.

Seguridad: restaurar sin reintroducir malware o spam

Restaurar desde un backup no siempre “limpia” un sitio. Si la copia se hizo cuando ya existía una intrusión, puede reintroducir puertas traseras, inyecciones en la base de datos o usuarios maliciosos. Por eso, la restauración debe incluir medidas de contención y verificación, especialmente si hubo síntomas de spam, redirecciones extrañas o alertas de seguridad.

Los vectores más habituales en WordPress son plugins o temas vulnerables, credenciales filtradas, permisos de archivos demasiado permisivos y modificaciones directas en archivos del tema. La respuesta razonable no es el alarmismo, sino un proceso: copia, restauración controlada, rotación de credenciales y revisión de integridad.

• Revise síntomas: redirecciones a dominios desconocidos, contenido spam, usuarios administradores no reconocidos, o cambios en .htaccess.
• Rote credenciales tras restaurar: WordPress, FTP/SFTP, panel del hosting, base de datos y cuentas de correo asociadas.
• Compruebe usuarios y roles: elimine cuentas sospechosas y revise la fecha de creación y el correo asociado.
• Aplique hardening básico: permisos correctos, desactivar edición de archivos desde el panel si procede, y limitar intentos de acceso según su entorno.
• Evite “limpiezas” sin copia: primero preserve evidencia (backup del estado actual) y luego actúe con método.

Rendimiento y estabilidad tras la restauración

Después de restaurar, es común notar lentitud, errores intermitentes o comportamientos inconsistentes. No siempre es un fallo del backup. Puede deberse a cachés desincronizadas, tareas programadas acumuladas, índices de base de datos, o a que el entorno de PHP y extensiones no coincide con el que tenía el sitio cuando se generó la copia.

La estabilidad se valida con pruebas repetibles y con observación de recursos. Si el hosting limita CPU, memoria o procesos, una restauración puede disparar tareas de regeneración (miniaturas, cachés, transients) y provocar picos. En ese caso conviene planificar la restauración en horas de menor tráfico y monitorizar.

• Vacíe cachés de forma controlada: plugin de caché, caché de servidor y, si existe, caché de CDN.
• Revise errores de PHP y memoria: aumentos puntuales de consumo tras restaurar pueden causar 500 o timeouts.
• Compruebe la carga de tareas programadas: colas de correo, importadores o procesos de WooCommerce.
• Valide enlaces permanentes y reglas de reescritura: una restauración puede dejar reglas antiguas.
• Haga pruebas de navegación y compra: home, categorías, buscador, checkout, formularios y área de usuario.

Plugins, temas y actualizaciones: restauración con staging

La restauración suele estar relacionada con una actualización fallida o un conflicto entre plugins y tema. En esos casos, restaurar “a antes” puede ser correcto, pero solo si después se gestiona el cambio que provocó el fallo. Si no, el problema se repetirá en la siguiente actualización o al reactivar el mismo plugin.

La buena práctica es validar en un entorno de staging: restaurar allí el backup, reproducir el error, aplicar correcciones y documentar qué cambió. En producción, el objetivo es minimizar el tiempo de caída y evitar cambios irreversibles. Si su proveedor no ofrece staging, puede montarse en un subdominio o entorno aislado, pero la configuración concreta varía según hosting.

• Use staging para probar restauraciones y actualizaciones: reduce riesgo y mejora la trazabilidad.
• Controle cambios: anote versiones de WordPress, tema, plugins y PHP antes y después.
• Gestione conflictos: desactive plugins de forma ordenada y verifique el impacto en funcionalidades críticas.
• Evite editar en caliente: cambios en functions.php o snippets deben versionarse y probarse.
• Tras restaurar, actualice con criterio: primero seguridad crítica, luego compatibilidad, y siempre con copia previa.

Hosting, dominio y correo en España: DNS, SSL y recursos

En una restauración, el hosting y el dominio influyen más de lo que parece. En España es habitual encontrar combinaciones de paneles de control, cachés de servidor, WAF, reglas anti bots y configuraciones de PHP que cambian con el tiempo o tras migraciones. Si restaura un backup en un servidor con otra versión de PHP o con límites distintos, pueden aparecer errores que no existían cuando se creó la copia.

También hay dependencias externas: DNS, certificados SSL, CDN y correo transaccional. Una restauración puede coincidir con un cambio de IP o de registros DNS, y provocar que parte de los usuarios vean el sitio antiguo durante horas. Esto no es un fallo de WordPress, sino propagación y cachés, y varía según proveedor y configuración.

• DNS y propagación: confirme A/AAAA, CNAME y TTL; los tiempos pueden variar según resolvers y proveedor.
• SSL y redirecciones: verifique que el certificado está activo y que no hay bucles http/https tras restaurar.
• Versión de PHP y extensiones: una diferencia puede romper plugins o generar avisos y errores fatales.
• Límites de recursos: memoria, procesos, IO y tiempo de ejecución; una restauración puede disparar picos.
• Correo transaccional: revise que formularios y WooCommerce envían emails; depende de la política del hosting y de su configuración.

Pruebas, accesos y documentación para una restauración trazable

Para restaurar sin perder datos, la diferencia entre improvisar y actuar con control es la documentación mínima. No se trata de burocracia, sino de poder volver atrás, comparar estados y demostrar qué se cambió. Esto reduce tiempos de caída y evita repetir restauraciones por falta de información.

Antes de tocar nada, reúna accesos y evidencias. Si trabaja con un tercero o con soporte del hosting, esta información acelera el diagnóstico. Si no dispone de algún acceso, adapte el plan a lo que sí puede verificar, y evite acciones destructivas.

• Trazabilidad de cambios recientes: registro de actualizaciones (qué se actualizó y cuándo), lista de plugins activos y tema, y revisión de changelog cuando exista.
• Evidencias técnicas: logs de errores (PHP y servidor si están disponibles), capturas del error, y URLs exactas afectadas.
• Inventario de backups: fecha, tipo (completo o incremental), ubicación, y si incluye base de datos y wp-content.
• Export de base de datos antes de restaurar: aunque sea para comparación o recuperación selectiva posterior.
• Accesos necesarios: panel de WordPress, SFTP/FTP, panel del hosting, y acceso a base de datos (según su proveedor).

Plan de acción ordenado para restaurar sin perder datos

Un plan ordenado reduce el riesgo de pérdida de datos y acorta el tiempo de caída. La idea es contener, copiar, restaurar con coherencia, verificar y monitorizar. Si su sitio recibe pedidos o leads, el punto crítico es evitar que entren datos nuevos mientras se restaura, o al menos registrarlos para no perderlos.

La ejecución exacta depende del método de backup (plugin, copia del hosting, copia manual) y del acceso disponible. En general, es preferible restaurar primero en staging, validar y luego aplicar en producción. Si no es posible, al menos asegure una copia del estado actual antes de sobrescribir nada.

• Contención: active modo mantenimiento si procede y reduzca cambios mientras se interviene.
• Copia del estado actual: export de base de datos y copia de archivos antes de restaurar, aunque el sitio esté roto.
• Restauración coherente: restaure base de datos y wp-content del mismo punto temporal; evite mezclar fechas.
• Ajustes post restauración: verifique URL del sitio, enlaces permanentes, permisos, y vaciado de cachés.
• Verificación y monitorización: pruebas funcionales, revisión de logs, y observación de recursos durante las horas siguientes.

Si ya se ha tocado algo o hay urgencia: cómo minimizar daños

En escenarios reales, muchas restauraciones empiezan con urgencia y con acciones parciales: se restauró solo la base de datos, se cambió de hosting, se borró un plugin crítico o se tocó código del tema. En ese punto, el objetivo es recuperar control y evitar perder evidencia técnica que permita entender qué pasó.

Si ya ha intervenido, no intente “arreglarlo todo” a la vez. Documente lo que se hizo, preserve el estado actual con una copia, y vuelva a un proceso ordenado. Si sospecha de malware, evite reinstalar componentes sin identificar la causa, porque puede reactivar la intrusión.

• Se instaló un plugin de seguridad: revise qué cambió (bloqueos, reglas, permisos) y si está impidiendo el acceso legítimo.
• Se restauró una copia parcial: identifique qué falta (base de datos o archivos) y evite restaurar “encima” sin copia del estado actual.
• Se cambió de hosting: confirme DNS, SSL, versión de PHP, límites y cachés; los síntomas pueden ser de entorno, no de WordPress.
• Se tocó functions.php o snippets: recupere el archivo anterior desde el backup y active depuración para localizar el error.
• Se intentó limpiar malware sin copia: haga una copia del estado actual igualmente y conserve logs; puede ser clave para cerrar el vector de entrada.

Preguntas frecuentes

Estas dudas aparecen con frecuencia al restaurar WordPress desde un backup. Si su caso implica cambios de hosting, dominio o seguridad, los detalles pueden variar según configuración.

P: ¿Puedo restaurar solo la base de datos para recuperar contenido sin tocar archivos?

R: A veces sí, pero es arriesgado si el tema o los plugins guardan configuraciones en archivos o si hay dependencias en wp-content. Lo habitual es validar primero en staging y comprobar coherencia entre tablas y versiones de plugins.

P: ¿Cómo evito perder pedidos o formularios recientes si tengo que restaurar?

R: Lo más seguro es congelar la operativa durante la ventana de restauración o registrar los datos entrantes por otra vía. Además, conviene hacer una exportación de la base de datos actual antes de sobrescribir, para intentar recuperar registros recientes si fuera necesario.

P: Tras restaurar, el sitio carga pero faltan imágenes, ¿qué suele ser?

R: Suele indicar que no se restauró wp-content/uploads, que hay permisos incorrectos, o que la URL base cambió y los enlaces a medios apuntan a otra ruta. También puede ser caché o CDN sirviendo versiones antiguas.

P: ¿Qué hago si la restauración provoca un bucle de redirecciones o problemas con https?

R: Revise la URL del sitio y del inicio, el estado del certificado SSL y las reglas de redirección en servidor o plugin. En cambios de hosting o proxy, la detección de https puede variar y requerir ajustes específicos.

P: ¿Restaurar un backup elimina malware automáticamente?

R: No necesariamente. Si el backup se generó cuando el sitio ya estaba comprometido, restaurarlo puede reintroducir la infección. Tras restaurar, es recomendable rotar credenciales, revisar usuarios y corregir el vector de entrada, como un plugin vulnerable.