Has restaurado una copia y WordPress sigue fallando, muestra contenido antiguo o se comporta de forma extraña. No repitas el proceso a ciegas: conserva el estado actual, identifica el síntoma y evita mezclar archivos y base de datos de fechas distintas, porque podrías sobrescribir pedidos, formularios, usuarios o cambios recuperables.
Los errores al restaurar backups de WordPress suelen deberse a copias incoherentes, credenciales incorrectas, versiones incompatibles o permisos del servidor. Revisa el mensaje visible y los registros antes de restaurar otra vez.
Índice
Anuncio
Diagnostica el síntoma antes de tocar otra copia
Identifica el mensaje visible y consulta los registros antes de restaurar de nuevo. En cPanel o Plesk, abre Errores, error_log o los logs del servidor; por SFTP, busca error_log en la carpeta principal. Revisa las últimas líneas, apunta la hora, el archivo citado y el texto exacto: una pantalla blanca, un error 500 y un error de base de datos requieren acciones diferentes.
| Síntoma | Comprobación en menos de 5 min | Acción segura | Cuándo escalar |
|---|---|---|---|
| Pantalla blanca | Mira `wp-content/debug.log` | Desactiva un plugin renombrando su carpeta | Si falla el núcleo de WordPress |
| Error 500 | Lee `error_log` y revisa `.htaccess` | Renombra `.htaccess` y prueba | Si el log cita Apache o Nginx |
| Error de base de datos | Compara `wp-config.php` con phpMyAdmin | Corrige nombre, usuario, clave o host | Si MySQL o MariaDB no responde |
| Dominio antiguo | Abre `wp_options` en phpMyAdmin | Cambia `home` y `siteurl` | Si hay redirecciones ajenas |
Lee el error 500 en su origen
Revisa el log antes de cambiar PHP o reinstalar archivos. Renombra .htaccess a .htaccess-antiguo y recarga una vez; si WordPress abre, guarda los enlaces permanentes para crear un archivo nuevo. Si el log indica Allowed memory size, aumenta el límite de memoria PHP desde el hosting o solicita entre 128 MB y 256 MB.
Comprueba la pantalla blanca sin exponer datos
Activa el registro de depuración sin mostrar errores a los visitantes. En wp-config.php, antes de That's all, añade define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true); y define('WP_DEBUG_DISPLAY', false);. Carga una página, abre wp-content/debug.log y renombra únicamente la carpeta del plugin citado dentro de wp-content/plugins. Consulta la guía de depuración de WordPress si necesitas interpretar el registro.
Restaura archivos y base de datos del mismo punto
Une archivos y base de datos de la misma fecha y hora para recuperar un sitio coherente. La copia debe incluir archivos de WordPress, wp-content, uploads, temas, plugins y el volcado SQL. Antes de importar, compara las fechas del ZIP y SQL, confirma que pertenecen al mismo punto completo y revisa las versiones de WordPress, PHP y MySQL o MariaDB usadas por esa copia.
No combines SQL y archivos de fechas distintas
Comprueba que el SQL y wp-content proceden del mismo punto de restauración. Revisa el historial del proveedor, UpdraftPlus, Duplicator o WPvivid y anota fecha, hora y tipo de copia. Si el backup es incremental, necesitas toda la cadena: restaurar solo el último archivo puede dejar archivos, imágenes o tablas incompletos.
Mantén las versiones mientras investigas
Conserva la versión de PHP y los plugins hasta saber qué causó el fallo. No cambies PHP, WordPress, tema o plugins durante la restauración: un tema antiguo puede fallar en PHP 8.2 aunque la copia sea correcta. Siempre que sea posible, prueba primero en staging, bloqueando correos e indexación para evitar efectos sobre clientes o buscadores.
Además, antes de restaurar una copia de seguridad de WordPress, verifica que el archivo se descargó completo y que contiene tanto el volcado SQL como los directorios necesarios. Un ZIP que abre no garantiza que sea utilizable: comprueba su tamaño frente al historial del proveedor, extrae una copia en local y confirma que incluye wp-content/uploads, temas y plugins de WordPress. Si el backup se creó mediante una tarea programada, revisa el registro de esa tarea para detectar límites de espacio, cortes durante la subida o exportaciones SQL incompletas.
Cuando el proveedor ofrezca checksum, manifiesto o verificación de integridad, compáralo antes de sobrescribir producción. Esta comprobación evita intentar restaurar una copia de seguridad de WordPress a partir de un archivo aparentemente válido pero incompleto.
Anuncio
Conserva los datos y prepara un rollback real
Guarda el estado roto antes de sobrescribir producción para poder volver atrás sin perder información reciente. Exporta la base completa desde phpMyAdmin y descarga por SFTP wp-content/uploads; aunque la web no cargue, puede contener pedidos, formularios, registros o pruebas de seguridad relevantes. Un rollback real requiere dos copias: la antigua que probarás y una copia nueva del estado actual.
Exporta pedidos y registros recientes
Preserva los datos creados después del backup antes de restaurar la base de datos. En WooCommerce, exporta los pedidos o conserva las tablas actuales; descarga también las entradas de formularios desde su plugin. Guarda ZIP y SQL en una ubicación privada, protégelos si contienen datos personales y evita enviarlos sin cifrado.
Verifica URLs, caché y enlaces finales
Corrige las URLs y vacía las cachés después de restaurar en otro dominio. En la tabla cuyo nombre termina en _options, revisa siteurl y home; después guarda los enlaces permanentes y vacía caché de plugin, CDN y navegador. Comprueba asimismo las redirecciones y que el certificado SSL cubra el dominio definitivo.
Resuelve tus dudas
¿Por qué falla mi restauración de WordPress?
Suele fallar porque archivos y SQL tienen fechas distintas, PHP no es compatible o las credenciales de wp-config.php no coinciden. Comprueba esos puntos antes de repetir la copia.
¿Qué hago si sale error de base de datos?
Compara DB_NAME, DB_USER, DB_PASSWORD y DB_HOST con los datos del hosting. Si son correctos y phpMyAdmin no abre la base, el proveedor debe revisar MySQL o MariaDB.
¿Puedo restaurar solo la base de datos?
Sí, solo si los archivos, tema y plugins actuales son compatibles con esa base. No lo hagas tras cambios relevantes de plugins, tema o versión de WordPress.
¿Cuánto tarda restaurar un backup?
Una copia pequeña suele tardar entre 10 y 30 minutos. Backups de varios GB, SQL grandes o servidores compartidos pueden necesitar entre 45 y 90 minutos.
¿Cómo sé si el backup está corrupto?
Puede estar corrupto si el ZIP no abre, el SQL termina a mitad o faltan carpetas como wp-content/uploads. Pruébalo primero en staging.
¿Debo borrar la caché después de restaurar?
Sí, borra caché del plugin, CDN y navegador al cambiar archivos, URLs o enlaces permanentes. Una caché antigua puede mostrar una web rota aunque el servidor ya funcione.
Cierra la restauración con pruebas concretas
Valida el sitio en staging y producción con una lista corta antes de dar la incidencia por cerrada. Prueba portada, página interna, acceso al administrador, formulario y proceso de compra hasta antes del pago, preferiblemente en una ventana privada. Confirma que wp-config.php apunta a la base correcta, que el prefijo de tablas coincide, que no hay errores nuevos en debug.log y que funcionan imágenes, correos, enlaces, redirecciones y SSL.
- El error al restaurar WordPress que duplica usuarios
- Tu backup de WordPress puede fallar cuando más lo necesitas
Josu Barrios
Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.