Por qué tus backups a Backblaze B2 fallan cuando más importa

¿Qué ocurre cuando el hosting cae y el backup falla justo al restaurar? Muchos responsables técnicos de pymes y proveedores descubren que backups automatizados no contemplaban cifrado, retención ni pruebas, lo que dispara costes y alarga el downtime. La prioridad pasa a ser automatizar, verificar y dimensionar RTO/RPO sin depender solo del hosting.

Para respaldar WordPress en Backblaze B2, crea un bucket y una application key, configura un plugin fiable o rclone/CLI para subir backups incrementales, programa copias automáticas, cifra los archivos y verifica restauraciones periódicas. Incluye retención/versionado y alertas de fallo: así garantizas RPO/RTO claros y costes controlados. Se incluye comparativa objetiva de plugins, ejemplos copy‑paste de rclone/CLI y una calculadora de costes para 50GB, 500GB y 2TB.

Fundamento: por qué usar backblaze B2 para backups

Backblaze B2 es un servicio de almacenamiento de objetos (object storage) con coste por GB bajo y compatibilidad con una API S3‑compatible; esta arquitectura orientada a objetos facilita la integración con herramientas de backup como rclone y clientes S3, pero difiere de un bloque lógico: no se monta como un disco RAW para I/O de bases de datos en caliente, sino que está pensado para objetos/versiones y acceso por API.

Esto permite separar copia y producción siguiendo la regla 3-2-1 y usar versionado nativo para retener versiones sin duplicar ficheros locales. Las tarifas públicas de Backblaze muestran precios de almacenamiento y egress que conviene revisar antes de definir retenciones.

Backblaze publica datos y políticas claras: almacenamiento ≈ $0.005/GB‑mes y egress ≈ $0.01/GB (precios indicativos, 2024). La implicación práctica es simple: los restores masivos generan coste y tardan según el ancho de banda. Por eso conviene planear restores parciales para reducir RTO y coste de egress.

El error más frecuente en este punto es asumir que subir los backups basta; no medir el tiempo de restauración ni el coste de descarga deja sorpresas cuando se necesita recuperar el servicio. Probar restores con datos reales revela cuellos de botella en redes y procesos.

Ventaja económica real

Backblaze es competitivo en almacenamiento puro frente a S3 estándar, lo que interesa a pymes con 50–2.000 GB de datos. Mantener incrementales reduce llamadas PUT/GET y egress. La decisión depende del patrón de restauración: si se restaura frecuentemente, el coste de egress puede superar el ahorro en almacenamiento.

Integración técnica

Backblaze ofrece API y compatibilidad con herramientas como rclone y clientes S3, lo que facilita automatizar backups desde servidores Linux con cron o desde servicios gestionados. Esto funciona bien en teoría, pero en la práctica hay que ajustar transferencias multipart para ficheros grandes y limitar concurrencia para evitar timeouts.

Para tomar decisiones económicas útiles, conviene un cálculo sencillo que combine coste de almacenamiento mensual y coste de egress por restore.

• Usando un precio indicativo de Backblaze B2: almacenamiento ≈ $0.005/GB‑mes y egress ≈ $0.01/GB, los ejemplos quedan así:
• 50 GB → almacenamiento ≈ $0.25/mes; un restore completo (50 GB) → egress ≈ $0.50, total evento ≈ $0.75 (sin contar operaciones).
• 500 GB → almacenamiento ≈ $2.50/mes; restore completo → egress ≈ $5.00, total evento ≈ $7.50.
• 2 TB (2.048 GB) → almacenamiento ≈ $10.24/mes; restore completo → egress ≈ $20.48, total evento ≈ $30.72.
• Para restores parciales (p. ej. solo DB de 1 GB) el egress es mucho menor (~$0.01 por 1 GB), por eso conviene priorizar restores parciales para bajar RTO y minimizar coste. Las operaciones (PUT/GET/list) añaden coste variable según la frecuencia y la herramienta.
• Para estimar la factura completa sume las operaciones previstas (incrementales vs completas) y calcule restores previstos al mes para obtener una cifra realista de coste total.

Elección: plugin frente a CLI para respaldos a B2

Elegir entre plugin y CLI determina control, coste y RTO. La CLI (rclone/B2 CLI) da control total, menor coste por operaciones y mejores opciones de cifrado local; los plugins (UpdraftPlus, BackWPup, Jetpack Backup) aportan interfaz y restores guiados, pero pueden generar más operaciones y costes de egress si no se configuran con cuidado.

La mayoría de guías recomiendan plugins por facilidad. Lo que omiten la mayoría es que un plugin mal configurado puede crear copias completas diarias y multiplicar operaciones PUT/GET. Eso sube la factura y complica pruebas de restauración.

Un caso habitual: un proveedor activa UpdraftPlus con copias completas diarias para 500 GB y descubre facturas inesperadas por operaciones y egress tras varios restores parciales. La corrección fue migrar a rclone para incrementales y mantener UpdraftPlus solo para restores guiados.

Matriz decisoria rápida

Opinión práctica y matizada

La solución más práctica para la mayoría de pymes es combinar CLI para las copias regulares y un plugin para restores guiados en entornos con menos personal técnico. Esta mezcla permite controlar costes mientras se mantienen restores sencillos para no técnicos. Funciona bien, pero solo cuando se prueban los restores y se automatiza la rotación de claves; si no se prueban, la combinación crea complejidad y sobrecoste.

Cuándo elegir cada opción

Si la prioridad es control de costes y auditoría, elegir rclone. Si la prioridad es rapidez para restaurar por parte de personal no técnico, elegir UpdraftPlus premium o un servicio gestionado. La elección depende del tamaño de los datos, frecuencia de restores y capacidad técnica.

Además de la comparación básica entre plugin y CLI, conviene una tabla mental de pros y contras por herramienta para elegir según capacidad técnica, coste operativo y requisitos de RTO/RPO. Duplicator y BackupGuard son útiles para migraciones y restores puntuales pero tienden a crear paquetes completos que aumentan el coste de egress; UpdraftPlus (premium) facilita restores GUI y programaciones pero puede generar más operaciones PUT/GET si no se configuran incrementales; Green Backup y BackWPup son ligeros pero tienen menos opciones de cifrado del lado cliente; rclone y la B2 CLI ofrecen control granular, cifrado local y menor coste por operación pero requieren scripts y verificación periódica.

En entornos multisite o con ficheros muy grandes, priorizar herramientas que soporten multipart upload y chunking reduce fallos; en entornos con personal no técnico, mantener un plugin para restores guiados junto con scripts CLI para las copias automatizadas suele equilibrar RTO, RPO, coste de almacenamiento y egress.

Cómo automatizar backups a B2 con rclone y cron

Este flujo crea mysqldump diario, sincroniza wp-content incrementalmente, cifra con rclone crypt opcional y registra checksums. Usar este método reduce operaciones y mantiene control sobre egress.

Configuración inicial

1. Crear remote en rclone:

bash rclone config create b2remote b2 account= key=

1. Verificar conexión:

bash rclone lsd b2remote:mi-bucket

Script de ejemplo

bash set -e D=/var/www/miwp OUT=/tmp/backup_$(date +%F) mkdir -p "$OUT" mysqldump --single-transaction -uUSER -p'PASS' DBNAME | gzip > "$OUT/db_$(date +%F).sql.gz" rsync -a --delete "$D/wp-content/" "$OUT/wp-content/" rclone sync "$OUT" b2remote:mi-bucket/mi-site/daily --transfers=4 --checkers=8 --backup-dir b2remote:mi-bucket/mi-site/archives/$(date +%F) rclone md5sum b2remote:mi-bucket/mi-site/daily > /var/log/b2_md5_$(date +%F).log rm -rf "$OUT"

Cron y pruebas

Agregar a crontab del usuario con permisos:

cron 0 2 * * * /usr/local/bin/backup_wp_to_b2.sh >> /var/log/backup_wp.log 2>&1

Verificación semanal con rclone check:

bash rclone check /var/www/miwp/wp-content b2remote:mi-bucket/mi-site/daily --one-way

El error típico aquí es olvidar capturar errores y reinicios en el script; sin reintentos el fallo temporal de red provoca pérdida de la copia diaria. Añadir reintentos exponenciales evita ejecuciones incompletas.

Para quien automatiza fuera de WordPress conviene complementar los ejemplos de rclone con el CLI oficial de Backblaze (b2) y la API S3‑compatible. Ejemplos prácticos: autenticarse con b2: b2 authorize-account ; listar buckets: b2 list-buckets; subir un archivo: b2 upload-file mi-bucket ruta/local/archivo.tar.gz carpeta/remota/archivo.tar.gz. Para descargas o restores por ID se usa b2 download-file-by-id ruta/local. Cuando se usa la compatibilidad S3 (SDKs o herramientas S3) hay que apuntar al endpoint S3 compatible y crear application keys con el scope adecuado; esto facilita integraciones con clientes que no soportan la API nativa.

Incluir ejemplos de b2 junto a los de rclone permite elegir la herramienta adecuada según la complejidad: rclone aporta sincronización y cifrado crypt en una sola herramienta, el b2 CLI da acceso directo a metadatos, fileId y lifecycle, y la compatibilidad S3 facilita integraciones con soluciones empresariales.

Restaurar WordPress desde backblaze B2

Probar restauraciones periódicas revela problemas de permisos, integridad y compatibilidad de plugins. Registrar cada prueba y su tiempo total permite definir RTO real para cada sitio. Restaurar sin pruebas previas suele fallar por rutas de archivo distintas o por plugins que esperan ficheros temporales.

Checklist paso a paso para restaurar

1. Listar objetos disponibles con rclone ls b2remote:mi-bucket/mi-site/fecha.
2. Restaurar base de datos: rclone copy b2remote:mi-bucket/mi-site/fecha/db.sql.gz /tmp && gunzip -c /tmp/db.sql.gz | mysql -uUSER -p'PASS' DBNAME.
3. Restaurar uploads críticos: rclone copy b2remote:mi-bucket/mi-site/fecha/wp-content/uploads /var/www/miwp/wp-content/uploads --transfers=4.

Checklist para restore completo en entorno staging

1. Crear entorno staging con la misma versión de PHP, MySQL y permisos de archivos.
2. Restaurar DB y ficheros según pasos anteriores.
3. Ejecutar WP‑CLI search‑replace si cambia dominio.
4. Probar páginas clave, formularios y procesos de pago si aplica.

Corrección y ejemplo numérico: para convertir GB a segundos de transferencia, calcule primero los gigabits: Gbits = Tamaño_GB * 8. Tiempo_real_segundos ≈ Gbits / (Banda_Mbps * factor_uso), con factor_uso típico 0.7–0.9 por overhead de red. Luego divida por 60 para pasar a minutos. Por ejemplo, 50 GB → 400 Gbit (400 Gbit = 400000 Mb); con 100 Mbps utilizable al 80% (80 Mbps) el tiempo ≈ 400000 Mb / 80 Mb/s = 5000 s ≈ 83 min.

Para 500 GB con 200 Mbps utilizable al 80%: 4000 Gbit / 160 Mb/s ≈ 25000 s ≈ 417 min (~7 h). Las cifras del artículo deben actualizarse con este cálculo realista para evitar subestimar los RTO.

Ejemplos con cifras reales

• 50 GB con 100 Mbps netos → ≈ 7–12 min. Egress ≈ $0.50.
• 500 GB con 200 Mbps netos → ≈ 33–60 min. Egress ≈ $5.
• 2 TB con 500 Mbps netos → ≈ 90–240 min. Egress ≈ $20.

El error más frecuente durante restores es no comprobar permisos y propietarios de archivos, lo que genera errores 500 tras copiar ficheros. Corregir permisos suele resolverlo.

Lifecycle, versionado y políticas de retención aplicadas

Definir reglas de ciclo de vida evita acumulación de objetos y controla costes. Una política práctica es mantener backups diarios 30 días, semanales 6 meses y mensuales 12 meses. Aplicar estas reglas por prefijos facilita auditoría y restores selectivos.

Reglas concretas para prefijos

• daily/ → conservar 30 días y eliminar versiones anteriores.
• weekly/ → mover cada domingo a weekly/ y conservar 26 semanas.
• monthly/ → conservar 12 meses en monthly/ para auditoría.

Compatibilidad legal y excepciones

Para datos sujetos a GDPR (Reglamento 2016/679, 2016) y normas como ISO 27001 o PCI DSS hay que adaptar retenciones y auditoría. En ciertos datos personales sensibles la retención mínima puede verse condicionada por obligaciones legales o por derecho a supresión.

Seguridad técnica: cifrado, application keys y rotación

Generar application keys con el scope mínimo y ponerles expiración reduce el riesgo si una clave se filtra. Rotar claves cada 90 días y usar cifrado del lado cliente para datos sensibles reduce exposición y ayuda con el cumplimiento.

Permisos mínimos y expiración

Crear la key solo para el bucket y prefijo del sitio. Fijar expiración a 90 días y documentar el procedimiento de rotación. Error común: usar una key con allBuckets o sin expiración.

Cifrado del lado cliente

Usar rclone crypt o cifrado previo con gpg para asegurar que Backblaze no maneje claves del contenido. Para cumplimiento GDPR y auditorías esto aporta control sobre claves maestras.

Solución de problemas comunes

Autenticación fallida suele deberse a accountId o applicationKey incorrectos o a clocks desincronizados. Las timeouts aparecen cuando transfers y checkers son altos en conexiones inestables. Manejar retries y limitar concurrencia reduce fallos.

Errores de autenticación y permisos

Comprobar accountId y applicationKey con rclone lsd. Revisar que la key tenga permisos para el prefijo. Si la consola muestra 403, la key tiene scope insuficiente.

Timeouts y performance

Reducir --transfers a 2 y --checkers a 4 si hay timeouts. Usar multipart upload para ficheros >5 GB. Esto mejora estabilidad en conexiones con latencia.

Backups en WordPress multisite y sitios grandes

Multisite complica backups por carpetas y bases de datos por site. Excluir cachés y archivos temporales reduce tamaño; aplicar chunking y multipart upload mejora la fiabilidad con ficheros grandes. Para redes con cientos de sitios, separar backups por prefijo evita restauraciones masivas innecesarias.

Buenas prácticas para multisite

Respaldar la base de datos completa y los prefijos uploads por site. Usar scripts que armen backups por site y suban por prefijos distintos para facilitar restores selectivos. Un error frecuente es intentar restaurar una red completa sin probar restores parciales.

Manejo de ficheros grandes

Usar rclone --multi-thread-streams y multipart uploads para ficheros >100 MB. Ajustar --tpslimit si el hosting limita conexiones. Esto evita timeouts y fallos intermitentes en subidas.

Para asistencia técnica sobre pruebas de restore o redacción de la política de retención, se recomienda contratar soporte especializado que verifique scripts, rotación de claves y un primer restore completo en entorno staging.

Preguntas frecuentes

¿Cómo hago una copia de la base de datos y la subo a B2?

Usar mysqldump y comprimir el volcado, luego subir con rclone copy. mysqldump --single-transaction -uUSER -p'PASS' DBNAME | gzip > /tmp/db.sql.gz && rclone copy /tmp/db.sql.gz b2remote:mi-bucket/backups/.

¿Cuánto cuesta almacenar 500 GB en backblaze B2?

El coste de almacenamiento suele rondar $0.005/GB‑mes (≈ $2.50/mes para 500 GB, tarifa indicativa 2024). Añada coste de egress para restores si los realiza.

¿Los restores desde B2 cobran por descarga?

Sí. El egress suele ser ≈ $0.01/GB; por tanto restaurar 100 GB costaría ≈ $1 en egress.

¿Cada cuánto debo rotar las application keys?

Se recomienda rotación cada 90 días y documentar el proceso de cambio para evitar interrupciones. Si la clave se filtra, revocar y restaurar acceso con una nueva clave.

¿Cómo pruebo que un backup está íntegro?

Hacer rclone md5sum sobre el remote y compararlo con md5sum local. Programa una verificación completa al menos semanalmente.

¿Qué hacer si el restore tarda mucho?

Priorizar restore parcial: base de datos y uploads recientes. Calcular tiempo de descarga con la fórmula indicada y considerar aumentar la red o usar servidores temporales en la misma región que el bucket.

Tu próximo paso

Generar un plan de backup que documente: qué se copia, cuándo, dónde, quién tiene keys y cómo probar restores trimestrales. Empiece por crear el bucket, una application key con alcance limitado y subir un primer mysqldump manual para validar credenciales.

• Reduce downtime con seguridad WordPress Multisite y backups
• Backups para tiendas digitales: protege ventas y archivos

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.