"I'd love to restore a Database Backup" said no one ever. When you're forced to do so, that means that the production system you're maintaining is going legs up and your company (or the company you're working for) is probably losing an outrageous amount of money for every second of downtime. If can happen for a variety of reasons:
- Someone running a DELETE query with a WHERE clause larger than intended, or worse with no WHERE clause at all.
- TRUNCATE and DROP queries being executed on the wrong tables or columns.
- A faulty Hard Disk that suddenly stops working.
- A hacker decided to ruin your company and deleted everything or worse, you got a ransomware that is now asking you some Bitcoins to get your data back.
It should be clear that storing your Database Backups appropriately is of extreme importance. We live in the hope that we won't need them, but when the urgency calls, you'll be glad of having gone the extra mile to protect your data and to have that database backup ready to be restored.
In this situations you, the DevOps engineer, or SysAdmin, or Cloud expert or simply "the only developer in the company", can either be the hero that saved the day or the one who didn't care about taking backups.
If you are using Amazon RDS you are pretty much sorted out as RDS will create and store backups for you every night automatically.
But if you are not in the Cloud, or running a Database server on an EC2 instance to retain more control, or on a third-party VPS to save some cents, you will have to manage this yourself.
In this article, we will use Amazon S3 as a safe heaven for one of our most precious assets.