Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Знание скриптов — это хорошо, но все же готовый инструмент будет лучшим решением.
Обратите внимание на Обновлятор 1С.
Обновляет он лучше Вашего скрипта: он завершает все активные сеансы и блокирует работу с ИБ, обновляет, запускает конфигурацию в режиме предприятия и выполняет регламентные операции при обновлении и это в автоматическом режиме и может обновлять сразу на несколько релизов. Это что касается обновления.
Что касается резервного копирования, то он умеет не только делать бэкап, но и допустим защищать его от шифровальщиков, или делать дополнительно бэкап в облако.
Бесплатная версия очень функциональна, а если заплатите 900 руб, то получите полнофункциональную версию.
Очень рекомендую.
Обратите внимание на Обновлятор 1С.
Обновляет он лучше Вашего скрипта: он завершает все активные сеансы и блокирует работу с ИБ, обновляет, запускает конфигурацию в режиме предприятия и выполняет регламентные операции при обновлении и это в автоматическом режиме и может обновлять сразу на несколько релизов. Это что касается обновления.
Что касается резервного копирования, то он умеет не только делать бэкап, но и допустим защищать его от шифровальщиков, или делать дополнительно бэкап в облако.
Бесплатная версия очень функциональна, а если заплатите 900 руб, то получите полнофункциональную версию.
Очень рекомендую.
Писал подобный скрипт, после того как 1с программисты отказались рассматривать продукты аналогичные тому что в первом комменте. У меня были следующие отличия от вашего:
1) базы находились на MS SQL и бэкапились его средствами (запуск invoke-sqlcommand вроде бы)
2) скрипт выполнялся каждые 5 минут, сканируя определенную сетевую шару на предмет файлов заданий (.update), в которых были указаны пути к базам и пути по unc к файлам конфигураций (обошлись без ftp)
3) по завершению файл-задание менял имя на .done или .error и высылал на почту (адрес получателя был в файле задания отдельной строкой) отчет о том как прошла процедура, и на каком шаге какая ошибка произошла
4) из-за особенностей платформы 8.3 и конфигураций (там не была реализована функция выхода всех пользователей), выгонялось через интерфейс кластера 1с + ставился запрет на фоновые задания и вход пользователей (пароль) до завершения процедуры обновления.
возможно что-то было еще, я это писал больше двух лет назад, и оставил в компании которую на тот момент покидал :) (то был дембельский аккорд)
Если интересно, попробую поднять старые исходники и показать интересующие места.
1) базы находились на MS SQL и бэкапились его средствами (запуск invoke-sqlcommand вроде бы)
2) скрипт выполнялся каждые 5 минут, сканируя определенную сетевую шару на предмет файлов заданий (.update), в которых были указаны пути к базам и пути по unc к файлам конфигураций (обошлись без ftp)
3) по завершению файл-задание менял имя на .done или .error и высылал на почту (адрес получателя был в файле задания отдельной строкой) отчет о том как прошла процедура, и на каком шаге какая ошибка произошла
4) из-за особенностей платформы 8.3 и конфигураций (там не была реализована функция выхода всех пользователей), выгонялось через интерфейс кластера 1с + ставился запрет на фоновые задания и вход пользователей (пароль) до завершения процедуры обновления.
возможно что-то было еще, я это писал больше двух лет назад, и оставил в компании которую на тот момент покидал :) (то был дембельский аккорд)
Если интересно, попробую поднять старые исходники и показать интересующие места.
ах, да — сама идея такого скрипта была следующая: есть куча разработчиков, которые делают конфигурацию и не имеют прав ее применять (административных и юридически). И есть больше 10 серверов 1с с более чем 30 баз, которые надо обновлять в наименее критичное для бизнеса время (нет такого понятия как люди не работают с базами). Обновления идут часто и человек занимающийся ручным обновлением хочет спать, за результат обновления (качество работы 1с кода) он не отвечает :)
Думаю, было бы интересно добавить
особенно отследить момент завершения процесса обновления.
запрет на фоновые задания и вход пользователей (пароль) до завершения процедуры обновления
особенно отследить момент завершения процесса обновления.
у меня он лежит на github, размещал для своих нужд, но расшарить не жалко. Все равно полноценную статью я писать не осилю:
github.com/OsipovDV/1c_update
еще одно важное отличие от вашего — у меня в файле задании говорится когда и во сколько обновлять. То есть какое-то жалкое подобие планировщика :)
github.com/OsipovDV/1c_update
еще одно важное отличие от вашего — у меня в файле задании говорится когда и во сколько обновлять. То есть какое-то жалкое подобие планировщика :)
Очень плохая идея, выгнать всех! А если идет массовое перепроведение документов? А если что то бухгалтера считать запустили? А если регламентные задания работают? Так что идея бекапить базу минуя сиквел сервер это плахая идея, база бекапиться только там и там же восстанавливается, при этом так же бекапяться и транзакшен логи. А про ком объект отдельная тема, любой админ 1ски знает, что иногда сервер DCOM перестает работать, ну просто вот так и ве это лечиться только перезагрузкой сервера целиком, что не всегда приемлемо. И вот в этом случае ваш скрипт уже сразу сломается. Далее вы грузите свой бекап на ftp, а если обрыв сессии? Докачка есть? Как показала практика бекап через фтп это не то что не безопасно это еще и не надежно, темболее хранить пароли в файле. Для этого как минимум можно их зашифровать и читать вообще с другого файла. Но лучшее решение это использовать Backula у нее есть клиент под винду, и проблема с фтп автоматом отпадет. В общем и целом, решение ваше это скорей попытка попробовать как можно, но не решение как нужно. Итак чтобы обеспечить точную доставку целого бекапа и последующее его восстановление нам надо:
1. Настроить Планы обслуживания на сервере БД, в том числе и бекап базы с проверкой, а так же бекап лога транзакций
2. Настроить Бакулу для забора этого бекапа, в определенное время
3. Переодически тестировать восстановление из бекапа
Только так.
1. Настроить Планы обслуживания на сервере БД, в том числе и бекап базы с проверкой, а так же бекап лога транзакций
2. Настроить Бакулу для забора этого бекапа, в определенное время
3. Переодически тестировать восстановление из бекапа
Только так.
1.Бэкап на ftp не грузится. Бэкап забирается по расписанию NASом с сервера.
2.COM-объект использую уже почти 4 года для выполнения целого ряда задач. За все время его «отвалы» проходили только после обновлений платформы и, реже, Windows. Обновления ОС ставятся по расписанию, после них уже составлен план для тестирования сервера. Платформу вообще вручную обновляем.
3.Как минимум две базы сразу разворачиваются из резервных копий в другие ИБ. В случае «несрабатывания» этого пункта получаем оповещение от пользователей в 9-00, и тут уже резервный вариант с копирование средствами СУБД. Пожалуйста, не спрашивайте, зачем такой извращенный способ.
По поводу того, что может быть прерван длительный процесс какой-либо обработки я с вами соглашусь. Но в моей практике такое было один раз и то сам виноват.
2.COM-объект использую уже почти 4 года для выполнения целого ряда задач. За все время его «отвалы» проходили только после обновлений платформы и, реже, Windows. Обновления ОС ставятся по расписанию, после них уже составлен план для тестирования сервера. Платформу вообще вручную обновляем.
3.Как минимум две базы сразу разворачиваются из резервных копий в другие ИБ. В случае «несрабатывания» этого пункта получаем оповещение от пользователей в 9-00, и тут уже резервный вариант с копирование средствами СУБД. Пожалуйста, не спрашивайте, зачем такой извращенный способ.
По поводу того, что может быть прерван длительный процесс какой-либо обработки я с вами соглашусь. Но в моей практике такое было один раз и то сам виноват.
1. ФТП сама по себе плохая идея, тут важен контроль закачки, если докачка не поддерживается то без разницы как оно сделано
2. Есть проекты, когда 1с достаточно хорошо нагружена и имеет в онлайне больше 100 пользователей сразу, там есть вещи которые отваливают СОМ+, темболее сама Майкрософт давно признала, что это плохая технология и не рекомендует ее использовать, но что 1С до рекомендаций какой то Майкрософт
3. Не спрашиваю, средствами БД это все равно лучше и правильней, есть только одно НО, если тестировщик или разработчик сидит в конфигураторе или что то делает с базой вы ее никак не накатите, даже средствами SQL, будет просто обломс
По поводу длительных процессов, ну видимо вы не так активно используете 1с, бывает ее нагибают и в хвост и в гриву, когда 1с это основная система.
2. Есть проекты, когда 1с достаточно хорошо нагружена и имеет в онлайне больше 100 пользователей сразу, там есть вещи которые отваливают СОМ+, темболее сама Майкрософт давно признала, что это плохая технология и не рекомендует ее использовать, но что 1С до рекомендаций какой то Майкрософт
3. Не спрашиваю, средствами БД это все равно лучше и правильней, есть только одно НО, если тестировщик или разработчик сидит в конфигураторе или что то делает с базой вы ее никак не накатите, даже средствами SQL, будет просто обломс
По поводу длительных процессов, ну видимо вы не так активно используете 1с, бывает ее нагибают и в хвост и в гриву, когда 1с это основная система.
Выгрузка в DT будет эффективна только для баз небольшого размера. Очень неэффективно рубить сессии не глядя кто и что делает — возможно кто-то задержался на работе или работает удаленно, а вы ему вырубили длительную операцию. Я использовал в течении 7 лет Vritas (ранее Symantec) Backup Exec с агентом для приложений — в результате эффективное копирование, шифрование, тестирование копии и прочие плюшки, включая мониторинг заданий.
Автоматическое обновление баз в продуктиве для смелых парней!
Автоматическое обновление баз в продуктиве для смелых парней!
Масштабно, делаю тоже самое, но в меньшее количество строк, одна перезапускает сервер, чтобы все не выключенные компы отвалились, вторая делает бекап в папку синхронизируемую с яндекс-диском. Наверно это не очень корректно, и без защиты от шифровальщиков, но я пока с проблемами такого подхода не сталкивался.
1. Резервное копирование средствами 1С, не является средством резервного копирования (https://its.1c.ru/db/v8311doc#bookmark:cs:TI000000136)
2. Чтобы обеспечить монопольный доступ, нужно не думать, как планировать задания (обновление индекса, например, может происходить каждый 15секунд), а ставить ключ блокировки сеансов.
2. Чтобы обеспечить монопольный доступ, нужно не думать, как планировать задания (обновление индекса, например, может происходить каждый 15секунд), а ставить ключ блокировки сеансов.
Такими темпами может оказаться, что проще развернуть 1С в виртуальной среде и делать резервные копии самих виртуалок целиком.
Захардкоженные логин и пароль это просто прекрасно.
Вы там хотя бы маломальскую авторизацию для этого прикрутите от AD или от локальной учетки хотя бы.
Вы там хотя бы маломальскую авторизацию для этого прикрутите от AD или от локальной учетки хотя бы.
А зачем убивать рабочие процессы 1С? Какой-то мегахаотичный скрипт. Да еще и на живую сеансы грохает… Лучше взять наработки 1с-комьюнити.Тот же обновлятор или скрипты "деплойки" по ссылкам выше привели.
Как уже было сказано, регламентно бекапить в dt идея не очень, но если уж так, то тогда, например —
rem Выключение службы, затем пауза на 30 секунд, затем включение службы, затем пауза на 30 секунд.
sc stop «1C:Enterprise 8.3 Server Agent»
ping -n 30 localhost
sc start «1C:Enterprise 8.3 Server Agent»
ping -n 30 localhost
rem Резервное копирование баз.
«C:\Program Files (x86)\1cv8\common\1cestart.exe» CONFIG /S«ts-2\BaseName» /N«User» /P«Password» /DumpIB"\\host\directory\%date:~-10%-basename.dt"
rem Выключение службы, затем пауза на 30 секунд, затем включение службы, затем пауза на 30 секунд.
sc stop «1C:Enterprise 8.3 Server Agent»
ping -n 30 localhost
sc start «1C:Enterprise 8.3 Server Agent»
ping -n 30 localhost
rem Резервное копирование баз.
«C:\Program Files (x86)\1cv8\common\1cestart.exe» CONFIG /S«ts-2\BaseName» /N«User» /P«Password» /DumpIB"\\host\directory\%date:~-10%-basename.dt"
Делать копию важных баз 1С с помощью механизма выгрузки информационной базы — моветон.
Цитата из официальной документации:
Если база sql, то копии нужно делать средствами sql сервера. Если база файловая, то только копия файлов БД. Это касается критических данных. Для тестирования и разработки наверно пойдёт и ваш метод.
Цитата из официальной документации:
Выгрузка информационной базы данных в файл
Не рекомендуется использовать данный способ для создания резервной копии информационной базы по следующим причинам:
● может возникнуть ситуация, при которой файл выгрузки будет невозможно загрузить, если в информационной базе, из которой производилась выгрузка, существовали ошибки;
● длительное время создания;
● необходимость монопольного доступа к базе данных;
● высокие требования к оперативной памяти.
Если база sql, то копии нужно делать средствами sql сервера. Если база файловая, то только копия файлов БД. Это касается критических данных. Для тестирования и разработки наверно пойдёт и ваш метод.
Download_File
проще использовать start-Bitstransfer
проще использовать start-Bitstransfer
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматическое обновление и резервное копирование 1С при помощи powershell