Imagen2: images/el-backup-equivocado-devuelve-el-malware-tras-un-hackeo-2.webp
Schema_json: {"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://wordpressplugins.es/el-backup-equivocado-devuelve-el-malware-tras-un-hackeo/#article","headline":"El backup equivocado devuelve el malware tras un hackeo","description":"Entre 3 y 7 días: Backups para recuperar después de hackeo deben probarse antes de devolver tu web a internet.","datePublished":"2026-09-12T13:40:00+00:00","dateModified":"2026-09-12T13:40:00+00:00","author":{"@type":"Person","name":"Jesús Barrios","url":"https://wordpressplugins.es/author/jesús-barrios/"},"publisher":{"@type":"Organization","name":"Plugins WordPress","url":"https://wordpressplugins.es"},"image":{"@type":"ImageObject","url":"https://wordpressplugins.es/images/el-backup-equivocado-devuelve-el-malware-tras-un-hackeo.jpg"},"url":"https://wordpressplugins.es/el-backup-equivocado-devuelve-el-malware-tras-un-hackeo/","mainEntityOfPage":"https://wordpressplugins.es/el-backup-equivocado-devuelve-el-malware-tras-un-hackeo/","inLanguage":"es","articleSection":"Backup","about":{"@type":"Thing","name":"Recuperación de WordPress después de un hackeo"},"mentions":[{"@type":"Thing","name":"WordPress"},{"@type":"Thing","name":"INCIBE"},{"@type":"Thing","name":"cPanel"},{"@type":"Thing","name":"UpdraftPlus"},{"@type":"Thing","name":"MySQL"}],"keywords":"backups para recuperar después de hackeo, recuperación de WordPress, restaurar copia de seguridad, malware, hackeo, staging, seguridad WordPress"},{"@type":"BreadcrumbList","@id":"https://wordpressplugins.es/el-backup-equivocado-devuelve-el-malware-tras-un-hackeo/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Inicio","item":"https://wordpressplugins.es/"},{"@type":"ListItem","position":2,"name":"Backup","item":"https://wordpressplugins.es/category/backup/"},{"@type":"ListItem","position":3,"name":"El backup equivocado devuelve el malware tras un hackeo","item":"https://wordpressplugins.es/el-backup-equivocado-devuelve-el-malware-tras-un-hackeo/"}]}]}
Un backup puede devolver tu WordPress a un estado funcional tras un hackeo, pero restaurar la copia equivocada también puede devolver el malware. La fecha más reciente no siempre es la más segura: si el atacante llevaba días dentro, esa copia puede estar infectada aunque la web pareciera normal.
Para recuperar WordPress después de un hackeo, primero bloquea accesos y conserva pruebas; después identifica el último backup limpio, pruébalo en un entorno de staging y escanéalo antes de publicarlo. Recupera con cuidado los pedidos, entradas o formularios posteriores que necesites y refuerza la seguridad al terminar.
✉
¿Quieres más información? Escríbenos y te orientamos
Contén el hackeo antes de tocar una copia
Primero corta el acceso del atacante y conserva las pistas. Pon la web en mantenimiento si sigue aceptando formularios o pagos, cambia las credenciales críticas y pide al hosting que conserve los registros.
Cierra todas las puertas de acceso
Cambia las contraseñas de WordPress, panel del hosting, cPanel, FTP o SFTP, base de datos, correo del dominio y cuentas de almacenamiento remoto. FTP y SFTP son las vías para subir archivos al servidor; si una de ellas sigue abierta, el atacante puede volver a colocar el código malicioso tras la restauración.
Guarda pruebas antes de limpiar
Pide los logs de acceso y de errores al proveedor antes de iniciar una restauración. El Instituto Nacional de Ciberseguridad ofrece pautas generales de respuesta ante incidentes en su web oficial de INCIBE , una referencia útil si manejas datos personales o no sabes si ha existido una filtración.
Elige la copia limpia, no la más reciente
La mejor copia es la más cercana anterior al inicio estimado del ataque y guardada fuera de la cuenta afectada. Busca señales como spam, alertas de malware, administradores nuevos, cambios de archivos o redirecciones.
Calcula la fecha probable del ataque
Empieza por el primer síntoma verificable: un aviso del hosting, una alerta de Search Console, un pedido fraudulento o un correo de cambio de contraseña. Después, elige una copia anterior a esa fecha y no una creada el mismo día por comodidad.
Revisa en el backup los usuarios administradores y los plugins activos. Un administrador que no reconoces, un tema pirata o un archivo PHP dentro de la carpeta de imágenes son señales que justifican detener la restauración y buscar una copia más antigua.
Decide según el origen de tu backup
Origen Úsalo cuando Comprobación previa Snapshot de hosting o cPanel Es anterior al primer indicio y soporte confirma la fecha. Que no sea el único backup y que incluya base de datos. UpdraftPlus o WPvivid en Drive Puedes descargar archivos y base de datos por separado. Usuarios, plugins y fecha del archivo SQL. BlogVault o Jetpack VaultPress Tienes historial y opción de staging en tu plan. Punto de restauración y retención disponible. Copia manual en disco externo Incluye archivos y exportación MySQL verificable. Que el disco no sea la única copia existente.
Comprueba que el backup está completo
Una restauración de WordPress necesita los archivos del sitio y su base de datos MySQL. La base de datos guarda entradas, usuarios, ajustes y pedidos; los archivos contienen WordPress, imágenes, temas y plugins.
Restaura en staging antes de publicar cambios
Restaura la copia elegida en un staging, escanéala y prueba sus funciones antes de sustituir tu web pública. Un staging es una copia privada de la web, como un local de ensayo antes de abrir una tienda al público.
Crea el entorno de prueba sin código
Muchos hostings ofrecen staging desde su panel, y servicios como BlogVault también permiten restaurar fuera de producción. Si no aparece esa opción, pide al soporte un subdominio temporal protegido con contraseña, por ejemplo prueba.tudominio.es.
Escanea y prueba lo que importa
Ejecuta el análisis de malware del hosting o de una herramienta de seguridad para WordPress. Busca redirecciones, usuarios administradores desconocidos, tareas cron extrañas y archivos PHP en wp-content/uploads, una carpeta que normalmente aloja imágenes y documentos.
Prueba el acceso de administrador, páginas principales, formularios, envío de correos, buscador, carrito y pago. Si usas WooCommerce, simula una compra sin cobrar para confirmar que los pedidos y los correos salen bien.
Después de publicar la copia limpia, completa una revisión post-restauración antes de dar el incidente por cerrado. Regenera las claves y salts de WordPress en wp-config.php para invalidar cookies y sesiones existentes, vuelve a cambiar las contraseñas de WordPress si hubo cualquier acceso durante la intervención y elimina los usuarios administradores de WordPress que no sean imprescindibles. Actualiza el núcleo, plugins y temas desde fuentes oficiales; borra los que estén inactivos o no se utilicen. Revisa las tareas cron, los permisos de archivos y carpetas, las reglas de redirección, la caché y las cuentas FTP o SFTP.
Activa alertas de cambios de archivos y conserva los logs de acceso durante varias semanas: eliminar malware de WordPress no basta si permanece la vía que permitió la intrusión.
✉
¿Quieres más información? Escríbenos y te orientamos
Recupera pedidos y contenidos sin traer código
Recupera de forma selectiva los datos legítimos posteriores al backup y nunca copies código desde la instalación infectada. Los pedidos, artículos y reservas suelen poder verificarse con fuentes externas.
Datos que puedes validar y rescatar
Recupera pedidos desde la pasarela de pago, correos de confirmación o el panel de tu banco, no desde tablas dudosas. Para una tienda, compara entre 10 y 20 pedidos recientes con Stripe, PayPal, Redsys o el método de cobro que uses antes de darlos por recuperados.
Puedes volver a crear manualmente entradas, páginas, productos, reservas y cupones tras revisar cada dato. Exporta solo registros necesarios si tu herramienta permite filtrarlos por fecha, y revisa los usuarios antes de importarlos.
Elementos que debes dejar fuera
No copies la carpeta completa wp-content, el archivo wp-config.php, plugins, temas ni usuarios administradores desde el sitio infectado. Tampoco restaures tareas cron, que son acciones automáticas programadas, sin saber quién las creó y qué hacen.
No restaures sin análisis si sospechas una filtración de datos personales, fraude, pedidos activos manipulados o acceso a tarjetas. El RGPD y la LOPDGDD pueden obligarte a documentar el incidente y, según el alcance, a comunicarlo. Restaurar tampoco es la solución principal para un error de configuración, una actualización fallida o una caída temporal del hosting.
Si todas las copias muestran señales de infección, instala WordPress limpio, crea una base de datos nueva y migra solo datos comprobados. Es más lento, pero suele ser más seguro que perseguir una infección de copia en copia.
✉
¿Quieres más información? Escríbenos y te orientamos
Define copias y plugins para el próximo incidente
Después de recuperar la web, configura backups automáticos remotos según cuántos datos puedes perder y cuánto tiempo puedes estar caído. El RPO es la cantidad máxima de datos aceptable perder, y el RTO es el tiempo máximo que tu web puede permanecer fuera de servicio.
Elige frecuencia y retención realistas
Para un blog pequeño, programa backup diario y conserva entre 14 y 30 días de historial. Para una tienda o academia con inscripciones, guarda la base de datos cada 1 a 6 horas , además de una copia completa diaria.
Aplica la regla 3-2-1: tres copias, en dos soportes distintos y una fuera del hosting. Un disco externo desconectado y una copia cifrada en Drive son ejemplos útiles, siempre que controles quién tiene acceso.
Plugins y servicios según tu caso
Opción Coste orientativo Mejor para UpdraftPlus o WPvivid Gratis, con extras de pago. Blog o web pequeña con Drive o Dropbox. Jetpack VaultPress Backup Plan mensual, según retención. Web con cambios frecuentes y recuperación guiada. BlogVault Plan mensual, según sitios y copias. Tienda que necesita staging e historial.
✅
Nuestra recomendación
Un disco externo dedicado permite mantener una copia desconectada del hosting. Es una capa útil frente a borrados, ransomware o errores en la cuenta remota.
Guarda una copia completa fuera de la cuenta de hosting comprometida
Permite conservar historiales de 14 a 30 días sin depender de un único proveedor
Puede desconectarse tras copiar los archivos y reducir el riesgo de ransomware
Ver disponibilidad →
Los servicios de restauración de WordPress en España suelen situarse entre 150 y 600 € cuando incluyen limpieza, recuperación y revisión básica, aunque una tienda con fraude o datos expuestos puede requerir análisis aparte.
Lo que más preguntan
¿Cómo recupero una web WordPress hackeada?
Recupera WordPress restaurando una copia anterior al ataque primero en staging y escaneándola antes de publicarla. Cambia accesos de hosting, correo, SFTP y administradores antes de devolver la web a internet.
¿Debo restaurar el último backup de WordPress?
No restaures el último backup si no sabes cuándo comenzó el hackeo. Elige una copia creada entre 3 y 7 días antes del primer indicio, o una más antigua si ves usuarios o archivos sospechosos.
¿Qué hago si todos mis backups tienen malware?
Si todas las copias parecen infectadas, crea una instalación limpia y migra solo datos verificados. No copies plugins, temas, archivos PHP, usuarios administradores ni el archivo wp-config.php desde el sitio afectado.
¿Cada cuánto debo hacer copias de seguridad?
Una web con pocos cambios necesita una copia diaria y entre 14 y 30 días de retención. Una tienda activa debe guardar la base de datos cada 1 a 6 horas para no perder pedidos recientes.
¿Cuánto cuesta recuperar un WordPress hackeado?
Una recuperación profesional básica suele costar entre 150 y 600 € en España. El precio aumenta si hay tienda, malware persistente, fraude, datos personales o falta de una copia limpia.
Lo esencial: El último backup no siempre es el seguro; manda la fecha real de la intrusión. Contén accesos y conserva logs antes de borrar o restaurar archivos. Prueba siempre la copia en staging y revisa funciones críticas antes de publicar. Recupera pedidos y contenidos recientes de forma selectiva, sin importar código del sitio infectado. Mantén copias 3-2-1 y prueba una restauración al menos una vez al mes.
Fuentes de interés
Otros artículos que pueden complementar lo que acabas de leer:
