phpMyAdmin本身不支持设置每周完整备份，因其仅为前端Web工具，无后台进程与定时任务能力；真正可行的是通过mysqldump结合系统cron实现自动化导出，并配合脚本完成压缩、命名及清理等操作。
phpmyadmin 本身不支持设置每周完整备份——它没有后台进程、不提供定时任务能力，也无法直接调用加密或归档逻辑。所谓“在 phpmyadmin 里设每周备份”，实际是常见误解，真正可行的路径只有：用 mysqldump + 系统 cron 实现自动化导出，再配合脚本完成压缩、命名、清理等操作。
为什么不能在 phpMyAdmin 界面里配置“每周备份”
phpMyAdmin 是纯前端 Web 工具，所有操作都依赖用户手动点击。它的「导出」功能本质是拼接并触发一次 mysqldump 命令（或等效 SQL 构造），但不会持久化调度逻辑。你看到的任何“计划备份”选项，要么是第三方插件（极少见且不维护），要么是面板（如宝塔）封装的外部脚本，和 phpMyAdmin 本身无关。
常见错误现象包括：Access denied（cron 环境下 MySQL 凭据失效）、command not found: mysqldump（没写绝对路径）、备份文件空或损坏（未加 --single-transaction 导致锁表/不一致）。
用 cron + mysqldump 实现每周完整备份的最小配置
以下脚本适用于 Linux，假设数据库名为 myapp，备份目标目录为 /backup：
#!/bin/bash
DB_NAME="myapp"
DUMP_FILE="/backup/${DB_NAME}_$(date +\%Y\%m\%d).sql"
/usr/bin/mysqldump \
-u root \
--defaults-extra-file=/root/.my.cnf \
--single-transaction \
--routines \
--triggers \
--events \
"$DB_NAME" > "$DUMP_FILE"
gzip "$DUMP_FILE"关键点说明：
立即学习“PHP免费学习笔记（深入）”；
-
--defaults-extra-file指向 MySQL 配置文件（含密码），比明文写-p安全；该文件权限必须是600 -
--single-transaction对 InnoDB 表保证一致性快照，避免锁库；MyISAM 表需改用--lock-all-tables - 务必用绝对路径调用
/usr/bin/mysqldump和/bin/gzip，cron 不继承 shell 的$PATH - 压缩用
gzip而非 phpMyAdmin 默认的 zip —— 更轻量、更易脚本处理
如何让 cron 真正按“每周一凌晨2点”执行
运行 crontab -e，添加这一行：
0 2 * * 1 /bin/bash /path/to/weekly_backup.sh >> /var/log/weekly_backup.log 2>&1
注意这几点：
-
1表示周日是 0，周一才是 1 —— 别写成7或mon（部分 cron 实现不识别英文缩写） - 开头显式调用
/bin/bash，确保脚本以 bash 解释器运行（尤其涉及$(date)时） - 日志重定向
>> /var/log/... 2>&1必不可少，否则失败时你根本看不到报错 - 测试 cron 是否生效：临时改成
* * * * *（每分钟跑一次），观察日志和备份文件生成情况
真正容易被忽略的是权限链和环境隔离：cron job 运行时没有你的交互 shell 环境变量（比如 HOME、PATH），也不会自动加载 ~/.bashrc。哪怕脚本本地测试通过，丢进 cron 就静默失败，八成是路径或凭据问题。别跳过日志验证这一步。
