Una copia diaria puede dejar tu membresía expuesta: entre dos backups pueden producirse renovaciones , cancelaciones, cambios de plan y altas de alumnos. Si restauras WordPress sin tenerlos en cuenta, un cliente que ha pagado podría perder su acceso, o alguien que canceló podría recuperarlo.
Los backups para membresías con pagos recurrentes deben proteger cada cambio de suscripción, separar los datos de WordPress de los que conservan Stripe o PayPal y permitir una recuperación sin duplicar cobros ni conceder accesos erróneos.
✉
¿Quieres más información? Escríbenos y te orientamos
Ajusta las copias al ritmo de tus renovaciones
La frecuencia debe depender de las operaciones que puedes perder, no de la copia gratuita que incluya el hosting.
Calcula el RPO con operaciones reales
El RPO , o punto objetivo de recuperación, es la cantidad máxima de datos recientes que aceptas perder y debe medirse en renovaciones, pedidos y cambios de acceso.
Como regla práctica, una web con entre 1 y 5 operaciones al día puede asumir un RPO de 12 a 24 horas si hay tiempo para revisar cada caso
Con entre 5 y 30 operaciones diarias , conviene bajarlo a entre 1 y 4 horas
Por encima de 30 renovaciones, altas o cambios diarios, una copia incremental cada 15 o 60 minutos reduce mucho el trabajo manual posterior
RPO de 24 horas: web pequeña, pocos cobros y sin accesos urgentes tras el pago.RPO de 1 a 4 horas: cursos y membresías con actividad diaria moderada.RPO de 15 a 60 minutos: renovaciones frecuentes, lanzamientos o acceso inmediato al contenido.
Define también el tiempo de vuelta
El RTO , o tiempo objetivo de recuperación, indica cuánto tiempo puede estar caída la web e incluye restaurar WordPress y validar usuarios, cobros y permisos. Una restauración completa suele tardar entre 30 minutos y 3 horas , según el tamaño de la web, el servidor y la herramienta.
Para una membresía nueva, deja al menos 14 a 30 días de retención. Ese margen permite volver a una copia anterior si un fallo se descubre varios días después, algo habitual cuando el problema afecta a renovaciones mensuales.
WordPress restaura datos, Stripe conserva cobros
WordPress recupera sus archivos y base de datos en la fecha de la copia, mientras Stripe y PayPal conservan los cargos, reembolsos y disputas procesados después.
Lo que vuelve con la base de datos
Un backup de base de datos devuelve usuarios, pedidos, suscripciones, niveles de membresía y ajustes tal como estaban al crear la copia. El backup de archivos devuelve plugins, temas, imágenes y código personalizado; necesitas ambos para recuperar correctamente la web.
Lo que Stripe y PayPal no revierten
Stripe y PayPal no retroceden cuando restauras WordPress: si un cliente renovó después de la copia, el cobro seguirá existiendo aunque WooCommerce, MemberPress o Paid Memberships Pro no lo reflejen. Los webhooks conectan esos eventos con tu sitio, pero no conviene reenviarlos todos sin revisar: identifica el periodo afectado y compara cada pago con su pedido, suscripción y permiso.
Revisa claves, webhooks y tareas cron
Las claves API, los webhooks y las tareas cron deben seguir configurados correctamente después de restaurar. Si WooCommerce deja acciones atascadas en Action Scheduler, pueden faltar cambios de estado o acumularse avisos de pago.
Una restauración segura compara el estado de la pasarela con el estado de WordPress antes de reactivar automatizaciones.
Elige la copia según facturación y riesgo
La solución adecuada combina copia completa, copias incrementales y almacenamiento fuera del hosting.
Situación de la membresía Frecuencia aconsejada Sistema principal Coste orientativo al mes
Hasta 5 operaciones diarias Completa diaria UpdraftPlus con nube externa 0 a 10 € más almacenamiento Entre 5 y 30 operaciones diarias Cada 1 a 4 horas Plugin con copias programadas y staging 10 a 30 € Más de 30 operaciones diarias Incremental cada 15 a 60 minutos Servicio externo con restauración rápida 30 a 80 € o más
UpdraftPlus, Jetpack o BlogVault
UpdraftPlus puede ser suficiente al empezar si programas archivos y base de datos, eliges un destino remoto y compruebas cada restauración. Jetpack resulta cómodo para una gestión integrada, mientras BlogVault suele tener sentido cuando necesitas un RPO corto y staging. El backup del hosting debe ser una segunda capa, no el único salvavidas.
Almacena una copia fuera del hosting
Guarda las copias en una ubicación distinta del servidor, con acceso protegido por doble factor. Para negocios sujetos al RGPD y la LOPDGDD, limita quién puede descargar backups y revisa dónde se almacenan: contienen datos de clientes, correos y pedidos.
✅
Nuestra recomendación
Un disco externo sirve como tercera copia física si lo guardas fuera del ordenador habitual. Úsalo para exportaciones cifradas periódicas, nunca en lugar de la copia remota automática.
Permite conservar una copia desconectada ante ransomware o un fallo de la cuenta en la nube
Facilita archivar una exportación mensual antes de cambios grandes en WooCommerce o MemberPress
Da una segunda ubicación para copias cifradas de archivos y base de datos
Ver disponibilidad →
✉
¿Quieres más información? Escríbenos y te orientamos
Restaura sin duplicar cobros ni accesos
Restaura primero en staging, un clon privado de la web, y concilia los eventos ocurridos desde la fecha de la copia.
Prueba la copia en un staging aislado
Crea staging desde el hosting o en un subdominio privado y restaura allí una copia reciente. Bloquea la indexación, los correos salientes y cualquier conexión de pago real; confirma además que no comparte webhooks, tareas cron ni automatizaciones con producción.
Comprueba la fecha, el tamaño y la integridad de archivos y base de datos.
Inicia sesión con una cuenta de prueba y valida su nivel de acceso.
Revisa un pedido, una suscripción activa, una cancelada y un pago fallido.
Verifica URL de webhooks, claves API, cron y correos transaccionales.
Anota el tiempo total de restauración y compáralo con tu RTO.
Conciliación tras volver a producción
La conciliación compara WordPress y la pasarela de pago. Filtra en Stripe o PayPal todos los cargos, reembolsos, cancelaciones y disputas posteriores al backup; después localiza su usuario y suscripción en la web restaurada. Corrige solo los casos que falten y verifica producto, cuenta, pedido, estado y nivel de acceso.
La recuperación termina cuando los pagos, las suscripciones y los permisos coinciden, no cuando la portada vuelve a cargar.
Este enfoque avanzado no es prioritario para un blog sin pagos, usuarios registrados ni contenido restringido. En una web de presentación con cambios poco frecuentes suele bastar una copia completa semanal o diaria, más una copia previa a actualizaciones importantes.
Antes de restaurar, crea un inventario de los datos que intervienen en la membresía y guárdalo junto a la documentación de la incidencia. Además de wp_users y wp_usermeta, revisa las tablas de pedidos y suscripciones que use tu instalación: WooCommerce puede trabajar con pedidos en entradas y metadatos heredados o con tablas HPOS, mientras que Paid Memberships Pro, MemberPress y otros plugins añaden sus propias tablas con el prefijo personalizado de WordPress. Incluye también las tablas de Action Scheduler, los productos y reglas de acceso, los cupones, los correos automatizados y cualquier integración que modifique niveles de membresía.
Así puedes comprobar que el backup de base de datos contiene tanto los cobros internos como los accesos de membresía que dependen de ellos.
Si se trata de una migración, aplica las mismas precauciones que en una restauración, pero con una ventana de corte clara. Haz una copia de seguridad de WordPress justo antes del cambio, pon temporalmente en pausa las renovaciones automáticas que el plugin permita y evita que el sitio antiguo y el nuevo procesen los mismos webhooks a la vez. Tras mover las membresías de WordPress, verifica que el dominio configurado en las suscripciones de Stripe y en los pagos de PayPal apunta al entorno correcto, actualiza las URL de webhook y comprueba las claves API.
Antes de abrir el nuevo sitio, realiza un pago de prueba y valida que crea pedido, suscripción y acceso. Mantén el sitio anterior inaccesible para clientes, pero disponible de forma privada durante la conciliación inicial.
✉
¿Quieres más información? Escríbenos y te orientamos
Preguntas frecuentes
¿Cada cuánto hago copias de una membresía?
Una membresía con renovaciones diarias necesita copias entre cada 15 minutos y 4 horas, según cuántas operaciones puedas perder.
¿Stripe conserva los pagos si restauro WordPress?
Stripe conserva los pagos procesados aunque restaures WordPress a una fecha anterior; después debes comparar los eventos posteriores al backup.
¿Basta el backup del hosting para WooCommerce?
No como única capa: mantén una segunda copia remota y comprueba una restauración al menos cada 30 días.
¿Un backup de archivos guarda mis suscripciones?
No suele guardar pedidos, usuarios ni estados de suscripción, que viven principalmente en la base de datos.
¿Qué hago si falla una restauración de membresías?
No repitas procesos en producción: aísla el problema en staging y revisa PHP, permisos, registros y espacio disponible.
¿Puedo reenviar todos los webhooks de Stripe?
No conviene: reprocesa solo eventos posteriores a la copia que no tengan pedido, suscripción o acceso coherente en WordPress.
Plan seguro antes de lanzar tu membresía
Configura una copia completa diaria, incrementales de 15 a 60 minutos si hay actividad frecuente y un destino remoto separado del hosting. Documenta el RPO, el RTO, las claves API, los webhooks y la persona que valida pagos tras una incidencia.
Lo esencial: La frecuencia de las copias debe seguir el número de renovaciones y el RPO que puedes asumir. WordPress recupera su base de datos, pero Stripe y PayPal conservan los cobros posteriores a la copia. Una restauración segura se prueba en staging con webhooks, cron y correos aislados. Tras recuperar la web, concilia pagos, suscripciones, usuarios y permisos antes de dar la incidencia por cerrada.
Fuentes de interés
Otros artículos que pueden complementar lo que acabas de leer:
