Версия ЛЭРС УЧЁТ: 3.61.3
Сервер БД: MS SQL Server 2008 R2 (на отдельном компьютере)
После обновления с версии 3.56 до 3.61.3 перестало работать резервное копирование базы данных.
Версия ЛЭРС УЧЁТ: 3.61.3
Сервер БД: MS SQL Server 2008 R2 (на отдельном компьютере)
После обновления с версии 3.56 до 3.61.3 перестало работать резервное копирование базы данных.
Искал в чём же отличие, почему перестало работать (ведь на SQL сервере мы ничего не меняли)…
Увидел, что появился новый пользователь LersServerAccount, который является пользователем Windows. До обновления его вроде бы не было.
Насколько я понял, версия 3.56.3 работала через пользователя LersUchetAccount, который явялется пользователем SQL. Предыдущая резервная копия была сделана именно этим пользователем.
Может быть с этим как-то связано?..
Данная учетная запись Windows не могла появиться после обновления 3.61.3, так как в нем нет функционала создающего и/или использующую ее. Такая учетная запись использовалась в очень старых версиях и судя по всему осталась у вас от одной из таких версий. Из под нее в этих версиях запускался Сервер, который из под нее же подключался к БД. В последствии Сервер стал запускаться из под системной учетной записи Windows, а подключение к БД стало выполняться из упомянутой вами внутренней учетной записи SQL Server. Это актуально и для текущей версии 3.61.3.
Старый способ запуска Сервера мог остаться в текущей версии, если бы вы проводили последовательное обновление ЛЭРС УЧЕТ после установки одной из старых версий,в которой он использовался, но это, исходя из вашего описания, не так.
Если в версии 3.56.3 для подключения к БД уже выполнялось из под внутренней учетной записи SQL Server, то после обновления это не могло измениться.
Вы можете проверить в параметрах конфигурации Сервера какой именно способ подключения к БД используется.
Судя по всему данную ошибку возвращает именно SQL Server, так как резервные копии в ЛЭРС УЧЕТ создаются через данную СУБД. Сервер ЛЭРС УЧЕТ лишь управляет процессом резервного копирования, передавая необходимые параметры SQL Server.
Попробуйте вручную создать резервную копию через Management Studio используя при этом ту же самую папку, которую вы указали в ЛЭРС УЧЕТ.
Спасибо за разъяснение.
Действительно на этой машине раньше работал ЛЭРС сервер, начиная с 2017 года и до 2024 до версии 3.56.3, когда произошло разделение и теперь на этой машине остался только SQL Server.
Значит мое предположение было ошибочно. Вычеркиваем.
Так и делаю. Пока создаю резервные копии вручную через SSMS. Создаётся без проблем. В ту же папку.
Вообще на этой машине (где SQL Server) никаких изменений не было, никаких обновлений не ставили, да вообще ничего не трогали.
Только обновили ЛЭРС сервер (он стоит на другом компе) с версии 3.56.3 до 3.61.3 и стала появляться эта ошибка.
Попробуйте авторизоваться под внутренней учетной записью SQL Server, под которой авторизуется ваш Сервер, и опять же создать резервную копию вручную с использованием все той же папки.
Вы имеете ввиду LersUchetAccount? Под этой учёткой были сделаны прошлые резервные копии.
Или ту учётку, которую я сделал, чтобы подключить ЛЭРС к базе SQL при установке дистрибутива ЛЭРС? Но вроде вы говорили, что под этой учёткой только установка проходит, а потом ЛЭРС взаимодействует с базой с учеткой LersUchetAccount.
Имелась ввиду именно эта учетная запись.
Уточните, пожалуйста, диск “F:\” имеется на компьютере SQL Server и на компьютере Сервера?
А как я могу авторизоваться под LersUchetAccount? У меня нет от неё пароля.
Диск "F:" находится на компьютере SQL Server.
На компьютере ЛЭРС Сервер диска F нет, и никогда не было. Диск E там последний.
Пароль есть в параметрах конфигурации Сервера в параметре “connectionString”.
Попробуйте временно указать путь, который присутствует на обоих машинах, и проверьте воспроизведется ли ситуация после этого.
На SQL Server диски D и E используются для файлов БД (.mdf и .ldf соответственно), я не хотел бы к ним вообще лезть. На диск C не пускает, отказано в доступе.
Я тогда попробую на ЛЭРС Сервере диск D (он пока не используется никак) переделать в F. Таким образом мы получим ситуацию, когда диск F будет присутствовать на обоих компьютерах.
Хорошо, давайте так. Ожидаем результат.
В свою очередь также проверим у себя на тестовом стенде вариант с наличием диска для сохранения резервных копий только на компьютере SQL Server.
Ну в общем да, заработало. Создание резервной копии началось.
Еще один интересный момент, у нас полный путь для резервных копий выглядит так: "F:\LERS.DATA.BUP". Это я потом уже упростил до одной буквы F, когда начал тестировать и разбираться.
Так вот, сейчас после того, как я диск D на ЛЭРС Сервере превратил в F, я запустил создание резервной копии как указано в настройках, то есть "F:\LERS.DATA.BUP". Создание резервной копии началось, на SQL Server появился файл “LERS_20250513121013_3.61.3.9.bak”, но и на ЛЭРС Сервере на диске F появилась папка “LERS.DATA.BUP”. Я её не создавал, она сама появилась.
Резервная копия создана. Находится она, как и должна, на SQL Server.
Уточните, пожалуйста, данный путь прописан в настройках резервного копирования системных параметров?
Собственно поэтому данная папка и создалась.
Что касается рассматриваемой ошибки, то ситуация удалось воспроизвести.
Спасибо за обращение! Мы поставили в план работ исправление данной ошибки. Как только она будет исправлена, обязательно сообщим в каком обновлении будет доступно исправление.
В качестве более простого способа обхода вы можете создать сетевой диск с нужной буквой и создать в нем папки пути сохранения резервной копии.
Исправление включено в вышедшее обновление 3.61.4. Пожалуйста, выполните обновление до данной версии и проверьте возникновение ошибки в ней.