Comment sauvegarder un conteneur Docker SQLite (2026)
Vous voulez une sauvegarde SQLite qui se restaure vraiment ? Dumpez-la avec `sqlite3 /data/app.db ".backup '/tmp/app-backup.db'"` depuis l'intérieur du conteneur au lieu de copier /data/app.db. l'API de sauvegarde en ligne de SQLite (sqlite3 ".backup" ou VACUUM INTO) lit une copie cohérente qui respecte le WAL et les transactions en cours, ce qu'une copie brute de fichier ne peut pas faire. Dockstash confie ensuite le dump à restic pour des instantanés chiffrés, dédupliqués et hors site.
Ce que Dockstash détecte
| Clés d'environnement détectées | DATABASE_PATH, DATABASE_URL, DB_PATH |
|---|---|
| Port par défaut | — |
| Chemins de données vivants (jamais copiés à chaud) | /data/app.db, /data/app.db-wal, /data/app.db-shm |
| Exemples d'images | embedded (no dedicated image), alpine + sqlite, app images bundling sqlite |
Sauvegarder SQLite avec Dockstash, étape par étape
Créez votre compte Dockstash et ouvrez le tableau de bord
Inscrivez-vous gratuitement sur app.dockstash.com/register. L'assistant de configuration unique vous demande votre VPS de stockage (la machine qui hébergera les sauvegardes chiffrées) et génère un mot de passe de chiffrement — enregistrez-le immédiatement dans un gestionnaire de mots de passe, il n'est affiché qu'une seule fois.
Ajoutez le projet Docker qui embarque SQLite
Sur l'écran Projects, Dockstash détecte automatiquement chaque dossier de projet Compose du serveur (par défaut sous /var/www). Choisissez le projet dont l'application stocke ses données dans un fichier SQLite — PocketBase, Vaultwarden, Uptime Kuma, Gitea et Ghost le font tous. Rien n'est encore sauvegardé — vous indiquez simplement à Dockstash où vit le projet.
Vérifiez que SQLite a bien été détecté
Ouvrez le projet et regardez l'onglet Plan. SQLite n'a pas de conteneur dédié — il vit dans l'image de votre application — donc Dockstash le repère via les clés d'environnement qui pointent vers le fichier de base (DATABASE_PATH, DATABASE_URL, DB_PATH) et ajoute une couche base de données qui le snapshotte avec l'API de sauvegarde en ligne. Vous pouvez activer ou désactiver fichiers, bases et configs de proxy avant d'enregistrer.
Optionnel : testez la sauvegarde à la main
Si vous voulez une preuve avant d'automatiser, lancez la même commande que Dockstash : sqlite3 /data/app.db ".backup '/tmp/app-backup.db'" dans le conteneur applicatif. Elle n'affiche rien en cas de succès et laisse une copie complète et cohérente dans /tmp/app-backup.db — contenu du WAL inclus. C'est cette copie qui est sauvegardée, jamais le fichier .db vivant.
docker exec <app-container> sqlite3 /data/app.db ".backup '/tmp/app-backup.db'"Confirmez votre destination de stockage
Les sauvegardes sont stockées sous forme d'instantanés restic chiffrés sur votre propre VPS de stockage, via SSH. Si vous avez terminé l'assistant de configuration, c'est déjà en place ; vous pouvez changer l'hôte, l'utilisateur, le port ou la clé SSH à tout moment dans Settings → Storage.
Définissez une planification de sauvegarde
Dans l'onglet Schedule du projet, choisissez quotidien, hebdomadaire ou une expression cron personnalisée (validée en direct). Un passage quotidien à une heure creuse est le bon défaut pour la plupart des applications adossées à SQLite. Ajoutez une planification de prune hebdomadaire avec votre politique de rétention.
Lancez la première sauvegarde maintenant
Cliquez sur Backup Now sur la carte du projet. Dockstash exécute la commande .backup dans le conteneur applicatif pour produire une copie cohérente de la base, puis envoie cette copie — avec les fichiers du projet — dans restic. Vous pouvez suivre la sortie restic en direct dans le panneau de logs.
Confirmez que l'instantané existe
À la fin de l'exécution, la carte du projet affiche la nouvelle date de dernière sauvegarde, le nombre d'instantanés et la taille du dépôt. Ouvrez l'écran Snapshots : le point de restauration apparaît dans la chronologie — c'est votre preuve que la sauvegarde est bien arrivée hors site.
La commande de dump
sqlite3 /data/app.db ".backup '/tmp/app-backup.db'"La commande de restauration
copy the .backup file into place while the app is stopped, or use .restorel'API de sauvegarde en ligne de SQLite (sqlite3 ".backup" ou VACUUM INTO) lit une copie cohérente qui respecte le WAL et les transactions en cours, ce qu'une copie brute de fichier ne peut pas faire.
Restaurer une sauvegarde SQLite et prouver qu'elle fonctionne
Une sauvegarde SQLite ne devient réelle qu'une fois restaurée. Les restaurations Dockstash n'écrasent jamais votre base vivante par défaut — vous restaurez d'abord vers un emplacement neuf, vous vérifiez les données, puis vous promouvez délibérément.
Choisissez un point de restauration
Ouvrez Snapshots, sélectionnez le projet et parcourez la chronologie des points de restauration. Chaque ligne contient une copie mono-fichier cohérente de la base — produite via l'API de sauvegarde en ligne, donc sans sidecars -wal ni -shm à réconcilier — plus les fichiers du projet capturés lors de la même exécution.
Restaurez vers un nouvel emplacement
Cliquez sur Restore et gardez le mode par défaut « Restore to new location ». Tapez le nom du projet pour confirmer — une action délibérée à confirmation saisie. La copie de la base et les fichiers atterrissent dans le chemin cible de votre choix, sans toucher au projet vivant.
Vérifiez les données restaurées
Lancez sqlite3 <fichier-restauré> "PRAGMA integrity_check;" — une base saine répond un unique « ok ». Ouvrez ensuite le fichier avec sqlite3 et sondez les tables dont dépend votre application : comptage de lignes et enregistrements récents sont le test de vérité le plus rapide.
docker exec <app-container> sqlite3 /tmp/app-backup.db "PRAGMA integrity_check;"Promouvez une fois satisfait
Quand les données restaurées sont validées, arrêtez l'application, remplacez son fichier de base par la copie restaurée et redémarrez (ou répétez la restauration en mode « Overwrite existing » — un opt-in explicite). Mieux : laissez l'exercice de restauration hebdomadaire produire cette preuve automatiquement.
Pièges à éviter
- Ne copiez jamais un fichier .db vivant pendant que l'application tourne en mode WAL — vous manquerez les sidecars -wal/-shm et capturerez une base déchirée, irrécupérable.
- Utilisez sqlite3 ".backup" ou « VACUUM INTO », qui passent tous deux par l'API de sauvegarde en ligne et gèrent correctement le WAL.
- Un checkpoint (PRAGMA wal_checkpoint(TRUNCATE)) avant une copie brute ne remplace pas l'API de sauvegarde sous écritures concurrentes.
Problèmes courants de sauvegarde SQLite
- Symptôme
- La base restaurée s'ouvre mais les lignes les plus récentes manquent.
- Cause
- La sauvegarde était une copie brute du seul fichier .db pendant que l'application tournait en mode WAL — les écritures les plus récentes étaient encore dans le sidecar -wal et n'ont jamais rejoint la copie.
- Correctif
- Ne copiez jamais à cru une base WAL vivante. Utilisez sqlite3 ".backup" ou VACUUM INTO, qui passent par l'API de sauvegarde en ligne et replient le WAL dans la copie. Dockstash utilise l'API de sauvegarde précisément pour cela.
- Symptôme
- La commande .backup échoue avec « database is locked ».
- Cause
- Une transaction d'écriture longue (ou un writer bloqué) détient le verrou de la base, et sqlite3 a abandonné avant sa libération.
- Correctif
- Définissez un busy timeout (sqlite3 -cmd ".timeout 30000" ou PRAGMA busy_timeout) pour que la sauvegarde attende au lieu d'échouer, et planifiez les sauvegardes à une heure creuse. Si le verrou ne se libère jamais, cherchez un processus writer bloqué dans le conteneur.
- Symptôme
- PRAGMA integrity_check sur un fichier copié répond « database disk image is malformed ».
- Cause
- Le fichier a été copié pendant que l'application y écrivait — une capture de page déchirée qu'aucun outil de réparation ne corrige de façon fiable.
- Correctif
- Jetez la copie déchirée et restaurez depuis un instantané produit par l'API de sauvegarde. Chaque instantané Dockstash est pris avec ".backup" : integrity_check doit répondre « ok » — c'est exactement ce que vérifie l'étape de vérification.
- Symptôme
- Vous avez lancé PRAGMA wal_checkpoint(TRUNCATE) avant une copie brute, mais la copie reste incohérente.
- Cause
- Un checkpoint replie les pages WAL dans le fichier principal à un instant donné, mais des writers peuvent ajouter de nouvelles trames WAL dès qu'il se termine — checkpoint puis cp n'est pas un instantané atomique sous écritures concurrentes.
- Correctif
- Considérez « checkpoint puis copie » comme une idée reçue, pas une technique. Le seul instantané sûr à chaud est l'API de sauvegarde en ligne (".backup" ou VACUUM INTO) ; la copie brute n'est sûre qu'application arrêtée.
Faites-le en un clic avec Dockstash
Dockstash exécute exactement le dump ci-dessus, le confie à restic hors site et teste la restauration par un drill automatiquement — aucun script à maintenir.
Dernière mise à jour : July 2026
Questions fréquentes
Puis-je simplement copier le fichier .db ?
Pas en sécurité pendant que l'application écrit. En mode WAL, les données les plus récentes vivent dans le sidecar -wal ; un simple cp du seul .db capture un état périmé et déchiré. Utilisez sqlite3 ".backup" ou « VACUUM INTO », qui lisent une copie cohérente via l'API de sauvegarde en ligne.
Qu'est-ce que VACUUM INTO ?
VACUUM INTO 'file.db' écrit une copie fraîche, défragmentée et transactionnellement cohérente de la base dans un nouveau fichier. C'est une façon propre de snapshoter une base SQLite vivante sans arrêter l'application.
Dois-je sauvegarder les fichiers -wal et -shm ?
Avec l'API de sauvegarde, non — elle consolide le WAL dans la copie. Si vous tenez à une copie brute (déconseillée à chaud), il faut inclure -wal et -shm, et cela reste sujet aux courses.
Comment restaurer une sauvegarde SQLite ?
Arrêtez l'application, remplacez le fichier de base par la sortie de .backup, puis redémarrez. La sauvegarde étant un fichier unique cohérent, il n'y a aucun sidecar à réconcilier.
Mon application embarque SQLite (PocketBase, Vaultwarden, Uptime Kuma) — Dockstash la trouvera-t-il ?
Oui. Il n'y a pas de conteneur SQLite séparé à repérer : Dockstash lit la config compose et les clés d'environnement de l'application (DATABASE_PATH, DATABASE_URL, DB_PATH) pour localiser le fichier, puis le snapshotte via l'API de sauvegarde. Vérifiez le chemin détecté dans l'onglet Plan avant la première exécution.
À quelle fréquence sauvegarder SQLite ?
Quotidien est le bon défaut pour la plupart des applications mono-fichier ; horaire si perdre une journée d'écritures est inacceptable. Sur l'offre Free, les sauvegardes sont manuelles (Backup Now) ; Pro autorise jusqu'à l'horaire, Business n'importe quelle expression cron.
Où vivent réellement les sauvegardes ?
Sur votre propre VPS de stockage, sous forme d'instantanés restic chiffrés poussés via SSH. Dockstash ne garde jamais vos données sur un cloud tiers — vous le pointez vers une machine que vous contrôlez, et le dépôt est chiffré avec un mot de passe que vous seul détenez.
Comment savoir que la sauvegarde est restaurable sans restauration manuelle ?
Planifiez un exercice de restauration. Dockstash restaure le dernier instantané dans un espace de travail isolé, compare chaque fichier par empreinte d'octets avec la source et vérifie la base restaurée — puis appose un badge réussite/échec sur le projet. Un exercice hebdomadaire vous garantit une preuve toujours fraîche.