17370845950

最可靠的小程序后端数据库备份方式是用系统级mysqldump工具配合PHP调用，而非mysqli逐行读写；需加--single-transaction、绝对路径调用、三参数exec捕获状态码、cron定时执行独立脚本、压缩+校验+自动清理。

用 mysqldump 命令直接导出数据库最可靠

小程序后端数据通常存在 MySQL 中，PHP 本身不负责“备份”，真正起作用的是系统级的 mysqldump 工具。PHP 只是调用它、拼参数、控制执行时机。别试图用 PHP 的 mysqli 一行行读写做备份——慢、易中断、不一致、没事务快照保障。

实操建议：

• 确保服务器已安装 mysqldump，且 PHP 进程有权限执行（常见于 CLI 模式，Web 进程常被禁用 exec）
• 用绝对路径调用，比如 /usr/bin/mysqldump，避免环境变量差异
• 必须加 --single-transaction（InnoDB）或 --lock-all-tables（MyISAM），否则备份中途写入会导致数据不一致
• 加上 --routines --triggers --events 如果业务用了存储过程或事件调度

PHP 脚本里调用 exec 要防超时和错误吞没

很多人写完 exec("mysqldump ...") 就以为完事了，结果备份失败却没日志、没告警、磁盘悄悄占满。

关键点：

• 用 exec($cmd, $output, $return_code) 三参数形式，$return_code 非 0 就代表失败（mysqldump 成功返回 0）
• 设置 set_time_limit(0)，大库导出可能耗时几分钟
• 把 $output 写进日志，尤其关注是否含 Warning: 或 ERROR 字样
• 别用 shell_exec 或 system——前者不返状态码，后者会直接输出到响应体（Web 环境下崩溃）

定时任务必须脱离 Web 请求，走系统 cron

用微信小程序后台“定时触发器”或 PHP 的 sleep() 循环来“定时备份”，等于没备。前者不可控、无日志、不保证执行；后者在请求中断后就停了。

正确做法：

• 写一个独立 PHP 脚本，比如 /var/www/backup/backup_db.php，只做备份一件事



• 用系统 cron 定期调用：例如每天凌晨 2 点执行 0 2 * * * /usr/bin/php /var/www/backup/backup_db.php >> /var/log/backup.log 2>&1
• 脚本开头加 #!/usr/bin/env php 并 chmod +x，可直接当命令运行（方便调试）
• 备份文件名务必带时间戳，如 db_backup_20250520.sql.gz，避免覆盖

压缩与清理不手动做，就等于白备份

原始 SQL 文件体积可能是数据库的 2–3 倍，放着不管几天就撑爆磁盘。更糟的是，没人检查过压缩包是否损坏——直到真要恢复时才发现解不开。

建议链式处理：

• 导出后立刻用 gzip 压缩：mysqldump ... | gzip > backup_$(date +\%Y\%m\%d).sql.gz
• 用 gzip -t 验证压缩完整性，失败则发邮件或写告警日志
• 保留最近 7 天备份，用 find /path/to/backups -name "*.sql.gz" -mtime +7 -delete
• 不要把备份存到 Web 可访问目录（如 /public/backup/），防止被下载

真正麻烦的不是“怎么备份”，而是“怎么确认每次备份都有效”。验证恢复流程、监控备份大小突变、检查磁盘余量——这些比写第一行 exec 更重要。