How to Back Up a Laravel Application with Spatie Laravel Backup

A Laravel service needs its database and runtime files, including user uploads. A backup gives you copies to restore after data loss or server failure. Spatie Laravel Backup packages combine selected files and a database dump, a file containing database data, into a ZIP archive. The package stores the archive on one or more storage disks configured in Laravel. A storage disk is a named destination, such as local storage or a cloud service.

Install the package, choose which files and database to include and where to store them, then schedule and monitor the backup command. Test how you will restore the database and files, too. Creating an archive alone does not prove you can recover the service.

Install the package and check its requirements

Check the package requirements before installing. The current Spatie Laravel Backup repository lists PHP 8.4 and Laravel 12 or higher. Older package releases support older Laravel and PHP versions, so use a release that matches your project rather than assuming the latest release will install.

Install the package through Composer:

composer require spatie/laravel-backup

Publish its configuration file:

php artisan vendor:publish --provider="Spatie\Backup\BackupServiceProvider"

This creates config/backup.php, where you can review which directories to back up, which disks to store archives on, when to remove old backups, and where to send notifications. The package also needs a database dump utility, a tool that exports database data to a file. Use the utility for your database engine, such as mysqldump for MySQL or pg_dump for PostgreSQL. Confirm that it is installed and available to the user running Laravel's Artisan command-line tool. The package introduction describes the archive contents and storage options.

Choose the files and destination

Review config/backup.php before backing up a production service. Its directory settings determine which files go into the archive. Add directories that hold important data, such as user uploads, if they are not already included. Exclude files that you do not need to recover, based on how you deploy and how long you need to keep data.

Set the destination to a disk defined in Laravel’s config/filesystems.php. The package can write to multiple configured disks, which lets you keep a local copy and send another to separate storage. The package’s storage documentation describes this disk-based approach. Do not rely only on a disk on the live service's server. A server failure could destroy both the service and its backups.

Check that the destination has enough capacity for the archive and that the backup process can write to it. If you send large archives to remote storage, test the transfer with a representative backup. A reported S3 upload issue describes a socket timeout during a large upload; that report does not establish a general size limit, but it shows why remote transfers should be verified in your environment.

Run and inspect a backup

Run the backup command from the Laravel project directory:

php artisan backup:run

The command creates an archive from the configured files and database, then stores it on the configured destination disk or disks. Use php artisan backup:list to inspect available backups. The package also provides backup:clean to remove older archives according to the cleanup settings in config/backup.php. Choose those settings carefully so saved backups do not fill all available storage.

For a one-off run, the package supports options such as --only-db, --only-files, and --only-to-disk=name-of-your-disk. These options back up only part of the data or send it to a specific disk. Use them for specific tasks, not instead of a full backup. The package monitor treats a database-only or files-only backup like a complete backup, so a partial archive can appear healthy even though it lacks data needed for recovery.

Schedule backups and receive alerts

Laravel's scheduler runs commands at set times. In Laravel 12, define scheduled tasks in routes/console.php:

use Illuminate\Support\Facades\Schedule;

Schedule::command('backup:clean')->daily()->at('01:00');
Schedule::command('backup:run')->daily()->at('01:30');

Set backup times to fit the service’s workload and backup window. Avoid scheduling between 2:00 and 3:00 a.m. in regions that change clocks for daylight saving time; the clock change can cause a scheduled run to happen twice or not at all.

On a Unix-like server, configure the cron service to run Laravel’s scheduler every minute:

* * * * * php /path/to/artisan schedule:run >> /dev/null 2>&1

Replace /path/to/artisan with the full path to the project’s Artisan file. Laravel’s scheduler and cron documentation explains how they work together: cron starts Laravel’s scheduler, which checks which commands are due.

Set up backup notifications in config/backup.php so the people responsible for recovery learn about failures. Spatie Laravel Backup supports Laravel notification channels such as mail and Slack. Its monitoring command checks backup health and can send alerts. After configuring the monitor, run php artisan backup:monitor and confirm that alerts reach the right destination. A scheduled command can succeed at first and fail later, or backups can go missing. Alerts help you spot these problems.

Test recovery before relying on the archive

A backup is useful only if you can restore it. Before an incident, test with a copy of the archive and a database that is not in production. Check that the archive contains the expected database dump and files, then verify that your restore procedure can recover both.

Spatie Laravel Backup creates the archive; a database restore requires a separate restore procedure or tool. For example, the community package laravel-backup-restore restores database backups created by Spatie Laravel Backup; application files need their own restoration plan. Its --reset option drops existing database tables before importing the backup, so use that option only when you intend to replace the target database and have confirmed the target is safe to reset.

Make sure the person who will restore the service can find the instructions, get the required credentials, and access remote storage. Check that the archive opens and that its database and files include what the service needs. A test restore can reveal missing files, access problems, and other gaps while the live service is still available.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com