Una restauración mal hecha puede duplicar renovaciones, romper pedidos o dejar tokens de pago inutilizables. Y cuando una tienda funciona con suscripciones, el error no solo afecta a una página: puede cortar cobros recurrentes, generar incidencias con clientes y complicar la vuelta a la normalidad justo cuando más falta hace control.
Hacer Backups para subscripciones WooCommerce no es solo copiar archivos: hay que proteger base de datos, pedidos, suscripciones y tokens de pago, guardar la copia fuera del servidor y restaurar con una verificación antes y después para evitar cobros duplicados. Así se recupera la tienda con seguridad, sin perder renovaciones activas ni romper la continuidad de los pagos.
Resume el proceso y evita el fallo típico
- Cierra la tienda durante la restauración para que no entren pedidos nuevos.
- Guarda una copia completa de base de datos, archivos y configuración del gateway.
- Restaura primero la base de datos y luego los archivos, si el backup separa ambos.
- Comprueba suscripciones activas, renovaciones pendientes y pedidos recientes.
- Reabre la tienda solo cuando el checkout y los cobros de prueba funcionen.
Una copia útil para suscripciones no solo guarda WordPress; también conserva el estado de cada renovación y el vínculo con la pasarela de pago.
Guarda lo que de verdad sostiene las renovaciones
Un backup fiable para una tienda con suscripciones debe cubrir tres piezas: la base de datos MySQL, los archivos de WordPress y la parte que conecta con el cobro. Si falta una de ellas, la restauración queda coja. Es como guardar una casa sin llaves: el edificio sigue ahí, pero no puedes entrar bien.
La base de datos contiene el historial real. Ahí viven las suscripciones, los pedidos, los estados de pago y muchas relaciones internas que WooCommerce y WooCommerce Subscriptions usan para decidir qué toca cobrar.
Prioriza la base de datos
La base de datos manda porque guarda la verdad operativa. wp-content importa, sí, pero no basta por sí solo.
Lo que suele pasar en tiendas reales es esto: se respalda la carpeta de archivos, se restaura rápido y todo parece bien hasta que una renovación falla o aparece un pedido repetido. El error más frecuente en este punto es pensar que el plugin de backup ya “lo hace todo” sin comprobar tablas, metadatos y versiones.
No olvides los archivos y el gateway
wp-content guarda temas, plugins y subidas. También conserva parte de la lógica visual y de funcionamiento que hace que la tienda cargue como debe.
Los tokens de pago dependen del gateway, como Stripe, PayPal u otros sistemas compatibles. Un token es como una ficha que permite cobrar sin pedir la tarjeta otra vez. Si esa ficha se pierde o se rompe en el proceso, las renovaciones automáticas pueden fallar aunque la tienda “parezca” viva.
Configura copias automáticas que sí sirvan
Un backup automático vale poco si llega tarde o guarda solo una parte. La mayoría de guías dicen “activa copias diarias”. Lo que no mencionan es que una tienda con suscripciones puede tener renovaciones varias veces al día, así que el horario del backup importa más de lo que parece.
En una tienda con bastante movimiento, suele funcionar mejor una copia cada pocas horas y una retención de varios días. Si el volumen es bajo, una copia diaria más una copia antes de cada actualización suele ser suficiente.
Elige la frecuencia por movimiento real
Si la tienda recibe renovaciones, altas y cambios de suscripción cada día, no conviene depender de una sola copia nocturna. Una copia de madrugada puede dejar fuera ventas y renovaciones del mismo día.
Un caso habitual: una tienda pequeña actualiza a las 18:00, restaura a las 20:00 con un backup de las 02:00 y luego descubre pedidos que han desaparecido. No es un fallo raro. Es un desajuste de tiempo.
WooCommerce Subscriptions depende de datos almacenados en la base de datos y de la pasarela de pago para gestionar renovaciones automáticas. Si una de las dos piezas falla, el cobro recurrente se rompe.
Usa retención y copia fuera del hosting
Guardar solo en el hosting es cómodo, pero arriesgado. Si el servidor cae, si hay un ransomware o si el propio panel tiene un error, la copia puede desaparecer con la web.
La regla práctica es simple: una copia local para recuperar rápido y otra externa para salir del apuro si el hosting falla. En España y en la Unión Europea, el RGPD y la LOPDGDD obligan a cuidar los datos personales, así que también conviene que el almacenamiento tenga acceso limitado y cifrado si el proveedor lo ofrece.
| Opción |
Velocidad de copia |
Riesgo de pérdida |
Útil para suscripciones |
Cuándo usarla |
| Copia solo en hosting |
Alta |
Alto |
Limitado |
Solo como apoyo temporal |
| Copia local + nube |
Media |
Bajo |
Alta |
La mayoría de tiendas |
| Backups incrementales |
Alta |
Muy bajo |
Muy alta |
Tiendas con renovaciones frecuentes |
Elige el plugin que mejor encaja con tu tienda
No todos los plugins de backup sirven igual para una tienda con suscripciones. Algunos van bien para webs sencillas y se quedan cortos cuando hay renovaciones y pedidos a menudo. Otros añaden puntos de restauración o copias incrementales, que son como fotos pequeñas del cambio en vez de una foto enorme de toda la web.
La elección correcta depende de dos cosas: cuánto cambia la tienda cada día y cuánto control hace falta al restaurar. Si hay muchas renovaciones, el valor está en poder volver atrás sin tocar lo que ya funcionaba.
UpdraftPlus, WP time capsule y BlogVault
UpdraftPlus funciona bien cuando se busca una opción conocida, sencilla y compatible con almacenamiento externo. Necesita pruebas antes de confiar en él con una tienda grande, porque no basta con instalarlo y asumir que todo quedará perfecto.
WP Time Capsule encaja mejor cuando interesa conservar cambios pequeños y frecuentes. BlogVault suele resultar cómodo en escenarios con restauración rápida y staging, que es una copia de prueba de la tienda donde se puede verificar todo antes de tocar producción.
Los datos apuntan a que las tiendas con más movimiento se benefician de copias incrementales, porque reducen tiempo y carga sobre el hosting. WordPress.org mantiene un repositorio amplio de plugins, pero la compatibilidad real con WooCommerce Subscriptions siempre exige prueba práctica.
Jetpack y BackWPup
Jetpack aporta una capa cómoda para muchos sitios WordPress, aunque su encaje depende mucho del plan y del flujo de restauración que se necesite. No se debe asumir que cubre una tienda recurrente solo porque pertenezca al ecosistema de Automattic.
BackWPup puede servir en tiendas pequeñas, pero requiere revisar bien qué guarda y cómo restaura. El error típico aquí es confiar en el nombre del plugin y no en la prueba de restauración.
La mejor opción no es la más famosa, sino la que restaura bien la base de datos y respeta el estado de las suscripciones.
| Plugin |
Incrementales |
Restauración granular |
Prueba de staging |
Perfil recomendado |
| UpdraftPlus |
Sí |
Parcial |
Sí |
Tiendas pequeñas y medianas |
| WP Time Capsule |
Sí |
Sí |
Sí |
Tiendas con cambios constantes |
| BlogVault |
Sí |
Sí |
Sí |
Restauración rápida y controlada |
| Jetpack |
Depende del plan |
Limitada |
Sí |
Sitios WordPress con uso general |
Elige el plugin según cómo maneja las copias
No todos los plugins de copia de seguridad se comportan igual cuando hay renovaciones automáticas. UpdraftPlus suele ser práctico para tiendas pequeñas porque facilita copias fuera del servidor y restauraciones sencillas, pero conviene comprobar en staging que recupera bien la base de datos MySQL completa y las tablas relacionadas con suscripciones. WP Time Capsule y BlogVault suelen encajar mejor cuando hay cambios frecuentes, porque trabajan con copias incrementales y reducen la ventana de riesgo entre una renovación y otra. Jetpack puede ser útil como solución general, aunque depende del plan y no siempre ofrece el mismo control sobre restauración granular.
BackWPup puede servir en tiendas simples, pero requiere revisar muy bien qué archivos wp-content y qué tablas de pedidos recurrentes incluye. En WooCommerce Subscriptions, la compatibilidad real no se mide por el nombre del plugin, sino por cómo restaura estados, tokens de pago y renovaciones automáticas sin romper el flujo de checkout.
Restaura sin provocar cobros duplicados
La restauración segura empieza antes de tocar el botón de recuperar. La tienda debe quedar quieta, como una caja registradora cerrada mientras se cambia la cinta. Si entran pedidos nuevos en mitad del proceso, el backup y la realidad se separan y luego vienen los sustos.
Este paso suele tardar entre 20 y 60 minutos si hay que revisar pasarelas, pedidos recientes y logs. Parece mucho. En la práctica, sale más caro saltárselo.
Cierra la tienda y congela cambios
Primero se bloquean los cambios. Eso incluye desactivar temporalmente el checkout, pausar campañas de pago si empujan tráfico y avisar al equipo para que nadie toque suscripciones manualmente.
La mayoría de fallos graves no vienen del backup, sino de la mezcla de datos viejos con pedidos nuevos. Si una renovación entra mientras se restaura, luego cuesta saber qué cobro pertenece a cada estado.
Restaura en el orden correcto
Si el plugin separa base de datos y archivos, la base de datos debe ir primero. Después se restauran los archivos de WordPress y se comprueba la pasarela de pago.
Un caso habitual: la web carga, el catálogo aparece y todo parece normal, pero las suscripciones nuevas fallan porque la base de datos antigua no encaja con el plugin o con el gateway actualizado. Esto funciona bien en teoría, pero en la práctica el orden marca la diferencia.
Si el backup separa archivos y base de datos, la restauración correcta suele ser base de datos primero, archivos después y pruebas al final.
Paso a paso para restaurar sin tocar las renovaciones
Si no eres técnico, la forma más segura de restaurar una tienda con suscripciones es seguir un orden fijo. Primero pon la web en mantenimiento y avisa al equipo para que no se creen pedidos nuevos. Después verifica qué backup usarás: idealmente uno hecho antes de la última renovación importante o antes de cualquier actualización del gateway. Restaura la copia en un entorno de pruebas o en una copia de la tienda, comprueba que las suscripciones activas siguen visibles y confirma que los tokens de pago permanecen asociados a la pasarela de pago.
Solo cuando el checkout, los pedidos pendientes y una renovación de prueba funcionen, devuelve la tienda a producción. En una tienda con WooCommerce Subscriptions, este orden reduce mucho el riesgo de cobros duplicados y de estados incoherentes en la base de datos MySQL.
Evita los fallos que arruinan la recuperación
Los errores que más daño hacen son muy repetidos. No suelen ser complejos. Suelen ser prisas, copias antiguas o confiar en que “si abre la web, ya está todo bien”. Ese pensamiento deja muchas tiendas con renovaciones rotas y cobros desordenados.
No restaures una copia vieja
Antes de restaurar, hay que comparar la fecha del backup con la última renovación, el último pedido y cualquier cambio manual en la suscripción. Si hubo actividad después de la copia, esos datos se perderán.
La trampa está en que WooCommerce Subscriptions puede parecer intacto por fuera. Por dentro, un estado antiguo puede devolver una suscripción a un punto que ya no existe.
No confíes en el plugin sin probarlo
Un plugin puede decir que hace copias completas y restaurarlas, pero la única prueba válida es recuperarlo todo en un entorno de prueba. El reporte bonito no cobra facturas ni salva tokens.
En mantenimiento WordPress, la revisión práctica vale más que la promesa. Automattic, WooCommerce y la propia documentación del ecosistema insisten en cuidar compatibilidad, y la experiencia diaria confirma lo mismo: sin prueba, no hay garantía.
Copia fuera del hosting y con retención
Guardar backups solo en el hosting es como dejar la llave de casa dentro del propio piso. Parece práctico hasta que hay un incendio, un bloqueo del panel o un borrado accidental. La copia externa no es un lujo; es la parte que salva la tienda cuando todo lo demás falla.
Usa nube y retención real
La copia externa puede vivir en almacenamiento en la nube, en un S3 compatible, en Drive o en el sistema del plugin, siempre que no dependa del mismo servidor donde vive WordPress. Eso reduce el riesgo de perder web y respaldo a la vez.
La retención también importa. No hace falta guardar cien copias, pero sí varias versiones recientes. Entre 7 y 30 días suele dar margen suficiente para recuperar un error que se descubre tarde, algo muy común después de una actualización o una migración.
El RGPD exige proteger los datos personales con medidas adecuadas, y las copias de seguridad forman parte de esa protección cuando contienen datos de clientes.
Limita accesos y prueba la descarga
Una copia que nadie puede restaurar sirve poco. Hay que comprobar que el archivo se puede descargar, abrir y usar sin errores.
También conviene limitar quién accede a la nube. Si varias personas tienen credenciales, aumenta el riesgo de borrado o exposición accidental. En una tienda con varios administradores, esto es más habitual de lo que parece.
Una política útil suele mezclar copia local para salir rápido, copia externa para salvar la tienda y varias versiones para poder volver a un punto limpio.
Comprueba que todo sigue vivo antes de abrirla
Después de restaurar, la tienda no se reabre por intuición. Se reabre cuando se comprueba que las suscripciones activas, los pedidos pendientes y el checkout funcionan sin errores. Es la diferencia entre “la web carga” y “la tienda cobra bien”.
Revisa suscripciones y pedidos
Hay que mirar las suscripciones activas, las fallidas, las pendientes de renovación y los pedidos creados justo antes del incidente. Si algo no cuadra, no se abre la tienda todavía.
En una restauración bien hecha, los estados coinciden y no aparecen duplicados raros en el admin. Si hay desajustes, suele ser por una copia vieja o por una restauración parcial.
Haz una prueba real de cobro
La prueba correcta no es solo entrar al panel. Hay que simular una renovación o un pedido de prueba en el entorno que corresponda y confirmar que la pasarela responde como antes.
También conviene revisar correos, logs y avisos del plugin de suscripciones. Si el checkout falla una vez, lo normal es que el fallo deje una pista clara en el log.
Si la prueba de cobro y el estado de las suscripciones coinciden, la tienda puede reabrirse con mucha más tranquilidad.
No aplica si la web no usa WooCommerce Subscriptions ni pagos recurrentes, o si solo hay que recuperar una web de contenido sin pedidos ni tokens de pago.
Checklist antes y después de restaurar
Antes de restaurar, confirma que el backup incluye base de datos MySQL, archivos wp-content, pedidos pendientes, suscripciones activas y la configuración de la pasarela de pago. Revisa también la fecha de la copia para evitar perder renovaciones automáticas recientes. Durante la restauración, bloquea el checkout y evita cambios manuales en suscripciones o reintentos de cobro. Después, comprueba que los tokens de pago siguen válidos, que no se han duplicado pedidos recurrentes y que las suscripciones activas mantienen su próxima fecha de renovación.
Haz una prueba real de compra o renovación con un importe mínimo y revisa los logs si algo falla. Este checklist reduce errores típicos cuando se recuperan copias de seguridad en tiendas con suscripciones, sobre todo si se usan copias fuera del servidor y retención de backups de varios días.
Preguntas frecuentes
¿Qué se debe incluir en un backup de WooCommerce
Debe incluir base de datos, archivos de WordPress y datos del gateway. La base de datos guarda suscripciones, pedidos y estados, que son la parte más sensible. Si falta una de esas piezas, la restauración puede abrir la web pero romper renovaciones.
¿Puedo restaurar solo wp-content y dejar la
No, si hay suscripciones activas. wp-content trae temas, plugins y subidas, pero no conserva por sí solo el estado de los cobros recurrentes. Para una tienda con suscripciones, eso deja fuera la parte que decide qué renovar y cuándo.
¿Cómo evito cobros duplicados al restaurar una
Hay que congelar la tienda antes de restaurar, revisar pedidos recientes y reabrir solo tras validar la pasarela. El riesgo aparece cuando entran compras nuevas mientras la copia antigua se está cargando. En ese caso, la tienda mezcla dos realidades distintas.
¿Qué plugin de backup va mejor para suscripciones?
El que restaura bien en staging y conserva la base de datos sin errores. UpdraftPlus, WP Time Capsule y BlogVault suelen entrar en las opciones más usadas, pero la prueba manda. Una tienda pequeña puede ir bien con uno sencillo; una con mucho movimiento suele agradecer incrementales.
¿Cuánto tiempo hay que guardar las copias?
Entre 7 y 30 días suele dar margen útil en tiendas con renovaciones. Ese rango permite volver atrás si un fallo se descubre tarde, que es bastante frecuente tras una actualización o una migración. Si la tienda mueve mucho volumen, conviene conservar más versiones recientes.
¿Qué pasa con los tokens de pago tras una
Depende del gateway y de cómo se haya hecho la copia. Si el token sigue intacto, las renovaciones continúan; si se rompe o falta, la suscripción puede fallar al cobrar. Por eso hay que probar renovaciones antes de reabrir la tienda.
¿Sirve un staging para probar el backup?
Sí, y es la forma más segura de comprobarlo. Un staging permite restaurar sin tocar la tienda real y revisar pedidos, suscripciones y checkout. Si la prueba falla allí, se corrige antes de afectar clientes de verdad.
Recupera la tienda sin jugarte las renovaciones
La restauración más segura es la que deja la tienda vendiendo igual que antes, sin cobros repetidos ni suscripciones rotas. Para conseguirlo, el orden correcto importa más que la prisa: congelar, restaurar, verificar y abrir solo cuando todo encaja.
Una copia bien hecha no solo protege la web; protege el historial de cobros, la confianza del cliente y el trabajo de semanas.
