Un backup diario, perfecto para un blog corporativo, puede significar perder un día entero de pedidos en una tienda activa. Y perder pedidos no es solo un problema técnico, es un cliente que pagó, cuyo pedido “desaparece”, y que probablemente no vuelva a confiar en tu tienda si eso ocurre.
Esta guía cubre específicamente qué cambia en la estrategia de backup cuando hay una tienda WooCommerce de por medio.
Para los fundamentos generales de backup, parte de Backups y Recuperación de WordPress: Guía Completa; para el panorama de gestión de WooCommerce, parte de Gestión y Mantenimiento de Tiendas WooCommerce.
Por qué la frecuencia estándar no siempre es suficiente
Un backup diario asume que puedes permitirte perder hasta 24 horas de cambios si algo falla justo antes del siguiente backup. En una tienda con ventas constantes, eso puede significar decenas de pedidos perdidos, no solo el contenido, sino transacciones reales con clientes reales esperando su compra.
| Volumen de pedidos diarios | Frecuencia de backup recomendada |
|---|---|
| Pocos pedidos (menos de 5 al día) | Diaria puede ser suficiente |
| Volumen moderado (5-30 pedidos al día) | Cada pocas horas |
| Alto volumen (30+ pedidos al día) | Prácticamente en tiempo real, o backups incrementales muy frecuentes |
Ese hueco entre “el último backup” y “el momento del fallo” es lo que en copias de seguridad se llama el punto de recuperación: cuánto trabajo estás dispuesto a perder si algo se rompe. En un blog, ese punto puede ser de 24 horas sin drama, como mucho reescribes un artículo. En una tienda, cada hora dentro de esa ventana puede contener pedidos pagados que no existen en ningún otro sitio de tu WordPress. Y a diferencia de un post, un pedido no lo puedes “volver a escribir”: o está respaldado, o el cliente pagó por algo de lo que tu tienda ya no tiene constancia.
Por eso la pregunta correcta no es “¿cada cuánto hago backup?”, sino “¿cuántos pedidos me puedo permitir perder si tengo que restaurar ahora mismo?”. Si la respuesta es “ninguno”, la frecuencia tiene que acercarse al ritmo real de ventas, no al del calendario. Y ese ritmo casi nunca es plano: una tienda que en un día normal factura cinco pedidos puede hacer cincuenta durante una campaña. La frecuencia de backup en rebajas o en un lanzamiento no debería ser la misma que en agosto.
Qué debe incluir un backup completo de WooCommerce
Además de los componentes estándar de cualquier WordPress (archivos y base de datos general), WooCommerce añade datos específicos que deben estar siempre incluidos:
- Pedidos: cada transacción, con su estado (pendiente, procesando, completado, reembolsado).
- Datos de clientes: cuentas registradas, direcciones de facturación y envío.
- Inventario: niveles de stock actuales por producto y variación.
- Configuración de pasarelas de pago: ajustes específicos de cada método de pago habilitado.
- Cupones y descuentos activos: si tu tienda usa promociones, su configuración también debe respaldarse.
Todos estos datos viven en la base de datos, por lo que un backup completo de base de datos los cubre, el riesgo está en asumir que “hacer backup de WordPress” cubre automáticamente todo esto sin verificarlo específicamente.
Dónde viven de verdad los pedidos (y por qué eso cambia las reglas)
Durante años, WooCommerce guardaba cada pedido como un tipo de entrada más dentro de las tablas genéricas de WordPress, las mismas donde viven páginas y posts. Las versiones recientes usan por defecto un almacenamiento dedicado de pedidos (conocido como HPOS, almacenamiento de pedidos de alto rendimiento): los pedidos pasan a sus propias tablas (wc_orders, wc_order_addresses, wc_orders_meta, entre otras), separadas del contenido normal.
¿Por qué importa esto para un backup? Porque cualquier copia que no respalde la base de datos completa (todas las tablas, no una selección) corre el riesgo de dejarse fuera justo las tablas donde ahora viven tus ventas. Un volcado íntegro de la base de datos las incluye sin que tengas que hacer nada especial; el problema aparece con configuraciones “a medida” que excluyen tablas para ahorrar espacio o acelerar la copia. La regla es simple: en una tienda, no excluyas tablas de la base de datos salvo que sepas exactamente qué estás dejando fuera y por qué.
Un matiz relacionado: los carritos en curso viven en su propia tabla de sesiones. No son pedidos (son compras a medias), pero conviene tenerlos en cuenta al restaurar. Volver a un backup de hace unas horas puede “resucitar” carritos abandonados o borrar sesiones activas de gente que está comprando en ese preciso momento. Es un motivo más para restaurar con cabeza y, siempre que se pueda, en franjas de poca actividad.
Dónde guardar la copia: no vale de nada si está donde se rompe
El error más caro que vemos entrar por soporte no es no tener backup, es tener el backup en el mismo servidor que acaba de fallar. Si el disco se corrompe, el hosting sufre un incidente o alguien borra por error la instalación, una copia guardada “al lado” desaparece con todo lo demás. La regla 3-2-1 (tres copias, en dos soportes distintos, con al menos una fuera del servidor) no es una formalidad para tiendas: es la diferencia entre “restauramos en veinte minutos” y “no hay nada que restaurar”.
En una tienda esto pesa aún más porque el backup no solo protege de un fallo técnico, sino de un ataque. Si alguien compromete tu WordPress, lo primero que puede tocar es lo que tenga a mano en el propio servidor. Una copia externa e independiente es la que sobrevive a ese escenario. Profundizamos en el porqué en Backup externo vs. backup del hosting.
Backup de plugin o backup del hosting: qué cambia en una tienda
No todos los backups son iguales, y en una tienda las diferencias se notan. Estos son los enfoques más habituales y con qué encaja cada uno:
| Método | Cómo funciona | Con qué encaja |
|---|---|---|
| Completo programado | Copia todo (archivos + BD) cada X horas | Tiendas de volumen bajo o medio |
| Incremental | Copia solo lo cambiado; reconstruye con la cadena entera | Tiendas de alta frecuencia sin sobrecargar el servidor |
| Snapshot del hosting | El proveedor “congela” el estado del disco completo | Recuperación rápida ante desastre; no sustituye la copia externa |
| Copia externa (offsite) | Guarda el backup en otra ubicación o proveedor | Requisito de la 3-2-1; imprescindible pase lo que pase |
Lo importante: estos métodos no compiten, se combinan. Un snapshot del hosting te saca rápido de un apuro, pero si el incidente afecta al propio hosting, la copia externa es la que te salva. En una tienda quieres las dos cosas.
Backups incrementales: la solución para alta frecuencia
Hacer un backup completo cada pocas horas puede ser pesado en recursos si tu tienda tiene mucho contenido e imágenes de producto. Los backups incrementales (que solo copian lo que ha cambiado desde el último, no todo de nuevo) son la solución habitual para tiendas que necesitan alta frecuencia sin sobrecargar el servidor cada pocas horas.
El precio a pagar es que la restauración depende de una cadena: el backup completo base más todos los incrementales posteriores. Si se pierde o corrompe un eslabón de esa cadena, la restauración puede quedar incompleta. Por eso un sistema incremental bien montado hace de vez en cuando un backup completo nuevo que “reinicia” la cadena, y verifica que los incrementales se están escribiendo de verdad, no solo que el proceso “dice” que terminó. El error clásico es fiarse del “backup correcto” del panel durante meses y descubrir el día del desastre que la cadena estaba rota desde hacía semanas.
Cuándo el tiempo real es exagerado (y cuándo se queda corto)
Es fácil leer “backup en tiempo real” y pensar que toda tienda lo necesita. No es así, y montarlo sin necesidad añade coste y complejidad para nada.
Se queda corto un backup diario cuando: entran pedidos a lo largo de todo el día, cada pedido representa dinero ya cobrado, y no tienes ninguna otra fuente fiable para reconstruir lo que se pierda en la ventana. Ahí la frecuencia tiene que subir.
Es exagerado el tiempo real cuando: tu tienda hace un puñado de pedidos a la semana, el catálogo cambia poco, y la pasarela de pago te deja un registro completo de cada cobro. En ese escenario, un backup cada pocas horas (o incluso diario en temporadas tranquilas) cubre el riesgo real sin gastar recursos de más. Adaptar la frecuencia al momento (más agresiva en campañas, más relajada en valle) suele ser más inteligente que fijar una única cadencia todo el año.
La pregunta que zanja la duda es siempre la misma: si tuvieras que restaurar en el peor momento posible, ¿cuánto perderías y podrías reconstruirlo desde otro sitio? Si la respuesta duele, sube la frecuencia.
Verificación: aún más crítica en una tienda
El paso de probar que un backup se puede restaurar correctamente, ya crítico en cualquier WordPress, lo es todavía más en una tienda: una restauración fallida en pleno pico de ventas (por ejemplo, durante una campaña o rebajas) tiene un coste directo mucho mayor que en un blog informativo.
La prueba de restauración no se hace sobre la tienda en producción, se hace en un entorno de pruebas aislado, precisamente para no tocar los pedidos reales mientras compruebas. Si aún no tienes uno, montar un staging de WordPress es el sitio natural donde ensayar restauraciones sin riesgo.
Qué verificar específicamente en la restauración de prueba
- Que los pedidos recientes aparecen correctamente con su estado real (no basta con que “cargue” la tienda: entra al listado de pedidos y comprueba los últimos).
- Que el inventario refleja los niveles correctos, no una versión desactualizada que genere ventas de productos sin stock.
- Que las cuentas de clientes y su historial de compra se mantienen intactos.
- Que las pasarelas de pago siguen configuradas y conectadas, una restauración que deja el checkout sin método de pago es tan grave como perder pedidos.
Reconciliar con la pasarela tras un incidente
Cuando algo sale mal y toca restaurar, tu WordPress no es la única fuente de verdad sobre lo que se cobró. La pasarela de pago (la plataforma que procesa las tarjetas) tiene su propio registro de cada transacción, y ese registro no se pierde porque tu web falle. Es tu red de seguridad.
Tras cualquier restauración que abarque un periodo con ventas, el proceso es:
- Anota la fecha y hora exacta del backup que has restaurado.
- Entra al panel de tu pasarela y lista los cobros posteriores a ese momento.
- Cruza cada cobro con los pedidos que ahora aparecen en WooCommerce.
- Cualquier cobro sin pedido correspondiente es una venta que hay que recuperar a mano: cliente que pagó y cuyo pedido quedó fuera de la ventana del backup.
Esta reconciliación es tediosa, pero es lo que evita que un cliente pague y se quede sin producto. Tener acceso al panel de la pasarela (y saber usarlo) forma parte de la estrategia de backup de una tienda tanto como el backup en sí.
Backup antes de cada actualización relevante
Además de la rutina automática, un backup manual adicional es imprescindible antes de actualizar WooCommerce, cualquier plugin de pagos, o el tema, no solo por el motivo general que aplica a cualquier WordPress, sino porque una actualización mal probada en una tienda activa puede generar pedidos duplicados, fallos de cálculo de precios, o pérdida de sincronización de stock durante el tiempo que tarde en detectarse el problema.
La combinación segura es sencilla: backup manual justo antes, prueba de la actualización en staging, y solo entonces aplicarla en producción, idealmente en una franja de poca actividad. En una tienda, “actualizar y ver qué pasa” no es una opción; es la forma más rápida de romper el checkout con clientes intentando comprar.
Preguntas Frecuentes
¿Necesito backups en tiempo real para mi tienda? Solo si el volumen de pedidos es muy alto. Para la mayoría de tiendas pequeñas y medianas, backups cada pocas horas son suficientes.
¿Los pedidos se pierden si restauro un backup anterior? Sí, cualquier pedido creado después del momento del backup restaurado se pierde, a menos que se pueda recuperar de otra fuente (por ejemplo, el registro de la pasarela de pago).
¿Cómo sé si mi backup incluye realmente los datos de pedidos e inventario? Verifica restaurando en un entorno de prueba y comprobando específicamente que los pedidos y el stock recientes aparecen correctamente, no solo el contenido general de la web.
¿Un backup incremental es tan seguro como uno completo? Sí, siempre que la cadena completa de incrementales más el backup completo base se mantenga íntegra, si se pierde un eslabón de la cadena, la restauración puede quedar incompleta.
¿Debo hacer backup de las notificaciones de la pasarela de pago también? Es recomendable tener acceso al panel de tu pasarela como fuente adicional de verificación de transacciones, independiente del backup de WordPress. No sustituye al backup, lo complementa.
¿Qué pasa con los pedidos si mi tienda se cae justo durante una compra? Depende del punto exacto del proceso en que ocurra el fallo, por eso es importante revisar tanto los registros de WordPress como los de la pasarela de pago tras cualquier incidente, para reconciliar posibles discrepancias.
¿La regla 3-2-1 de backups aplica igual a una tienda que a un blog? Sí, los mismos principios de ubicación externa y múltiples copias aplican, con la diferencia de que la frecuencia debe ajustarse al volumen real de transacciones.
¿Debo notificar a mis clientes si restauro un backup que afecta a su pedido? Es una buena práctica de transparencia si detectas alguna discrepancia en su pedido tras una restauración, especialmente si su experiencia de compra se vio afectada.
¿Sirve el snapshot que hace mi hosting como único backup? Como red de recuperación rápida, ayuda; como único backup, no. Si el incidente afecta al propio hosting, el snapshot puede caer con él, por eso necesitas también una copia externa e independiente.
¿Cada cuánto debería probar una restauración? Con una periodicidad fija (por ejemplo, al menos una vez al trimestre) y siempre tras cualquier cambio grande en la infraestructura o en los plugins de pago. Un backup que nunca se ha restaurado es una suposición, no una garantía.
¿Tengo que cambiar la frecuencia en campañas o rebajas? Sí, es lo recomendable. En los picos entran muchos más pedidos por hora, así que la ventana de pérdida asumible se estrecha: subir la frecuencia durante la campaña y volver a la habitual después es lo sensato.
Conclusión
El backup de una tienda WooCommerce no es solo “el mismo backup de WordPress pero de una tienda”: la frecuencia, la verificación de datos específicos (pedidos, stock, pasarelas) y la velocidad de reacción ante un fallo tienen un estándar más alto, proporcional a lo que hay en juego: ventas reales, en tiempo real.
Si prefieres no gestionar tú mismo esta frecuencia y verificación, en Avantys la incluimos dentro de la gestión completa de tiendas en Gestión WordPress.
Artículos relacionados
- Gestión y mantenimiento de tiendas WooCommerce
- Backups y recuperación de WordPress: guía completa
- Seguridad en WooCommerce: cómo proteger pagos y datos de clientes
- Actualizar WooCommerce sin romper el checkout
- Cómo restaurar un backup de WordPress paso a paso
¿Y si tu WordPress lo lleváramos nosotros?
Actualizaciones, seguridad, backups verificados, staging y rendimiento, gestionado de forma continua por una persona que responde, donde ya lo tengas o te lo montamos. Auditoría gratuita de tu web actual.
