Check your backups
Tags: devops, webdev
Published: 2019-06-07 12:07:57

Backups are often an afterthought until everything goes pear-shaped. If there's one thing you take away from this post then make it be this: Do not have the mindset of "set and forget" when it comes to backing up your computer or your websites!

Having a website update go wrong beyond repair or a database becoming corrupt is stressful enough. Imagine this happening and discovering that your fallback plan was a lie.

There are many reasons backups might not work and it can often depend on your set up. Perhaps your server is full and has no space to create local backups. Or maybe, if you never checked the backups initially, you configured them wrong and they were never being generated in the first place.

## General rules

### Don’t have your local server backups as your only source

It might be convenient to backup to the same server but if that server dies, gets hacked, or is disabled by your provider, you’re going to have a bad time.

If your backups are on a different server with the same provider, and that provider goes down / disables your account, you will have a bad time then, too! Always use another source. Amazon s3, Google Cloud Storage, or Backblaze b2 are great places to sync your backups to.

### Multiple backup methods can be a site-saver

Don’t rely on just one method of backing up. Most cloud hosting providers automated server backups for a fee. You could use this as your only backup, but they’re often limited to a weekly schedule, and also means that your backups are on the same provider as your server, which as mentioned above, is also a risk.

That said, these can be really handy to spin up a server to recover data, or even to revert to on your live server.

### Consider how up to date you need data to be

Do you need daily or even twice daily backups? Can you cope with missing a days worth of data? For some websites this is fine. 

I have a blog which gets updated perhaps once a month and the comments are hosted elsewhere. A daily backup for this is unnecessary.

Also consider how long you need to _keep_ backups. The more you back up, the more you will pay. 

To complicate this a bit, you might think it’s okay to keep 2 weeks of backups and delete the rest, but there are times when having older data can be useful. For example, perhaps some bad data has been added to a database and you want to figure out when this happened. Was it in the last month? The last six months? Having long-term backups is very handy in this situation.

### Have a schedule in place for testing backups

Consider how frequently you need to test your backups and have a schedule in place for doing so. 

Some websites might need to be tested once a year, others once a month. Set up a demo server with the latest backup and check the integrity of the data.

This has the added benefit of preparing you for when things really go wrong. You’ll know just what to do to get your live website back up as fast as possible.

## Useful resources

Now that I've drilled how important backing up is, here are some useful resources for making them. Some of these are scripts you can set up yourself and others are services you can use. I'm not affiliated with any of them.

* [Backup and encrypt Postgres to AWS](http://scotttactical.com/post/encrypt-postgresql-backup-to-s3/)
* [Backing up SQLite](https://www.ibiblio.org/elemental/howto/sqlite-backup.html)
* [Open Source cloud backup syncing software](https://www.duplicati.com/)
* [cPanel to AWS backup guide](https://storageswiss.com/2017/04/13/how-to-backup-a-cpanel-website-to-amazon-s3/)
* [MySQL/PostgreSQL backup service (Paid only)](https://ottomatik.io/)