- How do I install and set up spatie/laravel-backup in a Laravel application?
- Install it with composer require spatie/laravel-backup, then publish the config file so you get config/backup.php. Choose one or more destination disks that already exist in config/filesystems.php, and confirm the PHP zip extension plus a native dump binary such as mysqldump or pg_dump is available in your runtime image. After that, php artisan backup:run creates a zip of your selected directories and a database dump. Most teams get a working proof of concept in about half a day.
- Which PHP and Laravel versions does spatie/laravel-backup support?
- The current major targets PHP 8.4 and Laravel 12 or newer, so it effectively follows the latest framework upgrade cadence. If your application is on an older Laravel release you will be pinned to an older package major, which the maintainers state only receives bug fixes. Beyond PHP and Laravel versions, the host also needs the PHP zip extension and the matching native client binary for your database driver. Treat the version floor as a platform-planning constraint rather than a library preference.
- How do I schedule backups automatically in Laravel with spatie/laravel-backup?
- The package exposes backup:run, backup:clean, and backup:monitor artisan commands, which you register in your existing scheduler alongside your other tasks. A typical schedule runs backup:run nightly, backup:clean shortly afterwards, and backup:monitor once or twice a day. Chain withoutOverlapping and onOneServer so a long-running zip never stacks up on your queue or multiple app servers. No separate backup control plane or daemon is required.
- Can spatie/laravel-backup store backups on multiple filesystems or S3 at the same time?
- Yes. The disks array in config/backup.php accepts several destinations, and the package copies the finished zip to each of them. Because destinations are ordinary Laravel disks, you can target S3, an S3-compatible store, or a NAS and inherit your existing credential and IAM handling without bespoke code. The zip is assembled on the local filesystem first, then uploaded to each destination.
- Does spatie/laravel-backup include a restore command?
- No. The package creates and manages backups but has no restore capability, so recovery is your runbook, your tooling, and your test ownership. In practice that means downloading the zip, extracting the file archive, and importing the database dump with your normal database client. Budget restore work as explicit project scope rather than assuming the package provides it, and rehearse it before you need it in an incident.
- What does the backup monitor do and how do I get notified when a backup fails?
- The backup:monitor command inspects your destination disks for existing backups and checks their age and size against the thresholds in your config, then sends notifications through mail, Slack, or your other configured channels. The package also dispatches BackupWasSuccessful, BackupHasFailed, and BackupManifestWasCreated events, which you can wire into metrics, alert routing, or audit records without forking it. Be aware that runs limited with --only-db or --only-files are indistinguishable from full backups in the monitor, so a green dashboard can hide an unrecoverable state. Build any critical alerting on your own metadata as well.
- How much disk space and CPU does spatie/laravel-backup need on the application host?
- The zip is assembled locally before being copied to your destination disks, so the host needs free space at least equal to the total size of the files being backed up. On large upload volumes that becomes a real capacity line item and a plausible cause of degradation during the backup window. Plan both the temporary disk headroom and the CPU budget for compression, and prefer off-peak scheduling on smaller instances.
- Can I run multiple backup configurations with different schedules and retention policies?
- Yes, and it is one of the most operationally useful features. You can publish separate config files, for example backup_database.php and backup_uploads.php, and invoke backup:run with the --config option on different schedules, disks, and cleanup strategies. That lets you match different recovery point objectives for transactional data versus user uploads. Each configuration keeps its own retention rules, so cleanup stays predictable per data class.
- How should I test that backups actually work before relying on them in production?
- Run backup:run against a staging environment with production-like data volumes, then extract the zip and import the dump to prove the artifact is usable. Turn that into a periodic restore drill rather than a one-off check, because the package cannot verify restorability for you. For fast smoke tests in CI you can use --only-db, but remember the health monitor will not flag partial runs. Also confirm the dump binary and zip extension exist in your built container image, not just your local machine.
- How does spatie/laravel-backup compare to managed database point-in-time recovery and other backup alternatives?
- This package is a strong fit for a single Laravel application that needs scheduled file and database zips pushed to one or more disks with health monitoring and retention built in. It is a poor fit for polyglot estates, for services on a managed database where native point-in-time recovery or branching already exists, or for Windows hosts. Many teams run it for files and uploads while relying on managed PITR for transactional data to hit tighter recovery objectives. Custom mysqldump scripts or cloud snapshot tooling are viable alternatives, but you would rebuild monitoring, notifications, and cleanup yourself.