Plan — LMS WordPress (OVHcloud) + Backblaze B2 + ingesta desde Telegram

Fecha: 2026-09-22. Estado: plan + kit de despliegue esqueleto (nada desplegado). Kit ejecutable: ~/nef/Proyectos/curso-lms/.

Objetivo

Vender/custodiar cursos en vídeo en un WordPress propio, con los medios fuera del VPS (B2) y un canal rápido para meter vídeos nuevos (Telegram → VPS → B2).

Límite (requisito duro)

Esta arquitectura solo es para contenido que tú posees o tienes licencia para distribuir. La infraestructura (WordPress, B2, un canal propio de Telegram como bandeja de entrada) es neutra y legal; redistribuir cursos de terceros no lo es. El pipeline de Telegram se asume como tu buzón de subida personal, no como fuente de contenido ajeno. Si el origen es un canal de cursos pagados de otros, esto no se construye.

Corrección técnica clave (lo que el plan previo daba por hecho)

La Bot API de Telegram NO sirve para vídeos grandes. getFile está limitada a 20 MB por archivo, así que un bot tipo dropbot no puede bajarte un curso en vídeo. Para archivos grandes hay que usar MTProto con una cuenta de usuario (userbot con Telethon/Pyrogram, o el daemon “premium”), que sí baja hasta 2 GB (cuenta normal) o 4 GB (Premium). Implicaciones:

• Usa una cuenta secundaria de Telegram como userbot: automatizar con la cuenta principal arriesga suspensión.
• Límite duro 4 GB/archivo aun con Premium → parte vídeos largos o súbelos por otro canal.
• No es rsync literal: rsync no habla S3 nativo. Se usa rclone (rclone move, equivalente funcional y fiable). Si de verdad quieres rsync hay que montar el bucket con s3fs (rsync a un path montado) — más frágil. Recomendado: rclone.
• rclone no tiene backend oficial de Telegram (rclone#5829 sigue abierto). El fork sendotim/RcloneTelegram usa bot token → tope 2 GB y no accede a tu cuenta. Por eso la bajada de Telegram no se hace con rclone: se hace con tdl, y rclone solo se encarga del tramo staging → B2.

Ingesta masiva: bajar TODO lo que tienes (~TB)

Objetivo real: no un canal en vivo, sino un volcado completo de la cuenta. Herramienta: tdl (iyear/tdl) — Go, binario único, pensado para esto.

Flujo en dos fases:

Fase 1 (inventario)   tdl chat ls -o json          -> qué chats y cuánto pesan
Fase 2 (volcado)      por chat: export JSON -> tdl dl -f result.json \
                          --takeout --continue --skip-same --rewrite-ext --group \
                          -d /srv/telegram-downloads/<chat> -t 8 -l 2
                      y el cron existente hace  rclone move  staging -> B2

• --takeout es el truco clave a escala TB: las sesiones de takeout tienen límites de flood-wait mucho más bajos. Sin esto, Telegram te frena.
• --continue: reanudable. Un volcado de TB se cortará; debe poder retomarse.
• Nunca stagings completos en el VPS: tdl escribe en /srv/telegram-downloads y el cron de rclone move (cada 10 min) lo vacía a B2. El VPS solo necesita caber el archivo más grande (≤4 GB) + margen.
• Filtros de extensión (-i mp4,mkv,pdf o -e jpg,png) para no arrastrar basura si solo quieres vídeo/documentos.
• tdl chat ls -f "Type contains 'channel' && VisibleName contains 'X'" para acotar qué chats exportar.

Matemática de tiempo y costo (para dimensionar)

Cantidad	B2/mes (a $6.95/TB)	Tiempo de bajada (10–50 MB/s, server-side)
1 TB	~$7	~6–29 h
3 TB	~$21	~17–87 h (≈1–4 días continuos)
5 TB	~$35	~28–145 h

Realidad: añade 30–50% por flood-waits y reinicios. Cuenta con ~1 semana de volcado en segundo plano, no una tarde. Egress B2 gratis hasta 3× lo almacenado.

Riesgo de cuenta (importante)

tdl no envía mensajes ni hace acciones “peligrosas”, pero descargar TB de golpe puede disparar flood-wait o restricciones. Mitigación: cuenta secundaria (no la principal), --takeout, threads bajos (-t 4 -l 1), y no correr 24/7 a máximo. Alternativa sin riesgo de cuenta: exportar desde Telegram Desktop (GUI, por chat) — pero es manual y tedioso a escala TB.

Arquitectura

[Alumnos] ──► [WordPress + LMS en VPS OVHcloud] ──► [Backblaze B2: medios]
                        ▲
   [Tu cuenta Telegram] ─► [tdl en VPS (takeout)] ─► [/staging] ─(rclone move)─► B2

Capa	Qué	Dónde
App	WordPress + LMS (Masteriyo o LifterLMS)	VPS OVHcloud (nginx + php-fpm + MariaDB)
Medios	Bucket B2 S3-compatible + plugin offload	Backblaze B2
Volcado	tdl (MTProto, takeout, reanudable)	VPS, ejecución puntual
Sync	rclone move staging → B2 (cron)	cron del VPS

Offload de medios: el plugin sube a B2 lo que se cargue por WordPress y reescribe las URLs. Ojo: los archivos que entran por Telegram no pasan por WordPress, así que hay que decidir cuál de los dos caminos es canónico:

• A) Ingesta Telegram → B2 directo, y en WordPress referencias la URL del vídeo (funciona, pero pierdes el registro en la Biblioteca de medios).
• B) Ingesta Telegram → carpeta uploads local → plugin lo sube a B2 (más “nativo” en WP, pero el VPS necesita espacio temporal). Empezar por A (más simple, VPS nunca se llena).

Plan de 7 días (checklist completo en el kit)

1. VPS OVHcloud + Ubuntu + LEMP + WordPress + TLS.
2. Bucket B2 + plugin de offload (Advanced Media Offloader o KAZCODE Universal Storage) + prueba de subida.
3. tdl en el VPS: login (cuenta secundaria), inventario (chat ls), primer volcado de un chat con --takeout --continue, verificado contra B2.
4. rclone + sync-to-b2.sh + cron (staging → B2, libera el VPS).
5. LMS (Masteriyo o LifterLMS) + curso de prueba + Stripe/PayPal en modo test.
6. Caché, seguridad (Wordfence + 2FA), backups, monitorización.
7. Prueba de flujo completo + documentar credenciales + rutina de mantenimiento.

Costos mensuales estimados

Componente	USD/mes
VPS OVHcloud VPS-2 (2 vCPU / 8 GB / 80 GB)	~14–20
Backblaze B2 (1 TB, API gratis, egress gratis hasta 3× lo almacenado)	~7
Dominio (amortizado)	~1–2
Total	~22–29

Riesgos

• Restricción de la cuenta de Telegram por volcar TB de golpe (flood-wait) → cuenta secundaria, --takeout, threads bajos, ritmo humano.
• Egress de B2 puede superar el free tier con picos de alumnos ($0.01/GB).
• Coste real de transcodificar en VPS: sin GPU, varios alumnos simultáneos en calidades distintas saturan la CPU. Servir progresivo/HLS ya codificado; no transcodificar en vivo.
• Backups: B2 guarda los medios; la BD de WordPress necesita su propio backup (UpdraftPlus/BlogVault). No confundir.

Decisiones (ADR)

• rclone move, no rsync+s3fs. Razón: fiabilidad y borrado tras verificar.
• Medios en B2, no en el VPS. Razón: el VPS nunca debe llenarse.
• tdl para bajar de Telegram, no Bot API ni rclone-telegram. Razón: límite de 20 MB en Bot API y 2 GB en el backend de bot; tdl usa tu cuenta con takeout.
• WordPress + Masteriyo como MVP. Razón: menor fricción; se migra a LearnHouse si el proyecto crece.

Abierto / siguiente sesión

• ¿Qué LMS final: Masteriyo vs LifterLMS? (decidir antes de comprar licencia)
• ¿Bucket privado servido por CDN (Cloudflare) o URLs firmadas? (afecta egress y protección del contenido)
• ¿Volcado completo o selectivo? (filtrar por tipo/extensión antes de bajar TB)
• Confirmar flags exactos de tdl contra docs.iyear.me/tdl antes del volcado grande (el script del kit es plantilla).

Avance del kit (2026-09-22, sesión 2)

Añadido a ~/nef/Proyectos/curso-lms/:

• host/01-bootstrap-vps.sh — Día 1 automatizado (LEMP + WP-CLI + WordPress + certbot + ufw + swap). Idempotente.
• host/02-install-pipeline.sh — instala tdl/rclone/jq, despliega scripts a /usr/local/bin, deja /etc/cron.d/curso-lms-sync.
• host/verify.sh — verifica WP, tdl, rclone/B2, staging y cron (pass/fail).
• pipeline/env.example ampliado con las variables de host (DOMAIN, DB_*, WP_*).

Hechos verificados en esta sesión:

• Instalación oficial de tdl: curl -sSL https://docs.iyear.me/tdl/install.sh | bash (no hay que hardcodear assets). Release actual v0.20.4; Linux amd64 = tdl_Linux_64bit.tar.gz, arm64 = tdl_Linux_arm64.tar.gz.
• Los 5 scripts pasan bash -n. host/verify.sh ejecutado en seco (sin VPS) devuelve fallos esperados sin romper.

Sin verificar (requiere VPS real): 01-bootstrap-vps.sh y 02-install-pipeline.sh no se han corrido contra Ubuntu 24.04. Revisar antes de ejecutar en producción.