7 ответов в этой теме

[Jorik]

Здравствуйте!

Прошу помощи в исправдении БД сервера DrWeb ESS в среде Astra Linux SE 1.6.

С сервером, на котором крутился DrWeb ESS 13, произошел сбой, аварийно выключился.

В результате побилась БД Sqlite3.

Сервер drwcsd вручную стартует, но порты веб-интерфейса (8090, 8091) не появляются.

В логах обнаружил запись:

...ERR SqLite3/1 Unable to repair database because of Unable to repair database image "/var/opt/drwcs/database.sqlite" because of unable to compile temporary database statement <CREATE TABLE sqlite_sequence(name,seq)> because of table sqlite_sequence already exists (code1)

 

Если я правильно понимаю, то пока не удастся починить SqLite3, сервер не запустится.

Проблема усугубляется еще и тем, что резервное копирование БД по умолчанию не осуществляется, поэтому резервных копий предполагаю, что нет.

 

Процесс восстановления БД через drwcsd repairdb также завершается ошибкой.

 

Экспорт существующей БД в файл проведена успешно.

Подскажите, пожалуйста, варианты дальнейших действий.

Спасибо.

Сообщение было изменено Jorik: Сегодня, 13:21

[Kirill Polubelov]

Добрый день.

Прежде всего, при операциях по восстановлению БД, сам сервер должен быть надёжно остановлен.

То есть, перед запуском drwcsd repairdb необходимо убедиться, например, через 

ps ax | grep drwcsd

что сервер не запущен.
Ну и на результат работы из лога хорошо бы взглянуть.
Кстати, что покажет

ls -al var/database*

[Afalin]

Проблема усугубляется еще и тем, что резервное копирование БД по умолчанию не осуществляется, поэтому резервных копий предполагаю, что нет.

Это не так, по умолчанию оно производится куда-то в /var/opt/drwcs/backup.

[B.Chugunov]

резервное копирование БД по умолчанию не осуществляется

Если это предположение, то оно неверно. Т.е. бэкапов может и нет, но вообще резервное копирование БД в дефолте включено в список штатных заданий планировщика сервера, которые выполняются по расписанию. 
В норме бэкапы сервера под Linux должны лежать в /var/opt/drwcs/backup, но каталог бывает и переопределен. Можно по дискам поискать например файлик content.gz. В него, в норме бэкап базы экспортируется при выполнении штатного задания. 

drwcsd.log сервера бы поглядеть. 
Ну и если бэкапов прям вот точно нет нигде, но есть текущий экспорт БД, можете его куда-нибудь залить и прислать ссылку в ЛС. 
 

[Jorik]

Всем спасибо за ответы. Теперь по порядку.

 

 

что сервер не запущен.

Естественно. Перед восстановлением все процессы, связанные с сервером, были остановлены.

 

 

Кстати, что покажет

ls -al var/database*

Отображается сама БД на 450Мб и несколько попыток ее восстановления на 250Мб каждая в виде *.repair

 

 

Это не так, по умолчанию оно производится куда-то в /var/opt/drwcs/backup.

Такого каталога не существует. Сервер ставился по умолчанию. Вручную никаких каталогов не переопределялось.

в каталоге /var/opt/drwcs/ доступны подкаталоги:

- current-revisions

- etc

- extensions

- file-cache

- log

- plugins

- repository

- run

- sessions

- tmp

- twin-cache

 

 

 

drwcsd.log сервера бы поглядеть.

Журнал прикладываю

 

 

 

но есть текущий экспорт БД, можете его куда-нибудь залить и прислать ссылку в ЛС

Сервер работает на разных мандатных уровнях. Понимаете почему это невозможно.

 

 

Прикрепленные файлы:

•  drwcsd.log   3,01Мб   1 Скачано раз

Сообщение было изменено Jorik: Сегодня, 15:25

[B.Chugunov]

Видимо 181564, раз тут 13.00.0.202204040 (REL-1300_202107090 =) 
Без самой базы предполагаю, что можно попробовать modexecdb database-export, modexecdb database-init и затем в неё modexecdb database-import
Перед манипуляциями оригинальный .sqlite файл базы в отдельном месте сохранить. 
С некоторой вероятностью прокатит. 

[Jorik]

Видимо 181564, раз тут 13.00.0.202204040 (REL-1300_202107090 =)

Использовалась сертифицированная версия.

 

С некоторой вероятностью прокатит.

Если я правильно понимаю, то Ваш вариант сводится:

- к резервной копии самой базы;

- экспорт существующей;

- удаление существующей и инициализация новой;

- импорт экспортированной.

 

Что ж, буду пробовать, спасибо. Отпишусь.

[B.Chugunov]

Если я правильно понимаю, то Ваш вариант сводится:

Ага. По крайней мере на практике удавалось таким образом восстанавливать базы. Но вариант не гарантированный конечно.