One of the things I love the most about Platform as a Service when it comes to data is the fact that you get RDS backups, built in.
Go to the forums. Evidently, backups are one, or more, of the following:
a) insanely difficult, so no one does them
b) not considered important so no one does them
c) not necessary in modern systems because of X technology so no one does them
Then, someone deletes a row the business wants back. Someone drops a table. Someone drops a database. Then you find that one, or more, of the following is true:
a) no one has ever tried to restore from X technology and you can’t
b) come to find out, X technology doesn’t really do backups
c) backups are still fundamental to protecting data
Enter, backups, there for you, waiting.
RDS Backups
Let’s start by looking right at one of my RDS PostgreSQL databases. This is the Log & Events tab on the portal:
Understand, I set up this database pretty much with the defaults. While I have created objects within the database (and automated deployments to it through AWS Developer Tools), I haven’t gone mucking about with the backups. That a backup was taken at 3:28AM on the day I’m writing this post, that was handled for me.
You actually get quite a bit of functionality from AWS RDS when it comes to backups. Let’s take a look at some of the details when creating a database.
Backup Options
I’m using the console because it makes it easier to describe options. If you’re really getting into management of AWS, it’s a good plan to learn the command line.
In the console, when you’re initially creating a database, the backup options are not immediately available. By default, they’re slightly hidden here:
If I expand that out, I can scroll down to the backup settings:
The most important point I want to make here is right at the top of this image. By default, backups are enabled. Sure, you can turn them off. What is wrong with you?
Next, you set the backup retention. Yes, the longer you set this, the more you pay. Aurora will retain one day of backups for no cost.
Next is the backup window. This is the time frame in which you’d like backups to take place. There’s nothing magic about backups. While they don’t put much of a load on your system, they’re not free. So, pick a time when that impact is minimized, or, take the default and let AWS pick for you.
Next, tags. I need to put up a blog post about tags. For the moment, here’s Steve Jones talking about them on Azure. Same concept, just as important in AWS.
Finally, you can decide if you want some additional protection (yes, that you pay for) by having replication to another AWS region for your backups. Think of it like an offsite copy of your backups, because, that’s really what it is.
I know you’re thinking, surely it’s not that easy. Well, actually, yeah, it is. However, the devil is in the recovery (you thought I was going to say details). We’ll talk about that in another post.
Conclusion
That you automatically, with zero effort, no setup, no learning, nothing, get RDS backups is a win beyond accounting. If you haven’t spent years on the forums, you really do have no idea just how horrible people treat the concept of backups. I find it wonderful that AWS has built this directly into what they do and how they do it when it comes to RDS databases.
Next post, we’ll look at restoring from these backups and restoring to a point in time.