¿Cuánto costaría perder el progreso y los certificados de varios cursos por una restauración mal planificada? Quien gestiona un LMS con LearnDash conoce el riesgo: copias incompletas rompen relaciones usuario‑curso, borran métricas y dificultan auditorías y continuidad operativa.
Backup para sitios LMS (LearnDash): ¿qué conviene proteger? Protege base de datos (tablas clave de LearnDash y addons), archivos de cursos y multimedia en wp‑uploads, progreso y calificaciones, inscripciones, certificados, perfiles de usuario y metadatos; incluye configuraciones, plugins y logs. Se recomienda usar backups automáticos con retención ligada a la actividad, cifrado y pruebas periódicas de restauración para validar integridad y RTO/RPO y comprobar cumplimiento GDPR.
Factores que determinan qué proteger
La elección de qué copiar depende de la actividad del LMS, el volumen de usuarios y los requisitos legales.
Tablas SQL indispensables
Incluya siempre las tablas que almacenan cursos, lecciones, quizzes y actividad de usuarios.
- wp_posts contiene los Custom Post Types como sfwd-courses, sfwd-lessons y certificados.
- wp_postmeta guarda metadatos de cursos, quizzes y certificados.
- wp_users y wp_usermeta almacenan perfiles y campos personalizados.
- wp_options contiene ajustes globales y cron jobs.
- wp_learndash_user_activity y wp_learndash_user_activity_meta registran progreso y tiempos.
- Tablas de quizzes avanzados, por ejemplo wp_pro_quiz_*, si el sitio usa ProQuiz o addons.
La evidencia muestra que sin estas tablas se pierde el historial de alumnos tras un restore.
Guarde la carpeta wp-content/uploads completa y cualquier carpeta adicional donde se alojan los materiales.
- Subidas originales de alumnos y recursos del curso.
- Certificados generados (PDF o imágenes) en uploads o en postmeta.
- Plugins y themes en
wp-content, para reproducir el entorno.
Un curso sin sus archivos multimedia queda inservible aun con la DB intacta.
Localice las meta_keys relacionadas con LearnDash y los addons antes de automatizar backups.
- Buscar meta_keys en wp_postmeta, filtrando por post_type 'sfwd-%'.
- Revisar wp_usermeta para claves que guarden porcentajes, timestamps o tokens.
Lo que omiten la mayoría de guías es que algunos addons guardan JSON dentro de postmeta. Copiar solo tablas no basta sin incluir esos campos.
Políticas RPO/RTO según tipo de LMS
Definir RPO y RTO permite ajustar frecuencia y retención de backups al riesgo operativo.
Matriz RPO/RTO recomendada
- Cursos en vivo: RPO = 1 a 4 horas. RTO = 1 a 6 horas.
- Inscripciones periódicas: RPO = 6 a 12 horas. RTO = 12 a 24 horas.
- Biblioteca estática: RPO = 24 horas. RTO = 24 a 72 horas.
Estas cifras permiten balancear coste y disponibilidad según actividad.
Tipos de backup y retención
Combine snapshots del host con backups incrementales y una copia completa semanal.
- Snapshots reducen RTO, útiles para picos con cursos en directo.
- Incrementales reducen espacio y coste.
- Retenciones: mantener 7-14 snapshots diarios para cursos activos.
Desde la entrada en vigor del RGPD, conviene mantener ubicaciones en la UE y cifrado en reposo.
Almacenamiento y cifrado
Almacene offsite en S3 o GCS con cifrado servidor-lado.
- Preferir regiones EU para datos de alumnos en España.
- Activar SSE y cifrado en tránsito (TLS).
Según WordPress.org, WordPress impulsa una gran parte de los sitios web, con muchos LMS alojados sobre WordPress. Fuente
Plugins, hosting y compatibilidad con LearnDash
No todos los plugins de backup incluyen tablas personalizadas ni ofrecen restauración granular.
Tabla comparativa de soluciones
| Plugin/servicio |
Incluye DB completa |
Soporta tablas personalizadas |
Multisite |
Storage S3/GCS |
| UpdraftPlus |
Sí |
Depende de configuración |
Con add-on |
Sí |
| BlogVault |
Sí |
Sí, suele cubrir addons |
Sí |
Sí |
| VaultPress / Jetpack |
Sí |
Generalmente sí |
Limitado |
Sí |
| Snapshots hosting (Kinsta/WP Engine) |
Sí (snapshots) |
No siempre documentado |
Sí, por plataforma |
Interno |
Qué comprobar antes de elegir
Verificar que el servicio liste tablas wp_learndash_* o permita incluir patrones de tablas.
- Solicitar una prueba de restore en staging.
- Comprobar logs y opciones de restauración selectiva.
Un caso habitual: contratar un plugin y descubrir que no incluye tablas de ProQuiz. El resultado fue pérdida de resultados de quizzes tras la restauración.
Checklist de compatibilidad práctica
Antes de contratar o automatizar un backup WordPress para un LMS, valide con pruebas concretas si el proveedor incluye tablas y metadatos de LearnDash. Pasos de verificación sencillos:
- Solicite un listado de tablas incluidas o descargue un backup .sql y confirme la presencia con
grep -E "CREATE TABLE .*wp_learndash|CREATE TABLE .*wp_pro_quiz" backup.sql o con mysql -u user -p dbname < backup.sql en staging y luego SHOW TABLES LIKE 'wp_learndash%';
- Verifique que el backup contiene entradas de
wp_learndash_user_activity y wp_learndash_user_activity_meta y ejemplos de wp_pro_quiz_* si usa ProQuiz
- Compruebe si el plugin permite incluir/excluir tablas personalizadas desde la UI (por ejemplo, UpdraftPlus Premium tiene opción para tablas personalizadas; algunos servicios gestionados como BlogVault o las copias gestionadas por el hosting suelen capturar tablas adicionales, pero exija una restauración de prueba)
- Pruebe restauración selectiva en staging y coteje contadores con
SELECT COUNT(*) FROM wp_learndash_user_activity; y SELECT COUNT(*) FROM wp_posts WHERE post_type='sfwd-certificates';. Documente los resultados para cada herramienta (incluye si soporta Multisite y restores parciales)
Playbooks de restauración que preservan relaciones
Restaurar en el orden correcto preserva el vínculo usuario→curso. Siga este orden para minimizar errores.
Playbook básico
- Poner el sitio en mantenimiento.
- Restaurar la base de datos completa primero.
- Restaurar
wp-content/plugins y wp-content/themes.
- Restaurar
wp-content/uploads.
- Ejecutar search-replace si hubo cambio de dominio con WP-CLI.
- Limpiar caches y ejecutar cron inmediato.
La restauración de la DB debe preceder a los archivos para mantener integridad referencial.
Comandos y consultas útiles
- Exportar tablas concretas:
mysqldump -u user -p dbname wp_learndash_user_activity > activity.sql
- Importar DB:
mysql -u user -p dbname < all.sql
- WP-CLI search-replace:
wp search-replace 'old.example' 'new.example' --skip-columns=guid
Validaciones post-restore
- Comprobar actividad de usuarios:
SELECT COUNT(*) FROM wp_learndash_user_activity;
- Verificar certificados publicados:
SELECT ID FROM wp_posts WHERE post_type='sfwd-certificates' AND post_status='publish';
- Probar login con 3 perfiles: estudiante, profesor, admin.
El error más frecuente en este punto es restaurar archivos antes que la base de datos. Esto rompe referencias y obliga a remapear manualmente.
Restauración de un curso aislado
Cuando necesite restaurar solo un curso sin afectar el resto del sitio, siga un flujo dirigido que restaure tanto el contenido del curso como las entradas de actividad relacionadas. Paso 1: identificar IDs del curso y sus lecciones (por ejemplo, COURSE_ID y lesson IDs) con SELECT ID, post_title FROM wp_posts WHERE post_type='sfwd-courses' y SELECT ID FROM wp_posts WHERE post_parent=COURSE_ID AND post_type IN ('sfwd-lessons','sfwd-topic'). Paso 2: exporte posts y postmeta relacionados: mysqldump --single-transaction --skip-lock-tables dbname wp_posts --where="ID IN (list_ids)" > course_posts.sql y mysqldump dbname wp_postmeta --where="post_id IN (list_ids)" > course_postmeta.sql. Paso 3: exporte actividad de usuarios vinculada al curso: mysqldump dbname wp_learndash_user_activity --where="post_id IN (list_ids)" > course_activity.sql y mysqldump dbname wp_learndash_user_activity_meta --where="activity_id IN (select id from wp_learndash_user_activity where post_id IN (list_ids))" > course_activity_meta.sql.
Paso 4: en staging importe en el orden: course_posts.sql → course_postmeta.sql → course_activity.sql → course_activity_meta.sql y verifique con consultas como SELECT COUNT(*) FROM wp_learndash_user_activity WHERE post_id IN (list_ids) y comprobando que los user_id referencian usuarios existentes (wp_users). Si durante la importación hay desajuste de IDs, utilice el mapping user_id→user_email exportado previamente para remapear o restaurar usuarios antes de la actividad. Este procedimiento permite recuperar un curso y su historial de alumnos sin rehacer todo el sitio.
Multisite, rendimiento y consideraciones legales
Multisite exige respaldo de todas las tablas y de las carpetas uploads por sitio.
Backup en multisite
- Hacer dump de la base de datos completa, no solo del site principal.
- Respaldar
wp-content/uploads/sites/{blog_id} para cada subsite.
- Confirmar que el plugin soporta restores parciales por subsite.
Rendimiento y ventanas de backup
Programar backups completos fuera de horarios punta de cursos en vivo.
- Usar replicación de BD para ejecutar backups desde la réplica.
- Emplear snapshots incrementales durante sesiones en directo.
Cumplimiento RGPD y LOPDGDD
- Guardar backups en la UE y cifrados en reposo y tránsito.
- Mantener logs de acceso y lista de quienes acceden a los backups.
- Definir procedimiento para retirar datos personales de una copia si se solicita "derecho al olvido".
Desde su lanzamiento, LearnDash apareció como solución LMS para WordPress, y desde entonces muchas implementaciones requieren atención específica en los backups. LearnDash
Las tablas clave de LearnDash que nunca deben omitirse en el backup incluyen wp_learndash_user_activity y wp_learndash_user_activity_meta. Si el proveedor de backup no las lista, no lo contrate sin pruebas de restore en staging.
Flujo de backup recomendado
DB full
Incluye tablas LearnDash
Offsite cifrado
S3/GCS EU
Restore: DB → plugins/themes → uploads → search-replace → validación
Pruebas de restore y métricas operativas
Sin pruebas regulares, la política de backups es una ilusión.
Plan de pruebas y frecuencia
- Verificar backups diariamente para fallos de ejecución.
- Restaurar en staging al menos cada mes.
- Simular desastre completo cada trimestre y medir RTO.
Métricas a registrar
- RPO real alcanzado tras cada incidente.
- RTO medido en cada simulacro.
- Número de archivos corruptos detectados por prueba de checksum.
Los expertos recomiendan informes que el DPO pueda revisar en auditorías.
Playbook de pruebas
Para obtener métricas válidas de RTO y RPO en un entorno LearnDash, ejecute pruebas regulares con usuarios sintéticos y comprobaciones automatizadas. Preparación: cree un usuario de prueba ([email protected]), inscríbalo en un curso y registre una actividad (completar lección y generar certificado). Anote el timestamp del último evento (SELECT MAX(activity_last) FROM wp_learndash_user_activity WHERE user_id = X;). Simulación: borre o aísle la instancia en staging y ejecute la restauración desde el backup objetivo. Medición: mida el tiempo desde el inicio del incidente hasta que el sitio está funcional y el usuario de prueba recupera el progreso (RTO). Calcule RPO como la diferencia entre el timestamp del último evento y la marca temporal más reciente recuperada en la restauración (SELECT MAX(activity_last) FROM wp_learndash_user_activity WHERE user_id = X; en el sitio restaurado).
Validaciones adicionales: comprobar certificados con SELECT ID FROM wp_posts WHERE post_type='sfwd-certificates' AND post_author = X; y validar archivos multimedia con checksums (find wp-content/uploads/course_{id} -type f -exec sha256sum {} /;). Registre tiempos y resultados en cada simulacro para comparar con los RPO/RTO objetivo y ajustar la frecuencia de backups incrementales/snapshots en consecuencia.
Errores habituales y cómo evitarlos
Evite estos fallos para no perder progreso ni alumnos.
Errores que causan pérdida de datos
- Hacer solo copia de archivos y olvidar la base de datos.
- Confiar en plugins sin comprobar que incluyen tablas personalizadas.
- Restaurar sin mapear IDs de usuarios y posts.
Cómo prevenirlos
- Documentar listas de tablas y meta_keys antes de automatizar.
- Probar restore en staging tras cada cambio mayor.
- Mantener export de mapping user_id→email y post_id→slug fuera del backup principal.
Oferta práctica
Para validar la estrategia y ejecutar un simulacro, se puede solicitar una auditoría técnica que incluya pruebas de restore y reporte de RTO/RPO alcanzados.
No aplique estas recomendaciones si el sitio no usa LearnDash ni almacena datos de alumnos en WordPress. En ese caso, los backups pueden limitarse a archivos estáticos y DB mínima del CMS.
Preguntas frecuentes
¿Qué tablas de LearnDash debo incluir sí o sí?
Incluir las tablas wp_learndash_user_activity y wp_learndash_user_activity_meta junto con wp_posts, wp_postmeta, wp_users y wp_usermeta. También añadir tablas de quizzes como wp_pro_quiz_* cuando existan.
¿Con qué frecuencia probar restores en un LMS?
Probar restores completos en staging al menos una vez al mes y hacer simulacros trimestrales. Además vigilar backups diarios y comprobar logs cada día.
¿Puedo usar solo snapshots del hosting para backups?
Sí para RTO cortos, pero conviene complementar con backups offsite cifrados para cumplir retención y GDPR. Los snapshots del host suelen ser rápidos pero pueden no conservar retenciones largas.
¿Cómo evito perder certificados al restaurar?
Restaurar primero la base de datos y luego los archivos. Comprobar que los posts tipo sfwd-certificates existen y que los metadatos referencian users por ID.
¿Qué pasa si los IDs cambian tras migrar el sitio?
Si los IDs cambian, hay que remapear usermeta y tablas de actividad. Mantener export de mapping user_id→email evita remapeos complejos.
¿Cómo cumplir RGPD con backups en la nube?
Almacenar en regiones EU, cifrar en tránsito y en reposo, y mantener logs de acceso. Tener procedimientos para eliminar datos de un backup si un usuario lo solicita.
Qué hacer ahora
Revisar la lista de tablas y meta_keys y programar una prueba de restore en staging para comprobar integridad.
- Exportar mapping de usuarios y posts.
- Confirmar que el proveedor de backup incluye wp_learndash_ y wp_pro_quiz_.
- Programar prueba mensual y registrar RTO y RPO alcanzados.
Plazo orientativo: realizar la primera prueba de restore en un entorno staging en los próximos 30 días. Mantener registros de la prueba y corregir exclusiones de tablas si se detectan fallos.
