Как зарезервировать Docker-контейнер SQLite (2026)
Хотите копию SQLite, которая действительно восстановится? Снимите дамп командой `sqlite3 /data/app.db ".backup '/tmp/app-backup.db'"` изнутри контейнера вместо копирования /data/app.db. онлайн-API резервного копирования SQLite (sqlite3 ".backup" или VACUUM INTO) читает согласованную копию, уважающую WAL и активные транзакции, — сырая копия файла этого не может. Затем Dockstash передаёт дамп restic для зашифрованных, дедуплицированных внешних снимков.
Что находит Dockstash
| Найденные переменные окружения | DATABASE_PATH, DATABASE_URL, DB_PATH |
|---|---|
| Порт по умолчанию | — |
| Живые пути данных (никогда не копируются вживую) | /data/app.db, /data/app.db-wal, /data/app.db-shm |
| Примеры образов | embedded (no dedicated image), alpine + sqlite, app images bundling sqlite |
Резервируем SQLite с Dockstash, шаг за шагом
Создайте аккаунт Dockstash и откройте панель
Зарегистрируйтесь бесплатно на app.dockstash.com/register. Одноразовый мастер настройки спросит ваш VPS для хранения (машину, где будут лежать зашифрованные резервные копии) и сгенерирует пароль шифрования — сразу сохраните его в менеджере паролей: он показывается ровно один раз.
Добавьте Docker-проект со встроенным SQLite
На экране Projects Dockstash автоматически находит каждую папку Compose-проекта (по умолчанию под /var/www). Выберите проект, чьё приложение хранит данные в файле SQLite — так делают PocketBase, Vaultwarden, Uptime Kuma, Gitea и Ghost. Пока ничего не резервируется.
Проверьте, что SQLite распознан
Откройте проект и вкладку Plan. У SQLite нет своего контейнера — он живёт в образе приложения — поэтому Dockstash находит его по переменным окружения, указывающим на файл базы (DATABASE_PATH, DATABASE_URL, DB_PATH), и добавляет слой, снимающий его через онлайн-API резервного копирования. Файлы, базы и конфиги прокси можно переключать перед сохранением.
Опционально: проверьте копию вручную
Если хотите доказательство до автоматизации, выполните ту же команду: sqlite3 /data/app.db ".backup '/tmp/app-backup.db'" в контейнере приложения. При успехе она ничего не печатает и оставляет полную согласованную копию в /tmp/app-backup.db — вместе с содержимым WAL. Эта копия и резервируется, никогда не живой файл .db.
docker exec <app-container> sqlite3 /data/app.db ".backup '/tmp/app-backup.db'"Подтвердите место хранения
Резервные копии хранятся как зашифрованные снимки restic на вашем собственном VPS для хранения, по SSH. Если вы прошли мастер настройки, всё уже настроено; хост, пользователя, порт или SSH-ключ можно изменить в любой момент в Settings → Storage.
Настройте расписание резервного копирования
Во вкладке Schedule выберите ежедневно, еженедельно или собственный cron (валидируется при вводе). Ежедневно в тихий час — правильное умолчание для большинства приложений на SQLite. Добавьте еженедельный prune с политикой хранения.
Запустите первую копию сейчас
Нажмите Backup Now. Dockstash выполнит команду .backup в контейнере приложения, получит согласованную копию базы и отправит её — вместе с файлами проекта — в restic. Живой вывод смотрите в панели логов.
Убедитесь, что снимок существует
По завершении запуска карточка проекта показывает новое время последней копии, число снимков и размер репозитория. Откройте экран Snapshots: точка восстановления появится на таймлайне — это ваше доказательство, что копия дошла до внешнего хранилища.
Команда дампа
sqlite3 /data/app.db ".backup '/tmp/app-backup.db'"Команда восстановления
copy the .backup file into place while the app is stopped, or use .restoreонлайн-API резервного копирования SQLite (sqlite3 ".backup" или VACUUM INTO) читает согласованную копию, уважающую WAL и активные транзакции, — сырая копия файла этого не может.
Восстановите копию SQLite и докажите, что она работает
Резервная копия SQLite становится настоящей только после восстановления. Восстановления Dockstash по умолчанию не перезаписывают живую базу — сначала в новое место, проверка, затем осознанное продвижение.
Выберите точку восстановления
Откройте Snapshots, выберите проект и просмотрите таймлайн. Каждая строка содержит согласованную однофайловую копию базы — созданную через онлайн-API, значит без сайдкаров -wal и -shm — плюс файлы проекта того же запуска.
Восстановите в новое место
Нажмите Restore и оставьте режим по умолчанию «Restore to new location». Введите имя проекта для подтверждения — осознанное действие с набором текста. Дамп и файлы попадут в выбранный целевой путь, не трогая живой проект.
Проверьте восстановленные данные
Выполните sqlite3 <восстановленный-файл> "PRAGMA integrity_check;" — здоровая база отвечает единственным «ok». Затем откройте файл в sqlite3 и выборочно проверьте таблицы приложения: счётчики строк и свежие записи — самый быстрый тест.
docker exec <app-container> sqlite3 /tmp/app-backup.db "PRAGMA integrity_check;"Продвигайте, когда всё проверено
Когда данные проверены: остановите приложение, замените его файл базы восстановленной копией и запустите снова (или повторите восстановление в режиме «Overwrite existing» — явный опт-ин). Ещё лучше: пусть еженедельная тренировка делает это доказательство автоматически.
Каких ловушек избегать
- Никогда не копируйте живой файл .db при работе в WAL-режиме — вы потеряете сайдкары -wal/-shm и получите порванную, невосстановимую базу.
- Используйте sqlite3 ".backup" или «VACUUM INTO» — оба идут через онлайн-API и корректно обращаются с WAL.
- Чекпоинт (PRAGMA wal_checkpoint(TRUNCATE)) перед сырой копией не заменяет API при конкурентной записи.
Типичные проблемы резервирования SQLite
- Симптом
- Восстановленная база открывается, но свежайших строк нет.
- Причина
- Копия была сырой и только файла .db, пока приложение работало в WAL-режиме — новейшие записи сидели в сайдкаре -wal и в копию не попали.
- Решение
- Никогда не копируйте живую WAL-базу сырьём. Используйте sqlite3 ".backup" или VACUUM INTO — они идут через онлайн-API и вкладывают WAL в копию. Dockstash использует именно этот API.
- Симптом
- Команда .backup падает с «database is locked».
- Причина
- Длинная транзакция записи (или зависший писатель) держит блокировку, и sqlite3 сдался до её освобождения.
- Решение
- Задайте busy timeout (sqlite3 -cmd ".timeout 30000" или PRAGMA busy_timeout), чтобы копия ждала вместо падения, и планируйте копии на тихий час. Если блокировка не уходит — ищите зависший процесс-писатель в контейнере.
- Симптом
- PRAGMA integrity_check на скопированном файле отвечает «database disk image is malformed».
- Причина
- Файл скопировали, пока приложение в него писало — порванный захват страницы, который надёжно не чинится.
- Решение
- Выбросьте порванную копию и восстановитесь из снимка, созданного API. Каждый снимок Dockstash снят через ".backup": integrity_check должен ответить «ok» — именно это проверяет шаг верификации.
- Симптом
- Вы выполнили PRAGMA wal_checkpoint(TRUNCATE) перед сырой копией, но копия всё равно несогласована.
- Причина
- Чекпоинт вкладывает страницы WAL в основной файл в один момент, но писатели могут добавить новые WAL-фреймы сразу после — «чекпоинт, потом cp» не атомарный снимок при конкурентной записи.
- Решение
- Считайте «чекпоинт и копию» заблуждением, а не техникой. Единственный безопасный живой снимок — онлайн-API (".backup" или VACUUM INTO); сырая копия безопасна только при остановленном приложении.
Сделайте это в один клик с Dockstash
Dockstash выполняет ровно тот дамп, что выше, передаёт его restic вовне и автоматически проверяет восстановление тренировкой — без скриптов на поддержке.
Последнее обновление: July 2026
Часто задаваемые вопросы
Нельзя ли просто скопировать файл .db?
Небезопасно, пока приложение пишет. В WAL-режиме свежайшие данные живут в сайдкаре -wal; простой cp одного .db захватывает устаревшее, порванное состояние. Используйте sqlite3 ".backup" или «VACUUM INTO».
Что такое VACUUM INTO?
VACUUM INTO 'file.db' пишет свежую, дефрагментированную, транзакционно согласованную копию базы в новый файл. Чистый способ снять живую базу SQLite, не останавливая приложение.
Нужно ли резервировать файлы -wal и -shm?
С API — нет: он консолидирует WAL в копию. Если настаиваете на сырой копии (не рекомендуется вживую), включайте -wal и -shm — и всё равно останутся гонки.
Как восстановить копию SQLite?
Остановите приложение, замените файл базы выводом .backup и запустите. Копия — один согласованный файл: сайдкаров для сверки нет.
Моё приложение включает SQLite (PocketBase, Vaultwarden, Uptime Kuma) — найдёт ли его Dockstash?
Да. Отдельного контейнера SQLite нет: Dockstash читает compose-конфиг и переменные приложения (DATABASE_PATH, DATABASE_URL, DB_PATH), находит файл и снимает его через API. Перед первым запуском проверьте найденный путь во вкладке Plan.
Как часто резервировать SQLite?
Ежедневно — практичное умолчание для однофайловых приложений; ежечасно — если потеря дня записей недопустима. На Free копии вручную (Backup Now); Pro — до ежечасных, Business — любой cron.
Где на самом деле живут резервные копии?
На вашем собственном VPS для хранения, как зашифрованные снимки restic, отправляемые по SSH. Dockstash никогда не держит ваши данные в чужом облаке — вы указываете машину под вашим контролем, а репозиторий зашифрован паролем, который есть только у вас.
Как узнать, что копия восстановима, без ручного восстановления?
Запланируйте тренировку восстановления. Dockstash восстанавливает последний снимок в изолированную рабочую область, сверяет каждый файл по байтам с источником и проверяет восстановленный дамп — затем ставит на проект значок «прошло/провалено». Еженедельная тренировка означает всегда свежее доказательство.