Bit rot, часть вторая

Отдеплоили сегодня утром заведомо работающую базу данных Firebird одному клиенту.
В 2 часа мониторинг внезапно взвывает - "ошибка в логе сервера БД, повреждение данных".
Начинаю втыкать - ну да, одна из таблиц при чтении определенной записи вызывает исключение вида "decompression overran buffer", бэкап не проходит. Забираю копию файла БД себе, у клиента чиню стандартными средствами firebird (gfix -mend, затем бекап-ресторе). Благо, запись эта не особо нужная и я ее восстановить могу - gfix -mend такие записи помечает как ошибочные и бэкап их игнорирует.

Поскольку я в отпуске и спешить мне некуда, у меня есть эталонная работающая копия базы до ошибки, сами данные в базе почти целиком append-only и база очень мелкого размера - решаю разобраться, что ж все-таки за херня-то произошла (такие ошибки за последние лет 10 несколько раз встречались у разных клиентов).
Читаю описание формата файла бд: http://www.firebirdsql.org/manual/fb-internals.html

Нахожу с помощью запроса вида select rdb$db_key, убитая_таблица.* from убитая_таблица where (фильтр для пропуска битой записи) расположение записей по страницам бд. rdb$db_key состоит(на данный момент) из номера страницы и номера записи на странице.
Затем начинаю копаться в структурах собственно файла - нахожу страницу указателей на страницы таблицы БД, нахожу реальный номер и адрес нужной страницы, достаю страницу из хорошей и плохой БД и сравниваю.
Зашибись - в плохой БД ровно один бит в записи вместо 0 установлен в 1, что вырывает мозги RLE упаковке записей, вызывая ошибку сервера. Меняю его руками на 0, читаю запросом, делаю бэкап - все работает, база исправлена.

Вывод: ставьте память с ECC, а бытовое железо не ставьте. Второй раз за этот год сгнивают биты в файлах на пустом месте.
Надо, может, еще авторов FB попросить, чтобы адрес страницы и записи сразу в лог писали в сообщении об ошибке, возможно, в части подобных случаев быстрее будет руками починить, чем gfix по всей базе в десятки гиг размером делать.