Introducción

1

Bases de datos relacionales en AWS con RDS y DynamoDB

Introducción a RDS

2

Gestión de Bases de Datos en AWS RDS: Características y Buenas Prácticas

3

Creación de bases de datos MySQL en Amazon RDS

4

Conexión a MySQL en AWS usando MySQL Workbench

5

Creación de Tablas y Gestión de Datos con MySQL Workbench

6

Conexión MySQL desde Amazon EC2 a RDS paso a paso

7

Conexión y Gestión de Bases de Datos en AWS RDS

Backups, Performance y HA en RDS

8

Backups y alta disponibilidad en AWS RDS

9

Restauración de Bases de Datos con Amazon RDS: Técnicas Avanzadas

10

Estrategias Avanzadas de Optimización en RDS de AWS

11

Alta disponibilidad en bases de datos: Multi AZ en RDS de AWS

Migración a RDS

12

Estrategias de Migración a RDS con AWS DMS

13

Migración Homogénea con Database Migration Service

14

Escenarios de Uso para AWS RDS y sus Arquitecturas

Aurora

15

Características y Ventajas de Amazon Aurora en AWS

16

Configuración de Endpoints en Amazon Aurora para Alta Disponibilidad

17

Aurora Serverless: Configuración y Ventajas en AWS

18

Creación y Configuración de Bases de Datos Aurora en AWS

Introducción a DynamoDB

19

Bases No Relacionales con AWS DynamoDB

20

Consistencia Fuerte vs Eventual en DynamoDB

21

Creación y Configuración de Tablas en DynamoDB

22

Casos de Uso de DynamoDB en Aplicaciones Reales

23

Creación y Configuración de Tablas DynamoDB en AWS

Particiones e Índices en DynamoDB

24

Particiones e Índices en DynamoDB: Optimización de Bases de Datos

25

Operaciones Scan en DynamoDB: Uso y Mejores Alternativas

26

Consultas Eficientes en DynamoDB: Uso de Claves y Optimización

27

Consultas y Escaneos en DynamoDB: Filtrado y Eficiencia en AWS

28

Claves de Partición y LSI en AWS DynamoDB

DynamoDB Streams y Replicación

29

DynamoDB Streams: Uso en Arquitecturas de Big Data en Tiempo Real

30

Casos de Uso de DynamoDB Streams para Eventos en Tiempo Real

31

Optimización de consultas en DynamoDB con DAX

Contenido Bonus

32

Bases de Datos Relacionales vs No Relacionales en AWS

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Curso Práctico de Bases de Datos en AWS

Curso Práctico de Bases de Datos en AWS

Carlos Andrés Zambrano Barrera

Carlos Andrés Zambrano Barrera

Restauración de Bases de Datos con Amazon RDS: Técnicas Avanzadas

9/32
Recursos

¿Cómo restaurar una base de datos en Amazon RDS?

Restaurar una base de datos en Amazon RDS es una tarea crítica que requiere atención a los detalles y comprensión de las opciones disponibles. En esta sección, vamos a desglosar cómo proceder con la restauración y las diferentes opciones que ofrece RDS para realizar restauraciones automáticas de bases de datos.

¿Dónde encontrar las opciones de restauración?

Para comenzar, ingresa a la consola de Amazon RDS. Una vez dentro, ubica tu base de datos ya creada y haz clic en "Modify". Aquí encontrarás varias opciones que te permiten ajustar configuraciones hechas durante la creación inicial:

  • Modificar el período de retención, esencial para auditorías o cambios en requerimientos.
  • Cambiar características de la infraestructura, como tipos de instancias o configuraciones de almacenamiento.

¿Cómo restaurar a un punto en el tiempo?

Un método clave es "Restore to point in time", que te permite regresar tu base de datos a un momento específico. Esto se puede lograr seleccionando desde la fecha y hora exacta en que deseas restaurar:

  1. Último punto posible: Se muestran el año, mes, día y hora.
  2. Opción personalizada: Para restauraciones más específicas, elige "Custom" y selecciona días, horas, minutos y segundos de manera precisa.

¿Qué configuraciones se pueden ajustar durante una restauración?

Las restauraciones no son meramente una vuelta atrás en el tiempo; también ofrecen la oportunidad de ajustar e incluso mejorar configuraciones:

  • DB Engine: Asegúrate de que el motor de base de datos sea el correcto (e.g., MySQL).
  • Tipo de instancia: Cambia el tipo de instancia si es necesario.
  • Infraestructura adicional: Decide si deseas que la instancia sea multi-AZ y modifica el almacenamiento.

Estas opciones brindan flexibilidad y control durante el proceso de restauración, permitiendo una personalización detallada según las necesidades del negocio.

¿Qué prácticas son recomendables al manejar el período de retención?

El periodo de retención es crucial, especialmente para aplicaciones críticas. Aunque por defecto es de siete días, se recomienda extenderlo hasta 35 días o más para garantizar la posibilidad de restauración en entornos productivos con gran cantidad de información. Además, puedes complementar esta configuración con snapshots manuales para asegurar mayor integridad de datos.

¿Qué otras funcionalidades pueden activarse durante el proceso?

Durante el proceso de restauración, RDS permite activar funcionalidades extras que pueden ser útiles:

  • Autenticación IAM: Mejora la seguridad de acceso.
  • Logs y mantenimiento: Configura ventanas de mantenimiento y registros para un control más detallado.
  • Subredes y accesibilidad: Decide sobre qué VPC restaurar y si la base será accesible públicamente.

Estas funcionalidades extra no solo te permiten restaurar una base de datos sino optimizar su configuración para mejorar su rendimiento y seguridad.

¿Cómo RDS maneja los backups de forma integral?

RDS provee un enfoque integral para la gestión de backups, ofreciendo tanto copias automáticas como la posibilidad de crear y gestionar snapshots manualmente. Esto asegura que, independientemente de la complejidad del entorno, siempre exista una estrategia que mantenga la data segura y accesible.

Para concluir, el dominio de estas herramientas de restauración en RDS no solo asegura la recuperación efectiva de datos, sino que también incrementa el rendimiento y seguridad general de tus bases de datos. Cada ajuste realizado puede hacer una gran diferencia en el manejo cotidiano de la información crítica.

Aportes 9

Preguntas 6

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

No me queda claro cómo se puede complementar los snapshotp local y los backups automáticos

interesante RDS para el manejo de respaldos y restauración 😃

Los snapshot son muy poderosos, sin embargo consumen mucho almacenamiento en S3, sin embargo los snapshot automáticos después de pasado el tiempo límite no se puede recuperar ninguna información, así que si tu preocupación es el evolutivo de la información, re recomiendo hacer snapshot manuales

Información resumida de esta clase
#EstudiantesDePlatzi

  • Con la acción restore time puedo devolverme en el tiempo para restaurar la base de datos

  • Los tags me permiten identificar recursos para hacer reportes

  • Muy importante tener pendiente el periodo de retención, es recomendable que sea lo más largo posible

Aquí tienes una demostración de estrategias de backup en **SQL Server** y su integración con **AWS S3** para almacenamiento en la nube. ## 🔹 **Paso 1: Crear un Backup Completo (Full Backup)** 📌 **Este backup contiene toda la base de datos.** BACKUP DATABASE mi\_base TO DISK = 'C:\backups\mi\_base\_full.bak' WITH FORMAT, INIT; 📝 **Opción AWS:** Puedes almacenar este backup en **Amazon S3**. 📌 **Copiar el backup a S3 con AWS CLI:** aws s3 cp C:\backups\mi\_base\_full.bak s3://mi-bucket-backups/ ## 🔹 **Paso 2: Crear un Backup Diferencial** 📌 **Guarda solo los cambios desde el último backup completo.** BACKUP DATABASE mi\_base TO DISK = 'C:\backups\mi\_base\_diff.bak' WITH DIFFERENTIAL; ✅ **Menos espacio y tiempo que un full backup.** ## 🔹 **Paso 3: Backup Incremental con Logs de Transacciones** 📌 **Registra cada cambio en la base de datos para restauración punto en el tiempo.** BACKUP LOG mi\_base TO DISK = 'C:\backups\mi\_base\_log.trn'; ✅ **Ideal para bases de datos críticas que requieren restauración precisa.** ## 🔹 **Paso 4: Restauración desde un Backup** ### 📌 **Restaurar desde un Backup Completo** RESTORE DATABASE mi\_base FROM DISK = 'C:\backups\mi\_base\_full.bak' WITH NORECOVERY; ### 📌 **Restaurar un Backup Diferencial** RESTORE DATABASE mi\_base FROM DISK = 'C:\backups\mi\_base\_diff.bak' WITH NORECOVERY; ### 📌 **Restaurar desde un Backup de Logs** RESTORE LOG mi\_base FROM DISK = 'C:\backups\mi\_base\_log.trn' WITH RECOVERY; ✅ **Restaura todos los cambios desde el último backup diferencial o completo.** ## 🔹 **Paso 5: Automatización con un Job de SQL Server** 📌 **Automatiza backups con SQL Server Agent** USE msdb; EXEC sp\_add\_job @job\_name = 'Backup Diario'; EXEC sp\_add\_jobstep @job\_name = 'Backup Diario', @step\_name = 'Backup Completo', @command = 'BACKUP DATABASE mi\_base TO DISK = ''C:\backups\mi\_base\_full.bak''', @database\_name = 'mi\_base'; ## 🔹 **Paso 6: Backup en la Nube (AWS S3 o Glacier)** 📌 **Guardar backups en S3 para retención a largo plazo.** aws s3 cp C:\backups\mi\_base\_full.bak s3://mi-bucket-backups/ 📌 **Para archivos históricos, mover a Glacier (almacenamiento frío)** aws s3 mv s3://mi-bucket-backups/mi\_base\_full.bak s3://mi-bucket-glacier/ --storage-class GLACIER ## 🔹 **Conclusión** ✅ **Full Backup:** Mejor para restauraciones completas. ✅ **Diferencial:** Menos almacenamiento, rápida recuperación. ✅ **Incremental (Logs):** Permite recuperación punto en el tiempo. ✅ **Automatización:** Uso de **Jobs en SQL Server** o **AWS Backup**. ✅ **Almacenamiento en AWS:** **S3, Glacier o RDS Snapshots**.

¿Qué opciones nos da AWS para realizar una migración en tiempo real?

La granularidad de un backup se puede reestablecer hasta segundos.

resumen patatero ,al cargar un backup podemos re configurar toda la base de datos desde 0 para optimizar o cambiar la auditoria

Se puede regular para que no exista la posibilidad de restaurar a un segundo?
Pienso que AWS respalda o saca un Snapshoot 60 veces por minuto y ello degrada la performance…
Espero que no se así.