AWS Backup Recovery Pipeline - Consulta historica de backups MySQL

Este proyecto transforma un proceso manual y lento de recuperacion de datos historicos en un pipeline reproducible en AWS. A partir de backups MySQL comprimidos en formato .sql.gz, la solucion genera datasets Parquet consultables desde Athena, con trazabilidad operativa, catalogacion en Glue y despliegue reusable mediante Terraform.

Problema real

Cuando un equipo necesita revisar un backup antiguo, el flujo suele ser demasiado manual: localizar el dump, descargarlo, restaurarlo en local o en una instancia temporal y buscar los registros a mano. Si hace falta comparar otra fecha o revisar otro tenant, el proceso vuelve a empezar.

Ese enfoque resuelve urgencias, pero no escala bien. Consume tiempo, depende del entorno de un developer y deja poca trazabilidad sobre que se proceso y con que resultado.

Solucion aplicada

La arquitectura final preserva el dump original en S3 raw y lo transforma bajo demanda a una capa analitica en Parquet. La ejecucion se orquesta con Step Functions, usa Lambda para validacion y catalogacion, y delega el trabajo pesado de parseo y escritura a ECS Fargate.

El backup MySQL `.sql.gz` entra en S3.
Step Functions valida la entrada y genera `run_id`.
Fargate descomprime, parsea el SQL y escribe tablas en Parquet.
Glue registra tablas y particiones.
Athena consulta los datos por `tenant` y `backup_date`.

Decisiones tecnicas clave

El dump original se conserva intacto en `raw` como fuente de verdad.
La salida final es Parquet para reducir escaneo y mejorar eficiencia en Athena.
Fargate actua como motor de transformacion porque el parseo y la escritura exceden el caso de uso comodo de una Lambda unica.
Glue se registra de forma explicita para controlar mejor tablas, particiones y trazabilidad.
Terraform replica el flujo validado para dejar una version reusable de la arquitectura.

Validacion real en AWS

El proyecto no se quedo en una idea o una maqueta de infraestructura. El MVP se valido en una cuenta AWS real procesando un backup MySQL comprimido y confirmando el comportamiento del flujo de extremo a extremo.

Se proceso un backup `.sql.gz` real.
Se generaron datasets Parquet en la capa curated.
Se escribio `manifest.json` como evidencia operativa.
Glue creo correctamente tablas y particiones.
Athena devolvio resultados validos sobre los datos procesados.

Valor del proyecto

Este caso resume bien el tipo de trabajo que mas me interesa: convertir una necesidad operativa real en una solucion reproducible, observable y con criterio de arquitectura. No busca cubrir todos los escenarios posibles de restauracion, sino resolver con claridad uno muy concreto: consultar historico desde backups sin restaurar bases completas.

Trade-offs y limitaciones

El parser MVP se centra en `CREATE TABLE` e `INSERT INTO ... VALUES`.
Algunos tipos pueden degradarse a `string` en el catalogo analitico.
Backups con SQL exotico o BLOBs requieren hardening adicional.
La reinsercion automatica en MySQL origen queda fuera del alcance actual.