Jump to content
d@vinchi

Помогите настроить резервное копирование АдминКит'а...

Recommended Posts

БД админкита хранится на отдельном сервере SQL 2005 Ent. Сервер переехал на новое железо, БД админкита востановлена из резевной копии удачно! Проблема только в резерном копировании БД админкита, задача заканчивается с сообщением:

Завершена с ошибкой

Уровень важности: Отказ функционирования

Приложение: Kaspersky Administration Kit

Номер версии: 6.0.1710

Имя задачи: Резервное копирование Сервера администрирования

Компьютер: Сервер администрирования <ххх>

Группа: ххх

Время: 3 мая 2009 г. 0:30:37

Описание: Операция резервного копирования завершилась с ошибкой, убедитесь, что SQL Server имеет доступ к каталогу назначения

в этом случае по пути бекапа создается папка вида klbackup2009-05-06#19-15-00 и в ней только один файл файл kavsqldb.bkp...

бывает такое сообщение:

Завершена с ошибкой

Уровень важности: Отказ функционирования

Приложение: Kaspersky Administration Kit

Номер версии: 6.0.1710

Имя задачи: Резервное копирование Сервера администрирования

Компьютер: Сервер администрирования <ххх>

Группа: ххх

Время: 6 мая 2009 г. 19:25:39

Описание: Неизвестная ошибка: -520157282

в этом случае по пути бекапа создается только пустая папка вида klbackup2009-05-06#19-15-00...

 

Касательно бекапов базы админкита ничего не менялось в процессе модернизации SQL сервера и восстановлении БД админкита, до этого все работало...

Прошу помощи в решении этой траблы...

Edited by d@vinchi

Share this post


Link to post

так оно и есть... на SQL сервере расшарена папка в которую кдминкит бекапистя...

Share this post


Link to post

путь к папке указан в виде \\svr\backup$\kav, этот путь доступен обоим серверам и он был и раньше до шаманства с SQL сервером...

везде где можно дал полные права на доступ к папке бекапа учетке SQL сервера, админкита и компа на которм админкит - теперь стабильно сообщает что у SQL сервера нет доступа к папке бекапа: "Операция резервного копирования завершилась с ошибкой, убедитесь, что SQL Server имеет доступ к каталогу назначения"... но сам SQL сервер создает бекап самой базы судя по наличию файла kavsqldb.bkp в папке бекапа и событию системном журнале:

Имя журнала: Application

Подача: MSSQL$ххх

Дата: 06.05.2009 21:43:33

Код события: 18264

Категория задачи:(6)

Уровень: Сведения

Ключевые слова:Классический

Пользователь: <adminkit>

Компьютер: <sql_server>

Описание:

Создана резервная копия базы данных. База данных: KAV, дата (время) создания: 2008/12/28(03:58:46), выгружено из памяти страниц: 1675, первый номер LSN: 49588:193:212, последний номер LSN: 49588:278:1, число устройств хранения: 1, сведения об устройствах: (FILE=1, TYPE=DISK: {'\\svr\backup$\kav\klbackup2009-05-06#21-43-00\kavsqldb.bkp'}). Это информационное сообщение. Вмешательство пользователя не требуется.

 

похоже на то что админкит не может в эту папку скопировать все остальное...

Edited by d@vinchi

Share this post


Link to post
путь к папке указан в виде \\svr\backup$\kav, этот путь доступен обоим серверам и он был и раньше до шаманства с SQL сервером...

везде где можно дал полные права на доступ к папке бекапа учетке SQL сервера, админкита и компа на которм админкит - теперь стабильно сообщает что у SQL сервера нет доступа к папке бекапа: "Операция резервного копирования завершилась с ошибкой, убедитесь, что SQL Server имеет доступ к каталогу назначения"... но сам SQL сервер создает бекап самой базы судя по наличию файла kavsqldb.bkp в папке бекапа и событию системном журнале:

похоже на то что админкит не может в эту папку скопировать все остальное...

 

Проверьте следующее:

1. задача бэкапа работает по учетной записью скервера адм-я -- на вкладке учетной записи должено быть выбран "Default account" (учетная запись по умолчанию) .

2. в свойствах задачи прописан UNC-путь

 

Если все так, то запустите задачу и выложите файл klbackup.log из папки инсталляции продукта.

 

Share this post


Link to post
Проверьте следующее:

1. задача бэкапа работает по учетной записью скервера адм-я -- на вкладке учетной записи должено быть выбран "Default account" (учетная запись по умолчанию) .

не совсем понятно что все-таки должно быть на вкладке учетной записи - учетка админкита или учетка по умолчанию?

Share this post


Link to post
не совсем понятно что все-таки должно быть на вкладке учетной записи - учетка админкита или учетка по умолчанию?

 

Выранный селектор "Default account" означает, что задача будет запущена под той учетной записью, под которой работает служба сервера адм-я.

post-340-1242197397_thumb.png

Share this post


Link to post

выставил на учетку по умолчанию, задача отработала с ошибкой:

Операция резервного копирования завершилась с ошибкой, убедитесь, что SQL Server имеет доступ к каталогу назначения

вот лог:

Starting klbackup utility

Initializing DCOM...OK

Initializing basic libraries...OK

Checking arguments...OK

Openning SCM...OK

Stopping service 'KLNagent'...OK

Stopping service 'CSAdminServer'...OK

Checking backup paths...OK

Acquiring SQL server connection name and DB name...OK

Connecting to the database server...OK

Backing up db 'KAV' to '\\svr\backup$\kav\klbackup2009-05-13#10-48-47\kavsqldb.bkp'...FAILED - check whether SQL Server has enough permissions to access backup path '\\svr\backup$\kav\klbackup2009-05-13#10-48-47'

FAILED - error code 13 ('')

Saving results...OK

Starting service CSAdminServer...OK

Starting service KLNagent...OK

По пути \\svr-vlg-fs\backups$\kav\klbackup2009-05-13#10-48-47\ после завершения задачи создается только файл kavsqldb.bkp. С компа на котором админкит для этого пути разрешения есть и для учетки компа и для учетки админкита - проверено...

Может в параметрах имени входа на SQL сервер какие-то разрешения не заданы?

Share this post


Link to post
выставил на учетку по умолчанию, задача отработала с ошибкой:

 

вот лог:

 

По пути \\svr-vlg-fs\backups$\kav\klbackup2009-05-13#10-48-47\ после завершения задачи создается только файл kavsqldb.bkp. С компа на котором админкит для этого пути разрешения есть и для учетки компа и для учетки админкита - проверено...

Может в параметрах имени входа на SQL сервер какие-то разрешения не заданы?

 

Выложите, пожалуйста, файлы ERRORLOG* из подпапки LOG папки установки SQL Server'а, используемого сервером адм-я.

Share this post


Link to post

вот лог за достаточно долгий период:

2009-04-28 00:00:58.69 spid21s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-04-29 00:00:48.86 spid14s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-04-30 00:00:55.34 spid22s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-01 00:00:34.38 spid14s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-02 00:00:23.36 spid14s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-03 00:00:33.86 spid19s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-03 00:30:26.85 Database backed up. Database: KAV, creation date(time): 2008/12/28(03:58:46), pages dumped: 1675, first LSN: 49388:130:148, last LSN: 49388:189:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'\\svr\backup$\KAV\klbackup2009-05-03#00-30-00\kavsqldb.bkp'}). This is an informational message only. No user action is required.

2009-05-04 00:00:42.86 spid19s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-05 00:00:01.95 spid17s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-06 00:00:39.96 spid18s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-06 21:26:22.37 Database backed up. Database: KAV, creation date(time): 2008/12/28(03:58:46), pages dumped: 1675, first LSN: 49587:183:286, last LSN: 49587:299:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'\\svr\backup$\kav\klbackup2009-05-06#21-26-00\kavsqldb.bkp'}). This is an informational message only. No user action is required.

2009-05-06 21:43:33.61 Database backed up. Database: KAV, creation date(time): 2008/12/28(03:58:46), pages dumped: 1675, first LSN: 49588:193:212, last LSN: 49588:278:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'\\svr\backup$\kav\klbackup2009-05-06#21-43-00\kavsqldb.bkp'}). This is an informational message only. No user action is required.

2009-05-07 00:00:35.29 spid14s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-08 00:00:35.52 spid21s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-09 00:00:26.05 spid18s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-10 00:00:50.01 spid17s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-11 00:00:35.46 spid19s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-12 00:00:34.46 spid16s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-13 00:00:48.54 spid18s This instance of SQL Server has been using a process ID of 2020 since 24.04.2009 0:08:36 (local) 23.04.2009 20:08:36 (UTC). This is an informational message only; no user action is required.

2009-05-13 10:49:28.08 Database backed up. Database: KAV, creation date(time): 2008/12/28(03:58:46), pages dumped: 1675, first LSN: 49907:252:300, last LSN: 49907:372:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'\\svr\backup$\kav\klbackup2009-05-13#10-48-47\kavsqldb.bkp'}). This is an informational message only. No user action is required.

Share this post


Link to post
вот лог за достаточно долгий период:

 

Запустите, пожалуйста, бэкап с трассировкой.

Для этого сделайте на компьютере с сервером адм-я следующее:

1. запустите файл "trace-5-server.reg"

2. воспроизведите проблему

3. запустите файл "trace-off-server.reg"

4. выложите файл "$klbackup-1093.log" (в виде архива) или пришлите мне в личку.

 

И еще доп. вопрос: не стоит ли ограничение на кол-во соединений у шары \\svr\backup$ ?

files.zip

Share this post


Link to post

Трассировку закинул в личку...

Ограничение на количесво соединений - максимально возможное...

Share this post


Link to post
Трассировку закинул в личку...

Ограничение на количесво соединений - максимально возможное...

 

Похоже, все-таки доступа не имеет учетная запись, под которой задача работает, т.е. учетная запись сервера адм-я.

 

Share this post


Link to post

Учетка админкита 100% есть в разрешениях на шару и NTFS... Может у учетки админкита не хватает прав на SQL сервере?

Share this post


Link to post
Учетка админкита 100% есть в разрешениях на шару и NTFS... Может у учетки админкита не хватает прав на SQL сервере?

 

Попробуйте сделать бэкап в несуществующую папку на шаре. Т.е. напр., в "\\svr-vlg-fs\backups$\kav\Folder\Folder1", так, чтобы папок "Folder" и "Folder\Folder1" не существовало до запуска бэкапа. Посмотрим, сможет ли задача бэкапа эту папку создать. Если доступ есть, то должна смочь.

 

Share this post


Link to post

дык при каждом старте она и так создает несуществующую папку вида klbackup2009-05-13#10-48-47 и кладет в нее полный бекап kavsqldb.bkp... а вот все остальное туду перенести не может...

Share this post


Link to post
дык при каждом старте она и так создает несуществующую папку вида klbackup2009-05-13#10-48-47 и кладет в нее полный бекап kavsqldb.bkp... а вот все остальное туду перенести не может...

 

Посмотрите, не остался ли в папке инсталляции продукта файл $klserver-1093.log ? Он должен был сгенериться вместе с файлом $klbackup-1093.log. Если остался, то киньте его мне в личку (как архив).

Share this post


Link to post

Посмотри еще раз, сам не пойму как так происходит что SQL сервер нормально отрабатывает бекап, а дальше фиг - причем дело вроде как не в SQL на которого ругань идет...

Share this post


Link to post
Посмотри еще раз, сам не пойму как так происходит что SQL сервер нормально отрабатывает бекап, а дальше фиг - причем дело вроде как не в SQL на которого ругань идет...

 

Посмотрите, не остался ли в папке инсталляции продукта файл $klserver-1093.log ? Он должен был сгенериться вместе с файлом $klbackup-1093.log. Если остался, то киньте его мне в личку (как архив).

Share this post


Link to post
отправил!

 

Попробуйте запустить утилиту klbackup вручную под учетной записью "VGND\AdminKitService".

 

С какой-то тако командной строкой

 

klbackup.exe -path "\\svr-vlg-fs\backups$\kav" -use_ts -password PASSWORD

 

Share this post


Link to post

результат тот же самый - создается папка и в ней файл бекапа, у меня он примероно 13 Мб, вот лог:

Starting klbackup utility

Initializing DCOM...OK

Initializing basic libraries...OK

Checking arguments...OK

Openning SCM...OK

Stopping service 'KLNagent'...OK

Stopping service 'CSAdminServer'...OK

Checking backup paths...OK

Acquiring SQL server connection name and DB name...OK

Connecting to the database server...OK

Backing up db 'KAV' to '\\svr-vlg-fs\backups$\kav\klbackup2009-05-14#14-40-13\kavsqldb.bkp'...FAILED - check whether SQL Server has enough permissions to access backup path '\\svr-vlg-fs\backups$\kav\klbackup2009-05-14#14-40-13'

FAILED - error code 13 ('')

Starting service CSAdminServer...OK

Starting service KLNagent...OK

Share this post


Link to post
результат тот же самый - создается папка и в ней файл бекапа, у меня он примероно 13 Мб, вот лог:

 

А сами вы из-под учетки VGND\AdminKitService файл этот "'\\svr-vlg-fs\backups$\kav\klbackup2009-05-14#14-40-13\kavsqldb.bkp" прочитать можете ? И особенно его свойства в проводнике посмотреть ?

Share this post


Link to post

я проверяю так: свойства файла -> вкладка Безопасность -> кнопка дополнительно -> вкладка Действующие разрешения -> Учетная запись -> кнопка Оюзор -> выбираю учетку алминкита -> права полные...

Share this post


Link to post

×
×
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.