The course is part of these learning paths
This course explores the different strategies that are available for when you need to both back up and restore your AWS databases across Amazon Relational Database Service (RDS) and Amazon DynamoDB. During this course, you will learn about the different backup features that are available in Amazon RDS and DynamoDB, how to identify the differences between them, and when you should use one over the other. The course also explains how to copy and share RDS snapshots across regions and AWS accounts.
The concepts covered in this course are complemented with guided demonstrations from the AWS platform, to ensure you get a real-world understanding of them. If you have any feedback relating to this course, feel free to get in touch with us at firstname.lastname@example.org.
- Introduce you to the different backup features that are available in Amazon RDS and DynamoDB
- Identify the differences between the different backup features and when you should use one over the other
- Explain how to copy and share RDS snapshots across regions and AWS accounts
This course has been designed for those who are responsible for maintaining AWS database solutions at an operational level. It is also suitable for anyone looking to take the AWS Certified Database Specialty certification.
To get the most out of this course, you should be familiar with Amazon RDS and Amazon DynamoDB at a foundational level. For more information on these databases, please see our existing course here.
Hello and welcome to the final lecture in this course where I shall pull out the key points covered from each lecture.
I started this course by looking at the different RDS backup capabilities, and in this lecture, we learned that:
- There are 3 different options or methods of backing up an RDS database
- Using automatic backups
- Performing manual backups with snapshots
- Using the AWS Backup Service
- Automatic backups use a retention period determining how long the backups will remain between 0-35 days
- For automatic backups to take place, the retention period must be set to at least 1 day.
- The backup window allows you to define a time period in which the backup snapshot should be taken.
- If you're using a Multi-AZ configuration, then the backup will not affect your storage I/O as the backup will be taken from the standby instance
- You must ensure that your backup window does not overlap with your maintenance window
- RDS captures any transaction logs that have been created as and when updates to your DB was made
- RDS automatically stores backups on Amazon S3
- Snapshots are only supported for the InnoDB storage engine and not MyISAM
- When you delete your database instance you will be given the option to perform a final DB snapshot.
- When you delete your DB instance you automated backups will only last as long as the retention period allows them to
- To maintain a backup to restore from at a later stage you should create a final DB backup when prompted before deleting your instance
- User-initiated manual backups are known as DB snapshots.
- Manual snapshots do not offer the ability to perform point-in-time-recovery
- When you create your first backup, a full backup is taken and any subsequent backups that are taken are an incremental backup
- Manual DB snapshots are not restricted by any retention periods
In the next lecture, I then talked about how to restore from an existing RDS backup, the key points from this lecture included:
- RDS backs up the transaction logs to Amazon S3 every 5 minutes
- You can check the latest restore time possible from either the AWS Management Console or by using the AWS CLI
- The latest restore time shows you the latest point at which you can restore from
- When you perform a restore, it restores the entire instance
- If restoring a SQL Server DB instance, every DB on that instance will be restored to within 1 second of all other databases on that same instance.
- By restoring an Oracle DB instance, you can select a new license model and DBName for the new instance
- There is no option to perform a point in time recovery when you restore from a manual backup.
- Manual backups restore to the point in time that the backup was taken
- During the restore process, you can restore to a different storage type from the source database
- When you are restoring your manual snapshot, you have the option of changing both the parameter group and the security group.
Following this lecture, I looked at how you can copy and share your RDS snapshots, and here I explained that:
- You can copy your snapshots using both your automated or manual snapshots, within the same region, or to a different AWS region
- You can copy your snapshots to a different AWS account
- Any snapshot copy will be classed as a manual snapshot
- When a snapshot is copied, the database option group and the parameter group configurations will not be copied
- Instead, in the target region, it will use the defaults in that region for both of these instead. As best practice, you should perform the following steps when copying to another region
- Create a new option group and parameter group in the target region that replicates the same settings as the source database that the snapshot is taken from
- Copy the snapshot to the new region
- If you perform a restore from that snapshot modify the DB instance and select the new Option group and parameter groups
- If a snapshot is taken from an encrypted database, then the snapshot will also be encrypted
- If you copy a snapshot to the same region as the source snapshot, then you can use the same KMS key.
- If you copy an encrypted snapshot to a different region, you will need to specify a new KMS key in the target region
- You can choose to encrypt an unencrypted snapshot by selecting a KMS key during the copy process
- Sharing snapshots allows other AWS accounts to access the snapshot
- A snapshot can be shared as public or private
- A publically shared snapshot is available to everyone
- A privately shared snapshot allows you to specify which AWS accounts have access to the share
- You can only share manual snapshots
- By sharing your snapshots with another AWS account, it allows that account to take a copy of the snapshot
- It is not possible to share an encrypted snapshot if trying to share publicly
- You are not able to share a snapshot that has been encrypted with the default KMS key of the source account
- You can’t share snapshots that are encrypted with transparent data encryption (TDE)
- If you have used a customer created CMK to encrypt your source database, then you must ensure the target account has permissions to use the CMK
From here I then moved on from Amazon RDS and focused on Amazon DynamoDB, and I started by looking at the different backup capabilities it had to offer. During this lecture I explained that:
- DynamoDB uses automatic and manual backup options
- Like RDS, you can configure point in time recovery
- You do not need to set a backup retention period or backup time period, instead, this is automatically defined:
- PITR can be enabled or disabled
- The retention period for PITR backups is 35 days
- Should an incident occur, you can restore from any point in time from the previous 35 days
- When you delete your table you are given the option to create a backup before deleting it
- The final backup will be maintained until you manually delete it
- Manual backups are known as on-demand backups
- On-demand backs exist until you manually delete them
- When performing on-demand backups it does not impose any performance throughput impact
- Backups can be created in seconds despite the size of your database
- You do not need to create backup windows or schedules when using DynamoDB
- On-demand backups take a full backup of the entire table
- AWS Backup can be used to schedule on-demand backups on a regular and recurring basis.
The final lecture looked at how to restore an Amazon DynamoDB database. This lecture mainly focused on a demonstration, however, we also learned that:
During a restore, you have the ability to change some configuration settings, such:
- Restoring with or without secondary indexes
- Restoring to a different region
- Encrypting your database using a KMS (Key Management Service) key
That now brings me to the end of this lecture and to the end of this course.
In this course, we learned the different backup and restore options available when using Amazon RDS and DynamoDB. There are similarities between the two, but there are also some key differences as well. Depending on your use case as to which database service you might use within your environment, you should now have a better understanding of how to manage your backups and what type of backup you need to implement.
If you have any feedback on this course, positive or negative, please do contact us at email@example.com., your feedback is greatly appreciated.
Thank you for your time and good luck with your continued learning of cloud computing.
Course Introduction - RDS Backup Capabilities - Restoring an RDS Database - Copying & Sharing RDS Snapshots - Amazon DynamoDB Backup Capabilities - Restoring an Amazon DynamoDB Database
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.