Repetir la restauración puede borrar tus pedidos

Si falla la restauración de un backup de WordPress, no la repitas a ciegas: puede borrar datos creados después de la copia y dificultar la recuperación. Detén los cambios, guarda una copia del estado actual, conserva el error y los registros, e identifica si el fallo afecta a archivos, base de datos o configuración antes de restaurar solo lo necesario.

Conserva el estado actual antes de reintentar

Detén nuevos cambios y guarda una copia recuperable del estado actual.

Crea una copia aunque la web esté rota

Entra en cPanel, Plesk o el panel de tu hosting y genera un backup completo del estado actual. Si el panel no ofrece esa opción, descarga por SFTP o FTP las carpetas del sitio y exporta la base de datos con phpMyAdmin.

Guarda estos elementos en una carpeta fechada en tu ordenador o almacenamiento seguro:

• La carpeta wp-content, que contiene plugins, temas, medios y, a menudo, datos propios de extensiones.
• El archivo wp-config.php, donde están las credenciales de acceso a MySQL.
• Una exportación SQL de la base de datos, llamada también volcado SQL.
• Los pedidos, clientes y productos creados desde la fecha del backup, si la tienda usa WooCommerce.

Guarda pruebas del fallo ocurrido

Haz capturas del mensaje de error, de la hora del incidente y de la pantalla del panel que muestra el punto de restauración. Anota la fecha del backup, su tamaño y, si el hosting lo muestra, su hash o código de integridad.

Identifica el fallo por el síntoma visible

Localiza el síntoma y limita la zona afectada.

Revisa error 500 y pantalla blanca

Abre el registro de errores del hosting y busca líneas de la misma hora que el fallo. Si aparece memory exhausted, el límite de memoria PHP se ha quedado corto; si aparece permission denied, hay un problema de permisos o propietario de archivos.

Activa el debug de WordPress sin enseñar mensajes a los visitantes. Haz una copia previa de wp-config.php y, antes de la línea “That's all”, deja estas líneas:

define('WP_DEBUG', true);

define('WP_DEBUG_LOG', true);

define('WP_DEBUG_DISPLAY', false);

Después revisa /wp-content/debug.log. Tras la prueba, vuelve a dejar WP_DEBUG en false. El error típico aquí es mostrar el debug en pantalla y revelar rutas internas o datos técnicos a usuarios.

Comprueba conexión y redirecciones

Si ves “Error establishing a database connection”, compara el nombre de la base de datos, usuario, contraseña y servidor de wp-config.php con los datos del panel. Una contraseña de MySQL cambiada o un prefijo de tablas distinto pueden impedir que WordPress encuentre sus propios datos.

Si la restauración se queda detenida, muestra un porcentaje que no avanza o termina sin confirmar éxito, no des por hecho que el backup está dañado. Compara el tamaño y, si está disponible, el hash del archivo con los datos del panel o con la copia descargada; después revisa el log de la tarea de restauración, el espacio libre, la cuota de inodos, el directorio temporal y los límites de ejecución del hosting.

Una restauración parcial puede haber recuperado el volcado SQL pero no todos los archivos, o haber copiado wp-content sin completar plugins y subidas. Antes de reintentar, conserva ese estado y pide al hosting el motivo exacto de la interrupción si el panel no lo muestra.

Después de una restauración de backup de WordPress, un plugin actualizado o incompatible con la versión recuperada de PHP puede provocar un error 500 de WordPress o una pantalla blanca de WordPress aunque la copia sea válida. Para aislarlo sin borrar información, renombra temporalmente por SFTP la carpeta del plugin sospechoso dentro de wp-content/plugins y comprueba si el sitio responde; restaura su nombre antes de probar otro para no mezclar resultados. Si no puedes acceder al escritorio, empieza por extensiones de caché, seguridad, optimización o pasarelas de pago que hubieran cambiado recientemente.

Revisa también los permisos de archivos y el propietario de las carpetas restauradas, porque una extensión correcta puede fallar si PHP no puede leer o escribir sus archivos.

Mide el impacto antes de tocar MySQL

Compara la fecha de cada activo y evita sobrescribir datos recientes.

Exporta ventas y contactos recientes

Exporta desde WooCommerce los pedidos y clientes creados desde la fecha de la copia. Si el plugin de formularios permite exportar envíos, guarda también ese CSV antes de importar una base antigua.

Decide con la matriz de impacto

Restaurar solo los archivos suele ser más reversible que restaurar la base de datos. Restaurar tablas antiguas requiere más cuidado, especialmente si hubo ventas, reservas o altas de usuarios después del punto de recuperación.

Recupera producción con una reversión segura

Prueba la recuperación fuera de la web pública antes de aplicarla.

Abre una ventana de mantenimiento

Activa el modo mantenimiento y pausa campañas de pago, automatizaciones de correo y publicaciones programadas. En una empresa de Madrid que recibe solicitudes desde anuncios locales, dejar activo un formulario que no guarda envíos puede costar más que mostrar una página temporal honesta.

Valida las funciones que facturan

Comprueba estos puntos después de restaurar, no solo la portada:

1. Acceso de administrador y de usuario registrado.
2. Formulario de contacto, incluida la llegada del correo.
3. Checkout de WooCommerce con un pedido de prueba y método de pago seguro.
4. Correo transaccional de pedido, restablecimiento de contraseña y avisos.
5. Tareas cron, que son trabajos automáticos como renovar stock o enviar recordatorios.
6. Caché, CDN, etiquetas noindex, sitemap y redirecciones principales.

WordPress.org recomienda mantener copias y probar las actualizaciones antes de producción. La misma prudencia aplica a una recuperación: consulta las prácticas de seguridad publicadas por WordPress.org y guarda el registro de cambios efectuados.

Preguntas frecuentes

¿Qué hago si falla la restauración del backup?

No repitas la restauración hasta guardar archivos, base de datos, capturas y logs del estado actual. Después identifica si fallaron PHP, MySQL, caché o una parte concreta de WordPress.

¿Puedo perder pedidos al restaurar WordPress?

Sí, una base de datos anterior puede borrar pedidos creados después de la fecha del backup. Exporta pedidos, clientes y stock antes de importar un volcado SQL antiguo.

¿Por qué sale error 500 tras restaurar?

El error 500 suele indicar un problema de PHP, memoria, permisos o código incompatible. Lee el Error Log antes de desactivar plugins o restaurar de nuevo.

¿Cómo sé si se restauró solo una parte?

Una restauración parcial deja archivos y base de datos con fechas o versiones distintas. Revisa fechas de plugins, tema, tablas MySQL y el punto de restauración usado.

¿Debo vaciar la caché después de restaurar?

Sí, vacía la caché de WordPress, hosting, CDN y Cloudflare antes de diagnosticar un bucle o contenido antiguo. Hazlo después de copiar el estado actual, no antes.

• Un backup sin probar puede fallar tras un desastre
• El último backup no siempre es el seguro tras un hackeo

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.