本文目录导读：
Moodle 作为广泛使用的开源学习管理系统（LMS），其数据的备份与恢复策略至关重要，由于 Moodle 系统包含数据库、文件（上传的课程资料、用户头像等）和代码,一个完整的恢复策略需要考虑到这三部分。
以下是一套从基础到高级的 Moodle 备份与恢复策略。
核心原则
- 三部分都要备份：缺少任何一部分（数据库、数据文件、代码）都无法恢复完整功能。
- 自动化：手动备份容易遗忘,必须自动化。
- 异地与离线：备份必须存储在不同的物理地点或云存储上,以防服务器硬件故障或灾难。
- 定期验证：定期测试备份文件能否成功恢复,确保备份文件没有损坏。
第一部分：需要备份的内容（三大支柱）
数据库（最重要）
Moodle 的所有课程设置、用户信息、成绩、论坛帖子等都在数据库里。
- 数据库类型：MySQL 或 MariaDB（最常用）。
- 备份命令（Linux/MariaDB）：
mysqldump -u username -p --opt moodle_database > moodle_db_backup.sql
- 推荐策略：每日备份（或每6小时，视更改频率而定）。
数据文件（moddata）
这是用户上传的各种文件：课程资料、作业提交、论坛附件、用户头像、SCORM包等。
- 位置：通常在 Moodle 根目录下的
moodledata或data文件夹（注意：这不是 Web 根目录，而是配置文件中$CFG->dataroot指定的路径）。 - 备份命令（Linux）：
tar -czf moodledata_backup.tar.gz /path/to/your/moodledata
- 推荐策略：增量或全量备份（因为文件量大且增长慢，每周全量 + 每日增量比较高效）。
网站代码（核心 + 插件）
Moodle 的程序文件本身，虽然可以从官网下载，但你自己安装的插件（Plugin）、主题（Theme）、自定义语言包、以及 config.php 配置文件是独一无二的。
- 关键文件：
config.php绝对必备。/moodle/local/、/moodle/mod/、/moodle/blocks/、/moodle/theme/下的自定义插件。 - 备份命令（Linux）：
tar -czf moodle_code_backup.tar.gz /path/to/your/moodle_webroot
- 推荐策略：每月全量备份（代码相对稳定，仅在更新插件或 Moodle 版本时变化）。
第二部分：推荐备份策略（按场景分类）
场景A：小型站点（少于 500 用户，手动管理）
-
频率：每周一次全量备份。
-
方法：通过
mysqldump备份数据库，tar打包moodledata和moodle代码目录。 -
存储：保留最近 4 周的备份,下载到本地硬盘或云盘。
-
脚本示例（每周 cron 任务）：
#!/bin/bash BACKUP_DIR="/backups/moodle" DATE=$(date +%Y%m%d) # 1. 备份数据库 mysqldump -uMoodleUser -p'YourPassword' moodle_db > $BACKUP_DIR/moodle_db_$DATE.sql # 2. 备份代码 tar -czf $BACKUP_DIR/moodle_code_$DATE.tar.gz /var/www/html/moodle # 3. 备份数据 tar -czf $BACKUP_DIR/moodledata_$DATE.tar.gz /var/moodledata # 清理 30 天前的备份 find $BACKUP_DIR -name "*.sql" -mtime +30 -delete find $BACKUP_DIR -name "*.tar.gz" -mtime +30 -delete # 可选：上传到远程备份服务器 # rsync -avz $BACKUP_DIR user@remote-backup:/backups/
场景B：中型站点（500-5000 用户，自动化运维）
- 频率：
- 数据库：每日一次（凌晨低负载时）。
- 数据文件：每日一次增量（使用
rsync+ 快照）。 - 代码：仅在更新覆盖后手动备份。
- 方法：使用完整的备份脚本，并开启 Moodle 自带的维护模式（
$CFG->maintenance_enabled = true;）以避免备份时产生脏数据。 - 最终步骤：将备份文件自动复制到不同的服务器或云对象存储（如 AWS S3、阿里云OSS、自建 NAS）。
场景C：大型站点（高可用，集群）
- 数据库：使用主从复制,备份从库。
- 数据文件：使用共享存储（如 NFS、GlusterFS、对象存储），对这些存储进行快照备份。
- 恢复目标：RPO（恢复点目标）< 1小时，RTO（恢复时间目标）< 4小时。
- 常用工具：
xtrabackup（热备 MySQL）、LVM快照、rsync+hardlink（用于增量备份）。
第三部分：快速恢复方案（灾难恢复）
假设服务器完全崩溃，你拥有最新的 moodle_code.tar.gz、moodledata.tar.gz 和 moodle_db.sql。
恢复数据库
mysql -u root -p moodle_db < moodle_db_backup.sql
恢复代码
# 如果是从官网下载的新代码，先安装基础代码 # 然后解压你的备份代码（覆盖） tar -xzf moodle_code_backup.tar.gz -C /var/www/html/
恢复数据文件（关键）
# 确保目录权限正确（通常是 www-data 或 apache 用户） chown -R www-data:www-data /var/moodledata chmod -R 755 /var/moodledata tar -xzf moodledata_backup.tar.gz -C /var/
验证核心文件
确保 /var/www/html/moodle/config.php 存在且配置正确（数据库名、密码、dataroot 路径）。
清理与测试
- 在浏览器访问 Moodle 站点，看是否自动进入升级页面（如果有插件版本变化，需要运行
/admin/index.php）。绝对不要手动取消升级过程。 - 检查用户登录、课程访问、上传文件是否能显示。
第四部分：常见陷阱与最佳实践
| 陷阱 | 解决方案 |
|---|---|
| 备份时有人访问 | 在执行备份脚本前，短暂开启 Moodle 维护模式（php admin/cli/maintenance.php --enable）。 |
| 备份的文件损坏 | 每次备份后，运行 md5sum backup.sql 记录哈希值；恢复前检查一致性。 |
config.php 丢失 |
将 config.php 单独备份一次，甚至可以备份到密码管理器。 |
| 数据库字符集不同 | 导出时指定字符集：mysqldump --default-character-set=utf8mb4。 |
| 只备份了数据库 | 用户上传的文件（作业、课程素材）会丢失，保证 moodledata 是完整可恢复的。 |
| 插件版本不匹配 | 恢复代码时，不要恢复整个 /moodle 目录的 lib/ 和 admin/，更安全的做法是只恢复自己的自定义插件和主题，然后使用最新版 Moodle 代码（从官网下载）重新安装，再恢复数据库，这样能避免代码兼容性问题。（这是一种常见的“干净恢复”策略） |
最省心的策略（建议）
对于 90% 的 Moodle 管理员，推荐组合：
- 数据库：每天凌晨通过
mysqldump全量备份（保留7天）。 - 数据文件 (
moodledata)：通过rsync每天同步到另一台服务器（或云存储）。 - 代码 (
/moodle+config.php)：每次升级 Moodle/插件前后手动备份。 - 定期测试：每季度在测试环境完整恢复一次,验证可用性。
一句话：备份数据库 + 备份 moodledata + 保存好 config.php，这三点同时做好，Moodle 就可以在任何时候重生。
