¿Restaurar una copia de seguridad arregla una web hackeada?

Has restaurado una copia de seguridad y la web sigue mostrando lo mismo, o estás a punto de hacerlo y dudas si va a servir de algo. La respuesta honesta es que restaurar una copia hace una de estas tres cosas: a veces arregla el problema del todo, muchas veces solo lo aplaza unos días, y a veces lo empeora porque pierdes pedidos y encima sigues infectado. En esta guía vas a aprender a saber en cuál de los tres casos estás antes de pulsar el botón, y en qué orden hacer las cosas para que restaurar sea la solución y no un paso más del desastre.

Cuándo restaurar funciona y cuándo solo retrasa el problema

Restaurar una copia limpia resuelve el ataque cuando se cumplen dos condiciones a la vez: la vía por la que entraron ya está cerrada, y la copia es de una fecha anterior a que entraran. Si has actualizado el plugin vulnerable, has cambiado las contraseñas y la copia es de la semana pasada cuando todo iba bien, restaurar te devuelve a un punto sano.

Restaurar solo retrasa el problema cuando el agujero sigue abierto. Si el atacante entró por un formulario que sube archivos, por una contraseña de FTP robada o por un plugin que no has tocado, da igual la copia que pongas: en cuestión de horas o pocos días vuelven a entrar por la misma puerta y te reinfectan. Es el caso más frustrante, porque parece que has arreglado la web y al día siguiente está igual.

Y restaurar empeora las cosas cuando la copia que eliges ya está infectada. Muchas puertas traseras se instalan y se quedan semanas calladas antes de dar la cara. Si tu copia es de después de que entraran, estás restaurando el problema con sus mismas credenciales. Por eso, antes de restaurar nada, conviene entender dónde se esconden esas puertas: lo tienes explicado en cómo encontrar una puerta trasera en tu web.

Elegir la fecha: cómo saber cuándo empezó de verdad la infección

El error más común es restaurar a «ayer, cuando todo iba bien». El problema es que la infección casi nunca empieza el día que la notas. Puede llevar dentro semanas. Necesitas fijar la fecha del primer indicio, no la del síntoma. Estas son las señales que te dan esa fecha:

• Fecha de modificación de los archivos. Entra por FTP o por el administrador de archivos de tu hosting, ordena por fecha de modificación y mira los .php que se tocaron cuando tú no publicabas nada. En un servidor con acceso por SSH, find . -name "*.php" -newermt "2026-08-01" -printf "%TY-%Tm-%Td %pn" te lista los archivos PHP modificados desde esa fecha.
• Usuarios administradores que no reconoces. En Usuarios > Todos los usuarios, ordena por fecha de registro. Un administrador dado de alta un martes de madrugada te marca el día que entraron.
• La fecha de detección de Google. Si tienes aviso en Search Console, el informe de seguridad te dice desde cuándo lo ve Google.
• Los registros del servidor. En los logs de acceso puedes buscar la primera petición sospechosa (un POST a un archivo raro).

Con la fecha más antigua de todas ellas, elige una copia anterior a ese día. Si tu infección más vieja es del 5 de agosto, la copia buena es la del 4 o antes, no la del 10.

El error de restaurar solo los archivos o solo la base de datos

Una web WordPress son dos cosas: los archivos (el código, los plugins, el tema, las imágenes) y la base de datos (los textos, los pedidos, los usuarios, la configuración). El atacante suele ensuciar las dos. Si restauras solo una mitad, te dejas la otra intacta con lo malo dentro.

Un administrador falso vive en la base de datos, en la tabla wp_users. Si restauras solo los archivos, ese usuario sigue ahí tan tranquilo con su contraseña. Una shell PHP (un archivo que le da control del servidor) vive en los archivos. Si restauras solo la base de datos, esa shell sigue en su carpeta esperando. La regla es clara: o restauras las dos partes a la misma fecha limpia, o no restauras ninguna.

Pedidos, formularios y clientes: qué pierdes al volver atrás

Restaurar es viajar al pasado, y todo lo que pasó entre la fecha de la copia y ahora desaparece. Eso incluye cosas que sí quieres conservar: pedidos de la tienda, comentarios, mensajes que entraron por el formulario de contacto, altas de clientes reales, cambios de precios. Si tienes una tienda con ventas diarias, restaurar a hace dos semanas puede borrarte docenas de pedidos.

Antes de restaurar, saca lo que no puedes perder. En una tienda WooCommerce, ve a WooCommerce > Pedidos y exporta a CSV, o pídele a tu hosting una copia de la tabla wp_wc_orders (o wp_posts en tiendas más antiguas). Guarda también los mensajes del formulario y cualquier contenido nuevo. Luego, tras restaurar y limpiar, reimportas solo esos datos legítimos. Es más trabajo, pero es la diferencia entre perder el ataque y perder tu facturación.

Restaurar y limpiar: el orden que sí funciona

Restaurar no es un botón mágico, es un paso dentro de un proceso. Este es el orden que evita reinfecciones:

1. Guarda una copia del estado infectado. Aunque esté sucio, es tu prueba de lo que pasó y tu red de seguridad si algo sale mal. No lo borres.
2. Cierra la puerta de entrada. Cambia las contraseñas de WordPress, de FTP y del panel del hosting. Actualiza o desinstala el plugin por el que sospechas que entraron. Si no cierras esto, todo lo demás es inútil.
3. Restaura la copia limpia (archivos y base de datos, a la fecha anterior a la infección).
4. Actualiza WordPress, tema y todos los plugins a la última versión.
5. Cambia las claves de seguridad (los salts) del archivo wp-config.php para invalidar cualquier sesión abierta del atacante.
6. Reimporta los datos legítimos que exportaste (pedidos, mensajes) posteriores a la fecha de la copia.
7. Escanea otra vez y vigila los días siguientes.

Si la infección era grande o no te ves cerrando la puerta con seguridad, el proceso completo lo tienes paso a paso en cómo limpiar un WordPress hackeado. Y para entender qué buscabas exactamente y qué hay detrás de un ataque, el recorrido general de una web hackeada te da el mapa completo.

Copias del hosting frente a copias propias

No todas las copias sirven igual para esto. Las que hace tu hosting automáticamente son cómodas y no dependen de que te acordaras, pero suelen tener una rotación corta (a menudo solo 7 días). Si tu infección es más vieja que eso, todas las copias del hosting ya están contaminadas y no te sirve ninguna. Además, algunos hostings guardan la copia en el mismo servidor, con lo que si el ataque tocó el sistema entero, también podría haber tocado las copias.

Las copias propias (con un plugin de copias o descargadas a tu ordenador) te dan más control sobre las fechas y viven fuera del servidor, así que son más fiables después de un ataque. Qué debe incluir una copia para que de verdad te salve lo tienes detallado en qué debe incluir una copia de seguridad de tu web.

Dejar montada una copia que de verdad sirva la próxima vez

Cuando salgas de esta, monta un sistema que no dependa de la suerte. Tres reglas sencillas: guarda al menos tres copias, en dos sitios distintos, y una de ellas fuera del servidor (en tu ordenador o en un almacenamiento externo). Amplía la rotación a 30 días como mínimo, para que un ataque que tarda en dar la cara no te deje sin copias limpias. Y, sobre todo, prueba a restaurar una copia de vez en cuando: una copia que nunca has restaurado no es una copia, es una esperanza. Descubrir que el archivo estaba corrupto el día del incidente es el peor momento para enterarse.

Restaurar bien también evita el otro susto clásico: que el atacante vuelva y te cambie la portada por otra página, esta vez con la puerta que dejaste abierta.

Cuando hayas restaurado y limpiado, no te fíes de que la web «parece» bien: comprueba desde fuera si queda algo. Lanza el escáner gratuito de PathScan y confirma que la infección no sigue ahí antes de dar por cerrado el incidente.