Una tienda puede recuperar WordPress en minutos y seguir perdiendo ventas: si la última copia es de la noche anterior, los pedidos, pagos y cambios de stock posteriores pueden desaparecer. En sitios con una base de datos grande, combinar snapshots, copias externas y binlogs depende del RPO, RTO, volumen de escrituras y presupuesto.
Índice
Anuncio
RPO y RTO deciden cuántos datos puedes perder
El RPO define la antigüedad máxima de los datos que aceptas perder, mientras que el RTO indica cuánto puede tardar la web en volver a operar.
Calcula el RPO con datos que se escriben
Cuenta los pedidos, pagos, usuarios, reservas, formularios, progreso de cursos e imágenes que se generan durante una hora normal y una hora punta. Una tienda con 20 pedidos por hora no debería aceptar perder 24 horas de actividad por costumbre: incluso 30 minutos pueden implicar trabajo duplicado, cobros que revisar y reclamaciones de clientes.
Mide el RTO restaurando de verdad
El RTO incluye descarga o clonación, restauración de archivos, arranque de MySQL, limpieza de caché, comprobación de correos y pruebas de pago. No basta con que el panel del hosting muestre una restauración completada: una web puede cargar en 15 minutos y seguir sin vender si faltan claves, cron, colas de correo o tablas esenciales.
Tabla: copias y snapshots para bases grandes
Los snapshots aceleran la vuelta al servicio, mientras que los backups externos aportan retención, portabilidad y aislamiento.
| Criterio medible | Snapshot de volumen | Backup externo | Binlogs MySQL/MariaDB |
|---|---|---|---|
| RTO habitual | Entre 10 y 60 min | Entre 1 y 8 h | Depende del backup base |
| Pérdida posible | Desde minutos hasta frecuencia | Desde horas hasta frecuencia | Segundos o minutos tras el backup base |
| Coste de lista orientativo | EBS: 0,05 USD/GB/mes | S3: 0,023 USD/GB/mes | Almacenamiento según tamaño |
| Efecto en producción | Bajo o medio, según proveedor | CPU e I/O durante exportación | I/O continuo y espacio local |
| Retención independiente | No siempre | Sí, si está fuera del proveedor | No sin archivado externo |
Lee el coste junto al coste del fallo
El coste mensual del almacenamiento debe compararse con una hora sin ventas, el trabajo de soporte, la conciliación de pagos y la pérdida de confianza. La deduplicación puede reducir espacio, pero no debe darse por hecha: copias cifradas de forma diferente en cada ejecución pueden impedir detectar bloques repetidos.
Comprueba dónde se guardan las copias
Pregunta si las copias están en otra cuenta, región o proveedor, cuántos días se conservan, quién puede borrarlas y si existe inmutabilidad. Un snapshot en la misma cuenta puede desaparecer junto con producción tras un acceso comprometido, un borrado masivo o un incidente del proveedor.
La duración de una copia no depende solo de los gigabytes de la base de datos grande. Un backup lógico debe leer tablas, serializar filas, comprimir datos y enviarlos al almacenamiento externo; por eso una base de 100 GB puede terminar en menos de una hora con discos rápidos y red suficiente, o prolongarse varias horas si comparte I/O con el checkout. Un backup físico suele copiar bloques y puede restaurar antes, pero exige compatibilidad con la versión y configuración del motor.
Mide la ventana de backup en hora punta y fuera de ella, vigila latencia, IOPS, CPU y espacio temporal, y limita la velocidad del proceso si perjudica a los usuarios. El objetivo no es solo que la copia termine, sino que no degrade las ventas ni supere el tiempo de recuperación comprometido.
Snapshots frecuentes para volver rápido al servicio
Los snapshots son útiles para recuperarse rápido de actualizaciones fallidas, despliegues defectuosos o daños amplios en archivos.
Cuándo el snapshot merece su coste
Úsalo antes de actualizar WordPress, plugins, temas, PHP o reglas del servidor. Para una tienda con actividad constante, los snapshots cada 15 a 60 minutos pueden reducir la pérdida operativa, pero conviene mantener pocos puntos recientes, por ejemplo entre 24 y 96 horas, y verificar el tiempo real de restauración.
Qué no protege un snapshot aislado
Un snapshot del mismo hosting no cumple por sí solo una estrategia 3-2-1: tres copias, dos tipos de soporte y una copia fuera de la ubicación principal. Si un atacante controla la cuenta y no hay permisos separados, bloqueo o inmutabilidad, puede borrar tanto la producción como los snapshots.
Un disco externo puede servir como copia adicional desconectada para exportaciones cifradas, pero no debe ser la única copia de una tienda activa. Guárdalo separado del servidor y verifica que la restauración funciona.
- Permite conservar una exportación cifrada fuera de la cuenta del hosting
- Ayuda a crear una copia desconectada frente a borrados remotos o ransomware
- Facilita transportar una restauración de emergencia a otra infraestructura
Elige esto si: necesitas volver al servicio en menos de una hora y mantienes una copia externa independiente. Evítalo como única capa si el proveedor no separa los snapshots de tu cuenta principal.
No todos los snapshots ofrecen la misma consistencia. Un snapshot crash-consistent captura el volumen tal como estaría tras un corte eléctrico: InnoDB suele poder recuperar sus transacciones mediante sus logs al reiniciar, pero puede requerir una recuperación más lenta y no garantiza que otros servicios hayan quedado coordinados. Un snapshot application-consistent pausa o coordina las escrituras, vacía los datos pendientes cuando corresponde y registra un estado recuperable de MySQL o MariaDB antes de crear la imagen.
En una base de datos grande con pedidos activos, comprueba si el proveedor integra agentes, hooks previos o congelación de MySQL; si no lo hace, valida el snapshot en un entorno aislado antes de considerarlo apto para restaurar producción.
MySQL y binlogs para recuperar pedidos recientes
Los binlogs de MySQL o MariaDB registran cambios y permiten recuperar operaciones posteriores a un backup base hasta un instante concreto.
Recupera hasta antes del error humano
La recuperación a un punto en el tiempo parte de una copia completa válida y aplica binlogs hasta segundos antes de un borrado, una importación errónea o una actualización dañina. Para WooCommerce, membresías y marketplaces, la combinación más sólida es backup base externo, binlogs archivados y snapshots rápidos.
Evita dumps que bloquean la tienda
En bases grandes, un dump SQL puede tardar horas y generar I/O durante los pedidos. Usa InnoDB, verifica que la herramienta toma una instantánea transaccional y mide el impacto antes de programarla. PhpMyAdmin puede servir para tareas concretas, pero no suele ser adecuado para restaurar decenas de gigabytes en producción.
Elige esto si: gestionas transacciones frecuentes y puedes vigilar espacio, retención y restauraciones en un entorno aislado.
Frecuencia por tipo de WordPress y coste real
La frecuencia debe responder al volumen de escrituras y al coste económico de perderlas, no al tamaño total de la web.
Elige según las escrituras del proyecto
| Tipo de sitio | RPO recomendado | Combinación aconsejada | Retención mínima |
|---|---|---|---|
| WooCommerce activo | 5 a 60 min | Snapshot, backup externo y binlogs | 30 a 90 días |
| Membresía o LMS | 15 min a 4 h | Snapshot y backup externo | 30 a 90 días |
| Marketplace | 5 a 30 min | Snapshot, binlogs y copia inmutable | 90 días o más |
| Blog editorial | 4 a 24 h | Backup diario y snapshot previo a cambios | 30 días |
| Web corporativa | 24 h | Backup diario o semanal probado | 30 días |
Reduce CPU, I/O y ventana de copia
Programa copias fuera de las horas de compra, controla el cron real del servidor y evita procesos solapados. Separa archivos y base de datos si es posible, excluye cachés regenerables y temporales, pero no excluyas wp-content, configuraciones ni tablas de plugins sin conocer los datos que contienen.
Prueba y documenta la restauración
Mantén un runbook con responsables, credenciales de emergencia, ubicación de copias, orden de restauración y comprobaciones de checkout, usuarios y correos. Restaura en un entorno aislado cada 3 o 6 meses y registra la duración real para confirmar que el RTO sigue siendo viable.
Los plugins simplifican las copias de seguridad de WordPress, la programación, el envío a almacenamiento externo y la restauración de WordPress, pero no eliminan los límites del servidor. En copias de seguridad de WooCommerce con tablas de varios gigabytes, un plugin que comprime todo dentro de PHP puede agotar memoria, dejar procesos incompletos o competir con PHP-FPM y MySQL durante el checkout. Es más seguro usar el plugin para coordinar archivos, avisos y retención de copias, mientras una herramienta nativa del servidor o del servicio gestionado realiza la copia consistente de MariaDB o MySQL.
Configura alertas ante fallos, verifica que cada ejecución llegó al destino y registra el tamaño esperado; una tarea marcada como completada no demuestra que la recuperación de datos sea posible.
Anuncio
Preguntas y respuestas
¿Un snapshot es una copia de seguridad?
No siempre. Solo es suficiente si tiene retención, permisos separados y ubicación independiente.
¿Cada cuánto debo hacer copia de seguridad de una tienda?
Haz un backup externo diario y snapshots cada 15 a 60 minutos si tu RPO no admite perder más tiempo.
¿Puedo hacer una copia de WordPress sin plugin?
Sí, mediante herramientas del servidor, SSH, SFTP o panel, siempre que automatices retención, almacenamiento externo y pruebas.
¿UpdraftPlus o BackWPup bastan para una base de datos grande?
Pueden servir si completan la copia y restauran sin agotar recursos. Revisa memoria, tiempos y procesos largos.
¿Qué pasa si solo quiero recuperar un pedido?
Restaura primero una copia en un entorno aislado, localiza los datos y valida cómo reintroducirlos sin dañar producción.
¿Los backups del hosting gestionado son suficientes?
Son una capa útil, pero no la única: confirma descarga, retención y separación de infraestructura.
¿Cómo sé si mi backup está corrupto?
Solo restaurándolo y comprobando archivos, tablas, usuarios y funciones críticas.
¿Debo cifrar las copias de seguridad?
Sí, si contienen datos personales o pedidos; conserva las claves separadas de las copias.
La estrategia segura combina velocidad e independencia
Para un WordPress comercial con una base de datos grande, usa snapshots frecuentes para reducir el RTO, backups externos e inmutables para disponer de retención independiente y binlogs cuando el RPO exige perder solo minutos. Define primero cuánto dato puedes perder, cuánto tiempo puedes parar y cuánto tarda una restauración completa; después ajusta la política, controla los accesos y prueba la recuperación periódicamente.
- Un rollback puede borrar pedidos posteriores al snapshot
- Backup en Microsoft Azure para WordPress: protege datos
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.