📍 Article principal : Litestream/Turso 2026 : guide complet.
Trente minutes pour transformer SQLite local en base répliquée continue vers S3. Recovery point < 1 seconde. Méthode validée chez startups francophones.
Prérequis
- VPS Linux avec app utilisant SQLite.
- Bucket S3-compatible (Backblaze B2, MinIO, AWS).
- Niveau : intermédiaire.
- Temps : 30-45 min.
Étape 1 — Installer Litestream
wget https://github.com/benbjohnson/litestream/releases/latest/download/litestream-linux-amd64.deb
dpkg -i litestream-linux-amd64.deb
litestream version
Étape 2 — Activer WAL mode SQLite
sqlite3 /srv/app/app.db
PRAGMA journal_mode=WAL;
PRAGMA wal_autocheckpoint=1000;
PRAGMA synchronous=NORMAL;
.exit
WAL mode obligatoire pour Litestream.
Étape 3 — Configuration Litestream
nano /etc/litestream.yml
access-key-id: YOUR_B2_KEY_ID
secret-access-key: YOUR_B2_APPLICATION_KEY
dbs:
- path: /srv/app/app.db
replicas:
- type: s3
bucket: app-litestream-backup
endpoint: s3.eu-central-003.backblazeb2.com
path: prod/app
region: eu-central-003
retention: 720h # 30 jours
snapshot-interval: 1h
sync-interval: 1s
Étape 4 — Activer service systemd
systemctl enable litestream
systemctl start litestream
systemctl status litestream
journalctl -u litestream -f
Étape 5 — Vérifier réplication
litestream replicas /srv/app/app.db
litestream snapshots /srv/app/app.db
Étape 6 — Test write
sqlite3 /srv/app/app.db "INSERT INTO users (email) VALUES ('test@example.com')"
# Litestream sync vers B2 dans 1 seconde
sleep 2
litestream snapshots /srv/app/app.db
# Voir nouveau snapshot
Étape 7 — Restore depuis S3
Simulation crash : supprimer DB, restaurer depuis B2 :
rm /srv/app/app.db /srv/app/app.db-shm /srv/app/app.db-wal
litestream restore /srv/app/app.db
# Restauration depuis B2 dernier snapshot + WAL
sqlite3 /srv/app/app.db "SELECT * FROM users"
# Données récupérées
Étape 8 — Recovery to point in time
litestream restore -timestamp 2026-04-27T10:00:00Z /srv/app/app.db
# Restaure état à un instant T précis
Étape 9 — Monitoring
litestream replicas /srv/app/app.db -json | jq
Endpoint Prometheus pour Grafana : --exec metrics.
Étape 10 — Multi-DB
Configurer plusieurs bases dans litestream.yml :
dbs:
- path: /srv/app/users.db
replicas: [...]
- path: /srv/app/sessions.db
replicas: [...]
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| « database is locked » | WAL pas activé | PRAGMA journal_mode=WAL |
| S3 401 unauthorized | Keys mal configurées | Régénérer B2 application key |
| Snapshot manqué | Service down | systemctl status + journalctl |
| Disk plein | WAL accumule | wal_autocheckpoint=1000 |
| Restore vide | DB pas répliquée | Vérifier replicas list |
| Performance dégradée | fsync agressif | synchronous=NORMAL |
Adaptation au contexte ouest-africain
Trois précisions. B2 Eu-Central-003 : 90 ms vers Afrique Ouest acceptable. Coût : 1 GB DB = 0,006 USD/mois B2. Bandwidth : sync continu utilise ~10 KB/s. Négligeable.
Tutoriels frères
FAQ
Multi-writer ? Non. Single-writer. Pour multi-writer, Turso ou Postgres.
Latence sync ? 1 seconde par défaut, configurable.
S3 alternatives ? MinIO, B2, AWS, Wasabi tous compatibles.
RPO/RTO ? RPO 1s, RTO < 60s pour DB < 1 GB.
Conformité ARTCI/CDP ? B2 EU-Central, conforme.
Pour aller plus loin
- 🔝 Pilier : Guide complet 2026
- Documentation : litestream.io