RDS Backups and High Availability

When running databases, two critical concerns are data loss and downtime. What if a server fails? What if you accidentally delete crucial data?

AWS RDS offers powerful features to ensure your database is both resilient against failures and recoverable from data loss. We'll explore how to achieve this with backups and high availability.

Automated backups are a lifesaver. RDS automatically creates and stores backups of your database instance.

• They include a full daily snapshot and transaction logs.
• You define a retention period (1-35 days).
• Backups happen during a specified backup window to minimize performance impact.

These are enabled by default for new instances!

Automated backups enable Point-in-Time Recovery (PITR). This means you can restore your database instance to any second within your retention period.

Imagine accidentally deleting a table at 10:30 AM. With PITR, you can restore your database to 10:29 AM, before the error occurred. This creates a brand new RDS instance with the restored data.

While automated backups are great for short-term recovery, manual snapshots offer more control and flexibility.

• You initiate them whenever needed.
• They are stored until you explicitly delete them.
• Useful for long-term archiving, major schema changes, or migrating data.

They are full backups of your database instance at a specific point in time.

When you restore from either an automated or manual snapshot, RDS creates a new database instance. This new instance is independent of the original one.

You can specify the instance type, storage, and other configurations for the new instance. This process is great for testing changes or recovering a specific version of your data.

Multi-Availability Zone (Multi-AZ) deployments are crucial for high availability. Instead of just one database instance, RDS automatically provisions and maintains a synchronous standby replica in a different AZ.

An Availability Zone (AZ) is a physically separate, isolated location within an AWS Region. This protects against an outage in a single AZ.

If your primary database instance in a Multi-AZ deployment becomes unavailable (e.g., due to an AZ outage or underlying infrastructure issue), RDS automatically performs a failover.

The standby replica is promoted to become the new primary. Your application's database endpoint automatically points to the new primary, usually within minutes, with minimal disruption.

It's important to distinguish Multi-AZ from Read Replicas.

• Multi-AZ: Focuses on high availability and disaster recovery. The standby replica is synchronous and not directly accessible for reads.
• Read Replicas: Focus on performance scaling by offloading read traffic. They are asynchronous and can be in the same or different AZs/Regions.

We'll dive deeper into Read Replicas in a future lesson.

For maximum database resilience and uptime, a common strategy is to combine these features:

• Automated Backups: For point-in-time recovery from accidental data changes.
• Manual Snapshots: For long-term archives or specific recovery points.
• Multi-AZ: For high availability against AZ-wide outages.

This layered approach ensures your data is protected and always available.

You've learned about RDS's powerful features for backups and high availability. Let's test your understanding!

Great job! In this lesson, we explored how AWS RDS helps you build resilient databases:

• Automated Backups provide point-in-time recovery.
• Manual Snapshots offer flexible, user-initiated backups.
• Multi-AZ Deployments ensure high availability and automatic failover across Availability Zones.

By using these features, you can significantly enhance your database's data protection and uptime.