La restauración y recuperación ante desastres en WordPress exige saber qué restaurar, quién decide y cuánto tiempo puede estar caída la web.
Índice
Anuncio
Comprueba si tu copia permite volver a operar
Una copia solo protege el negocio si puedes recuperarla desde fuera del hosting y dentro del tiempo que tu empresa puede asumir.
Dónde guardar las copias de seguridad
Para una web WordPress, la copia externa puede almacenarse en AWS, Google Cloud, Microsoft Azure, OVHcloud o un servicio de almacenamiento separado del proveedor web. Debe incluir tanto los archivos como la base de datos MySQL, y tener una retención suficiente para volver a un punto anterior a una infección.
Qué debe volver a funcionar después
Revisa el alcance real de cada backup: archivos, base de datos, reglas DNS, configuración de Cloudflare, SMTP, claves API, pasarelas de pago, licencias y caché.
Saber qué falta es el primer paso. El siguiente consiste en decidir cuánto tiempo y cuántos datos puede perder cada parte de tu negocio.
Conviene separar conceptos que suelen mezclarse. Las copias de seguridad externas son los datos almacenados para poder recuperar archivos o un backup de base de datos MySQL; por sí solas no garantizan la vuelta al servicio. La recuperación ante desastres organiza personas, accesos y procedimientos para ejecutar esa restauración de WordPress dentro de un plazo asumible. La continuidad de negocio mantiene procesos alternativos mientras el servicio falla, por ejemplo, aceptar pedidos por teléfono si la recuperación de WooCommerce no está disponible.
La respuesta ante incidentes permite contener y analizar la causa. Además del tiempo objetivo de recuperación (RTO) y el punto objetivo de recuperación (RPO), define el MTD: el tiempo máximo tolerable de interrupción antes de que el daño al negocio sea inaceptable.
Define RTO y RPO según el daño al negocio
El RTO es el tiempo máximo aceptable de caída, y el RPO es la máxima pérdida de datos aceptable.
Calcula el tiempo máximo de caída
Calcula el RTO por proceso, no por tecnología. Para una tienda con ventas diarias, el checkout, el pago y el correo de confirmación pueden requerir entre 1 y 4 horas; una sección corporativa puede aceptar entre 24 y 72 horas.
Decide cuántos datos puedes perder
El RPO responde a una pregunta muy concreta: si restauras una copia, ¿cuánto trabajo, pedidos o registros desaparecen? Un RPO de 24 horas significa que podrías perder todo lo ocurrido desde la última copia diaria.
| Proceso | RTO orientativo | RPO orientativo | Prioridad |
|---|---|---|---|
| Pago y checkout WooCommerce | 1 a 4 horas | 15 minutos a 1 hora | Crítica |
| Formularios de captación | 4 a 8 horas | 1 a 4 horas | Alta |
| Área privada de clientes | 4 a 12 horas | 1 a 4 horas | Alta |
| Blog y páginas informativas | 24 a 72 horas | 24 horas | Media |
Con los tiempos escritos, la conversación deja de ser técnica. Ahora toca dejar claro quién hace cada tarea y con qué credenciales.
Anuncio
Documenta un plan que funcione bajo presión
Un plan de recuperación ante desastres debe reunir activos, responsables, accesos, dependencias, contactos y orden de restauración.
Guarda accesos fuera del servidor afectado
Documenta el registrador del dominio, DNS, hosting, Cloudflare, WordPress, SFTP, cPanel, phpMyAdmin, WP-CLI, correo, almacenamiento externo y pasarelas de pago. Guarda las credenciales en un gestor de contraseñas con acceso de emergencia, nunca solo en el correo de una persona.
Un plan recuperable indica qué restaurar, desde qué copia, quién lo autoriza y cómo comprobar que el negocio vuelve a cobrar, captar y atender.
Ordena la restauración por impacto
Prioriza primero dominio y DNS, después acceso al servidor, base de datos, archivos WordPress, pagos, correo transaccional y formularios. La analítica, el blog y los elementos secundarios pueden esperar si no frenan ventas ni atención al cliente.
- Crítica: checkout, pedidos, pagos, datos de clientes y acceso de administración.
- Alta: formularios, correo SMTP, áreas privadas, stock y webhooks.
- Media: contenidos, analítica, caché, CDN y recursos no esenciales.
- Baja: mejoras visuales, pruebas internas y páginas sin tráfico comercial.
Un documento sin ensayo es solo papel. La parte delicada llega cuando hay que contener el fallo sin borrar las pistas que explican qué ocurrió.
Una plantilla útil de plan de recuperación ante desastres puede organizarse por activo. Para cada sitio, base de datos, dominio, buzón o integración, registra su propietario, prioridad, RTO, RPO, última copia comprobada, ubicación del almacenamiento externo y procedimiento de restauración. Añade las dependencias previas —por ejemplo, que el checkout requiere DNS operativo, certificado, MySQL, SMTP y pasarela de pago—, los contactos de hosting, registrador, desarrollador y pagos, y las credenciales de emergencia custodiadas en un gestor seguro.
Incluye también los criterios de escalado: quién autoriza una restauración, cuándo se informa a dirección y cuándo se contacta con proveedores o especialistas externos. Este inventario debe actualizarse tras cambios de hosting, plugins, correo o configuración DNS.
Actúa durante las primeras 24 horas del incidente
Las primeras 24 horas deben seguir este orden: contener, conservar evidencias, comunicar, restaurar un punto seguro, validar y cerrar.
Contén el fallo antes de tocar datos
Guarda logs del servidor, alertas de monitorización, capturas, fecha de detección, archivos sospechosos y usuarios afectados. Después cambia contraseñas, claves API y cuentas administrativas cuando exista sospecha de acceso no autorizado.
Si el incidente afecta a datos personales, el RGPD exige valorar la notificación a la autoridad de control en un plazo máximo de 72 horas desde que se tiene constancia de la brecha. Consulta los criterios publicados por la AEPD y el servicio de ayuda de INCIBE antes de afirmar qué datos han quedado expuestos.
Elige el método de restauración adecuado
| Método | Tiempo habitual | Recupera fuera del hosting | Mejor para |
|---|---|---|---|
| Panel de hosting | 15 a 90 minutos | No siempre | Error reciente sin compromiso del proveedor |
| Plugin WordPress | 30 a 120 minutos | Solo si exportó fuera | Restauración parcial y entornos pequeños |
| Copia en la nube | 1 a 6 horas | Sí | Caída total, migración o ransomware |
| SFTP, MySQL y WP-CLI | 2 a 8 horas | Sí | Recuperación selectiva y casos complejos |
Un disco duro externo cifrado puede ser una segunda ubicación física para una copia desconectada del hosting. No sustituye la nube, pero reduce el riesgo de perder todas las copias ante un acceso no autorizado a una cuenta.
- Permite conservar una copia desconectada de ransomware y borrados remotos
- Facilita trasladar un backup completo a otro proveedor si el hosting queda inaccesible
- Sirve para verificar restauraciones sin tocar la instalación de producción
La restauración técnica es solo la mitad del trabajo. Falta demostrar que los pedidos, los avisos y los accesos funcionan como deberían.
Durante la primera hora, aísla el sitio si hay indicios de malware, conserva logs y capturas, registra la hora de detección y designa a una persona responsable de coordinar la respuesta. Entre la primera y la cuarta hora, comunica una incidencia interna, confirma qué servicios están afectados, bloquea accesos comprometidos y selecciona el último punto de recuperación seguro. Antes de restaurar, prepara un entorno separado cuando sea posible y comprueba que la copia contiene archivos, base de datos y configuraciones necesarias.
En las horas siguientes, restaura por prioridad, valida pagos, pedidos, formularios, correos, redirecciones y accesos, y comunica el estado real a clientes si procede. El cierre exige documentar el tiempo empleado, los datos perdidos frente al RPO, las causas identificadas y las acciones pendientes. Las pruebas de restauración permiten comprobar que este calendario es viable.
Prueba la recuperación antes de necesitarla
Un simulacro documentado permite conocer el tiempo real de vuelta al servicio y debe hacerse al menos cada seis meses.
Qué validar después de restaurar
Comprueba acceso de administradores, inicio de sesión de clientes, pedidos de prueba, pagos, stock, formularios, correos transaccionales, DNS, certificados, redirecciones y analítica. También revisa que la caché y el CDN no estén mostrando una versión antigua o una página de error.
Qué evidencia debe quedar del simulacro
Guarda una captura del backup externo, listado de ficheros restaurados, comprobaciones funcionales, tiempo total y tareas pendientes. Esa evidencia permite comparar pruebas futuras y demuestra que el procedimiento no depende de una sola persona.
Anuncio
Preguntas frecuentes
¿Cómo restauro WordPress a un estado anterior?
Restaura archivos y base de datos del mismo punto de copia, preferiblemente primero en un entorno de prueba. Elige una fecha anterior al incidente y valida pedidos, formularios, correos y accesos antes de reabrir la web.
¿Qué diferencia hay entre RTO y RPO?
El RTO marca cuánto puede durar la caída y el RPO cuántos datos puedes perder. Por ejemplo, un RTO de 4 horas y un RPO de 1 hora exigen volver en cuatro horas perdiendo como máximo la última hora de actividad.
¿Cada cuánto debo probar mis copias de seguridad?
Prueba la restauración al menos cada seis meses y tras cambiar hosting, DNS o correo. Un ecommerce con pedidos diarios se beneficia de simulacros trimestrales, porque acumula más dependencias y cambios.
¿Un backup del hosting es suficiente?
No, si es la única copia o está en la misma cuenta afectada. Debes mantener una copia externa y comprobar que puedes descargarla, leerla y restaurarla sin depender del panel del hosting.
¿Qué hago si sospecho que mi WordPress tiene malware?
Aísla la web, guarda evidencias y no restaures automáticamente el último backup. Cambia credenciales, identifica un punto anterior a la infección y revisa vulnerabilidades de plugins, temas y usuarios antes de publicar de nuevo.
Convierte tus copias en un plan verificable
La prioridad inmediata es localizar una copia externa, comprobar que puedes acceder a ella y anotar cuánto tarda una recuperación de prueba.
- Una copia diaria no basta si vive en el mismo hosting, no se ha probado o ya contiene el problema.
- RTO, RPO y MTD deben definirse por proceso crítico, no con una cifra genérica para toda la web.
- La recuperación completa incluye WordPress, MySQL, DNS, correo, pagos, caché, CDN y credenciales externas.
- Un simulacro cada seis meses convierte una promesa técnica en un tiempo de recuperación comprobado.
Para saber más
Si deseas profundizar, aquí tienes algunos recursos de interés:
- Recuperación ante desastres y restauración con 1 clic ... — duplicator.com
- Plantilla de Plan de Recuperación ante Desastres ... - Orathos — orathos.com
- Recuperación ante Desastres de TI: Estrategias para ... — splashtop.com
- Compartir cuenta arruina tus copias fuera de sitio
- 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.