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 support@cloudacademy.com., your feedback is greatly appreciated.

Thank you for your time and good luck with your continued learning of cloud computing. 

Thank you.

Lectures

Course Introduction - RDS Backup Capabilities - Restoring an RDS Database - Copying & Sharing RDS Snapshots - Amazon DynamoDB Backup Capabilities - Restoring an Amazon DynamoDB Database