SQLite: database disk image is malformed

#Что означает ошибка

Ошибка SQLite «database disk image is malformed» говорит о повреждении файла базы: сбой питания во время записи, копирование открытой базы без WAL-файлов, проблемы диска или сетевой файловой системы, одновременная запись несколькими процессами.

Первым делом остановите приложение и скопируйте файл вместе с -wal и -shm.

Работайте с копией.

Файл базы повреждён: сбой диска, прерванная запись или копирование во время работы. Попробуйте .recover или восстановление из копии.

#Причины и решения

#Пошаговое решение

1. Остановите приложениеЭто потенциальная потеря данных. Сначала остановите приложение штатно (для веб-сервиса согласуйте короткое обслуживание и прекращение запросов на запись), убедитесь, что ни один процесс не использует базу; не удаляйте -wal/-shm. Создайте отдельную резервную копию всех имеющихся файлов app.db, app.db-wal, app.db-shm с сохранением их имён и времени, если они присутствуют. Для работающей исправной базы правильнее штатный .backup, но при повреждении отдельная неизменяемая копия исходного набора нужна до любых попыток восстановления. Проверьте свободное место и скопируйте набор на другой исправный носитель.
2. Выполните PRAGMA integrity_checkРаботайте только с копией. В терминале установите штатную утилиту sqlite3 из доверенного источника и запустите sqlite3 /путь/к/копии/app.db 'PRAGMA integrity_check;', подставив реальный путь. ok — проверка структуры пройдена на выбранном снимке; любые строки с повреждениями означают, что простое исправление файлов «вслепую» недопустимо. Проверьте, не подключились ли вы к пустой, автоматически созданной базе из-за неверного пути; для открытия копии можно сначала убедиться в ls -l и сравнить размер.
3. Выгрузите данные .recoverЕсли проверка сообщает повреждения, сначала поищите целую резервную копию и сравните её дату с нужным восстановлением. Если её нет, на рабочем снимке примените .recover (нужна поддерживающая команда версия sqlite3): sqlite3 /путь/к/копии/app.db '.recover' > recovered.sql. Затем создайте новую базу в другом каталоге: sqlite3 recovered.db < recovered.sql. Не выполняйте команды поверх исходной базы. .recover пытается извлечь данные, но может восстановить не всё, вернуть удалённые строки или нарушить связи; сохраните SQL и журнал ошибок для последующего анализа.
4. Проверьте количество записейДля новой восстановленной базы выполните sqlite3 recovered.db 'PRAGMA integrity_check;' и проверьте список таблиц ('.tables'), основные количества строк и контрольные отчёты приложения. Сравните с последней известной целой копией, проверьте внешние ключи через PRAGMA foreign_key_check; и бизнес-данные; даже ok не гарантирует полноту восстановления. Не подменяйте рабочий файл, пока владелец данных не примет потери и пока не проверены связанные индексы/триггеры и функции приложения.
5. Включите WAL и резервные копииПричину повреждения ищите отдельно: нехватка места, отказы диска, копирование живой базы без согласованного снимка, неподходящая файловая система/сетевой диск. Для исправной базы настройте регулярные резервные копии через встроенную команду sqlite3 .backup '/путь/к/backup.db' с учётом прав и свободного места. WAL — способ журналирования, а не средство лечения уже повреждённой базы; PRAGMA journal_mode=WAL не выполняйте как ремонтную команду. После согласованного восстановления перезапустите приложение и проверьте тестовую запись.
6. При наличии WAL файл базы, -wal, -shm копируются согласованно

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   При наличии WAL файл базы, -wal, -shm копируются согласованно. .recover может потерять или восстановить ранее удалённые данные; использовать только после поиска целой резервной копии.

   # После прекращения работы приложения, ТОЛЬКО НА КОПИИ базы

   sqlite3 /путь/к/копии/app.db 'PRAGMA integrity_check;'

   sqlite3 /путь/к/копии/app.db '.recover' > recovered.sql

   # Создаёт новую базу в отдельной папке, не перезаписывать существующую

   sqlite3 recovered.db < recovered.sql

#Проверка

Запускайте PRAGMA integrity_check на согласованном снимке базы, а не на случайно найденном data.db. Сообщение ok — успешная структурная проверка текущего снимка, не гарантия полноты данных. При подозрении на отказ диска остановите запись и диагностику носителя поручите системному администратору.

#Восстановление

Лучший исход — восстановление из последней проверенной целой резервной копии. Если её нет, используйте .recover только на отдельном снимке, сохраняйте SQL и создавайте новый файл БД; проверяйте целостность, внешние ключи и важные данные. Ни .recover, ни .dump, ни REINDEX не гарантируют восстановление повреждённых данных, а REINDEX применим только при подтверждённой проблеме индекса.

#Профилактика

После восстановления исправьте причину повреждения и настройте регулярное резервирование через SQLite Backup API или команду .backup. WAL может помогать при конкурентном чтении/записи, но не восстанавливает повреждённую базу. Не меняйте journal_mode или synchronous в качестве ремонта; это отдельные настройки с компромиссами по надёжности и производительности.