Your Data Backup Strategy in AWS
Using AWS Services for Data Backup
As a part of your business continuity and disaster recovery practices, it’s extremely important to have a data backup strategy in AWS. Under the Shared Responsibility Model, AWS provides you with services to manage data backup, but it is your responsibility to configure these services to align with how and when you back up data. AWS provides several backup and recovery services, including:
- AWS Backup is a fully managed backup service for automating backups across AWS services.
- Amazon S3 Glacier and S3 Glacier Deep Archive are the storage classes of S3 for data archiving and long-term backup.
- Amazon EBS provides block storage and has a snapshot feature that lets you back up EBS volumes for use with Amazon EC2.
- AWS Storage Gateway is an option for hybrid cloud storage, giving you on-premoses access to cloud storage.
- Amazon EFS works with EC2 instances to provide scalable file storage.
There are so many things that you can back up in AWS – EC2 instances, EBS volumes, DB instances. It’s crucial to establish your data backup strategy, and properly configure the AWS services that you choose to use.
AWS provides you with the capability of managing your data backup strategy within your environment, but it is your responsibility to ensure that you are following your expectations for how, when, and how often you manage your data backups. You will see services within AWS that end with the word “snapshot.” This can be a valuable component of your data backup strategy. You will have EBS snapshots or you’ll have RDS snapshots. They also provide you with the service AWS Backup. This is the way that you can configure and manage your EBS volumes and their backups. You can back up your EC2 instances. You can back up your RDS. This is your responsibility because it is up to you to determine when we want to be able to go back and restore from a different point in time.
Think about this scenario with me. What if you have set up a high-availability strategy using Availability Zones within AWS and you think, “Well there’s no reason for us to perform data backups because we have this availability strategy in place and because we are replicating this data. We should not have to ever restore or have any backups.” People are under the false assumption sometimes that this is a good data backup strategy. It is not, because what if a file is deleted in one Availability Zone? What if there is file corruption and it gets replicated to the other Availability Zone? You are going to, at some point, have to restore back to a point, and what that point is will be up to you. Is that an hour? Is that a day? Is that a week? At what point can you handle going back to restore any files that were lost or corrupted? That is why you have to establish a very sound and effective database strategy using the capabilities that are provided to you within the AWS account