Восстановление убитого кэша Беркли (BerkeleyDB)

[zed]

Имеджери работает

Не факт, что так будет и дальше.

а Ях так и не хочет

Указанный файл удаляли? Приведите содержимое папки env или даже выложите её на обменник.

[Gma]

И ещё. сейчас заметил, что куда-то делись несколько уровней карты. Вот список существующих:
env\
z10\
z11\
z12\
z13\
z16\
z17\

[Gma]

Указанный файл удаляли?

да, всё сделал по рецепту.

Приведите содержимое папки env

__db.register
DB_CONFIG
__db.001
__db.002
__db.003
__db.004
__db.005
__db.006
log.0000000001

выложите её на обменник.

http://progressor.ru/gm/book/env.zip

[zed]

куда-то делись несколько уровней карты

Может их и небыло. Может вы что-то перепутали. А может их вам по-удалял злобный вирус, а в логах осталась запись, вот кэш и не стартует. Ищите проблему на своей стороне.

[zed]

Проблема в отсутствии sdb файлов в кэше. В логе есть ссылки на файлы z5/z6/z14 а у вас этих папок нету, вот оно и обламывается.

Плюс ко всему, файл лога создан 16.09.2013 и в нём не более 2 Мб данных. Поскольку порядковый номер у файла log.0000000001 то очевидно, других файлов небыло и в кэш ничего больше не писалось. К тому же, последняя запись в логе датирована также 2013 годом:

Код: Выделить всё

Mon Sep 16 22:25:18 2013

Что-то вы у себя намудрили и я вам тут не помогу, потому как восстанавливать тут попросту нечего. Или лог не от этого кэша или одно из двух.

[zed]

Обновил утилиту sdb_util:
- вроде исправил баги;
- добавил настройки логирования в файл (None - не сохранять, Normal - по мере заполнения лога в памяти или в конце проверки, Extreme - при выводе каждой строчки в лог на экран, она сперва сохраняется в файл);
- добавил опцию, чтобы лог не перезаписывался, а дописывался;
- добавил опцию ограничения на размер лога в памяти (который в чёрное окошко пишется);
- добавил ключ командной строки --autostart для автозапуска проверки при старте программы;
- добавил кэширование результатов проверки, чтобы не перепроверять файлы, не изменившиеся с прошлой проверки (требует sqlite3.dll);
- сделал отдельную утилиту sdb_info.exe для просмотра статистики (см скриншот).

Архив пока что с приставкой *_test, жду отзывы по результатам тестирования: https://bitbucket.org/zedxxx/sdb_util/d ... 3_test.zip

Image 1.png

Спонсор этого масштабного обновления - пользователь sergbrother, большое ему спасибо.

[T_Im]

Столкнулся с битым кешем. Восстановить с ходу не удалось, пришлось разбираться с логикой работы утилит. Это конспект опыта, соображений и найденных в работе утилит баго-фич.

Простой кейс: файл 616.316.sdb.bad ~200М, тип ошибки: "обнулился" конец базы - последние ~10% файла сплошные нули (файл по просьбе могу выложить, но такую ситуацию можно смоделировать и на меньшем файле).

Достаточно большая часть тайлов из этой базы читаются в SAS планете, и даже частично экспортируются, но периодически происходит "завис" на битых тайлах. Выделив большую область смог экспортировать ~77М тайлов, т.е. выделяя маленькие участки и экспортируя их в тайловый кеш, следуя логике повреждения, можно восстановить предположительно до 90% тайлов).

Итоги восстановления с помощью sdb_util_1.3
Выбирается вариант восстановления .bad файлов (Restore broken files from *.bad [cmd: db_dump && db_load]) поочередно тестировал все 3 возможных варианта восстановления.

а) по дефолту (без дополнительных ключей в настройках).
Процесс происходит без ошибок. Казалось бы можно радоваться, но... размер файла 616.316.sdb = 11,486 М! (<6% от исходного)
Это, похоже, читает и восстанавливает базу только до первой ошибки.
Более того, файл *.sdb.bad после восстановления НАСОВСЕМ УДАЛЯЕТСЯ (особо цинично при этом читается рекомендация из шапки выкладывать .bad файлы после рекавери "если что то не работает" ).
Нельзя же так по дефолту совершать деструктивные действия, даже в SAS планете из таких бэдов можно вытянуть в разы больше тайлов!
Еще отмечу (это касается и следующего пункта рекавери), что создавать дамп - неправильно, т.к. db_dump и db_load прекрасно работают с потоками.
В итоге этот пункт стоит реализовывать следующим образом (в итоге не будем зря гонять диск, дополнительно записывая и потом считывая огромный дамп):

db_dump.exe 616.316.sdb.bad | db_load 616.316.sdb

б) salvage data (-r) спотыкается на этапе дампа:

Ошибка db_dump.exe: пямять не может быть read

Да, уже говорилось, что в версии утилит 5.1 "db_dump -r" нерабочий. Чтобы это обойти, достаточно взять db_dump.exe и libdb53.dll из версии 5.3 (можно 6.1, но не 6.3). Поскольку остальные утилиты и SAS жестко завязаны на libdb51.dll, такой финт никаких конфликтов не создаст.
Но это не помогает: видно, что создается файл 616.316.sdb.dump, но дальше происходит затык и дамп просто удаляеся! Почему не срабатывает db_load? Запись в логах:

Код: Выделить всё

db_dump.exe: 616.316.sdb.bad: DB_VERIFY_BAD: Database verification failed
<< ExitCode = 1

наталкивает на мысль, что получив ExitCode = 1 sdb_info просто прерывает восстановление, в то время как согласно документации

"If you are dumping a database known to be corrupt, you can safely ignore a DB_VERIFY_BAD error return."

Еще полученный дамп не имеет в заголовке "правильной" строчки db_pagesize=1024, однако его можно грузить без редактирования заголовка задав pagesize вручную. Итого правильно было бы так:

Код: Выделить всё

db_dump.exe -r 616.316.sdb.bad | db_load -c db_pagesize=1024 616.316.sdb

В некоторых случаях так удается создать более менее рабочую базу (на которую все равно ругается SAS), но в этот раз получился файл ~180МБ, с которым SAS не смогла работать (сыпятся ошибки и все зависает):

Код: Выделить всё

BerkeleyDB: путь\616.316.sdb: multiple databases specified but not supported by file [root path: "путь к папке с кешем"]

в) Aggressively salvage data (-R)
та же ошибка ошибочного завершения создания дампа по "ложному" коду ошибки. Но даже ее игнорирование помогло бы:

Код: Выделить всё

db_load -f 616.316.sdb.dump 616.316.sdb
db_load.exe: line 1: unexpected format

ибо при дампе с ключем -R в заголовке дампа будут лишние две строчки, из-за которых db_load не сможет воссоздать из дампа базу. Т.о. без дополнительных утилит этот пункт в принципе невозможно сделать работоспособным.
Получающаяся база, если поменять заголовок и загрузить дамп db_load, ведет себя аналогично предыдущему пункту.

Вывод: sdb_util идеально подходит для устранения мелких ошибок, но если после проверки образовались .bad файлы, нельзя использовать штатное рекавери *.bad файлов: опции, способные максимально полностью восстановить данные, не функциональны, а единственная работающая дефолтная опция чревата большой потерей данных!

Поскольку ниже найден оптимальный метод восстановления базы, рекомендуется включить его и использовать по умолчанию в sdb_util (а также добавить опцию "удалять *.bad файлы после восстановления"). Пока же рекомендуется использовать описанную ниже методику восстановления .bad файлов.

[T_Im]

Продолжаю конспект.

Как выглядит дамп?
сначала идет заголовок

скрытый текст: показать

при дампе базы без доп. ключей и с ключем -R

Код: Выделить всё

VERSION=3
format=bytevalue
database=
type=btree
db_pagesize=1024
HEADER=END

при дампе с ключем -r

Код: Выделить всё

 
 00000002
VERSION=3
format=bytevalue
type=btree
HEADER=END

Затем идут пары строчек ключ-значение.
Сравнивая дампы нормальной и битой баз сразу же становятся видны отличия и понятны причины возникновения проблем (см. вложения):

а) битые тайлы и тайлы без ключей
появляются при дампе -r/-R (в последнем варианте их существенно больше). После загрузки дампа, по всей видимости, они беспрепятственно уходят в базу, вызывая недовольство SAS. Восстановленная база не будет до конца работоспособна, только экспорт bdb-bdb, возможно, это может фиксить.

б) несколько баз внутри одного дампа (дополнительные база/базы возникают как с ключем -r, так и с ключем -R). Это причина ошибки SAS о "multiple databases" (см. выше). Если такое произошло - все тайлы из второй и последующих баз невозможно восстановить штатными средствами. В моем случае те восстановленные 11М и есть первая база (режим восстановления без ключей).
Если грузить db_load полученные с ключами -r/-R большие дампы, то эти несколько баз включаются в состав одной базы sbd, однако SAS частично может работать опять таки только с первой из них: при экспорте bdb2bdb через "управлением кэша" из полученного большого восстановленного файла sdb экспортируется только те 11М первой базы.

Теперь становится понятно как с этим бороться: из дампа надо взять все пары строк ключ-тайл, в которых лежат валидные тайлы.
Для фильтрации была написана элементарная утилитка на перле, которая фильтрует пары ключ-тайл, по следующим условиям:
- длина строки ключа = 18 (включая символ переноса строки)
- у тайла на 86-м месте стоит hex-код начала jpg-а ffd8ff
- конец строки тайла совпадает с hex-кодом конца jpg-а ffd9 (не уверен в строгости условия)
Полученный фильтрованный дамп уже можно превратить в полностью работоспособную базу db_load и вернуть в кэш.

Итог восстановления: файл 616.316.sdb
из дампа, полученного с ключем -r ~176040К
из дампа, полученного с ключем -R 177112К

[T_Im]

Заметки по результатам восстановления.

База из "-r дампа" содержит 10178 тайлов, из "-R дампа" на 64 тайла больше. Общие файлы между ними одинаковы (распаковал в файловый формат и проанализировал)

Возможные проблемы.

1) Проблема единственности.
Насколько я понимаю, db_load последовательно закидывает все встреченные пары ключ-тайл в восстанавливаемую .sdb. Т.о. если у одного ключа при чтении дампа будет встречено несколько значений, в .sdb уйдет последнее встреченное.
- может ли теоретически такое быть с дампами?
(В распакованных "-r" и "-R" кешах файлы с одинаковыми путями имеют одинаковые md5. Наличие разных тайлов с одним ключем в имеющихся дампах пока не проверял)
- может ли один и тот же тайл попасть в разные ключи? (проверил, в моих кэшах дубликаты тайлов не найдены)

2) проблема битости.
- может ли у jpg-а в дампе быть валидным начало и конец, но побиться середина? (badpeggy в распакованных кэшах их не нашла)
NB: с ключем -r в дампе нет ни одной записи тайла, где есть валидное jpg начало, но нет валидного jpg конца. Но с ключем -R в дампе уже появляются ~30 jpg "огрызков".

[T_Im]

По итогам выкладываю утилиту для очистки дампа от мусора, которая должна дополнить комплект имеющихся db_* утилит для наших нужд.

Использование

Код: Выделить всё

db_cleaner -fi файлдампа -fo файлочищенногодампа

если один или оба -fi/-fo не указаны, то чтение/запись будут происходить со STDIN/STDOUT соответственно (по аналогии db_dump/db_load).
Утилита отфильтровывает из дампа валидные jpg и png тайлы (проверяется соответствие сигнатур начала/конца файла).

Примеры использования:
очистка дампа 616.317.sdb.dump в дамп 616.317.sdb.cdump:

db_cleaner -fi 616.317.sdb.dump -fo 616.317.sdb.cdump

очистка дампа 616.317.sdb.dump с одновременной загрузкой результата в рабочую базу:

db_cleaner -fi 616.317.sdb.dump | db_load 616.317.sdb

Это должно стать основным вариантом рекавери: создаем из *.bad сразу рабочую *.sdb (тайлы плавно перетекают из битой базы в рабочую через память без промежуточных файлов на диске) :

db_dump -R 616.317.sdb.bad | db_cleaner | db_load 616.317.sdb

Пока в sdb_util не входит такой вариант рекавери, сделал кнопочку для атоматизации процесса восстановления в Total Commander

скрытый текст: показать

положить файл db_ClearRebuild.bat (и db_cleaner.exe !) из архива в папку sdb_util, скопировать следующий код (поправить в 2-х местах путь к папке sdb_util на свой)

Код: Выделить всё

TOTALCMD#BAR#DATA
d:\sdb_util_13\db_ClearRebuild.bat
"%P%O.%E" "%P%O"
shell32.dll,65
Построить базу *.sbd на основе файла *.bad под курсором
d:\sdb_util_13\

-1

Теперь, если поместить курсор на .bad файл и нажать кнопку, будет создан восстановленный файл .sdb

PS. Поправил предыдущие сообщения с учетом всей новой информации.