¿Qué ocurre si un fichero se corrompe tras una venta? Fallos en copias pueden romper historiales de pedidos, facturación y cumplimiento, y disparar horas de soporte y reclamos. Un responsable técnico necesita identificar rutas, tablas, permisos y RPO/RTO y disponer de un plan que funcione con ficheros grandes o fragmentados para recuperar ventas sin pérdida de datos.
Las tiendas digitales (descargas) requieren copias de la base de datos, la carpeta de descargas y versiones de ficheros; usar backups incrementales y almacenamiento externo (S3/Wasabi/FTP), aplicar firma o checksum para comprobar integridad, y tener un playbook de restauración que coordine DB + archivos preservando pedidos y cuentas. Ponerlo en práctica y probar la restauración.
Resumen del proceso
Este resumen da los pasos concretos para tener un plan funcional en menos de 48 horas.
- Preparar: identificar rutas, tablas y permisos y definir RPO/RTO.
- Copia inicial: full backup de archivos y base de datos con manifest y checksums.
- Automatizar: incrementales frecuentes y multipart upload para ficheros grandes.
- Verificar: pruebas de integridad automáticas y tests de restore parcial.
- Restaurar: DB primero, luego ficheros, comprobación E2E antes de abrir la tienda.
Qué consigue este resumen
Un plan listo para reducir la pérdida de pedidos y el tiempo de restauración a metas definidas.
Frase accionable rápida
Definir RPO de pedidos a 1 hora y RTO a 2 horas permite priorizar tablas y backups.
Paso 1: qué incluir en el backup
La copia debe reunir datos y ficheros que hacen funcionar las descargas.
Archivos a incluir
Incluir la carpeta de descargas concreta y wp-content completo, manteniendo la estructura de URLs.
Tablas de base de datos imprescindibles
Incluir tablas de pedidos y metadatos: wp_posts, wp_postmeta, wp_woocommerce_order_items, wp_woocommerce_order_itemmeta y tablas de EDD como edd_logs.
Incluir wp-config.php, .htaccess, certificados TLS y scripts de generación de enlaces expirables.
Sin las tablas de order_itemmeta y los ficheros de descargas, la restauración deja enlaces inválidos.
Para tiendas que venden archivos es clave implantar un versionado explícito de los ficheros y registrar la versión entregada en el pedido: cada archivo del catálogo debe almacenarse en un path o bucket con versión única (por ejemplo downloads/v1/miarchivo.zip, downloads/v2/miarchivo.zip) y el pedido debe conservar el identificador de versión (hash o cadena de versión) en la tabla de metadatos. Esto permite restaurar exactamente la versión que el cliente compró, auditar cambios y servir descargas históricas aunque exista una versión más reciente.
En la práctica conviene activar versioning en el almacenamiento S3/Wasabi, generar un manifest con SHA256 por versión y añadir el campo file_version en order_itemmeta; así las restauraciones y reenvíos usan la ruta inmutable asociada a cada compra y no rompen enlaces ni licencias.
Paso 2: automatización y ficheros grandes
Automatizar reduce errores manuales y controla costes al subir ficheros pesados.
Multipart upload y segmentación
Para archivos >100 MB usar multipart upload (S3 compatible) o rclone con chunk-size.
Herramientas recomendadas
Usar wp-cli para DB, rsync/duplicity para ficheros y rclone para destinos S3/Backblaze/Wasabi.
Plan de retención y controles de coste
Retener: copias diarias 30 días, semanales 90 días y mensuales 365 días para conciliación contable.
Dividir ficheros grandes en partes evita timeouts y facilita la reanudación de transferencias (multipart upload evita retransmisiones completas si falla una parte). No obstante, el coste por egress normalmente se calcula por volumen transferido, por lo que fragmentar no reduce directamente la factura de egress; donde sí puede ahorrar es en tiempo operativo y en permitir restores parciales (por ejemplo restaurar solo el archivo necesario en lugar de todo el volumen).
Flujo de backups para descargas
DB + archivos + verificación
Origen: Carpeta descargas + wp-content + DB
→
Staging/Checksum: SHA256 y manifest
Multipart upload a S3/Wasabi
→
Almacenamiento: Versionado y retención
Pruebas: restore parcial semanal y registro auditable
Un procedimiento manual reproducible ayuda a resolver incidentes cuando las automatizaciones fallan. Ejemplo de pasos y comandos:
- Exportar DB: wp db export /tmp/site-$(date +%F).sql o mysqldump -u usuario -p base_de_datos > /tmp/site.sql
- Comprimir y generar checksum: gzip /tmp/site.sql && sha256sum /tmp/site.sql.gz > /tmp/site.sql.gz.sha256
- Sincronizar ficheros: rsync -av --progress /var/www/mi-tienda/wp-content/uploads/downloads/ user@backup:/backups/downloads/ y generar manifest: find /var/www/... -type f -exec sha256sum {} /; > /tmp/manifest.sha256
- Subir a destino S3 compatible con rclone: rclone copy /tmp site-backups:mi-tienda --s3-chunk-size 64M --progress
- Verificar integridad tras la copia: rclone sha1sum site-backups:mi-tienda || ssh user@backup 'sha256sum -c /backups/manifest.sha256' Estos comandos permiten descargar, comprobar y auditar manualmente backups antes de una restauración completa
Paso 3: playbook de restauración
El orden y la verificación evitan inconsistencias que rompen entregas.
Preparación antes del restore
Poner el sitio en modo mantenimiento y generar snapshot actual antes de cualquier cambio.
Restaurar base de datos primero
Restaurar tablas de usuarios y pedidos en una transacción o entorno staging y validar claves foráneas.
Restaurar ficheros y verificar
Copiar ficheros y comprobar SHA256 contra el manifest antes de actualizar enlaces expirables.
Pruebas E2E
Hacer una descarga completa con usuario de prueba y validar licencias y expiraciones.
Restaurar DB primero y ficheros después preserva relaciones entre pedidos y entregas.
Errores que arruinan el resultado
El fallo más común es tener backups incompletos, lo que da una falsa sensación de seguridad.
Error 1: confiar solo en la DB
Guardar solo la base de datos deja enlaces rotos y ficheros faltantes.
Error 2: backups en el mismo servidor
No tener copia offsite convierte al backup en inútil ante caída del hosting.
Error 3: no verificar integridad
Un archivo corrupto en backup impide entregas, aunque el archivo exista.
El error más frecuente en este punto es confiar en que un plugin almacenó "todo" sin comprobar las rutas de descarga.
Comparativa de soluciones y decisión
Escoger según volumen, equipo y requisitos legales reduce costes y riesgos.
| Proveedor |
Coste €/GB |
Egress €/GB |
Multipart |
Versioning |
| AWS S3 (EU) |
Variable según clase |
Sí (coste notable) |
Sí |
Sí |
| Wasabi |
Bajo |
Bajo |
Sí |
Limitado |
| Backblaze B2 |
Competitivo |
Moderado |
Sí |
Sí |
| BlogVault / UpdraftPlus |
Incluido en plan |
Variable |
Depende |
Sí |
Pros y contras resumidos
Wasabi y Backblaze reducen coste de almacenamiento y egress para restores frecuentes.
Los servicios gestionados facilitan restores pero cobran por conveniencia.
Matriz de decisión rápida
Si volumen >1 TB y equipo técnico, optar por S3/Backblaze con rclone y scripts multipart.
Si menos de 200 GB y equipo limitado, elegir servicio gestionado con destino Wasabi.
Para cumplimiento RGPD elegir data centers en la UE y cifrado en reposo; más información sobre AEPD: AEPD.
Para comparar precios de S3 ver: AWS S3 pricing.
Esto funciona bien en teoría, pero en la práctica los costes de egress en restores mal planificados disparan la factura durante un incidente.
Para una revisión rápida del plan de backups y una estimación de costes por volumen, se puede solicitar un análisis técnico con presupuesto orientativo.
No aplica si todos los archivos están almacenados y versionados fuera de WordPress, por ejemplo en una plataforma de entrega con backup propio; en ese caso centrar la estrategia en la plataforma externa y conservar solo backups de metadatos y bases de datos en WordPress.
Para tomar decisiones económicas es útil un ejemplo numérico con supuestos:
- Imagine 2 TB de archivos activos y 200 GB de crecimiento mensual. Si quiere retención diaria 30 días y copias mensuales y anuales, estime almacenamiento efectivo como full inicial (2 TB) + acumulado de incrementales. Con incrementales eficientes podríamos asumir 200 GB * 30 días = 6 TB de incrementos brutos, pero aplicando deduplicación/incrementales reales el volumen adicional podría ser 1–2 TB
- por tanto almacenamiento total 3–4 TB. Si asumimos un precio ejemplo de 0,02 €/GB-mes para S3 estándar, coste mensual ≈ 3.000 GB * 0,02 € = 60 €/mes
- con Wasabi a 0,005 €/GB-mes sería ≈ 15 €/mes
Para restores considere egress: si necesita restaurar 500 GB y el egress S3 supone 0,09 €/GB, el coste puntal sería ≈ 45 €. Este tipo de cálculo (volumen base, tasa de crecimiento, eficiencia incremental y coste por GB + egress por GB en restores) permite comparar S3/Wasabi/FTP y planificar retención y restores sin sorpresas en la factura.
Preguntas frecuentes
¿Qué incluye un backup correcto para una tienda?
Debe incluir la base de datos completa, la carpeta de descargas y las tablas de metadatos de pedidos.
La copia debe conservar la estructura de rutas y un manifest con checksums por archivo.
¿Cómo verificar que los ficheros del backup no están corruptos?
Generar SHA256 en origen y comprobarlos tras la copia con scripts automatizados.
Registrar resultados en un log y alertar si hay discrepancias.
¿Cada cuánto hacer backups si hay muchas ventas?
Hacer incrementales cada hora para la base de datos y diarios para ficheros grandes, si RPO es estricto.
Ajustar según volumen de pedidos y costes.
¿Puedo usar solo un plugin de WordPress para todo?
Un plugin puede cubrir parte del proceso, pero conviene combinarlo con backups offsite y verificación de integridad.
Comprobar que el plugin incluye ficheros de descargas y tablas de pedidos.
¿Cómo restaurar sin perder pedidos o usuarios?
Restaurar primero la base de datos y tablas de pedidos, luego los ficheros, y validar con tests de descarga.
Evitar restaurar ficheros sin reconciliar transacciones con el gateway de pago.
¿Qué soluciones son más económicas para grandes volúmenes?
Wasabi y Backblaze suelen ser más baratos en almacenamiento por GB y ofrecen compatibilidad S3.
Si el volumen es muy alto, combinar almacenamiento frío para archivado y caliente para restores frecuentes reduce costes.
¿Cómo cumplir RGPD en los backups?
Cifrar backups en reposo y en tránsito y documentar accesos y retenciones según RGPD y LOPDGDD.
Mantener contratos de tratamiento de datos con proveedores y elegir centros de datos en la UE.
Recomendaciones prácticas y checklists
Priorizar RPO de pedidos y automatizar comprobaciones de integridad reduce tiempo de recuperación y pérdidas comerciales.
Checklist mínimo:
- Identificar rutas de descargas y tablas críticas.
- Hacer full backup inicial con manifest y SHA256.
- Configurar incrementales horarios para DB y diarios para ficheros.
- Subir a destino S3/Wasabi con multipart para archivos grandes.
- Probar restore parcial semanal y registrar evidencias.
Un caso habitual: una tienda restauró solo la base de datos y perdió 48 pedidos porque las rutas de descarga no existían en el backup; el resultado fue conciliación contable manual y reenvío de archivos.
Datos relevantes:
- el RGPD ya está en vigor
- la LOPDGDD ya fue aprobada
- PCI DSS publicó la versión 4.0 actualmente
La evidencia visual de la comprobación se puede adjuntar en auditorías y registros técnicos para cumplir la AEPD.
