22 puntos por baeba 2025-05-02 | 2 comentarios | Compartir por WhatsApp

Introducción

  • Copiar directamente una base de datos SQLite con rsync puede ser lento e inestable porque el tamaño del archivo crece debido a los índices y otros elementos.
  • Por eso se propone usar .dump para comprimir y restaurar en un formato basado en texto.

Desarrollo

  • El comando .dump exporta toda la base de datos como texto SQL, y los índices se reemplazan por una sola línea de comando, lo que reduce el tamaño del archivo.

    sqlite3 my_database.db .dump > my_database.db.txt  
    
  • El archivo de texto puede reducirse aún más al comprimirlo con gzip:

    sqlite3 my_database.db .dump | gzip -c > my_database.db.txt.gz  
    
  • Se cambia el proceso para generar la versión comprimida en el servidor, copiarla en local y luego restaurarla:

    ssh username@server "sqlite3 db.db .dump | gzip -c > db.txt.gz"  
    rsync --progress username@server:db.txt.gz .  
    gunzip db.txt.gz  
    cat db.txt | sqlite3 restored.db  
    
  • El archivo original de la base de datos pasa de 3.4GB → texto volcado de 1.3GB → versión comprimida con gzip de 240MB, una reducción de aproximadamente 14 veces.

  • Con el método tradicional usando rsync, si la base de datos cambia durante la transferencia, puede aparecer el error database disk image is malformed.

  • Con el método de volcado en texto no existe el riesgo de que el contenido cambie una vez iniciada la copia, por lo que se puede obtener un respaldo consistente.

Conclusión

  • El método .dump + compresión + restauración mejora tanto la velocidad como la estabilidad al transferir SQLite de gran tamaño.
  • Es especialmente efectivo para bases de datos con muchos índices y puede reducir la probabilidad de fallos en la transferencia o corrupción.
  • Si trabajas con SQLite grande con frecuencia, es una optimización práctica que vale la pena aplicar.

2 comentarios

 
ng0301 2025-05-02

Me da curiosidad el contexto de por qué se necesita hacer este tipo de trabajo.

 
winterjung 2025-05-02

En el texto original dicen que sería para respaldo y análisis. Supongo que tal vez querían analizarlo localmente con algo como DuckDB.