Brief
The snapshots which Amazon RDS performs for enabling automated backups are available to you for copying (using the AWS console or the copy-db-snapshot command) or for the snapshot restore functionality.
You can identify them using the “automated” Snapshot Type. In addition, you can identify the time at which the snapshot has been taken by viewing the “Snapshot Created Time” field.
Alternatively, the identifier of the “automated” snapshots also contains the time (in UTC) at which the snapshot has been taken.
Architecture
You can implement this in different cross accounts as shown in below architecture.
Technical Design
BackupRetentionPeriod
You can set the backup retention period when you create a DB instance. If you don’t set the backup retention period, the default backup retention period is one day if you create the DB instance using the Amazon RDS API or the AWS CLI.
The default backup retention period is seven days if you create the DB instance using the console. After you create a DB instance, you can modify the backup retention period.
You can set the backup retention period to between 0 and 35 days. Setting the backup retention period to 0 disables automated backups. Manual snapshot limits (100 per region) do not apply to automated backups.
Note: An outage occurs if you change the backup retention period from 0 to a non-zero value or from a non-zero value to 0.
Different engine types
For the MySQL DB engine, automated backups are only supported for the InnoDB storage engine. Use of these features with other MySQL storage engines, including MyISAM, can lead to unreliable behavior while restoring from backups.
Specifically, since storage engines like MyISAM don’t support reliable crash recovery, your tables can be corrupted in the event of a crash. For this reason, we encourage you to use the InnoDB storage engine.
For the MariaDB DB engine, automated backups are only supported with the InnoDB storage engine (version 10.2 and later) and XtraDB storage engine (versions 10.0 and 10.1).
Use of these features with other MariaDB storage engines, including Aria, might lead to unreliable behavior while restoring from backups.
Even though Aria is a crash-resistant alternative to MyISAM, your tables can still be corrupted in the event of a crash.
For this reason, we encourage you to use the XtraDB storage engine.
You can retain automated backups for RDS instances running MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQL Server engines.
Restoring a DB backup
To view your retained automated backups, switch to the automated backups page. You can view individual snapshots associated with a retained automated backup on the database snapshots page in the console.
Alternatively, you can describe individual snapshots associated with a retained automated backup. From there, you can restore a DB instance directly from one of those snapshots.
Restored DB instances are automatically associated with the default parameter and option groups. However, you can apply a custom parameter group and option group by specifying them during a restore.
In this example, you restore a DB instance to a point in time using the retained automated backup. First, you describe your retained automated backups, so you can see which of them to restore.
To describe your retained automated backups using the RDS API, call the DescribeDBInstanceAutomatedBackups action with one of the following parameters:
DBInstanceIdentifier
DbiResourceId
aws rds describe-db-instance-automated-backups --db-instance-identifier DBInstanceIdentifier
Or
aws rds describe-db-instance-automated-backups --dbi-resource-idDbiResourceId
Next, to restore your retained automated backup to a point in time, using the RDS API, call the RestoreDBInstanceToPointInTime action with the following parameters:
SourceDbiResourceId
TargetDBInstanceIdentifier
aws rds restore-db-instance-to-point-in-time --source-dbi-resource-id SourceDbiResourceId --target-db-instance-identifier TargetDBInstanceIdentifier --use-latest-restorable-time
Pricing Implications
The cost of a retained automated backup is the cost of total storage of the system snapshots that are associated with it.
There is no additional charge for transaction logs or instance metadata. All other pricing rules for backups apply to restorable instances.
For example, suppose that your total allocated storage of running instances is 100 GB. Suppose also that you have 50 GB of manual snapshots plus 75 GB of system snapshots associated with a retained automated backup. In this case, you are charged only for the additional 25 GB of backup storage, like this: (50 GB + 75 GB) — 100 GB = 25 GB.
Storage Cost example
MariaDB in Singapore: General Purpose (SSD) Storage $0.276 per GB-month => $582.36 for 2.1 TB (Could change over time)
[https://aws.amazon.com/rds/mariadb/pricing/]
Limitations and Recommendations
The following limitations apply to retained automated backups:
The maximum number of retained automated backups in one region is 20. It’s not included in the DB instances limit. You can have 20 running DB instances and an additional 20 retained automated backups at the same time.
You can have up to five snapshot copy requests in progress to a single destination region per account.
Retained automated backups don’t contain information about parameters or option groups.
You can restore a deleted instance to a point in time that is within the retention period at the time of delete.
A retained automated backup can’t be modified because it consists of system backups, transaction logs, and the DB instance properties that existed at the time you deleted the source instance.
Automate
Automate the implementation of Snapshot Tool for RDS in python by creating manual snapshots, copying them into a different account and a different region and deleting them after a specified number of days (Refer to the architecture diagram above). It also allows you to specify the backup schedule (at what times and how often) and a retention period in days.
Top comments (0)