Son las 10:15, la tienda recibe pedidos y WordPress deja de responder tras una caída del servidor. La copia de la madrugada está intacta, pero restaurarla requiere horas, revisar pedidos recientes, reconfigurar DNS y comprobar que los pagos funcionan.
Los backups para alta disponibilidad no bastan por sí solos: un backup permite recuperar WordPress después de un fallo, no mantenerlo disponible mientras ocurre. La continuidad exige redundancia, copias externas verificadas y un plan probado con responsables, RPO y RTO definidos.
Índice
Anuncio
¿Tu WordPress aguanta una caída o solo tiene copias?
Un WordPress tiene continuidad operativa cuando puede volver a prestar servicio dentro del tiempo que el negocio acepta perder; una copia diaria protege los datos de ayer, pero no evita que WooCommerce deje de cobrar durante horas.
¿Qué pierde una tienda en una hora caída?
Una tienda pierde pedidos, margen y confianza en cada hora caída. Si factura entre 150 y 800 € por hora, una interrupción de cuatro horas supone entre 600 y 3.200 € de ventas que quizá no regresen, sin contar campañas pagadas que siguen enviando visitas a una página rota.
¿Cuándo una copia diaria ya no basta para estos servicios?
¿Qué servicios no pueden esperar a restaurar?
Los pagos, reservas, captación de contactos y áreas privadas suelen requerir tiempos de vuelta más cortos. El coste de la caída marca la arquitectura, no el nombre del plugin: primero define cuánto dato puedes perder y cuánto tiempo puede parar la web.
RPO y RTO: fija pérdidas y paradas asumibles
El RPO fija cuántos datos puedes perder y el RTO cuánto tiempo puede estar parado WordPress. Un RPO de una hora exige una copia o captura coherente, como mínimo, cada hora; un RTO de 30 minutos exige algo más que restaurar manualmente un archivo grande.
¿Cuántos pedidos puedes perder?
El RPO debe medirse con transacciones, no solo con tiempo. Si entran entre 10 y 40 pedidos por hora, un RPO de cuatro horas puede dejar entre 40 y 160 pedidos fuera de la restauración, aunque el backup esté intacto.
¿Cuánto tiempo puedes vender cero?
El RTO debe incluir detección, decisión, restauración, pagos, correo, DNS y caché. Restaurar archivos en 20 minutos no sirve si el pago con tarjeta o los correos transaccionales siguen fallando una hora más.
| Tipo de sitio | RPO orientativo | RTO orientativo | Capa mínima |
|---|---|---|---|
| Web corporativa estable | 12 a 24 horas | 4 a 8 horas | Backup externo probado |
| Captación o reservas | 1 a 4 horas | 1 a 4 horas | Copias frecuentes y runbook |
| Tienda WooCommerce activa | 15 a 60 minutos | 15 a 90 minutos | Réplicas, backup y failover |
¿Quién aprueba el RPO y el RTO?
La dirección debe aprobar RPO y RTO porque decide las pérdidas comerciales aceptables; el proveedor técnico traduce esos límites a frecuencia de copias, almacenamiento, servidores duplicados y coste mensual.
Backup, réplica y HA: elige cada capa
Backup, replicación, alta disponibilidad y recuperación ante desastres resuelven fallos distintos. Una estrategia seria combina las capas necesarias porque duplicar servidores no sustituye una copia histórica aislada.
¿La réplica también copia el ransomware?
Una réplica puede copiar ransomware, borrados y errores de aplicación casi al instante. Debe acompañarse de copias con versiones anteriores, retención bloqueada y permisos separados para proteger frente a corrupción lógica.
¿Un snapshot sustituye al backup externo?
Un snapshot no sustituye al backup externo si está en la misma cuenta del proveedor. Un atacante con acceso a esa consola, un borrado malicioso o una incidencia amplia pueden afectar a producción y snapshots a la vez.
¿Cuándo necesitas failover automático?
El failover automático se justifica cuando esperar una restauración rompe una venta, atención urgente o servicio contratado. Puede usar balanceo de carga, servidores redundantes y DNS preparado, aunque exige pruebas para no enviar tráfico a una copia incompleta.
Réplica y failover
Snapshot probado
Copia inmutable
Backup offsite y DR
No todas las copias de seguridad WordPress consumen el mismo espacio ni permiten la misma velocidad de recuperación. Una copia completa guarda todos los archivos y la base de datos en cada ejecución; es simple de restaurar, pero pesada. Las copias incrementales guardan solo los cambios desde la última copia y reducen el almacenamiento, aunque la restauración WordPress depende de que la cadena de versiones esté íntegra. Las diferenciales acumulan cambios desde la última copia completa y suelen ofrecer un término medio.
Los snapshots son útiles para revertir cambios rápidos de servidor, pero no reemplazan un backup externo. En un backup WooCommerce, conviene combinar una copia completa periódica con copias frecuentes de la base de datos, porque pedidos, stock y clientes cambian mucho más que los archivos.
Copias 3-2-1-1-0 frente a ransomware
La regla 3-2-1-1-0 exige tres copias, dos soportes, una copia fuera de la ubicación principal, una inmutable o aislada y cero errores en pruebas. Solo funciona si puedes restaurar y verificar las copias.
¿Dónde guardar la copia inmutable?
Una copia inmutable puede guardarse en almacenamiento de objetos con bloqueo de retención, en una cuenta separada o en un sistema desconectado tras completar la copia. El objetivo es que un acceso comprometido a WordPress no pueda alterar el historial.
¿Quién puede borrar las copias?
La cuenta que administra WordPress no debería poder borrar todas las copias. Usa MFA, permisos mínimos y credenciales distintas para producción, almacenamiento y restauración.
¿Cuánto tiempo debes conservarlas?
La retención debe cubrir el tiempo que tardas en detectar un problema. Para muchas pymes, conservar diarias entre 14 y 30 días, semanales entre 8 y 12 semanas y mensuales entre 6 y 12 meses ofrece margen frente a errores tardíos.
Un NAS o disco externo puede aportar una copia local rápida para restauraciones urgentes. Debe complementarse con una copia cifrada fuera de la oficina y con retención protegida.
- Permite conservar una copia local accesible aunque falle la conexión a internet
- Facilita descargar restauraciones grandes sin depender de un proveedor externo
- Añade un soporte distinto a la cuenta donde está alojado WordPress
Los plugins de backup simplifican las copias de archivos y base de datos desde el panel de WordPress, pero no deben ser la única capa de protección. Al elegir una herramienta, verifica que permita programar copias frecuentes, enviar el archivo a un backup externo, cifrarlo, conservar versiones y restaurar en un entorno de pruebas. También debe respaldar por separado la base de datos de WooCommerce cuando el RPO lo requiera. Para una alta disponibilidad WordPress, combina el plugin con snapshots o copias del hosting y, si el RTO es muy reducido, con replicación de servidores y failover.
Un plugin puede fallar por un error de PHP, falta de espacio o un ataque que comprometa el sitio; por eso la copia externa debe poder sobrevivir a WordPress.
Recupera WordPress completo, no solo archivos
Una restauración correcta recupera base de datos, archivos, código, configuración y secretos desde un punto temporal coherente. Recuperar solo wp-content deja fuera pedidos, usuarios, ajustes y piezas esenciales de la aplicación.
¿Qué debe coincidir al restaurar?
Deben coincidir la base de datos, wp-content, versión de WordPress, PHP, plugins y configuración del servidor. También deben estar disponibles claves de cifrado, variables de entorno, credenciales de correo, DNS, CDN y reglas de Cloudflare.
¿Cómo recuperas pedidos recientes?
Los pedidos posteriores al RPO deben recuperarse desde pasarelas de pago, correos, ERP o registros de WooCommerce, según el caso. Ninguna arquitectura evita esta revisión si el RPO admite pérdida de datos.
¿Qué secretos se olvidan al restaurar?
Las claves API, contraseñas SMTP, claves de pago, certificados y variables de entorno suelen olvidarse. El criterio de éxito debe incluir inicio de sesión, compra de prueba, formulario, correo transaccional, imágenes, caché y tareas programadas.
Anuncio
Prueba el runbook y mide el RTO real
El RTO real se mide desde que se declara la incidencia hasta que WordPress supera las pruebas de negocio. Un runbook documenta responsables, accesos, pasos y decisiones para restaurar sin improvisar bajo presión.
¿Quién restaura si falta el técnico?
El runbook debe nombrar un titular y una persona suplente con acceso de emergencia. Guarda contactos, ubicación de credenciales, proveedor, dominio, Cloudflare, almacenamiento remoto y orden de escalado fuera del WordPress afectado.
¿Cómo pruebas sin romper producción?
Restaura en un entorno aislado con dominio temporal, correos bloqueados y pagos en modo prueba. Así compruebas la integridad sin enviar mensajes reales ni duplicar cobros.
¿Qué métricas debes registrar?
Registra tasa de restauraciones correctas, RTO real, RPO alcanzado, errores y responsable. Una prueba fallida demuestra un riesgo que debe corregirse antes de que ocurra una incidencia real.
| Registro de prueba | Qué anotar | Éxito esperado |
|---|---|---|
| Inicio y fin | Hora de alerta y web operativa | RTO dentro del objetivo |
| Punto restaurado | Fecha y hora real de la copia | RPO dentro del límite |
| Pruebas de negocio | Login, pedido, correo y formulario | Sin fallos críticos |
| Acciones pendientes | Error, responsable y fecha límite | Riesgo corregido |
Preguntas frecuentes
¿Qué es un backup de alta disponibilidad?
Un backup no da alta disponibilidad por sí mismo, porque recupera después de la caída. La disponibilidad se logra con redundancia y failover; el backup protege frente a borrado, corrupción y ransomware.
¿Cuál es la diferencia entre HA y recuperación ante desastres?
La alta disponibilidad reduce cortes cortos, mientras la recuperación ante desastres reconstruye el servicio tras una pérdida grave. HA usa réplicas y conmutación; DR depende de copias externas, runbook y una infraestructura alternativa.
¿Qué son RPO y RTO en WordPress?
RPO indica cuántos datos puedes perder y RTO cuánto puede durar la caída. Por ejemplo, un RPO de una hora exige recuperar como máximo una hora de cambios.
¿Los snapshots del hosting son suficientes?
Los snapshots no bastan si viven en la misma cuenta o proveedor que la web. Mantén al menos una copia externa, cifrada y con versiones que no pueda borrar el acceso habitual.
¿Cada cuánto debo probar una restauración?
Una tienda activa debe probar al menos cada mes y una web menos crítica cada tres meses. Repite la prueba tras cambios de PHP, hosting, DNS, pagos o plugins importantes.
Elige protección según el coste de parar
La protección adecuada depende de pérdidas reales, no de una lista de funciones del hosting. Define RPO y RTO, separa las copias, protege una versión inmutable y mide restauraciones completas antes de añadir una arquitectura compleja.
- Define un RPO con los datos que puedes perder y un RTO con las horas de negocio que puedes asumir.
- Usa replicación para caídas técnicas, pero conserva backups históricos contra ransomware y borrados.
- Protege al menos una copia fuera del proveedor, con cifrado, permisos separados e inmutabilidad.
- Restaura base de datos, archivos, configuración y secretos desde el mismo punto temporal.
- Mide restauraciones reales con un runbook, no con promesas del panel de hosting.
Anuncio
Lecturas adicionales
Si quieres ampliar información sobre este tema, estas fuentes pueden interesarte:
- WordPress de alta disponibilidad: 12 aspectos clave — stackscale.com
- WordPress en Alta Disponibilidad — wpsysadmin.com
- Con 1.000 productos, salva pedidos en Woo: nube o local
- En WooCommerce, un backup no revierte el cobro recurrente
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.