¿Cuántas suscripciones se perderían si una restauración rompe facturas o duplica cobros? Un fallo en la restauración suele generar churn, sanciones y problemas con auditorías: el riesgo aumenta con WooCommerce Subscriptions y volúmenes crecientes, por eso es urgente una política operativa clara que reduzca costes y garantice integridad transaccional.
Retención de backups para tiendas con suscripciones: la política debe definir retenciones que distingan tipos de datos (transacciones, suscripciones, facturas, logs), sincronizar snapshots con ciclos de facturación y cumplir GDPR/PCI‑DSS. Aplicar backups diarios y snapshots antes de cierres de facturación, retenciones escalonadas (30/90/365 días) y pruebas regulares de restauración asegura integridad transaccional sin elevar costes ni riesgo de incumplimiento. Plantillas, ejemplos por plugin/hosting, cálculos de coste y checklists facilitan la implementación inmediata.
Retención de backups para tiendas con suscripciones
La política debe separar tipos de datos, tiempos y almacenamiento. Esto reduce costes, facilita cumplimiento y evita restauraciones que rompan cobros.
La primera decisión es qué conservar: transacciones, suscripciones, facturas, logs y snapshots. Cada tipo tiene un riesgo distinto y una obligación legal diferente.
Las reglas operativas deben incluir RPO y RTO concretos, ventanas de snapshot antes del cierre y pruebas regulares de restauración. Sin estas reglas, los backups son papel mojado.
¿Qué tipos de datos diferenciar?
Separar al menos cinco grupos: DB transaccional, registros de suscripción, facturas y contabilidad, archivos estáticos (imágenes), y logs de auditoría. Cada grupo define un periodo distinto y un nivel de cifrado.
¿Cómo vincular retención y riesgo?
Asignar retención según riesgo:
- transacciones elevan riesgo financiero
- facturas elevan riesgo fiscal
- logs elevan riesgo de auditoría
Por eso conviene reglas diferentes por prefijo o bucket.
Quién necesita esta política y cuándo aplicarla
La política aplica a tiendas WooCommerce con cobros recurrentes y pasarelas que manejan pagos periódicos. Si un proveedor externo gestiona todo el ciclo y documenta responsabilidades, la tienda puede reducir alcance.
Los responsables de la tienda, el administrador de WordPress y el proveedor de hosting deben acordar roles y accesos. El registro de actividades del responsable del tratamiento debe incluir la política de backups.
Esta política no es necesaria para sitios estáticos sin datos transaccionales ni para casos en que el proveedor SaaS asume legalmente la retención y el restore.
¿Qué perfiles deben intervenir?
El equipo técnico (administrador de WordPress y administrador de sistemas) configura backups y snapshots. El responsable del tratamiento y el DPO documentan la retención legal y validan excepciones.
¿Cuándo activar reglas estrictas?
Activar reglas estrictas en picos de ventas, cierres fiscales o ante auditorías. El error más frecuente aquí es confiar en backups automáticos del hosting sin probar restauraciones antes de la auditoría.
Plazos de retención según tipo de dato y riesgo
Definir plazos concretos salva costes y cumple normas. Propuesta recomendada:
- transacciones 90–365 días
- suscripciones activas hasta cancelación +365 días
- facturas 5–10 años
- logs 30–90 días
- snapshots 7–30 días
Las facturas deben conservarse conforme a la normativa española (mínimo 5 años para efectos fiscales), pero esa obligación legal debe documentarse como la base jurídica para cualquier retención prolongada frente al RGPD.
En la práctica, la política debe distinguir entre la retención activa (bases de datos y facturación) y la retención en backups: a) justificar en el registro de actividades el interés legítimo o la obligación legal que permite conservar facturas hasta 5–10 años; b) aplicar pseudonimización o bloqueo de acceso a los datos personales en backups cuando sea posible; c) definir un procedimiento para solicitudes de supresión que incluya marcar registros como borrados y coordinar su eliminación efectiva en el ciclo de lifecycle de los backups (por ejemplo, purgar versiones antiguas en cuanto las políticas de ciclo lo permitan), todo ello con trazabilidad para auditoría.
PCI DSS v4.0 se publicó y obliga a no almacenar datos de tarjeta sin tokenización, además de exigir cifrado y controles de acceso a backups. Consulte la guía oficial para detalles. PCI Security Standards Council
¿Cuánto conservar transacciones?
Para conciliaciones y reclamaciones, mantener transacciones entre 90 y 365 días. 90 días cubren la mayoría de disputas; 365 días cubren auditorías y reembolsos tardíos.
¿Y suscripciones y facturas?
Conservar suscripciones activas hasta cancelación y 365 días después de la baja. Guardar facturas al menos 5 años, y hasta 10 años si existe riesgo fiscal o procesos abiertos.
Programar backups y snapshots según facturación
Sincronizar snapshots con cierres de ciclo evita inconsistencias entre pagos y estados de suscripción. Snapshot justo antes del cierre; backup incremental poco después del pico.
La política operativa concreta: snapshot/DB dump 1 hora antes del cierre de facturación, backup incremental 1–2 horas después, full semanal fuera de horas punta. Esto permite RPO de horas y RTO razonable.
¿Qué horario elegir según pasarela?
Alinear con la hora de conciliación de Stripe, Redsys o PayPal. Si la pasarela liquida a las 00:00, programar snapshot a las 23:00 y backup incremental a las 01:00.
¿Qué hacer con webhooks y cron durante restores?
Antes de restaurar, pausar webhooks y WP‑CRON. Esto evita re-procesar cobros o duplicar eventos. Restaurar en staging, reconciliar y luego reactivar webhooks.
Días -30 a -1
Snapshots diarios antes de cierres
Día 0
Snapshot crítico (cierre)
Día 1–30
Backups incrementales diarios
Día 31–365
Archivar a storage frío (Glacier)
La infografía muestra la ventana típica de retención y transición a almacenamiento frío.
Configuración práctica en plugins y hosting
Configurar plugins con almacenamiento offsite y cifrado resuelve la mayoría de riesgos. UpdraftPlus, BlogVault y VaultPress permiten integración con S3 y pruebas de restauración en staging.
En host gestionado (WP Engine, Cloudways, SiteGround), confirmar que snapshots se exportan a un bucket externo y que el proveedor rota claves de acceso. El proveedor debe documentar los SLA de restore.
¿Cómo configurar UpdraftPlus con S3?
Crear bucket en AWS, habilitar versioning y SSE. En UpdraftPlus seleccionar S3, activar backups diarios incrementales y conservar DB 180 días, archivos 30 días. Programar full semanal.
¿Qué hacer en WP engine o cloudways?
Programar snapshot antes del cierre de facturación y configurar exportación automatizada a S3 o Spaces. El proveedor debe documentar al menos una prueba anual de restauración completa y, además, el equipo interno del comercio debería ejecutar pruebas parciales o de componentes críticos (DB transaccional y conciliación de transacciones) con frecuencia trimestral.
Así se combina la garantía del proveedor (test anual con evidencia) con validaciones más frecuentes del propio equipo que aseguren que los RPO y RTO definidos se mantienen en la práctica.
Plantilla de retención y responsables (ejemplo práctico para WooCommerce Subscriptions y plataformas SaaS):
- Para una tienda con WooCommerce Subscriptions, una política operativa clara puede estructurarse así: Transacciones (pedidos y metadatos de pago): conservar copias completas durante 365 días para conciliación
- Suscripciones (post_type = 'shop_subscription' y metadatos relacionados): mantener mientras la suscripción esté activa y 365 días adicionales tras la baja
- Facturas y contabilidad: conservar 5 años (mínimo legal), hasta 10 si hay procesos abiertos
- Logs de auditoría y webhooks: 90 días
- Snapshots críticos: 30 días (snapshots diarios, full semanal)
En modelos SaaS donde la pasarela o el proveedor gestionan cobros, la política debe incluir un SLA que documente quién es responsable del RTO/RPO, qué registros (transaction IDs, balances) exporta el proveedor y cómo el cliente puede exigir la entrega de logs en caso de incidencia. Añadir un bloque de responsabilidades (merchant, proveedor de hosting, PSP) con contactos y tiempos máximos de respuesta facilita la ejecución en incidentes y las reclamaciones ante auditorías o ante la AEPD.
Configuración práctica paso a paso en plugins y soluciones (UpdraftPlus, BlogVault, VaultPress): Ejemplo paso a paso para UpdraftPlus:
- Ajustes → UpdraftPlus Backups → Elegir almacenamiento remoto: Amazon S3
- En AWS crear bucket con versioning y políticas de ciclo de vida
- En UpdraftPlus, introducir credenciales IAM con permisos restringidos (PutObject/GetObject/ListBucket), activar 'Enable encryption' y seleccionar SSE‑KMS en la consola AWS
- Programar Backups: DB diario (horario alineado con el cierre de facturación), archivos incrementales cada 4–6 horas si es necesario, full semanal fuera de horas punta
- Retención en UpdraftPlus: DB 180 días, archivos 30 días (retenciones escalonadas); activar limpieza automática y exportación a bucket con lifecycle (30 días → storage frío, 365 días → expiración). Para BlogVault/VaultPress: habilitar backups diarios y backups on‑demand antes de cierres, activar pruebas de restore automáticas en un entorno staging y configurar notificaciones por fallo. En todos los casos, documentar el RPO y RTO objetivo en la configuración y conectar la solución con un KMS (AWS KMS o equivalente) para gestión de claves conforme a requisitos PCI DSS y GDPR
Costes y ciclo de vida en S3: ejemplos y plantilla
El coste depende de GB almacenado, solicitudes y salidas. Aplicar lifecycle reduce coste moviendo objetos fríos tras 30 días. Para 50 GB, pasar a Glacier puede reducir coste hasta un 80%.
Ejemplo numérico 2024: S3 Standard €0.023/GB‑mes; 50 GB = €1.15/mes. Tras 30 días a Glacier, coste mensual puede bajar a €0.20–0.40. Calcular además requests y egress.
Plantilla rápida de cálculo
- GB_base = 50
- GB_incremental_mes = 5
- Tarifa_standard = 0.023
- Coste_mes = GB_base * Tarifa_standard
- Con lifecycle: mover a glacier tras 30 días reduce coste aproximadamente 70–90%
Reglas lifecycle recomendadas
Colocar DB dumps en /db-dumps/ y aplicar: 30 días → Glacier Flexible, 365 días → Expirar. Habilitar versioning y políticas de retención por prefijo.
| Opción |
Coste mensual aprox |
RTO esperado |
Ventaja clave |
| Backup local (disk) |
Bajo (hosting incluido) |
<4 horas |
Recuperación rápida sin egress |
| S3 Standard + Glacier |
Moderado (€0.2–1/mes para 50GB) |
Horas a días |
Escalable y barato a largo plazo |
| Proveedor gestionado con réplica |
Alto (SLA incluido) |
Minutos a horas |
Alta disponibilidad y soporte |
Restauración segura sin romper cobros recurrentes
Restaurar sin pausar webhooks puede provocar cobros duplicados. Procedimiento seguro: pausar webhooks, snapshot del estado actual, restaurar en staging, reconciliar y reactivar en producción.
Esto funciona bien en teoría, pero en la práctica la mayoría olvida exportar los logs de pasarela antes de restaurar. Sin esos logs, la conciliación queda incompleta.
Pasos concretos para restaurar
- Poner tienda en modo mantenimiento y pausar WP‑CRON y webhooks
- Hacer snapshot del estado actual
- Restaurar DB y archivos en staging
- Reconciliar IDs de transacción con la pasarela
Checklist post-restore
Verificar tabla de suscripciones (start_date, next_payment, status). Simular cobros en modo test. Revisar logs y notificar a DPO si aparecen divergencias.
Procedimiento operativo de restauración con integridad transaccional (ejemplos y queries): Restaurar sin romper la integridad transaccional exige pasos repetibles y verificables. Flujo práctico:
- Pausar webhooks de la pasarela y WP‑CRON en producción
- Generar snapshot del estado actual y exportar logs de la pasarela
- Restaurar la DB en un entorno de staging
- Ejecutar consultas de reconciliación para detectar duplicados o inconsistencias, por detectar IDs de transacción duplicados: SELECT meta_value AS tx_id, COUNT(*) c FROM wp_postmeta WHERE meta_key = '_transaction_id' GROUP BY tx_id HAVING c > 1; o listar suscripciones con next payment en pasado: SELECT p.ID, p.post_status, m.meta_value AS next_payment FROM wp_posts p JOIN wp_postmeta m ON p.ID = m.post_id WHERE p.post_type = 'shop_subscription' AND m.meta_key = '_schedule_next_payment' AND m.meta_value < UNIX_TIMESTAMP()
- Comparar estos resultados con los logs exportados de Stripe/PayPal/Redsys por transaction_id y por fecha
- Marcar en la DB en staging los pedidos afectados y simular cobros en modo test para validar RPO/RTO
- Solo cuando la conciliación y las simulaciones confirmen integridad transaccional, aplicar el restore en producción y reactivar webhooks. Registrar cada paso en el log de restauración y conservarlo como parte del proceso de auditoría
Errores frecuentes y advertencias operativas
Un error habitual es usar una única retención para todo. Esto encarece almacenamiento y viola principios de GDPR. Otro error es confiar en backups del hosting sin pruebas de restore.
Cuidado cuando se eliminan datos personales: eliminar en producción no borra automáticamente las copias antiguas. Documentar procesos y plazos de supresión.
¿Qué no hacer al definir retención?
No mezclar retenciones de facturas con logs. No usar solo snapshots locales sin copia offsite. No guardar PAN sin tokenización en backups.
¿Qué exige la auditoría técnica?
La auditoría pide pruebas de restauración, registros de acceso y cifrado en reposo. PCI DSS reforzó controles sobre backups y gestión de claves.
No aplica si la tienda no procesa pagos recurrentes ni datos transaccionales, si un proveedor SaaS gestiona legalmente retenciones y restores, o cuando restricciones contractuales exigen plazos diferentes a los recomendados.
Preguntas frecuentes
¿Cuánto tiempo conservar copias de la base de datos?
Conservar copias de la base de datos transaccional entre 90 y 365 días, según la frecuencia de disputas. 90 días cubren la mayoría de reclamaciones; 365 días cubren auditorías y conciliaciones extendidas.
¿Cómo afecta el RGPD a los backups?
El RGPD exige justificar el periodo de conservación y aplicar minimización. Si un usuario solicita supresión, la copia activa se borra y las futuras copias deben reflejar ese cambio según la política.
¿Debo cifrar los backups y quién gestiona las claves?
Sí, cifrar en tránsito y en reposo es obligatorio para datos personales y de pago. Las claves deben gestionar el responsable del tratamiento o un servicio KMS con acceso restringido.
¿Qué pasa si restoro y hay pagos duplicados?
Si ocurre, pausar cobros inmediatamente, comparar IDs en la pasarela y comunicar a la pasarela para revertir duplicados. Restaurar primero en staging y reconciliar evita este problema.
¿Cuánto cuesta almacenar 100 GB en S3?
Con S3 Standard a €0.023/GB‑mes, 100 GB ≈ €2.30/mes. Con lifecycle a Glacier tras 30 días, coste puede reducirse a ≈€0.40/mes, más requests y egress.
¿Cómo probar que la restauración mantiene la integridad transaccional?
Restaurar en un entorno de staging, ejecutar pruebas de compra y simular webhooks de la pasarela. Verificar campos next_payment y status en la tabla de suscripciones.
El plan concreto
- Implementar backups diarios incrementales y full semanal
- Snapshot crítico 1 hora antes del cierre de facturación
- Retenciones: transacciones 90–365 días, suscripciones activas hasta cancelación +365, facturas 5–10 años
- Configurar lifecycle en S3 y cifrado SSE‑KMS
- Probar restauración completa cada trimestre
La evidencia práctica muestra que las tiendas que aplican este plan reducen incidentes de conciliación y resuelven restores en tiempo acorde al RTO establecido. Un caso habitual: restauración sin pausar webhooks → cobros duplicados → 48 horas para conciliación y reembolso; aplicar el plan evita esa pérdida.
Coste orientativo: para una tienda con 50 GB de backups y 5 GB/mes incrementales, mover DB dumps a Glacier tras 30 días reduce coste mensual de €1.15 a €0.30–0.50, dependiendo de requests y egress.
AEPD
