Integrantes:
Stevie Gerald Marca Aguilar
Soanny Geraldine Rivas Gutierrez
INTRODUCCIÓN
Un inventario necesita conservar información fiable sobre las existencias y los precios. Si se elimina un registro o se modifica por error, una copia anterior permite recuperar su contenido. El código del repositorio reconstruye la aplicación, pero recuperar los datos requiere un respaldo de MySQL.
El proyecto combina una aplicación de inventario en Node.js y Express con una base MySQL. Los scripts generan una exportación completa, la comprimen y la protegen mediante cifrado. GitHub Actions incluye un flujo diario de respaldo, mientras Railway publica la aplicación y la configuración contempla una conexión a MySQL administrado en Aiven.
El documento describe la arquitectura, la preparación del entorno y el procedimiento de recuperación. Incluye las pruebas locales reportadas y las capturas de la publicación del repositorio y de una ejecución manual del backup. La aplicación pública responde y confirma su conexión con MySQL; la ejecución diaria programada debe comprobarse en el historial de Actions.
1. Arquitectura del inventario
El inventario permite listar productos, registrar nuevas entradas y eliminar registros. Cada producto contiene ID, nombre, precio, cantidad disponible y fecha de creación. Este modelo facilita comparar la información original con los datos obtenidos después de restaurar una copia.
La Tabla 1 presenta componentes y responsabilidades de la solución.
Tabla 1
Componentes y responsabilidades de la solución
Las pruebas de desarrollo se realizan en el entorno local. Railway ejecuta la API en la nube y la configuración de conexión permite utilizar MySQL en Aiven. El proceso de Actions accede a la base configurada y conserva la copia como artefacto cifrado. El repositorio almacena el código; los archivos de respaldo se descargan aparte y tienen una retención limitada.
- Criterios para conservar las copias Para esta base de demostración se eligió una exportación lógica completa. La copia reúne las tablas y sus registros en un archivo SQL que puede revisarse después del descifrado. El procedimiento no incluye respaldos incrementales ni recuperación a un instante específico mediante binlogs.
La Tabla 2 reúne la frecuencia, la conservación y las condiciones necesarias para recuperar una copia.
Una copia diaria exitosa permite recuperar el estado guardado en la última ejecución. Por ello, podrían perderse los cambios posteriores, aproximadamente los de un día si se cumple el horario. Los fallos o retrasos aumentan ese intervalo. El tiempo de recuperación debe medirse con la cantidad real de datos; este proyecto no garantiza un RTO concreto.
3. Organización y puesta en marcha
El proyecto organiza la API, la interfaz y las herramientas de mantenimiento en carpetas separadas. Los archivos de configuración permiten reproducir el entorno local y definir los procesos de pruebas, publicación y respaldo. La Tabla 3 identifica sus elementos principales.
En Windows se prepara el archivo de variables a partir de la plantilla y se asignan claves propias. Docker Desktop debe utilizar contenedores Linux. Desde la carpeta del proyecto, estos comandos levantan los servicios y consultan su estado.
Los datos de MySQL permanecen en un volumen de Docker. MYSQL_DATABASE, MYSQL_USER y MYSQL_PASSWORD se aplican al inicializar un volumen nuevo. Cambiar esos valores posteriormente no actualiza las cuentas existentes. La aplicación establece la conexión con DB_HOST, DB_PORT, DB_USER, DB_PASSWORD y DB_NAME.
La configuración de laboratorio admite DB_SSL=false en la red local. La conexión externa a Aiven requiere DB_SSL=true y su certificado CA. La comprobación TLS debe validar la confianza del certificado y el nombre del servidor.
*4.Estructura de datos y operaciones de la API
*
La tabla productos usa InnoDB y guarda el precio con dos decimales. El stock no admite cantidades negativas. El SQL actúa sobre la base seleccionada por la conexión, sin imponer un nombre mediante USE; así puede importarse en una base de recuperación distinta.
La API ofrece consultas públicas y operaciones de escritura protegidas. Registrar o eliminar productos exige enviar X-API-Key, cuyo valor se define en ADMIN_API_KEY. También se comprueba que el precio sea numérico y no negativo, con hasta dos decimales, y que el stock sea un entero no negativo.
Las rutas y sus funciones se presentan en la Tabla 4.
5.Generación y protección del respaldo
Antes de exportar, backup.sh comprueba la configuración y crea un espacio temporal privado. La contraseña se entrega al cliente MySQL mediante un archivo de opciones, evitando incluirla en los argumentos del proceso. Ese archivo se retira cuando finaliza la ejecución.
La exportación se realiza con las siguientes opciones de mysqldump.
La opción --single-transaction obtiene una vista consistente de los datos en tablas InnoDB. Mientras se genera la copia deben evitarse cambios de estructura como ALTER, DROP y TRUNCATE. La exportación cubre la base de la aplicación, pero no incluye las cuentas del servidor, los procedimientos ni los eventos (Oracle, s. f.).
Una vez validada la compresión, crypto.js obtiene la clave mediante scrypt y una sal aleatoria. AES 256 GCM protege el contenido con un nonce aleatorio y una etiqueta de autenticación. El archivo se identifica con la fecha y un valor aleatorio, y se acompaña de un checksum SHA 256. La frase de cifrado debe conservarse por separado mientras se necesiten las copias.
El respaldo local puede ejecutarse desde PowerShell utilizando el contenedor de herramientas.
docker compose --profile tools run --rm tools scripts/backup.sh
Get-ChildItem backups
El archivo .sql.gz.enc contiene datos comprimidos y cifrados; requiere el procedimiento de descifrado antes de leer el SQL. Debe conservarse junto a su archivo de checksum. La retención local elimina copias por antigüedad: siete días no significan necesariamente siete archivos, porque pueden realizarse varias ejecuciones en una misma fecha.
*6.Restauración y comprobación de los datos
*
El script restore.sh recupera la información en otra base para proteger el inventario activo. Primero exige que el destino sea diferente de DB_NAME y esté vacío. Después comprueba el checksum, valida el descifrado y revisa el archivo comprimido antes de importar el SQL.
En el entorno de práctica, una cuenta administradora prepara la base de destino y otorga los permisos necesarios al usuario utilizado por el proyecto.
La prueba local reportada se ejecutó con MySQL 8.0.46. Se añadió un cuarto producto y se generó el respaldo. Al restaurarlo, se verificaron las cuatro filas y la igualdad de sus campos. Después se eliminó el registro de prueba desde la API y se comprobó que continuaba disponible en la base recuperada.
También se verificó que el procedimiento rechazara una copia alterada, un destino con tablas y un destino con el mismo nombre de la base activa. La importación completa no constituye una operación atómica: ante un fallo parcial, hay que revisar los objetos creados antes de repetirla.
*7.Conexión de MySQL y publicación en Railway
*
Para utilizar MySQL en Aiven se toman de su consola el host, el puerto, el usuario, la contraseña y la base, además del certificado CA. Deben emplearse los valores reales del servicio: la base puede ser defaultdb y el puerto puede diferir de 3306. Las guías de conexión explican estos parámetros y el uso del certificado (Aiven, s. f.-a, s. f.-b).
Railway ejecuta el servicio Node.js a partir del Dockerfile. Las variables de entorno indican cómo conectarse a MySQL. El archivo railway.json ejecuta la inicialización antes del despliegue y utiliza /health para revisar el servicio. La inicialización está preparada para conservar una tabla que ya exista.
La aplicación publicada dispone de un dominio de Railway. En la comprobación realizada, la página devolvió HTTP 200 y /health respondió con status ok y database MySQL. El servicio escucha en 0.0.0.0 y toma el puerto del entorno. Esta respuesta confirma conectividad con MySQL, pero por sí sola no identifica su proveedor.
El runner de GitHub Actions necesita acceso de red a la base remota. Si se restringen las direcciones permitidas, debe habilitarse la salida del runner o utilizar uno autorizado. Los valores sensibles se almacenan en Secrets y la conexión externa mantiene la verificación TLS.
**
8.Validación del código y publicación automática**
La automatización distingue las pruebas del código, el despliegue y la copia de datos. El archivo ci.yml define pruebas de API y cifrado y una recuperación con MySQL 8.4. El flujo deploy.yml espera el resultado de CI en main para publicar el commit que superó las comprobaciones.
El flujo de despliegue recibe la finalización de CI mediante este evento.
El despliegue exige una ejecución de CI exitosa originada por un push del propio repositorio y la variable DEPLOY_ENABLED=true. Utiliza RAILWAY_TOKEN y RAILWAY_SERVICE_ID para seleccionar el servicio. Railway describe los Project Tokens para esta automatización (Railway, s. f.-a).
Después de railway up se consulta /health en el dominio público. Para comprobar el flujo completo puede modificarse un texto visible, enviar el commit a main y revisar CI, el despliegue y el cambio publicado. Conviene elegir un único mecanismo de publicación para evitar ejecuciones duplicadas. La documentación de railway up describe su comportamiento y opciones (Railway, s. f.-b).
9. Copias remotas mediante GitHub Actions
El flujo backup.yml construye un contenedor con el cliente MySQL 8.4 y llama al mismo script usado en las pruebas locales. Las credenciales de la base y la frase de cifrado se obtienen de Secrets. El artefacto conserva el resultado cifrado y su checksum.
Estas definiciones establecen el horario previsto y la conservación del artefacto.
La ejecución requiere BACKUP_ENABLED=true. Se configuran DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME, DB_SSL_CA y BACKUP_PASSPHRASE como Secrets. Para Aiven, BACKUP_DB_SSL debe estar en true. La cuenta de respaldo necesita acceso de lectura y los permisos de los objetos incluidos en la exportación.
La captura incorporada muestra una ejecución iniciada con workflow_dispatch que terminó correctamente y produjo un artefacto descargable. Este resultado acredita una prueba manual. Para verificar el horario diario hay que revisar una ejecución identificada como Scheduled. También debe descargarse la copia y comprobar su restauración en una base vacía usando la misma frase de cifrado.
Los artefactos se descargan desde la página de la ejecución en GitHub Actions; git clone solo obtiene los archivos versionados del repositorio (GitHub, s. f.).
*10. Resultados y evidencias del proyecto
*
La Figura 5 documenta el registro de un producto en el inventario local. Esta prueba permite observar la validación y la actualización de la lista, pero no demuestra por sí misma una recuperación ni un despliegue remoto.
Las pruebas de recuperación reportadas corresponden a MySQL 8.0.46. El entorno de Docker y los workflows emplean MySQL 8.4. Las nuevas capturas documentan el repositorio público y un backup manual exitoso. La respuesta de /health confirma que la aplicación pública llega a MySQL. Aún debe documentarse la ejecución programada y la restauración del respaldo remoto.
Conclusiones
El ejercicio de restauración permitió recuperar un estado anterior del inventario y comparar sus registros. Trabajar con una base de destino independiente evitó sobrescribir los datos activos durante la validación.
La propuesta integra la comprobación del software, su publicación y la protección de sus datos en flujos separados. Railway mantiene accesible la API; la configuración permite conectar MySQL en Aiven, y GitHub Actions ejecuta las tareas definidas en el repositorio.
Para una demostración con pocos datos, la exportación completa ofrece un procedimiento fácil de revisar. Un uso en producción requeriría definir el RPO y la retención según el negocio, añadir alertas y ensayos de recuperación y guardar otra copia independiente. El proyecto no implementa por sí solo una estrategia completa 3 2 1 ni recuperación PITR.
- Enlaces de la entrega Repositorio público del proyecto: https://github.com/Soanny/mysql-backup-strategy_Stevie-Marca_Soanny-Rivas Aplicación pública en Railway: https://mysql-backup-strategystevie-marcasoanny-rivas-production.up.railway.app/ Video público de máximo cinco minutos: https://www.youtube.com/watch?v=ViPQl8gZ20U
Referencias
Aiven. (s. f.-a). Connect to Aiven for MySQL® from the command line. Recuperado el 3 de octubre de 2026, de https://aiven.io/docs/products/mysql/howto/connect-from-clI
Aiven. (s. f.-b). Connect to Aiven for MySQL® with MySQL Workbench. Recuperado el 3 de octubre de 2026, de https://aiven.io/docs/products/mysql/howto/connect-from-mysql-workbench
GitHub. (s. f.). Downloading workflow artifacts. Recuperado el 3 de octubre de 2026, de https://docs.github.com/en/actions/how-tos/manage-workflow-runs/download-workflow-artifacts
Oracle. (s. f.). 6.5.4 mysqldump — A database backup program. Recuperado el 3 de octubre de 2026, de https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html
Railway. (s. f.-a). Deploying with the CLI. Recuperado el 3 de octubre de 2026, de https://docs.railway.com/cli/deploying
Railway. (s. f.-b). railway up. Recuperado el 3 de octubre de 2026, de https://docs.railway.com/cli/up
Top comments (0)