Creating a Backup Plan Demo

Contents

Cross-Region Backups with AWS Backup Service
1
Introduction
PREVIEW2m 17s
2
Terminology
PREVIEW1m 43s
6
Summary
PREVIEW1m 7s
Creating a Backup Plan Demo
Difficulty
Intermediate
Duration
17m
Students
32
Ratings
5/5
starstarstarstarstar
Description

In this course, you will learn how to use AWS Backup to create snapshots and have them available in another region — essentially creating a Disaster Recovery site.

Learning Objectives

  • Have a greater understanding of the AWS Backup service and how it interacts with other services such as EC2, EBS, and RDS
  • See how we create a cross-region backup
  • Terminology of AWS Backup
  • Basic usage
  • Creating a Backup Plan
  • Enabling and verifying cross-region functionality

Intended Audience

  • Those who want to understand the basics of the AWS Backup service
  • Those ready to tackle the hands-on task of creating EC2 snapshots that could be used to recover from an outage
  • Those who manage a fleet of EC2, perhaps along with RDS for their databases 

Prerequisites 

  • Have an understanding of the basics of AWS, such as using EC2 for Virtual Machines and RDS for your databases. As long as you understand how those services work at a high level, you should be able to get the most out of this course.
Transcript

All right. Let's go ahead and start by going to the backup console. I'll type backup and it should be the first option here. And before we start backing up resources, we need to tell AWS backup what to do with our backups. You know, where to store them, how long to keep them and a few more options. This is going to be our backup plan, so let's go ahead and create one. You have the option of a template right here and the templates, you know, by their name, you already know what's going on. This is daily, 35-day retention, daily, monthly and in one year retention and so on. For our purposes, let's go ahead and build one from scratch. I'm just going to call it 'ProductionBackupPlan'. And we need to configure at least one rule, we're going to call it daily, 120-day retention. For the storage or the backup vault, we're just going to use the default. If you need to create one, there's the button right there. But in 99% of use cases using the default backup vault is more than enough. Now, let's talk about frequency. It really depends on the sensitivity of your data.

You know, if it's really highly transactional data, you may need to go as far as backing it up every hour. But for most use cases, let's say a web server, a WordPress blog or something like that, a daily backups is more than adequate. That's why you see this as the default option. The backup window, this is where you get to specify the time of day where the backup is going to occur. Generally, a backup is not going to cost you any downtime or, you know, heavy resource usage. So, as long as it's night time for you, you can just go ahead and fire up your backup. It should be fine depending on, of course, server size, number of users, and so on. So, in some cases you may have to have a dedicated backup window to perform your backups. Now, once you have your backups, you have the option of going to cold storage. A cold storage is simply a cheaper way to store your backups. This is really critical if you have terabytes of information, you know, it can get really expensive. So, you can say well, after 15 days, go ahead and move my backups from readily available to cold storage. Now, this is also related to the same.

So, let's say a specified days here, 120. What I'm saying here is at the end of this retention period, 120 days, I want you to go ahead and delete these backups because they're not really useful to me anymore because they're already gone stale, not really useful, right? We can talk about copy to destination but we're going to save that for another conversation, so for now, let's go ahead and skip that. And that's pretty much it here, let's just quickly mention these two notes that you see here. Number 1, we did not assign any EC2 instances or RDS databases and that's okay, we get to do that up next. And number 2, if you have more complex transition or data retention rules, you can always come back and add to this backup plan that we just created. So, for now let's just go ahead and click the 'Create' button and we're sent directly to this page that says 'Assign Resources'. Let's go ahead and skip this for now, so I'll just click on 'Cancel' here and you can see this is the main page for our backup plan.

We have our retention rule that we defined and as you can see, we don't have any resources so, let's take care of this right away. What we're going to do is we're going to specify a tag which we're going to call 'environment' and we're going to say whenever this tag is equal to production, I want you to go ahead and select those resources for backup. As long as they're compatible with this service, they will be backed up. So, I forgot the name, let's give it a name. Let's say ProductionResources. Now, we can click on 'Assign Resources' and continue. Now, as you can see, we have the rule here in resource assignments. So yeah, this should be it for plan creation and resource assignment. It should run by itself as long as you have properly tagged production resources, they will be backed up.

 

About the Author
Avatar
Carlos Rivas
Sr. AWS Content Creator
Students
176
Courses
7

Software Development has been my craft for over 2 decades. In recent years, I was introduced to the world of "Infrastructure as Code" and Cloud Computing.
I loved it! -- it re-sparked my interest in staying on the cutting edge of technology.

Colleagues regard me as a mentor and leader in my areas of expertise and also as the person to call when production servers crash and we need the App back online quickly.

My primary skills are:
★ Software Development ( Java, PHP, Python and others )
★ Cloud Computing Design and Implementation
★ DevOps: Continuous Delivery and Integration