spatie/laravel-backup: Scheduled Zip Backups for Laravel Apps and Their Databases

What spatie/laravel-backup actually produces

The output is a single zip file. According to the README, that zip contains all files in the directories you specify plus a dump of your database. That sentence is the whole product in one line: it is not a block-level snapshot, not a WAL stream, not an incremental chain. It is a zip, which means it is portable, inspectable with unzip -l, and cheap to move between machines.

The intended user is a Laravel team that already has filesystems configured in config/filesystems.php and wants a scheduled job to write an archive somewhere else. Because the destination is a Laravel filesystem, the same configuration can point at local disk, S3, or any other driver the framework supports. The README also states that you can back up to multiple filesystems at once, which is the answer to the single-copy problem without adding a second tool.

The package ships a monitor and a cleanup command alongside the backup command, so the scope is the full lifecycle of an archive: create it, notice when it stops being created, and delete old ones before they fill the disk. What it does not ship, at least not in the README, is a restore command.

How the backup command assembles the archive

The flow starts at an artisan command. You invoke php artisan backup:run, and the package reads its configuration to decide which directories to include, which database connection to dump, and which filesystems to write to. The README gives the command as the primary interface and links to a documentation page titled taking backups for the detail.

Two design consequences follow from that shape. First, the archive is built on the machine running the application, so the process needs enough local disk to stage the zip before it is uploaded to a remote filesystem. A large storage directory on a small instance will fail here. Second, because the database is dumped rather than copied as raw files, the dump is only as consistent as the dump tool for that driver allows; the README does not claim transactional consistency, and you should not assume it.

The repository layout shows a config/ directory and a docs/ directory at the top level, so the tunable surface is a published config file rather than environment variables scattered through the code. The backup monitor is a separate concern from the backup itself: it checks the health of backups, and the README states you can be notified via several channels when a problem is found. That separation matters, because a backup job that throws an exception and a backup job that succeeds but writes nothing look identical from the outside until something checks.

Installing spatie/laravel-backup and running the first backup

The README states the package requires PHP 8.4 and Laravel 12.0 or higher, and that installation instructions live at https://spatie.be/docs/laravel-backup. It does not print the composer command in the README itself, so treat the documentation site as the source of truth for the exact install step and for publishing the config file.

Once installed, the first real use is the artisan command the README shows:

php artisan backup:run

Run it on a staging database first. You should see the command report progress and finish with an archive written to the filesystem or filesystems named in your config. If nothing appears, the usual cause is that the destination disk was never configured in config/filesystems.php.

For a recurring job, the package is designed to be scheduled rather than run by hand. The monitoring side is what tells you the schedule is still working, and the README links to a page on monitoring the health of all backups. The cleanup side is a separate command documented under cleaning up old backups, which is what keeps the destination from growing without bound.

If you are on an older runtime, the README is explicit: on PHP below 8.4 or Laravel below 12.0, use an older version of the package, and it links version 3 through version 6 documentation. It also states that no new features will be introduced to v6 and below, with bug fixes continuing as necessary.

Where the package stops: no restore command in the README

Search demand around this package leans heavily toward restore. People type laravel backup restore, laravel backup restore database, and laravel backup database to google drive far more than they type the install command. The README does not describe a restore command. It documents creating a backup, monitoring backups, and cleaning up old backups. That is the boundary, and it is worth stating plainly rather than assuming a restore path exists because a backup path does.

In practice the archive is a zip containing your files and a database dump, so recovery is a manual exercise: fetch the zip from the filesystem, unpack it, and load the dump into your database with the appropriate client. Nothing in the README automates that, and nothing in the README describes verifying that a dump restores cleanly. A backup you have never restored is a hypothesis.

The second limitation is scope. This is a Laravel package. It assumes a Laravel application with configured filesystems and an artisan console. If your data lives in a service that Laravel does not own, or your infrastructure team already runs a host-level snapshot system, adding an application-level zip duplicates work and creates two recovery stories that can disagree about which one is authoritative.

The third is runtime coupling. Requiring PHP 8.4 and Laravel 12.0 or higher means the package version you can install is pinned to your framework version. Teams that defer framework upgrades will be running an older release line, and the README says that line receives bug fixes but no new features.

How it compares with Laravel Backup Panel and laravel-health

Two adjacent tools come up in the same searches. The first is a panel-style backup manager that wraps this kind of backup in a UI with a restore button. The difference is architectural: spatie/laravel-backup is a console-first package whose interface is artisan plus notifications, while a panel puts the same archive behind a web interface and adds restore as a first-class action. If your operators are comfortable on the command line and your recovery procedure is documented, the console-first shape is fewer moving parts. If recovery is performed by people who will not open a terminal, the panel is doing real work that this package does not attempt.

The second is spatie/laravel-health, which is a general health-check package rather than a backup tool. The overlap is the monitoring idea. laravel-backup includes its own backup monitor with notification channels, so you get freshness checking without a second dependency. Choosing laravel-health instead means you assemble your own check for archive age and wire it to your own notification path. That is more flexible and more code.

Neither comparison changes the core trade-off. This package optimizes for a scheduled, portable archive written to storage you already have configured. Anything beyond that, whether it is a restore UI or a broader health dashboard, is a different product with a different maintenance burden.

Maintenance, versioning and the MIT licence

The repository is not archived, and the last push was on 2026-09-14. Release 10.3.3 landed the same day, following 10.3.2 on 2026-08-20 and 10.3.1 on 2026-07-28. That cadence suggests patch releases arrive on a roughly monthly rhythm, which is a reasonable signal for a package you would put on a schedule.

The upgrade cost is the runtime floor. Because the current line requires PHP 8.4 and Laravel 12.0 or higher, a major Laravel upgrade can force a major package upgrade in the same window. The repository carries an UPGRADING.md at the top level, so the maintainers document breaking changes rather than leaving you to read the changelog. Read that file before bumping the constraint in composer.json.

The licence is MIT, stated in the README and in the LICENSE.md file at the repository root. MIT is permissive: you can use the package in commercial and closed-source applications without publishing your own code. That is the extent of what can be said here; questions about your specific distribution or compliance obligations belong with your legal counsel, not with a package review. The README also mentions postcardware, which is a request rather than a licence term and carries no legal weight.

Editorial conclusion

Adopt spatie/laravel-backup if you run Laravel 12 on PHP 8.4 or newer, want a scheduled zip of selected directories plus a database dump, and are willing to store the archive on a filesystem outside the machine being backed up. Do not adopt it as your only recovery plan if you need one tool that both writes and restores backups: the README documents backup:run, the monitor and the cleanup command, but no restore command, and the restore route it points to is a separate package. Before trusting it, verify three things in your own setup: that the destination disk is a filesystem configured in config/filesystems.php and not a local path on the same host, that your database driver is one the dump path supports, and that the backup monitor is scheduled so a silently failing job surfaces as a notification rather than as a missing archive.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. spatie/laravel-backup on GitHub