«Невозможная» порча базы может прятаться ниже вашего приложения

Если резервная копия не проходит проверку целостности, а логи приложения не показывают причину, привычный путь диагностики обрывается. Именно так Tailscale полгода искала источник порчи SQLite-баз в своём контуре управления: 19 случаев без закономерности и возможности повторить сбой по запросу.

Условия выглядели безопасно: к базе каждого шарда обращался один Go-процесс, полные снимки каждые несколько минут уходили в S3. Причина всё же оказалась в SQLite: ошибка жила там не менее 16 лет.

Для Java-команд этот кейс полезен как методика расследования сбоев, которые документация считает невозможными. В разборе на DEV Community остались ход поиска и чек-лист для Spring Boot с Postgres, MySQL или SQLite.