spatie/laravel-backup 命令未找到需检查服务提供者注册与配置发布；未压缩备份易致磁盘爆满，应启用 gzip 压缩；定时任务需用绝对路径并确保 php 环境一致；恢复失败多因字符集不匹配，须在 database_dumpers 中显式指定 utf8mb4。
备份命令执行失败：找不到 spatie/laravel-backup 命令
装完包却运行 php artisan backup:run 报错“command not found”，大概率是服务提供者没注册或配置没发布。
- 确认已执行
composer require spatie/laravel-backup，且 Laravel 版本 ≥ 9.x（低版本需用 v7） - 检查
config/app.php中是否漏掉了Spatie\Backup\BackupServiceProvider::class（Laravel 10+ 可能自动发现，但建议显式确认） - 必须运行
php artisan vendor:publish --provider="Spatie\Backup\BackupServiceProvider"，否则config/backup.php不会出现，命令也无法加载 - 如果用了 Laravel Sail 或 Docker，确保在容器内执行命令，宿主机上跑会找不到 artisan
备份文件存到本地但没压缩，磁盘空间悄悄爆掉
默认配置下，spatie/laravel-backup 生成的是未压缩的 SQL 文件，尤其对大表（比如日志表、订单表）非常危险。
- 打开
config/backup.php，找到'database_dump_compressor' => null，改成'database_dump_compressor' => Spatie\DbDumper\Compressors\GzipCompressor::class - 同时确认系统已安装
gzip（Linux/macOS 默认有；Windows WSL 需检查，原生 Windows 需额外配7z并换对应 compressor 类） - 别忽略
'temporary_directory' => storage_path('app/backup-temp')—— 这个临时目录如果空间不足，dump 过程会静默失败，只留空文件
定时任务在服务器上不触发：cron 没跑对 Laravel 环境
php artisan schedule:run 在本地 OK，但服务器上 cron 定时备份没反应，常见原因是路径、PHP 版本或用户权限不对。
- 用绝对路径写 cron：例如
* * * * * cd /var/www/myapp && /usr/bin/php artisan schedule:run >> /dev/null 2>&1，不能依赖~或相对路径 - 确认 cron 使用的 PHP 和 artisan 用的一致：
/usr/bin/php -vvswhich php，混合使用可能因扩展缺失导致备份中断（比如没开pdo_mysql） - 检查
APP_ENV=production是否生效 —— 开发环境默认跳过备份，config/backup.php里有'only_on_envs' => ['production']这种守门逻辑
备份成功但恢复不了：mysqldump 字符集不兼容
从备份 SQL 文件恢复时出现乱码或报错 Unknown character set: 'utf8mb4_0900_ai_ci'，本质是 dump 时没锁定字符集。
- 在
config/backup.php的'database_dumpers'配置里，为 MySQL 加上显式字符集参数：'mysql' => [ 'dump_binary_path' => '/usr/bin', // 根据实际调整 'use_single_transaction' => true, 'timeout' => 60, 'extra_options' => '--default-character-set=utf8mb4', ] - 避免用
utf8（MySQL 已弃用），统一用utf8mb4；如果数据库是 MySQL 8.0+，且排序规则含_0900_，备份时加--skip-set-charset反而更安全 - 恢复前先查目标库的
character_set_database和collation_database，确保和源库一致，否则光改 dump 文件头没用
备份真正难的不是“怎么跑起来”，而是“怎么验证它真能恢复”。每次新部署、升级 MySQL 或调整表结构后，务必手动抽一个备份文件试还原——别等出事那天才发现 mysqldump 版本不匹配或者 event_scheduler 被关了。
