Litestream 0.5.14 con SQLite: S3, WAL y restauración
Litestream replica SQLite hacia S3 y permite restaurar una app chica sin montar una base pesada. Flujo, permisos, costo, alertas y prueba mínima para pymes.
Un archivo SQLite puede sostener una aplicación interna si la copia vive fuera del servidor. Litestream 0.5.14 replica cambios hacia S3 o almacenamiento compatible y permite restaurar una base chica sin operar PostgreSQL para todo. Esta guía explica cuándo sirve, dónde queda cada dato, qué permiso cuida el destino y cómo probar una restauración antes de confiar en el backup.
Dónde aparece la base que nadie mira
El síntoma se ve en apps internas de poca escala: un turnero, un registro de prácticas, un inventario de laboratorio o una mesa de entrada chica. El antagonista es el archivo app.db guardado en el mismo VPS que ejecuta la aplicación. Un disco Kingston de 480 GB con etiqueta manuscrita puede ser todo el plan de continuidad. La cifra que corrige la decisión viene del proyecto. La API de GitHub marcó Litestream v0.5.14 como última versión estable publicada el 6 de julio de 2026; el repositorio benbjohnson/litestream tenía 13.943 estrellas, 370 forks y licencia Apache-2.0 al 19 de julio. Es una herramienta chica, con una función bien delimitada. El dato global acompaña el cambio de escala. GitHub contó en Octoverse que en 2025 se crearon más de 230 repositorios por minuto. Muchas aplicaciones internas nacen livianas y después reciben datos reales. El respaldo tiene que aparecer antes de que el archivo sea irremplazable. Una base simple también merece una prueba seria y un responsable visible. La decisión técnica queda en una pregunta concreta: cuánto dato se perdería si el servidor desaparece entre dos copias manuales.
Cómo funciona por dentro Litestream corre al lado de la aplicación y lee cambios de SQLite mediante el mecanismo WAL.
La explicación oficial de How it works describe cómo toma páginas nuevas, las empaqueta en archivos LTX y las envía a una réplica. La aplicación sigue escribiendo en su archivo local; Litestream observa y copia cambios de manera asincrónica. El flujo mínimo tiene cinco pasos. Primero, la aplicación escribe datos en SQLite: alumno, turno, equipo, estado o auditoría. Segundo, SQLite registra cambios en WAL. Tercero, Litestream empaqueta esos cambios y los sube a S3 o un servicio compatible. Cuarto, una política de retención decide cuánto historial queda. Quinto, una restauración baja snapshot y LTX hasta reconstruir la base en otro servidor. SQLite guarda los registros estructurados. S3 guarda copias, snapshots y transacciones replicadas. Litestream recibe la ruta de la base y la credencial del destino; entrega archivos de réplica y permite restaurar a un punto cubierto por el historial, según el comando restore. IT administra claves, retención y prueba. Gerencia solo consulta si el sistema volvió y con qué fecha.
Qué se instala o configura primero
La instalación puede empezar con una app que ya usa SQLite, Litestream como proceso de sistema o contenedor, un bucket S3 compatible, credenciales con permiso limitado, monitoreo de último LTX subido y backup del archivo de configuración. La guía de replicación a S3 muestra la ruta de réplica; la referencia de configuración cubre retención y destinos. Ese archivo también debe quedar versionado fuera del servidor para reconstruir la tarea. El costo operativo puede ubicarse entre USD 8 y USD 30 mensuales, entre ARS 12.000 y ARS 45.000 al dólar oficial de venta de ARS 1.500. Ese rango incluye VPS chico, almacenamiento S3 modesto, monitoreo y margen de transferencia. No incluye desarrollo de la aplicación ni revisión de datos viejos. El primer entregable verificable es una restauración completa: borrar una copia de prueba, restaurar desde el bucket, abrir la aplicación contra la base restaurada y comparar cantidad de registros, último ID, fecha máxima y un archivo exportado. UMSA puede ayudar cuando la organización necesita sostener una app chica sin sobredimensionar infraestructura.
Dónde se rompe y cómo probarlo
El primer riesgo es escribir demasiado rápido para la ventana de réplica. La señal es un atraso creciente entre el último cambio local y el último archivo subido. La prueba es cargar 1.000 registros de prueba, cortar red durante cinco minutos, volver a conectar y medir cuánto tarda en ponerse al día. El segundo riesgo aparece en credenciales amplias. La señal es una clave de S3 que puede borrar cualquier bucket de la cuenta. La prueba es usar una credencial de ensayo y confirmar que solo escribe, lista y lee la ruta de esa aplicación. El tercer riesgo aparece en restauración parcial. La señal es una base que abre, pero perdió los últimos registros. La prueba es escribir una marca conocida, esperar replicación, restaurar en otra ruta y buscar esa marca. Si no aparece, el RPO real es mayor al declarado. El cierre debe quedar en agenda: una aplicación chica merece un simulacro con fecha, resultado y responsable.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.