Oh Dear is the all-in-one monitoring tool for your entire website. We monitor uptime, SSL certificates, broken links, scheduled tasks and more. You'll get a notifications for us when something's wrong. All that paired with a developer friendly API and kick-ass documentation. O, and you'll also be able to create a public status page under a minute. Start monitoring using our free trial now.

Taking care of backups with Laravel

Original – by Freek Van der Herten – 8 minute read

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.

Solutions

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 put 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 too 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.

Drawbacks

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.

Stay up to date with all things Laravel, PHP, and JavaScript.

You can follow me on these platforms:

On all these platforms, regularly share programming tips, and what I myself have learned in ongoing projects.

Every month I send out a newsletter containing lots of interesting stuff for the modern PHP developer.

Expect quick tips & tricks, interesting tutorials, opinions and packages. Because I work with Laravel every day there is an emphasis on that framework.

Rest assured that I will only use your email address to send you the newsletter and will not use it for any other purposes.

Comments

What are your thoughts on "Taking care of backups with Laravel"?

Comments powered by Laravel Comments
Want to join the conversation? Log in or create an account to post a comment.