В архиве готовый скрипт для выгрузки баз 1С в формате .dt
Перед выгрузкой базы удаляются все активные сеансы (принудительно!)
Использую у себя на работе уже год для ежедневного ночного создания бэкапов баз 1С
Для работы по расписанию необходимо его добавить в планировщик (Task Scheduler) операционной системы.
Поля, которые скорее всего необходимо будет вам скорректировать:
$mes.From = "1cdoc@mail.ru" — от кого будет формироваться письмо
$mes.To.Add("Test@mail.ru") — список адресов, на которые будет происходить рассылка. Если необходимо добавить еще добавляем строчку $mes.To.Add("Test2@mail.ru")
$smtp = New-Object Net.Mail.SmtpClient("1.1.1.1", 25) — указываем адрес и порт SMTP сервера (для эл. рассылки)
$smtp.Credentials = New-Object System.Net.NetworkCredential("1cdoc", "123") — логин и пароль от учетной записи, осуществляющей рассылку
Start-Transcript -Path "D:Backup1CBackup1c.txt" — путь к файлу, куда будет писаться лог
$PathTo1C = "C:Program Files (x86)1cv8"; — путь к папке, где установлена 1С
$Version1C = "8.3.15.1489"; — указываем версию платформы 1С
$stat=PerformBackup "new1c_doc" "DO" "Робот" "28065b7" $BackupFolderPath; — имя сервера 1С, имя базы, пользователь и пароль
$BackupFolderPath = "D:Backup1C" — путь, куда будут "складываться" бэкапы баз 1С (.dt)
dt — это не резервная копияИТС
(0), если в базе остались работать пользователи, то dt будет сформирована?
(2)нет, это же выгрузка ИБ
дт по заявлению самой 1с не является резервной копией и порой в дт попадают не все данные… автор отстой
А как вы потом разворачиваете, если первоначально база была 500 gb?
(3), получается, что если из базы не выйдут все пользователи, то и архив ночью не создастся?
Нахрена тогда нужен этот скрипт?
Объяснять пользователям, что необходимо всегда выходить из программы — бесполезно. Всегда найдется такой, который не выйдет.
(2)
Если внимательно посмотреть на картинку скрипта, там говорится о завершении активных сессий.
Хотя неплохо было бы автору упомянуть об этом в самой статье.
А что, кроме как вызгрузка/загрузка DT, вы посоветуете для ежедневного автоматического создания зеркала базы?
(Не для целей отказоустойчивости или бэкапа, а для пользователей которым нужна свежая копия для «экспериментов» )
Если делать задание копирования источника в копию средствами sql, то при перезаписи кэш базы на сервере 1c не будет соответствовать ее новому sql состоянию. В итоге в копии возможны глюки, например с нумерацией создаваемых документов
(2) да.
Перед выгрузкой все пользователи выгоняются принудительно (убиваются активные соединения с базой)
(7) Других вариантов выгрузки (кроме как .dt или .bak) я к сожалению не знаю
Исходя из моей практики .dt — самый надежный вариант
(7)Я может чего не понимаю, чем простой бэкап средствами SQL и актуализация копии БД из этого бэкапа не устраивает?
(4) в терминологии я не силен, поправьте если что. Я скорректирую публикацию
(5) Разворачивается из .dt довольно долго. У нас база рабочая 150 Гб разворачивается 1,5 часа
(10)
Ой 🙂
(3) будет сформирована, пользователи предварительно выгоняются приндительно
(11) тоже себе вариант , кому как удобней
(16)эээ….так он заметно быстрее, чем восстановление из *.dt, более того, есть еще и разностный бэкап……..
(10)
Исходя из моей практики dt выгружается, но не всегда загружается. Так что или bak если СУБД или копирование каталога.
На 150 базах в течении года ситуация когда из dt база не восстанавливалась было 3 раза, что не так уж и мало.
(15)
Сидит так какой нибудь разработчик в конфигураторе, а его раз и выкинуло. И кстати в файловой базе тоже используется СУБД.
(19)в боевой разработчик ночью не сидит — если он нормальный разработчик :))) бу-га-га.
(20) конечно, он всех днем выгоняет, чтобы обновления накатить.
(9)Не путайте просто выгрузку и бэкап, тогда уж проще всё таки делать средствами штатными SQL, там и на пользователей плевать есть они или нет, на рег задания тоже как то с высокой колакольни, да и файлик меньше получается+штатное обслуживание самой СУБД
(13)Ну а SQL back у вас бы разворачивался от силы минут 20, так что вы не в том направлении малость работаете с резервным копированием, а ещё лучше смотрите на серьёзные продукты для ведения резервных копий, раз в неделю к примеру на ленту/нас полный, а в течении недели инкрементальные/дифференциальные
(7)
При помощи скриптавот отсюда : заливаю в копию последний актуальный бекап. У нас журнал транзакций архивируется в рабочее время каждые 5 минут, получить актуальную копию можно в любой момент, одним нажатием кнопки. Очень удобно.
(7)
Не разу не было проблем описанных вами. Можно узнать айди и сбрасывать кеш для этой конкретной базы наверняка. Но описанных вами проблем не встречал ни разу. 1Сный кеш судя по скорости старта 1с, после перезаливки, судя по всему, обнуляется успешно сам. Но описанная вами проблема была, когда одна база открывалась разными экземплярами сервера1С(я для отладки использую отдельный сервер с включенной отладкой)