Every two weeks I send out a newsletter containing lots of interesting stuff for the modern PHP developer. You can expect quick tips, links to interesting tutorials, opinions and packages. Want to learn the cool stuff? Then sign up now!

Taking care of backups with Laravel

A new major version of laravel-backup was recently tagged. This package can backup files and databases of your Laravel app (or any PHP application really). The backup consists of a zipfile containing a dump of the databases and all files that are selected for backup. The package will copy over the zipfile to external storage such as S3, Dropbox, SFTP, … If something goes wrong during the package can notify you via, amongst others, mail or Slack. In this post I’d like to give some background on why and how it was built.

Keep in mind that there is no one size fits all solution for backups. A small company will probably handle backups in another way than a bigger company. This post has small companies in mind with a couple of developers and no dedicated operations person or team.

Using modern hosting

Up until a few years ago the company where I work made small sites and applications. We used shared hosting for all our projects. When our client or we ourselves accidentally deleted files or some values in db, we asked our hosting provider make the necessary restores. We didn’t do anything regarding backups ourselves.

But as time went by we started to make bigger applications. Shared hosting wasn’t cutting it for us anymore. We experimented with some of the newer cloud hosting providers and we liked the freedom that goes with using such solutions. Resources like serversforhackers.com and tools like Forge make it real easy to setup and administer your own servers. We settled on DigitalOcean. When I look around me I see many developers that are make the switch to DO, Linode, Rackspace, Amazon, etc… too.

The problem with modern hosting

But using such a provider can also bring a lot of sadness. At one fine morning I got a mail from DigitalOcean saying that they had lost our entire server. This kind of thing doesn’t happen at DigitalOcean alone. Here’s another horror story about a crashed server at Rackspace. If you google around a bit, you’ll find similar stories for all major cloud hosting providers.

Some of those providers provide a backup service. You might think that enabling such a backup service will save you from the problems described above. But unfortunately that’s not the case. In the beginning of this year Taylor Otwell, the creator of Laravel, found that out the hard way.

The hosting provider he was hosting his sites on was experiencing a denial of service attack. The whole datacenter was down for several days.

Taylor had enabled the backups, but soon learned that if the entire datacenter is down, those backups can’t be restored, because they can only be used in the datacenter where they were taken. Since that datacenter was down, the backups could not be restored.

If you’re on DigitalOcean you should be aware that their backup service only backs up your server once a week. So if your server crashes on a Friday, and your last backup was performed on a Monday, you’ve just lost data for an entire week. Your clients won’t be happy.


I should stress that I’m not trying to bash on DigitalOcean or any other specific provider. The point I want to make is that, in most cases, it’s not enough to rely on the backups of your hosting provider alone. You shouldn’t but your eggs in one basket. In addition to the backups performed by the hosting provider it’s a good idea to take care of backups yourself as well.

There are many options available, both free and paid. You could take matters in your own hands by running your own custom backup script. Here’s a great one by Chris Fidao. This script will dump the database and will, together with the files that need to be backed up, be copied over to S3. The only downside that it will not notify you when something goes wrong with the backup. If you need notifications you will need to code that up yourself.

Another option you have is to subscribe to Ottomatik.io, a paid service. I haven’t used this myself but a lot of people seem to be happy with it. Take a look at their site to learn more about it.

There are also free, open source, alternatives, such as BackupPC, Bacula and many others. They all work pretty good and have some great features, but the downside is that you need some system administration knowledge to set them up.

Introducing laravel-backup

My goal in creating laravel-backup was making a powerful backup solution that could be easily used by any developer that has some experience with Laravel. It can be installed into any Laravel app. These are the main functions it provides:

Backing up files and databases

Once installed the package can dump the databases used by the application and, together with the files selected in the config file, create a zipfile. The package will copy over the zipfile to one or more backup destinations. These backup destinations can be local, S3, Dropbox, … Under the hood Laravel’s cloud filesystem is used.

When the package is installed, artisan will have gained some backup commands. A backup can be performed by running this command:

php artisan backup:run

Of course, this command can be scheduled in the console kernel of your application.

Cleaning up old backups

When using the package for a couple of weeks or months you will have hopefully taken many backups . Probably some of the older backups are not as important as the newer backups. When using S3 to store your backups you’re going to pay for every byte you use. So it’s probably a good idea to get rid of any excess backup that you don’t need.

Out of the box the package contains a sane strategy of cleaning up the backups that you don’t need anymore. When running php artisan backup:clean the package will use the grandfather-father-son rotation scheme to remove backups. In short this means that all backups for a certain period are kept. After that, only one backup a day will be kept. After that only one backup a week will be kept. After that, only one a month. And, not surprisingly, after that only one backup a year will be kept.

Sending out notifications

The package can send out notifications when there was a problem taking a backup. Out of the box it can notify you via mail or Slack. The notifications are powered by Laravel 5.3’s native notification capabilities. This means that, if you want to be notified using a another channel, you can easily use one of the community created notification drivers or create a notification driver yourself.

Monitoring the backups

Once you’ve setup and scheduled the backups you’re probably never going to take another look at them again. You’re going to assume that backup process will run frequently. But what if something unexpected goes silently wrong?

The package comes with monitoring capabilities built in. Running php artisan backup:monitor will check if a backup was made in the last day and that the total storage used for the backups is not to high. Both criteria can be configured in the config file.

You can monitor the backups from inside your app but I recommend setting up a separate server from which you do the monitoring. This will ensure that the monitoring will still work even if your app is completely down.

Stuck on PHP 5 or and older version of Laravel?

The new version of laravel-backup, v4, requires PHP 7 and Laravel 5.3 or higher. If you’re stuck on PHP 5 or on Laravel 5.1 or 5.2 you can use v3 of the package. That version can do everything described above. Instead of relying on Laravel 5.3’s notifications v3 of the package uses a custom notification system that has support for mail, Slack, Pushover and Telegram.

There’s also extensive documentation on v3 available. Though we won’t introduce new features to v3 anymore we will still fix bugs.


I recommend using this package only in small- to medium-sized apps. There should be enough free space on your local disk in order for the zip to be created.

You should also be aware that, by using this package, your application holds the credentials to access your backups. In the case that your app is hacked, the hacker will gain access to your backups as well.

In closing

If you’re interested in using this package, head over to our documentation site to learn in detail how to set it up and use it. If you like it be sure to take a look at the list of Laravel packages we’ve previously made.

Freek Van der Herten is a partner and developer at Spatie, an Antwerp based company that specializes in creating web apps with Laravel. After hours he writes about modern PHP and Laravel on this blog. When not coding he’s probably rehearsing with his kraut rock band.
  • This is a great package!

  • Mark

    It’s an interesting project and thanks for your efforts but I’m not sure this is something that should be done at application level but rather system level with dedicated back-up tools.

  • Pingback: Дайджест PHP #5 | Straven-Loft. Лофт заметок, мыслей, идей()

  • Very cool package! I am having a bit of trouble getting the ‘clean’ function working properly though. Could you show me an example ‘defaultStrategy’ that would keep daily backups for 90 days and nothing else? Thank you!

    • set the value of `keepDailyBackupsForDays` in the config file to 90, and all other config values that start with `keep` to 0

  • andreliem

    Thank you for this, and the article discussing the pitfalls of reyling on DO. I have relied on DO’s backup system and had this feeling I shouldn’t rely on it entirely and this just confirms my suspicion. Looking forward to getting your package up in use for my applications.