Son las 10:15, entra un pedido y WooCommerce confirma el pago, pero la web cae tras una actualización. El backup del hosting es de la madrugada, la carpeta de imágenes pesa decenas de gigas y restaurar la copia completa podría borrar los pedidos y cambios de stock de las últimas horas. Con más de 1.000 productos, una copia “disponible” no siempre es una copia utilizable.
En materia de backups locales vs en la nube para tiendas con catálogo >1000 productos, no conviene elegir solo una opción: la alternativa más segura suele ser una estrategia híbrida 3-2-1-1-0. Prioriza copias incrementales frecuentes de base de datos y pedidos, mantiene archivos y medios con otra cadencia y valida restauraciones para recuperar ventas sin paralizar la operativa.
Índice
Anuncio
Con más de 1.000 productos mandan RPO y RTO
Una tienda WooCommerce con más de 1.000 productos debe elegir su sistema de copias según el RPO y el RTO. El RPO indica cuántos datos aceptas perder, como máximo, tras un fallo; el RTO marca cuánto tiempo puede estar la tienda sin vender antes de causar un daño serio al negocio.
Piensa en el RPO como la distancia entre dos fotos de tu contabilidad. Si guardas una foto cada 24 horas y el servidor cae a las 18:00, podrían faltar hasta 18 horas de pedidos, pagos, cambios de stock y cupones usados. En una tienda con 100 pedidos diarios, eso puede suponer decenas de operaciones que habrá que reconstruir manualmente.
El RTO no termina cuando alguien dice que la copia se ha descargado. Incluye descargarla, descomprimirla, escribir archivos en el servidor, importar la base de datos MySQL, limpiar cachés y comprobar que el carrito, el checkout y la pasarela de pago funcionan.
RPO de pedidos frente al de imágenes
Los pedidos, clientes, devoluciones, cupones e inventario cambian durante el día. Casi todos viven en la base de datos MySQL, que es el archivador donde WooCommerce guarda la información que hace funcionar la tienda.
Las imágenes de producto cambian menos. Por eso, una copia incremental de la base de datos cada 15, 30 o 60 minutos puede convivir con una copia diaria de wp-content/uploads, la carpeta que suele contener las imágenes y documentos subidos.
Una tienda con menos de 20 pedidos al día puede aceptar un RPO de entre 1 y 4 horas. Con entre 20 y 100 pedidos diarios, conviene bajar a entre 30 y 60 minutos. Por encima de 100 pedidos al día, perder una hora puede ser demasiado.
RTO significa volver a cobrar
Un RTO útil responde a una pregunta sencilla: ¿cuándo podrá un cliente terminar una compra real? Una página de inicio visible no basta si falla el stock, Redsys, Stripe, PayPal o el correo de confirmación.
El error más frecuente que se detecta aquí es confundir una copia disponible con una recuperación disponible. Un archivo de 150 GB puede estar correctamente guardado y, aun así, tardar entre 4 y 12 horas en restaurarse si el servidor tiene poco disco, I/O limitado o mala conexión.
En Madrid, donde muchas pymes trabajan con hosting gestionado y fibra rápida en oficina pero servidores remotos compartidos, la velocidad que importa es la del servidor que restaura, no la de la conexión desde el despacho. Saber esto fija el límite de riesgo; la siguiente decisión consiste en asignar cada perfil de tienda a una arquitectura concreta.
La matriz para elegir local, nube o híbrido
El backup híbrido suele ser la opción más equilibrada para una tienda española con más de 1.000 productos. Combina una copia cercana para recuperar antes y otra externa, con versiones protegidas, para sobrevivir a un fallo del servidor, un borrado humano o un ataque.
Las copias locales pueden estar en un disco distinto, un NAS o un servidor separado. Las copias en la nube se guardan en servicios externos, como Amazon Web Services, Google Cloud o Microsoft Azure. Una estrategia híbrida une ambos destinos y reduce el riesgo de depender de un único punto.
La regla práctica es clara: si tu RTO es inferior a 4 horas, no dependas solo de descargar una copia grande desde almacenamiento remoto. Mantén una copia reciente accesible desde un destino separado del servidor de producción.
| Perfil | Pedidos/día | Base MySQL | Medios | RPO | RTO | Estrategia |
|---|---|---|---|---|---|---|
| Catálogo amplio, venta moderada | Menos de 20 | Menos de 2 GB | Menos de 50 GB | 1 a 4 horas | 8 a 12 horas | Nube versionada más copia local semanal |
| Tienda activa | 20 a 100 | 2 a 10 GB | 50 a 250 GB | 30 a 60 min | 2 a 6 horas | Híbrido, MySQL frecuente y archivos diarios |
| Venta continua o campaña | Más de 100 | Más de 10 GB | Más de 250 GB | 15 a 30 min | Menos de 4 horas | Híbrido con copia externa inmutable |
Tamaño de MySQL y biblioteca media
Una base de datos de 8 GB no se comporta como un catálogo con 300 GB de fotos. La primera exige atención por sus cambios continuos; la segunda condiciona el tiempo de copia, el espacio de disco y el ancho de banda necesario para recuperar.
Las tiendas que suben cientos de fotografías, fichas PDF o variaciones visuales cada día deben aumentar también la frecuencia de archivos. Si el catálogo no cambia, copiar esos mismos 250 GB cada hora solo carga el servidor y eleva el coste.
Presupuesto y destino de la copia
El coste no es solo la cuota mensual de almacenamiento. También cuentan el espacio temporal para restaurar, las solicitudes al almacenamiento de objetos, la transferencia de salida y el tiempo técnico durante una incidencia.
Para una pyme, un disco externo cifrado de 4 TB puede servir como copia offline adicional si se conecta solo durante el proceso de copia y se guarda bajo control. No sustituye una política cloud, pero sí aporta una barrera útil frente a ransomware que cifre las unidades conectadas.
Un disco externo de 4 TB puede alojar una copia offline rotativa cuando el tamaño de medios hace lenta una restauración desde la nube. Debe cifrarse y desconectarse al terminar la copia.
- Permite conservar una versión aislada de wp-content y de la base de datos fuera del servidor de producción
- Reduce la dependencia de descargas largas durante una caída de hosting
- Facilita mantener dos rotaciones físicas guardadas en ubicaciones separadas
Una copia local aislada solo tiene sentido si existe otra externa y verificable. La matriz define el destino correcto, pero el siguiente punto decide qué parte de WooCommerce merece la frecuencia más alta.
Las copias de seguridad WooCommerce pueden generarse con un plugin, con el sistema del hosting o mediante un backup manual por SSH, SFTP y mysqldump, pero no ofrecen el mismo control. Un plugin bien configurado facilita automatizar backups incrementales de base de datos y el backup de wp-content/uploads hacia almacenamiento externo; el backup del hosting es una capa adicional útil, aunque hay que confirmar su frecuencia, retención, alcance y si permite restaurar solo MySQL sin reemplazar archivos.
El método manual aporta control para migraciones o incidencias complejas, pero depende de ejecución y documentación técnica. En las copias de seguridad para catálogos grandes, la combinación más práctica suele ser plugin o herramienta gestionada para las copias frecuentes, hosting como contingencia y exportaciones manuales verificadas antes de cambios críticos.
Los pedidos necesitan más frecuencia que las fotos
La base de datos de WooCommerce debe copiarse con más frecuencia que las imágenes porque concentra pedidos, pagos, clientes, stock, cupones y ajustes. Para una tienda activa, una copia incremental de MySQL cada 15 a 60 minutos suele proteger mejor las ventas que un backup completo diario.
Un backup completo guarda todos los datos seleccionados. Un backup incremental conserva solo los cambios desde la última copia, como apuntar en una libreta únicamente lo que ha cambiado desde ayer. El incremental reduce transferencia y carga, pero necesita una cadena de restauración íntegra.
Las copias diferenciales guardan cambios desde el último backup completo. Pueden ser más simples de restaurar que una cadena larga de incrementales, aunque crecen con los días. La mejor elección depende de la herramienta, el espacio y el RTO real.
Pedidos, clientes y stock primero
El inventario puede cambiar aunque no se publique ningún producto nuevo. Una venta, una devolución, una cancelación o una reserva de stock modifica datos que pueden causar sobreventa si desaparecen tras una restauración.
Lo que demuestra la práctica en estos casos es que el backup diario completo da una falsa sensación de seguridad cuando la tienda vende durante el día. Protege la estructura general, pero deja expuesto el tramo de negocio creado entre dos ejecuciones.
En instalaciones con High-Performance Order Storage o HPOS, WooCommerce puede guardar pedidos en tablas específicas. Antes de cambiar de herramienta, comprueba que exporta y restaura esas tablas, sus metadatos y los índices necesarios.
Archivos que admiten otra cadencia
Las fotos, el tema hijo, plugins, archivos de idioma y documentos suelen admitir una copia diaria. Esto reduce el consumo de I/O, es decir, las operaciones de lectura y escritura del disco que pueden ralentizar una tienda compartida.
Hay una excepción importante: si un equipo carga cada mañana cientos de imágenes de recambios o moda, esos archivos son datos operativos. En ese caso, programa copias de medios cada pocas horas o después de cada importación de catálogo.
Separar prioridades baja el tamaño de cada copia y mejora la recuperación. Aun así, una nube bien configurada puede ser lenta cuando llega el momento de traer muchos gigabytes.
La nube puede romper el RTO por egress e I/O
Una copia en la nube no garantiza una recuperación rápida. Restaurar 100 GB a una velocidad efectiva de 100 Mbps requiere alrededor de 2 horas y 15 minutos solo para transferir los datos, antes de descomprimir, escribir archivos e importar MySQL.
La fórmula básica es tamaño de copia dividido entre velocidad efectiva de transferencia. La palabra efectiva importa: una línea de 1 Gbps no mantiene siempre 1 Gbps, y el servidor puede limitar procesos, disco, CPU o conexiones SFTP y SSH.
Cloudflare y otros CDN aceleran la entrega de imágenes a visitantes. No son una copia de seguridad de WooCommerce, porque no guardan un estado restaurable de pedidos, clientes ni configuraciones de la base de datos.
Descarga, disco e importación
Una descarga de 100 GB a 1 Gbps puede rondar los 15 minutos en condiciones ideales. En un caso normal hay que sumar margen por cifrado, congestión, descompresión, I/O, permisos de archivos y carga de tablas; el proceso total puede pasar de 1 a 4 horas.
Un caso habitual: se guarda un archivo comprimido de 180 GB en almacenamiento externo, pero el VPS solo tiene 200 GB libres. La restauración falla porque necesita espacio para el archivo descargado, los archivos extraídos y una base de datos temporal.
Egress y capas de almacenamiento
El egress es la transferencia de salida desde un proveedor cloud hacia tu servidor. Algunos servicios cobran esa salida, cobran llamadas API o tardan más si la copia está en una capa fría pensada para guardar durante meses.
Dropbox y Google Drive pueden ser destinos secundarios en tiendas pequeñas o medianas. Pero no reemplazan el control de acceso, el versionado, las alertas y el plan de restauración que necesita un comercio con pedidos diarios.
Antes de continuar, hay algo que debes saber: una copia externa sincronizada sin protección puede ser alcanzada por el mismo ataque que daña producción.
La regla 3-2-1-1-0 frena el daño de ransomware
La estrategia 3-2-1-1-0 mantiene tres copias, en dos soportes distintos, con una copia fuera de producción, una inmutable u offline y cero errores demostrados en pruebas. Para WooCommerce, esta regla convierte el backup en un plan de recuperación ante desastres y no en una carpeta más.
Una copia inmutable no puede modificarse ni borrarse durante el periodo fijado. Una copia offline permanece desconectada. Ambas protegen frente a ransomware, que busca cifrar archivos locales, unidades montadas y credenciales cloud accesibles.
El Instituto Nacional de Ciberseguridad recomienda mantener copias de seguridad y protegerlas frente a accesos no autorizados dentro de las medidas de continuidad. Puede consultarse su información pública en INCIBE.
Una cuenta cloud no basta
Una carpeta cloud sincronizada puede replicar un borrado o un cifrado malicioso. Si el atacante obtiene las mismas credenciales que usa WordPress, el hosting o el plugin de backup, puede intentar borrar también el histórico.
El error más frecuente que se detecta aquí es guardar todas las copias en el mismo servidor o en la misma cuenta sin MFA. MFA es una segunda prueba de acceso, como un código temporal en el móvil además de la contraseña.
Usa cuentas separadas para producción y backups, permisos mínimos, cifrado en tránsito y cifrado en reposo. El primero protege durante el envío; el segundo protege cuando el archivo queda almacenado.
RGPD, región y retención
Los pedidos y clientes contienen datos personales. El Reglamento General de Protección de Datos, la LOPDGDD y los contratos con proveedores obligan a saber dónde se procesan y guardan esos datos.
Conviene priorizar regiones de España, la Unión Europea o el Espacio Económico Europeo cuando el análisis de riesgos lo requiera. Documenta también la retención: conservar copias entre 30 y 90 días suele dar margen ante fallos detectados tarde, aunque el plazo depende de volumen, coste y obligaciones del negocio.
La inmutabilidad conserva la copia, pero no evita que una restauración antigua borre ventas nuevas. Ese riesgo se controla con un procedimiento de reconciliación.
Anuncio
Restaurar y probar evita perder pedidos recientes
Restaurar una copia completa de WooCommerce puede sobrescribir pedidos creados después del punto de recuperación. Si el backup es de las 10:00 y la caída ocurre a las 16:00, los pagos posteriores pueden existir en Stripe, PayPal o Redsys, pero no en la base restaurada.
La primera acción no debería ser pulsar “restaurar” sobre producción. Activa modo mantenimiento, detén importaciones, renovaciones automáticas y sincronizaciones de stock, y registra la hora exacta del incidente y de la última copia sana.
Cuando el RTO lo permite, restaura primero en staging. Staging es una copia aislada de la tienda para hacer pruebas sin cobrar a clientes ni enviar correos reales.
Exporta antes de tocar producción
Exporta pedidos, clientes, notas, reembolsos, cupones y movimientos de stock posteriores al backup. Conserva los identificadores internos de pedido y los identificadores de transacción de cada pasarela.
La recomendación que se repite al comparar las principales fuentes especializadas de WooCommerce y recuperación de datos es preservar el estado actual antes de sustituirlo. Sin esa exportación, reconstruir ventas puede depender de correos, extractos bancarios y hojas de cálculo.
Después de restaurar, reimporta de forma controlada o reconstruye los pedidos confirmados. Nunca cargues un CSV sin revisar campos, relaciones y estados, porque puede duplicar ventas o descontar stock dos veces.
Conciliar pagos y stock
Conciliar significa comparar dos registros que deberían coincidir. Revisa ID de pedido, ID de transacción, importe, moneda, estado de captura, reembolso y fecha frente a Stripe, PayPal, Redsys u otra pasarela usada.
Un pago autorizado no es igual que un pago capturado. Los reembolsos y pagos pendientes también deben entrar en el listado, porque tratar todos como cobros cerrados puede crear errores contables.
Una prueba trimestral revela la verdad
Una restauración de prueba cada tres meses permite medir si la copia cumple el RTO. No basta con validar que el ZIP abre: hay que comprobar productos simples y variables, imágenes, stock, cupones, impuestos, envíos, carrito, checkout y pasarelas en modo de prueba.
Registra la fecha, tamaño de backup, minutos de descarga, importación MySQL, restauración de archivos, incidencias y RTO final. El objetivo “cero” de 3-2-1-1-0 significa cero errores críticos conocidos tras esa validación, no que un sistema sea infalible.
- Comprueba productos, variaciones, precios, atributos, categorías e imágenes.
- Revisa pedidos, clientes, devoluciones, stock y cupones creados antes del punto de copia.
- Prueba carrito, impuestos, métodos de envío y checkout sin enviar correos ni cobrar dinero real.
- Documenta permisos, versión de PHP, WordPress, WooCommerce y plugins activos.
Esto funciona bien en teoría, pero en la práctica fallan límites de memoria PHP, tiempos de espera, tablas incompletas y permisos incorrectos. Medir el ensayo convierte una promesa de backup en un tiempo de recuperación defendible.
Si tu backup tarda más de lo que tu tienda puede estar cerrada, un servicio de mantenimiento WordPress puede revisar el RPO, el RTO, la retención y una restauración de prueba antes de una migración o una campaña de ventas.
Dudas habituales
¿Cómo hago una copia de seguridad de WooCommerce?
Una copia de WooCommerce debe incluir MySQL, wp-content, configuración y una copia externa. Para ventas continuas, respalda MySQL cada 15 a 60 minutos y archivos al menos una vez al día, verificándolo en staging.
¿Dónde guardo las copias de seguridad de WooCommerce?
Guarda una copia fuera del hosting y otra en un destino distinto o offline. Amazon Web Services, Google Cloud, Microsoft Azure, Dropbox o Google Drive pueden servir según tamaño, acceso, versionado y requisitos del RGPD.
¿Cada cuánto debo hacer backup de WooCommerce?
La base de datos debe copiarse cada 15 a 60 minutos si la tienda vende de forma continua. Los archivos pueden copiarse cada 24 horas, salvo que haya importaciones o subida intensa de imágenes.
¿Cómo restauro WooCommerce sin perder pedidos?
Exporta los pedidos posteriores a la copia, concilia los pagos y reimporta solo los registros validados. Siempre que el RTO lo permita, prueba primero la restauración en staging.
¿Es mejor guardar backups en local o en la nube?
El backup híbrido suele ser mejor para una tienda WooCommerce activa porque combina velocidad local y redundancia externa. La nube sola puede incumplir el RTO por transferencia, egress o límites de disco.
¿Vale la pena un backup incremental en la nube?
Un backup incremental merece la pena cuando reduce la copia de cambios frecuentes sin cargar el servidor. Debe conservar una cadena restaurable, retención suficiente y pruebas reales de recuperación.
La decisión segura para tu WooCommerce
La mejor decisión para una tienda con catálogo grande es separar la protección de pedidos de la protección de imágenes. La base de datos necesita frecuencia; los medios necesitan planificación de espacio y transferencia.
Una copia local acelera la vuelta a producción. Una copia externa protege si el hosting, el VPS o el acceso principal quedan comprometidos. La capa inmutable u offline aporta defensa cuando un ransomware intenta alcanzar todos los destinos.
Una copia de seguridad no protege una tienda hasta que puede restaurarse, validarse y reconciliar los pedidos creados después de su fecha.
- Define primero un RPO de pedidos y un RTO de tienda operativa, no solo un destino de almacenamiento.
- Haz copias frecuentes de MySQL y usa otra cadencia para imágenes y archivos estáticos.
- Mantén un modelo 3-2-1-1-0 con destino externo, acceso protegido y una copia inmutable u offline.
- Prueba cada tres meses una restauración completa y reconcilia pagos antes de restaurar producción.
Anuncio
Para saber más
Si deseas profundizar, aquí tienes algunos recursos de interés:
- ¿Cómo hacer una copia de seguridad de una tienda, base ... — duplicator.com
- Cómo Hacer Backups de WooCommerce sin Perder Pedidos — avantys.com
- 5 plugins para realizar copias de seguridad en WordPress — webempresa.com
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.