spatie/laravel-backup是最省心的laravel数据库备份方案，支持多数据库、自动压缩、保留策略与失败通知，避免手动mysqldump的权限、路径、字符集及性能问题。
用 spatie/laravel-backup 是最省心的选择
Laravel 官方不提供数据库自动备份功能，硬写调度 + mysqldump 命令容易出错、难维护。直接装 spatie/laravel-backup，它专为 Laravel 设计，支持 MySQL/PostgreSQL/SQLite，自动压缩、保留策略、失败通知一应俱全。
常见错误现象：自己写 Artisan 命令调 exec('mysqldump ...')，结果线上环境权限不足、路径不存在、字符集乱码、大库卡死进程。
- 安装后执行
php artisan vendor:publish --provider="Spatie\Backup\BackupServiceProvider"生成配置 - 关键配置在
config/backup.php中：'name'必须是合法文件名（别含空格或斜杠），'monitor_backups'开启后可用php artisan backup:list查状态 - MySQL 备份默认用
--single-transaction，对 InnoDB 安全；但 MyISAM 表会锁表，得手动改'dump_options'
php artisan backup:run 手动触发时的坑
命令能跑通不代表生产可用——它默认不输出详细错误，失败时只报 Backup failed，根本看不出哪一步崩了。
使用场景：CI/CD 部署后快照、上线前手动保底、调试备份流程。
- 加
--verbose参数看完整日志：php artisan backup:run --verbose - 如果卡在
Copying zip to disk...，大概率是磁盘满或disks.backup对应的 storage 驱动（如 S3）凭证失效 - 本地测试务必关掉
'send_notifications_when_backup_fails'，否则每试一次都发 Slack/邮件
定时备份必须配 crontab，不能只靠 scheduler
Laravel 的 schedule 是基于 PHP 进程的，依赖 php artisan schedule:run 每分钟拉一次——一旦队列卡住、服务器重启漏跑、或部署时没重载 crontab，备份就停摆。
性能影响：备份过程本身 IO 密集，和 Web 请求争磁盘带宽，必须脱离请求生命周期。
- Linux 下直接编辑系统 crontab：
sudo crontab -e - 写死绝对路径（避免 PATH 环境变量问题）：
0 2 * * * /usr/bin/php /var/www/myapp/artisan backup:run --no-interaction >> /var/log/backup.log 2>&1 - 别用
php别名，查真实路径用which php；--no-interaction防止交互式提示卡住
备份文件权限和清理策略要人工盯
默认备份存到 storage/app/backup，但 Laravel 的 storage 目录常设为 755，而备份文件是 644——Web 服务器可能被配置为禁止下载 .zip，导致恢复时连文件都拿不到。
兼容性影响：有些托管环境（如某些 cPanel）会定期清空 storage/app 下非标准扩展名文件，.zip 可能被误删。
- 改存储位置：在
config/backup.php的'disks' => ['backup']里指定独立磁盘（比如local-backup），并确保其根目录不在storage/内 - 清理靠
'keep_all_backups_for_days'和'keep_daily_backups_for_days'，但它们只管“过期”，不管“磁盘爆满”——建议额外加脚本监控df -h并告警 - 恢复时别信界面按钮，优先用
php artisan backup:restore --id=xxx，它会校验 ZIP 完整性再解压
真正麻烦的不是备份动作本身，而是验证恢复路径是否通、权限是否够、时间戳是否被时区搞乱——每次新环境上线，必须跑一次完整 restore 流程，而不是只看 backup:run 成功就完事。
