Comment copier plus rapidement une base de données SQLite entre ordinateurs

Introduction

• Copier directement une base SQLite avec rsync peut être lent et peu fiable, car la taille du fichier augmente à cause des index, entre autres.
• Pour y remédier, il est proposé d’utiliser .dump afin de compresser et restaurer la base sous forme de texte.

Corps de l’article

• La commande .dump exporte toute la base en texte SQL, et les index sont remplacés par une seule ligne de commande, ce qui réduit la taille du fichier.

  sqlite3 my_database.db .dump > my_database.db.txt  
  

• Le fichier texte peut être davantage réduit avec une compression gzip :

  sqlite3 my_database.db .dump | gzip -c > my_database.db.txt.gz  
  

• La procédure consiste alors à générer l’archive compressée sur le serveur, la copier en local, puis la restaurer :

  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  
  

• Le fichier DB d’origine passe de 3,4 Go à 1,3 Go en dump texte, puis à 240 Mo après compression gzip, soit une réduction d’environ 14×.

• Avec la méthode rsync classique, si la base change pendant le transfert, une erreur database disk image is malformed peut survenir.

• Avec le dump texte, il n’y a plus de risque de modification du contenu après le début de la copie, ce qui permet d’obtenir une sauvegarde cohérente.

Conclusion

• La combinaison .dump + compression + restauration améliore à la fois la vitesse et la fiabilité lors du transfert de grosses bases SQLite.
• Cette approche est particulièrement efficace pour les bases riches en index et réduit les risques d’échec de transfert ou de corruption.
• Si vous manipulez souvent de grosses bases SQLite, c’est une optimisation pratique qui mérite d’être adoptée.

[ng0301]

Je suis curieux de connaître le contexte qui rend ce type de tâche nécessaire.

[winterjung]

L’article original précise que c’est pour la sauvegarde et l’analyse. J’imagine qu’il s’agissait sans doute d’analyser ça en local avec quelque chose comme duckdb.