linux下用crontab调用php脚本执行备份，关键在于确保cron能正确加载环境、找到php可执行文件，并处理路径、权限及mysql连接等问题；必须用绝对路径调用php和命令，脚本中所有文件操作路径须为绝对路径，数据库连接建议用127.0.0.1替代localhost，mysqldump应使用--result-file参数并重定向错误，密码应通过~/.my.cnf配置，备份需压缩并清理旧文件，crontab中需显式声明path，且务必添加日志重定向。
Linux下用crontab调用PHP脚本执行备份，不是写完就能跑
PHP脚本本身不会自动定时运行，必须依赖系统级调度器。Linux最常用的是cron，关键在于让cron能正确加载环境、找到PHP可执行文件、并处理脚本中涉及的路径和权限问题。
常见错误现象：cron日志里报Command not found（找不到php）、Permission denied（没执行权限）、或脚本里file_put_contents写入失败（路径是相对的，而cron工作目录默认是/root或用户家目录）。
- 用绝对路径调用PHP：比如
/usr/bin/php /var/www/backup.php，别只写php backup.php - 脚本开头加
#!/usr/bin/env php并chmod +x后，仍建议在crontab里显式指定PHP路径——避免env在cron里不可靠 - 所有文件操作路径（如
date("Y-m-d").".sql"）必须用绝对路径，比如/var/backups/mysql/，不能用./backups/ - 数据库连接若用socket（如
localhost），cron可能无法访问/var/run/mysqld/mysqld.sock，改用127.0.0.1更稳妥
PHP脚本里用exec()还是shell_exec()导出MySQL
直接在PHP里调用mysqldump比用PDO读再写文件更可靠——它天然支持表结构、触发器、字符集选项，且不占PHP内存。但函数选错会导致静默失败或权限卡住。
错误示例：exec("mysqldump -u root db > /tmp/backup.sql")——重定向>在exec()里不生效，输出会丢失；shell_exec()能处理管道和重定向，但返回值是字符串，大文件会吃内存。
- 推荐用
exec()配合mysqldump的--result-file参数：例如exec("/usr/bin/mysqldump -u {$user} -p{$pass} --databases mydb --result-file=/var/backups/mydb_".date('Y-m-d').".sql 2>&1", $output, $return_code) -
2>&1必须加上，否则错误信息看不到，$return_code为非0时才说明失败 - 密码明文传参有风险，生产环境应改用
~/.my.cnf配置文件，并设chmod 600，然后mysqldump --defaults-extra-file=/root/.my.cnf mydb
备份文件按日期压缩并自动清理旧文件
不压缩的SQL文件体积大、传输慢、恢复也慢；不清理会导致磁盘撑爆。PHP自带zipArchive类可以压缩，但大文件容易超内存限制；用系统gzip更轻量。
典型坑：gzencode(file_get_contents($sql_file))把整个SQL读进内存，1GB文件直接OOM；system("gzip $sql_file")又可能因路径空格或特殊字符出错。
- 用
exec("gzip -f /var/backups/mydb_".date('Y-m-d').".sql 2>&1", $out, $code)，-f确保覆盖已有.gz - 清理7天前的备份：
find /var/backups -name "mydb_*.sql.gz" -mtime +7 -delete，放进同一行exec()或单独cron任务都行 - 压缩后校验：用
exec("gunzip -t /var/backups/mydb_".date('Y-m-d').".sql.gz", $out, $code)，$code === 0才算成功
crontab里PATH和SHELL环境和你终端不一样
你在bash里敲php -v能出来，但crontab里执行就报错，大概率是PATH没继承。cron默认PATH极短（通常是/usr/bin:/bin），很多命令（如mysqldump）根本不在里面。
错误做法：在脚本里putenv("PATH=...")——PHP的putenv对子进程不保证生效；正确做法是在crontab里显式声明。
- 编辑用户crontab时，第一行加：
PATH=/usr/local/bin:/usr/bin:/bin（根据which mysqldump php结果补全） - 不要用
sudo crontab -e来跑普通用户脚本，权限错乱；用crontab -e切到对应用户下编辑 - 测试时加日志：
0 2 * * * /usr/bin/php /var/www/backup.php >> /var/log/backup.log 2>&1，别省掉2>&1
真正麻烦的从来不是写几行PHP，而是确认每一步的执行上下文：谁在跑、在哪跑、用什么PATH、有没有权限访问socket和文件路径。漏掉任意一环，备份就变成“以为在跑”的假象。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
