Cómo restaurar un sitio WordPress desde una copia de seguridad (sin perder pedidos)

Una restauración debería ser la parte tranquila de un mal día. En la práctica, a menudo empeora las cosas: la copia equivocada, pedidos perdidos, un sitio que vuelve con el mismo agujero por el que lo hackearon. Esta guía te da una rutina para restaurar un sitio WordPress de un cliente desde una copia, elegir la copia correcta, conservar los datos que necesitas y comprobar el resultado antes que el cliente.

1. Decide qué necesitas restaurar de verdad

No todos los problemas requieren una restauración completa. Pregunta primero qué se rompió y qué ha cambiado desde la última copia buena.

• Una actualización de plugin o tema rompió el sitio: a menudo solo tienes que reponer esa carpeta del plugin o del tema. La base de datos puede quedarse como está.
• Se borró o sobrescribió contenido: puede que solo necesites la base de datos, o incluso una sola entrada desde una revisión.
• El sitio fue hackeado o faltan archivos: necesitas los archivos y normalmente también la base de datos, de antes de que empezara el problema.

Después, haz una lista de lo que ha pasado en el sitio desde la copia: pedidos nuevos, envíos de formularios, comentarios, cuentas de usuario, cambios del cliente. Una restauración completa lo tira todo.

2. Elige la copia correcta

La copia más reciente no siempre es la correcta. Quieres la última copia de antes del problema.

• Compara la fecha y la hora con el momento en que empezó el problema (un registro de actualizaciones, el primer error, el primer mensaje del cliente).
• En un sitio hackeado, vuelve a antes del periodo de infección, no a ayer. Una copia de un sitio infectado restaura la infección.
• Asegúrate de que la copia está completa: tanto los archivos (al menos wp-content) como la base de datos, y de que el archivo se abre de verdad.

3. Respalda primero el sitio roto

Antes de cambiar nada, haz una copia del sitio tal como está ahora. Cuesta unos minutos y te da una vía de vuelta si la restauración sale mal, además de los pedidos y envíos que quizá tengas que pasar después. Con WP-CLI:

wp db export before-restore.sql

Descarga también wp-content, o pide a tu hosting que haga una instantánea.

4. Restaura primero en una copia si puedes

Si tienes una copia de staging o puedes crear una, restaura primero ahí. Ves el resultado sin que el cliente mire y descubres si la copia sirve. En un sitio corporativo pequeño que ya está caído, restaurar directamente en vivo es aceptable. En una tienda, prueba en una copia.

5. Haz la restauración

Usa la herramienta de la que viene la copia. Las tres rutas habituales:

• Plugin de copias: usa su función de restauración y elige archivos, base de datos o ambos.
• Panel del hosting: muchos proveedores pueden restaurar archivos y base de datos desde sus propias instantáneas. Comprueba si restauran toda la cuenta o un solo sitio.
• A mano: sube los archivos por SFTP e importa la base de datos.

Para la ruta manual con WP-CLI:

wp db import backup.sql
wp search-replace 'https://old-domain.test' 'https://www.client-site.com' --skip-columns=guid
wp rewrite flush
wp cache flush

Solo necesitas search-replace cuando la copia viene de otro dominio o de una URL de staging. Ejecútalo primero con --dry-run .

6. Restauraciones parciales sin perder pedidos

En una tienda WooCommerce, restaurar la base de datos significa perder cada pedido, cliente y cambio de stock desde la copia. Prefiere la restauración más pequeña que resuelva el problema:

• Una actualización rota: repón solo la versión antigua de esa carpeta del plugin o del tema.
• Una base de datos rota en una tienda: antes de importar, exporta los pedidos realizados desde la copia y vuelve a introducirlos o pide a tu desarrollador que los combine.
• Contenido que falta: revisa las revisiones y la papelera antes de tocar una copia.

7. Comprueba el sitio antes de decírselo al cliente

Una página de inicio que carga no es un sitio que funciona. Repasa esta lista:

1. La página de inicio y las tres páginas más importantes, en escritorio y en un móvil.
2. Envía un mensaje de prueba por el formulario de contacto y comprueba que llega.
3. En una tienda: añade algo al carrito y completa el pago con un método de pago de prueba.
4. Entra en wp-admin y comprueba que están activos los plugins que esperas.
5. Vacía todas las cachés: el plugin de caché, la caché del servidor y la CDN.

8. Tras un hackeo: cierra el agujero antes de reabrir

Una restauración tras un hackeo repone la versión antigua y vulnerable. Antes de que el sitio vuelva a ser público:

• Actualiza el plugin, el tema o la versión de WordPress por donde entraron.
• Cambia todas las contraseñas de administrador y la de la base de datos, y elimina las cuentas de administrador que no reconozcas.
• Renueva las claves de seguridad en wp-config.php (wp config shuffle-salts), lo que cierra la sesión de todos.
• Vigila el sitio unos días: administradores nuevos, archivos modificados, redirecciones extrañas.

9. Haz que restaurar sea aburrido

La mayoría de las restauraciones fallidas fallan porque nadie lo había probado nunca. Restaura cada mes un sitio desde una copia, en una copia de prueba, y anota cuánto tardaste. Acuerda de antemano con los clientes qué significa una restauración para los pedidos y envíos de formularios recibidos entretanto, para que la conversación no sea nueva el día que ocurra.

Cómo gestiona Verploy las copias y restauraciones

Cada actualización se comprueba, y las arriesgadas se prueban primero en una copia, incluidos los formularios y el pago, así que menos actualizaciones necesitan una restauración. Las copias nocturnas vienen con una prueba de restauración y, si un sitio se rompe tras publicar, Verploy lo revierte. Más sobre las copias de seguridad de WordPress para agencias.