"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 belly up and your company (or the company you're working for) is probably losing an outrageous amount of money for every second of downtime. It 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 even worse, you got a ransomware that is now asking you to pay some Bitcoins to get your data back (spoiler: you will not get it back).
So, if you worked in IT for more than a day, 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 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 even "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 safely 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 may have to manage this yourself.
In this article, we will use Amazon S3 as a safe heaven for one of our most precious assets.