(3), получается, что если из базы не выйдут все пользователи, то и архив ночью не создастся?
Нахрена тогда нужен этот скрипт?
Объяснять пользователям, что необходимо всегда выходить из программы - бесполезно. Всегда найдется такой, который не выйдет.
(9)Не путайте просто выгрузку и бэкап, тогда уж проще всё таки делать средствами штатными SQL, там и на пользователей плевать есть они или нет, на рег задания тоже как то с высокой колакольни, да и файлик меньше получается+штатное обслуживание самой СУБД
(2)
Если внимательно посмотреть на картинку скрипта, там говорится о завершении активных сессий.
Хотя неплохо было бы автору упомянуть об этом в самой статье.
А что, кроме как вызгрузка/загрузка DT, вы посоветуете для ежедневного автоматического создания зеркала базы?
(Не для целей отказоустойчивости или бэкапа, а для пользователей которым нужна свежая копия для "экспериментов" )
Если делать задание копирования источника в копию средствами sql, то при перезаписи кэш базы на сервере 1c не будет соответствовать ее новому sql состоянию. В итоге в копии возможны глюки, например с нумерацией создаваемых документов
Исходя из моей практики .dt - самый надежный вариант
Исходя из моей практики dt выгружается, но не всегда загружается. Так что или bak если СУБД или копирование каталога.
На 150 базах в течении года ситуация когда из dt база не восстанавливалась было 3 раза, что не так уж и мало.
А что, кроме как вызгрузка/загрузка DT, вы посоветуете для ежедневного автоматического создания зеркала базы?
При помощи скрипта вот отсюда: заливаю в копию последний актуальный бекап. У нас журнал транзакций архивируется в рабочее время каждые 5 минут, получить актуальную копию можно в любой момент, одним нажатием кнопки. Очень удобно.
(7)
Если делать задание копирования источника в копию средствами sql, то при перезаписи кэш базы на сервере 1c не будет соответствовать ее новому sql состоянию. В итоге в копии возможны глюки, например с нумерацией создаваемых документов
Не разу не было проблем описанных вами. Можно узнать айди и сбрасывать кеш для этой конкретной базы наверняка. Но описанных вами проблем не встречал ни разу. 1Сный кеш судя по скорости старта 1с, после перезаливки, судя по всему, обнуляется успешно сам. Но описанная вами проблема была, когда одна база открывалась разными экземплярами сервера1С(я для отладки использую отдельный сервер с включенной отладкой)
(13)Ну а SQL back у вас бы разворачивался от силы минут 20, так что вы не в том направлении малость работаете с резервным копированием, а ещё лучше смотрите на серьёзные продукты для ведения резервных копий, раз в неделю к примеру на ленту/нас полный, а в течении недели инкрементальные/дифференциальные