Despite everybody knowing that you should have backups the internet is full of crazy stories of invalid, corrupt, outdated or even just missing backups and people needing help restoring their data. Why is that? In my opinion backups are in a kind of way just like unit tests. They are not needed to run your application. Implementing them costs time and resources. And just like unit tests the management maybe will never actually see them.

But just like unit tests are very handy to have for refactoring purposes, backups are indispensable if something bad happens to your production data.

In my talk „Backups in the Time of Microservices“ at the upcoming International PHP Conference in Munich I will talk about some ideas on how to make backups less painful. One of the main concepts I will talk about is to treat your backup scripts in a “configuration as code” kind of way.

One of the tools I will focus on is a PHP tool called phpbu that enables you to simply configure your backups, so you are able to store the configuration within your projects’ source code management repository.
So how could this look like?

Have a look at this small XML configuration example of a MySQL database backup:

<?xml version="1.0" encoding="UTF-8"?>
<phpbu> 
<backups> 
<backup> 
<source type="mysqldump">
<option name="databases" value="mydbname"/>
</source> 
<target dirname="backup/mysql"
filename="mysqldump-%Y%m%d-%H%i.sql"
</backup> 
compress="bzip2"/>
</backups> 

I am not going into the details here, I hope it is readable enough so you can understand the concept behind these kind of configuration files.

There are two big benefits available with this kind of approach.

The first is that these configuration files serve as documentation. If you do not have any other kind of process documentation (although you definitely should!), you can easily find out what kind of data is stored and where it is stored with the help of this technique. So even if you do not care about your backups most of the time, you have a starting point that you can take a look at.

Secondly, this approach serves as some kind of contract between the developers and the devops or operations folks. It shifts the mindset of your developers kindly towards backups so they consciously think about the data they collect. May it be records in a database, files in a directory or some other kind of data. Because who if not the developers know which data is needed to revive your application?

Doing backups does not just encompass simply copying some data.

It is a process involving different steps, like verifying your backup for example. This goes from simple file size checking to automated recovery procedures. As long as you have not successfully restored a backup you cannot be sure that your backup is working. So running regular restore tests are a means of helping you to be prepared in case of a critical incident.

Another important part of the process is encryption – especially if you are working with personal data of your customers, or maybe even payment data. By the way, payment data should only be stored encrypted anyway. But your backups should be encrypted, too. Especially if you store your backups on a cloud service live AWS or Dropbox.

To be on top of your backup monitoring is another very important part of the process. Setting up a backup process is not worth a thing if you do not make sure the process works as intended. So being able to see daily backup reports or receiving notifications if something is not working properly is essential for your backup process.

During the talk I will cover a lot more of this subject in detail, so I hope I will see you there.