spatie/laravel-backup 是基于 Artisan 命令的自动化备份方案,需配置 Flysystem 驱动、调度任务及环境依赖,不提供 Web 界面;安装需补全 guzzlehttp/guzzle,MySQL 备份依赖 mysqldump,务必验证备份可恢复性。
spatie/laravel-backup 不是“一键备份”的图形化按钮,而是通过 Artisan 命令触发、可调度、带校验和清理策略的自动化备份方案。它本身不提供 Web 界面或点击式操作,所谓“一键”实际指运行 php artisan backup:run 这条命令。
该包依赖 Flysystem 抽象层,本地备份用 local 驱动最简单,生产环境建议搭配 s3 或 digitalocean 等远程驱动。注意 Laravel 10+ 默认已移除 guzzlehttp/guzzle,需手动安装(否则 backup:run 会报 Class "GuzzleHttp\Client" not found):
composer require spatie/laravel-backup composer require guzzlehttp/guzzle
发布配置后,主要修改 config/backup.php 中的 destination 和 disks:
destination.disks 指定备份文件存到哪个
Laravel Storage disk(如 ['local'] 或 ['s3'])disks 数组必须包含同名 disk,且该 disk 在 config/filesystems.php 中已正确定义(例如 local disk 的 root 路径不能是 /var/www/html 这类 Web 可访问目录)mysqldump 命令,确保系统 PATH 中可用;若用 Docker,需在 PHP 容器内安装 mariadb-client 或 mysql-client
Laravel 自带的 scheduler 是唯一推荐的定时方式,不要用系统 crontab 直接调 php artisan backup:run —— 它会绕过 Laravel 环境配置,导致日志、通知、disk 配置失效。
在 app/Console/Kernel.php 的 schedule 方法中添加:
protected function schedule(Schedule $schedule)
{
$schedule->command('backup:clean')->daily()->at('02:00');
$schedule->command('backup:run')->daily()->at('02:15');
}
关键点:
backup:clean 必须在 backup:run 之前执行,否则旧备份不会被清理cleanup.strategy.defaultStrategy 在配置中控制保留逻辑:默认按数量(keepAllBackupsForDays、keepDailyBackupsForDays 等)而非文件大小判断,磁盘空间不足时需额外监控backup:run 可能超时,需调大 PHP 的 max_execution_time 和 memory_limit(CLI 模式下独立于 Web 配置)运行 php artisan backup:run --verbose 是第一排查手段。高频失败点:
Could not find a database driver:检查 config/database.php 中当前 DB_CONNECTION 是否在 backup.source.databases 列表里(例如你用 pgsql,但配置里只写了 ['mysql'])mysqldump: command not found:不是 Laravel 问题,是 PHP 进程执行环境缺少该二进制;Docker 用户应在 PHP 镜像中 apt-get install -y default-mysql-client
ZipArchive::close(): Failure to create temporary file:sys_temp_dir 配置不可写,或磁盘无剩余空间;可通过 php -r "echo sys_get_temp_dir();" 查看路径mysqldump 执行失败但被静默忽略,加 --verbose 后会输出原始 mysqldump 错误(如权限拒绝、socket 路径错)真正容易被忽略的是备份文件的可恢复性——包不验证备份能否还原。上线前务必用 gunzip -t 检查压缩完整性,并手动导入一次 SQL 文件验证结构和数据。