DEV Community: ANTONY PIERO SOLORZANO ZEGARRA

Cómo saber si tu backup funciona: integridad y recuperación con SQLite — Adriana Laos

ANTONY PIERO SOLORZANO ZEGARRA — Sat, 03 Oct 2026 21:01:40 +0000

Artículo del equipo — integrante: Adriana Rafaela Laos Gonzales. Publicado desde la cuenta del equipo administrada por Antony.

Guardar un archivo y llamarlo «backup» no demuestra que los datos estén recuperables. Podemos conservar una copia incompleta, perder los cambios posteriores a ella o descubrir demasiado tarde que nadie conoce el procedimiento de restauración. En este artículo me centro en cómo comprobar la recuperación, usando un laboratorio con SQLite y registros ficticios.

El proyecto que vamos a comprobar

El equipo construyó una pequeña aplicación de inventario. Usa SQLite en el navegador mediante sql.js y un laboratorio independiente en Python. No utiliza Microsoft SQL Server.

La página funciona con datos de prueba y no requiere iniciar sesión. GitHub Pages publica la interfaz; la base se ejecuta en la memoria del navegador de cada visitante. Una recarga elimina el estado, de modo que no debe confundirse esta demostración con almacenamiento persistente en la nube.

Tres preguntas distintas para una misma copia

Antes de restaurar, conviene distinguir tres comprobaciones:

Pregunta	Comprobación del laboratorio	Qué no garantiza
¿Cambió el archivo respecto del original?	SHA-256	No cifra ni autentica si un atacante puede reemplazar también el hash.
¿La estructura de SQLite está íntegra?	`PRAGMA integrity_check`	No prueba por sí sola que los registros esperados estén presentes.
¿Recuperamos el contenido previsto?	Comparar inventario ordenado por ID	Solo valida los datos y reglas que realmente se comprobaron.

Son pruebas complementarias. Una base puede ser estructuralmente válida y estar vacía; también puede contener información desactualizada. Por eso la comprobación de integridad de SQLite forma parte del procedimiento, pero no es su único criterio de éxito.

Un experimento para entender el RPO

El RPO expresa la pérdida de datos tolerable, normalmente en tiempo. La demo permite observar el efecto de guardar un estado anterior:

Abrir la aplicación: hay tres productos.
Pulsar «Crear copia completa».
Añadir un cuarto registro después de la copia.
Pulsar «Simular pérdida de datos»; el inventario queda vacío.
Restaurar y verificar.

La recuperación devuelve los tres productos originales. El cuarto no vuelve porque fue creado después del backup. No es un error de restauración: la copia contiene un estado anterior. Esta diferencia permite entender por qué la frecuencia de backups debe responder a una necesidad concreta.

Si una operación no tolera perder muchas transacciones, una copia completa ocasional puede ser insuficiente. Harían falta una frecuencia adecuada y, según el motor, otras estrategias de recuperación. Este proyecto no implementa backups incrementales, diferenciales ni recuperación a un instante específico.

Recuperar de forma segura

En la aplicación, primero se comprueba la copia y se construye una base candidata. Se verifica su integridad y se comparan sus registros con los guardados. Solo entonces se sustituye la base activa. Así, un fallo en la comprobación no reemplaza directamente los datos existentes.

La API de sql.js permite obtener los bytes SQLite con export() y crear una base con new SQL.Database(bytes), como indica su documentación. Esta copia se conserva en memoria y puede descargarse como .sqlite.

Para trabajar con una base SQLite activa fuera del navegador, no conviene copiar a ciegas el archivo principal. La API oficial de backup de SQLite proporciona una forma de generar una copia consistente. En el laboratorio Python se usa Connection.backup(). También se genera un dump con iterdump() y se restaura en una base independiente, según la documentación de Python.

El RTO va más allá del cronómetro

La página muestra el tiempo local de restauración de una base mínima. Ese número sirve para observar la operación, pero no estima la recuperación de un sistema real.

Un objetivo de RTO debe considerar localizar la copia, descargarla si está fuera del equipo, reconstruir el entorno, restaurar permisos y dependencias, ejecutar comprobaciones y confirmar que la aplicación vuelve a funcionar. Tres registros en memoria no representan una base grande ni una caída de infraestructura.

Qué automatizamos y qué debemos practicar

El repositorio contiene un flujo de GitHub Actions que se ejecuta cuando cambia la rama main. Primero prueba el ciclo de pérdida y recuperación en Python; si pasa, publica la aplicación en Pages. La configuración utiliza las acciones de despliegue oficiales.

Esta automatización evita desplegar si falla la prueba incluida. No programa backups de una base de producción: las copias del navegador son manuales y el laboratorio usa datos generados para cada ejecución.

Además de automatizar, mantendría un procedimiento breve de restauración: identificar la copia y su fecha, validar su referencia, recuperar en un entorno controlado, comprobar datos y registrar el resultado. Practicar ese procedimiento permite detectar problemas antes de una emergencia.

Guardar una copia donde el incidente no llegue

La copia de esta demo está en el mismo dispositivo que la base. Si se pierde el equipo o se cierra la pestaña sin descargarla, también podemos perderla. Para un uso real propondría copias independientes, al menos una ubicación externa, retención definida, acceso restringido y cifrado. Una copia descargada en el mismo disco tampoco basta ante el fallo de ese disco.

La estrategia debe evaluarse por su capacidad de recuperación. El ejercicio deja una evidencia concreta: podemos perder el inventario, reconstruir el estado guardado y comprobarlo, comprendiendo qué cambios quedan fuera.

Video del equipo: añadir el enlace público después de publicarlo.

Texto preparado con asistencia de IA para el artículo correspondiente a esta integrante. Las pruebas del proyecto fueron ejecutadas localmente, en GitHub Actions y en la aplicación pública por el asistente del equipo.

Un backup sirve cuando puedes restaurarlo: laboratorio con SQLite y GitHub Actions

ANTONY PIERO SOLORZANO ZEGARRA — Sat, 03 Oct 2026 20:29:26 +0000

Una carpeta llena de copias no demuestra que una aplicación pueda recuperarse. Para comprobarlo, necesitamos provocar una pérdida controlada, restaurar una copia y verificar que los datos recuperados sean los esperados.

Este proyecto usa SQLite y un inventario ficticio. No utiliza Microsoft SQL Server. Incluye una aplicación que ejecuta SQLite en el navegador y un laboratorio de Python que prueba copias físicas y lógicas.

Primero, definir qué significa recuperarse

El RPO expresa cuántos cambios podemos permitirnos perder. Si guardo una copia y después ingreso una venta, restaurar esa copia no recuperará la venta posterior. El RTO expresa cuánto tiempo podemos permitir que dure la recuperación; incluye localizar la copia, preparar el entorno y comprobar la aplicación.

En esta demostración ambos conceptos se observan con pocos registros. El tiempo local mostrado es una medición del ejercicio, no una promesa para producción.

Elegir la estrategia

Una copia completa conserva un estado íntegro y simplifica la recuperación, pero su coste aumenta con el volumen de datos. Una incremental guarda cambios desde la copia anterior y exige reconstruir la cadena; una diferencial guarda cambios desde la última completa. Este laboratorio implementa copias completas, no incrementales, diferenciales ni recuperación a un instante mediante logs.

También hay formatos físicos y lógicos. En Python creo otra base SQLite mediante Connection.backup() y genero un dump SQL con iterdump(). El dump reconstruye esquema y registros, pero no conserva todos los detalles físicos del archivo. Ambas operaciones aparecen en la documentación de sqlite3 de Python.

Copiar un archivo activo sin coordinar escrituras puede producir una copia incorrecta o incompleta. SQLite ofrece su Online Backup API y la alternativa VACUUM INTO. Con WAL no debemos asumir que el archivo principal contiene todos los cambios confirmados. Aquí uso la API de backup.

Construir el ejercicio reproducible

El laboratorio funciona sin paquetes externos:

python3 backup_demo.py --output lab-results

El directorio debe ser nuevo para evitar sobrescrituras. El programa crea tres productos ficticios, obtiene una copia, calcula SHA-256 y genera un dump. Después vacía únicamente ese inventario desechable y restaura la copia.

La operación central es:

with sqlite3.connect(target) as snapshot:
    live.backup(snapshot)

Para recuperar invierto origen y destino. Antes de restaurar compruebo la copia y después comparo los registros con los originales. También reconstruyo otra base en memoria desde el dump SQL. El informe muestra filas iniciales, filas después del incidente, filas recuperadas e integridad.

La prueba ejecutada obtuvo 3 registros iniciales → 0 tras el incidente → 3 restaurados, con integrity_check correcto y restauración lógica correcta. GitHub Actions volvió a ejecutar la prueba antes de desplegar.

Una demo que cualquiera puede probar

La página usa sql.js para exportar bytes de una base SQLite y construir otra a partir de ellos, según la documentación de Database.

Crear una copia de los tres productos.
Añadir un cuarto registro después del backup.
Simular la pérdida: el inventario queda vacío.
Restaurar y comprobar que regresan los tres registros guardados.

El cuarto registro no estaba en la copia y no vuelve: así observamos el RPO. La recuperación verifica SHA-256, integridad y contenido. Este recorrido se probó también en la aplicación pública.

Podemos descargar la copia como .sqlite. La base activa y la copia interna viven en memoria y se pierden al recargar. GitHub Pages aloja la interfaz pública; SQLite se ejecuta en el navegador de cada visitante. No hay un servidor de base de datos compartido ni un servicio de backups remotos.

Automatizar el despliegue

El repositorio incluye .github/workflows/pages.yml. Cada push a main prueba la recuperación; solo si pasa, sube site/ y publica la aplicación en GitHub Pages. También puede iniciarse manualmente. Se habilita seleccionando GitHub Actions como origen de publicación en los ajustes del repositorio. El patrón está descrito en la documentación oficial de Pages.

El flujo no necesita contraseñas ni un token personal guardado en el código. Usa los permisos temporales de Actions. El despliegue es automático; el backup del navegador se crea al pulsar el botón. Son procesos distintos.

Verificar y almacenar fuera del dispositivo

SHA-256 detecta cambios si el hash de referencia es confiable; no cifra ni autentica la copia ante alguien que pueda sustituir archivo y hash. PRAGMA integrity_check comprueba estructura, mientras que comparar registros valida el resultado concreto del ejercicio. Ninguno sustituye todas las comprobaciones funcionales de una aplicación real.

Para un entorno real propondría tres copias, sistemas o medios de almacenamiento independientes y una ubicación externa, junto con permisos restringidos, cifrado y restauraciones periódicas. La copia del laboratorio en la misma memoria no cumple una estrategia 3-2-1.

También definiría retención según el RPO: por ejemplo, diarias durante siete días y semanales durante cuatro semanas, ajustadas a la necesidad real. El proyecto no implementa esa retención.

Lo que demuestra el proyecto

La evidencia es recuperar el inventario y comprobarlo. Crear una copia es el inicio; localizarla, restaurarla y confiar en su contenido es el resultado que buscamos. El repositorio y la aplicación ya son públicos. El video todavía debe grabarse y publicarse; el guion está disponible en el enlace inicial.

Proyecto y redacción preparados con asistencia de IA; las pruebas de restauración se ejecutaron localmente, en GitHub Actions y en la demo web.