Добрый день всем!
Создал *.bat со строкой "C:\%$EXEPath%" CONFIG /S"%$1CServer%\%$BaseName%" /N%$1CUser% /P%$1CPassw% /DumpIB %$BackUpPath%%$FileName%
Перед вызовом этого задания включалась/снималась блокировка ИБ.
Все отлично работало.
Затем выполнили переход с 8.3.18 на 8.3.20. Соответственно в *.bat поправил путь на "Program Files\1cv8\8.3.20.1789\bin\1cv8.exe" и все.
В итоге в планировщике задание выгрузки перестало работать, как и завершение сеансов пользователей (""C:\%$EXEPath%" ENTERPRISE /S"%$1CServer%\%$BaseName%" /N%$1CUser% /P%$1CPassw% /DisableStartupMessages /C ЗавершитьРаботуПользователей"). Запускается задание, но само висит и при этом никак не завершаются сеансы пользователей.

НО! если зайти в планировщик и вручную запустить задание выгрузки *.dt - оно срабатывает.

К сожалению, параллельно апгрейду платформы ещё и конфигурацию поставщика обновили до самой актуальной, но мне кажется не в этом проблема.

Подскажите, пожалуйста, что могло сломаться?

права?

Кроме переустановки 1с и правки *.bat ничего больше не делал.
Права на что? Задание запускается под Администратором, под ним же выполнялась переустановка 1с.

Пользователь (Администратор), под которым выполняется задание не залогинен (то есть включили сервак ив все, вход не выполнен).
Раньше работало без проблем. Может быть такое, что в 1С что-то поменяли? Ну типа не может больше 1С запуститься в таком режиме. Только под залогиненым пользователем?

Сеанс который запускается висит запускается планировщиком? А если прямо сейчас сказать планировщику запустить (не ручечками а расписанием)?
Что в ЖР?

Да, висит. если прямо сейчас планировщиком - все отлично отрабатывает, НО я то залогинен, когда вручную запускаю задание планировщика!

Знаете что, я посмотрел свой лог, все же после изменения платформы 1 день все отработало, а вот когда перешли с ERP 2.5.6.220 на 2.5.6.291 - перестало работать.
Может тогда все дело в правах пользователя, под которым запускается? Запускаю так же под Администратором.

Вообще конечно какой-то бред :( год все работало.

(0) А вы в курсе что бекап базы 1С нужно делать методом простого архивирование а не выгрузкой так правильней?
А если база скульная то скульный бекап средствами скуля.
А выгрузка нужна всего лишь для перехода туда или обратно. И то не всегда рабочая схема при обратном переходе.

Хороший совет! Подскажите, пожалуйста, как мне тогда написать батник, чтобы выгрузить средствами скуля и загрузить в файловую ИБ тут же? Ну или как-то иначе получить что-то, чтобы загрузить в файловую ИБ?

(7) Почему такая необходимость все время выгружать из скуля и потом разворачивать в файловую?
У меня базы рабочие все на скуле и базы для разоработки все на скуле.
Базы размерами у меня 100 ГБ, 150 ГБ, 250 ГБ...

(7) Прежде чем задавать подобный вопрос определись с реальными размерами базы. Не всякая файловая прожуется нормально. Что-нибудь да выплюнет однажды.

Какая разница какой размер? Мне нужен именно *.dt, предложили, что все надо делать средствами сиквела. Вот я и спросил как, может я просто чего-то не знаю?

(9) Ну как только это однажды наступит поставит скуль, а сейчас что зря ресурсы компа занимать, если оно ниразу и не понадобиться

Сиквел стоит и база на нем. Но мне нужен *.dt. Так как средствами сиквела его получить?

(8) Бедность

(12) Ни как!
Добивайся чтоб у тебя скрипт срабатывал или выгружай по ночам сам ручками.
Как вариант каждый день скульный бекап загружай в копию и от него выгружай ДТ.

Таких людей не истребить. Тех кто делает бекапы выгрузкой в ДТ.
В данном случае не понятно почему автору именно так и нужно.
На вопрос зачем не хочет отвечать. Его право.

(15) я так делаю, потому что
а. у меня нет доступа к серваку и к бекапам (это владение админа)
б. у меня нет уверенности и гарантии в этих самых бекапах (админ проспал, что то зависло, место кончилось, и выясняется когда нужен бекап на определенную дату, а его нет)
в. Если нужна свежая копия проще развернуть из своего dt ника чем ждать и выпрашивать когда админ соблаговолит это сделать (у него времени нет, места нет, руки заняты, так как жопа чешется)

Так что иногда проще и надежнее дублировать систему бекапов с помощью выгрузки в dt

буквально недавно в филиале развалился рейд, а у админа последний бекап 2-х недельной давности. Благо за денюшку нам полностью восстановили всю инфу с дисков.
Вот и не делай после этого свои бекапы в dt формате

(16) и (17) все верно говорите. От себя добавлю: какая разница зачем, если он просто нужен?
Пока не получилось победить.
Сейчас проверяю, может какие-то сеансы не завершаются. Отпишусь.

(16) (17) (18)
Очередной и миллионный (об этом тут не раз говорилось) раз довожу до вас сведение которое известно всем 1сникам (или почтив всем).

а. Самый надежный бекап в скульной базе это скульный бекап. И его нужно делать всегда и даже в день по нескольку раз. тем более это делается в горячую не выгоняя юзеров с базы.
б. Самый надежный бекап в файловой базе это бекап сделанный архиваторами или виндовыми бекаперам  всю папку или файл базы (архиваторами).
в. Выгрузка в ДТ первую очередь именно для перехода нужен! Для бекапа выгрузку можно использовать конечно, но она не надежна! Для больших баз это даже невозможно.

Выводы:
1. Даже если  у вас нет доступа с скулю вы должны добиться чтоб бекапы админ делал постоянно.
2. Даже если вы не отвечаете это возьмите это на контроль. Хотя бы папки с бекапами у вас должны быть доступны чтоб следить делаются они или нет.

ПС я всегда добиваюсь доступ к скулю и при этом даже не отвечаю за бекапы. Потмоу что мне нужно для работы.

Я выгрузки в дт получаю если только сторонний клиент на шабашку вышлет базу от 0 до 1.5 гига. В развернутом виде если база не более 10-15 гигов.
Более жирные базы я пытаюсь сопровождать удаленно на ихнем сервере.
У себя на работе только все скульные. В любой момент можно выгрузить скульную и развернуть.
Или же достать бекап на любую дату за ближайшие месяцы или кварталы.

(19) "Самый надежный бекап в скульной базе это скульный бекап."
Надежный то он надежный, но вот не факт что из него получится поднять базу) С постгресом были заморочки такие, помнится. Там проблема в том, что какие-то определяемые типы в бэкап не попадали. В результате бэкап не ресторился, вылетала ошибка.

(21) Это не аргумент, чтобы не делать )

(21) Для таких случаев в нормальных организациях периодически базу со скуля подымают. При возникновении проблем срочно решают проблему с базой.
Это как регламент делается.

(21) + (23) "постгресом" принципиально не работаю с ней. У нас на них развернуты только периферийные базы в кассах магазина из-за не возможности развернуть MS sql express. Объем базы если больше 10 ГБ.

Ларчик открывался просто: удалил задание в планировщике, создал заново и все заработало. Без понятия почему так, изменения по факту вносил только в батник. Может планировщик хранит какой-то хэш и при изменении запускаемого файла перестает работать?

PS: я не знаю где вы живете и работаете, но из моей практики 90% не имеют ресурсов делать мощные сервера с резервированием, с реплицированием, с резервным контроллером домена, а у некоторых нет даже много места для бэкапов. Поэтому в большинстве случаем покупается внешний контроллер с FTP, делается *.dt локально и хранится 2-3 дня, и тут же заливается на FTP, где бэкапы живут 3-4 месяца. Дешево и сердито. Ну и если грохнулся сервак (и такое бывало) - на любой локальной машине разворачивается файловая база, расшаривается папка и работаем. Как из бэкапа сиквела восстановить файловую ИБ?

(19) "Довожу до Вас сведение которое известно всем 1сникам (или почтив всем)" - за два десятка лет (почти) ежедневного использования выгрузки в *.DT файл выгрузки оказался нерабочим... эээ... наверное, возможно, точно не помню сколько раз... три, ну может быть, четыре раза. Пара раз, точно помню, из-за "не совместимости" релизов платформы и три или четыре раза из-за выявления выгрузкой/загрузкой своевременно не обнаруженных проблем в самой базе данных. Не в качестве спора, просто информация к сведению.

(27) большинство на скульных базах сидят, и в этом случае зачем тратить час-два времени на бэкап в дт и столько же на восстановление из него, если можно потратить 5-10 минут на бэкап скулем и столько же на восстановление.

(28) при условии, что с восстановлением не возникнет проблем. Не у всех и не всегда проблем с восстановлением не возникает. Тем более, когда для восстановления из скульного бакапа требуется скульный комп, тот самый, единственный, который вышел из строя и его надо восстанавливать какое-то время, а пользователи лишились своей базы и не могут проводить отгрузку...

Понятно, что все нужно настраивать по серьезному, но далеко не всегда на это серьезное имеются в наличии ресурсы и средства.

PS: не самый надежный бэкап, а самый точный бэкап - "Использование этих способов дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы"(методисты 1С)

(28) Допустим, пример нормального решения это когда у клиента установлено два сервера : один - прод и второй - разработческий.
При возникновении проблем на прод-сервере, разработческий тут же переводят в доступ для пользователей,
поднимая там самый свежий бакап, который только возможно сделать.

(28) У каждой организации свои тараканы на чердаке. Например, есть такие, где программисты 1C не имеет доступа к серверам SQL и скульным бэкапам баз данных, а также им запрещено создавать базы данных "для разработки".
Или, например как у меня было, - РИБ и зоопарк на филиалах из файловых и скульных баз на узлах.

(15) >Таких людей не истребить. Тех кто делает бекапы выгрузкой в ДТ.

В DT это самый надежный вид бэкапа 1С
Бэкап средствами sql он ненадежен, фоновое или юзеры не выгнанные запросто могут писать в базу в момент бэкапа и будет ошибка в данных
например 1С не будет запускаться или будет но не полностью, разные глюки типа форма списка документов определенного (наиболее частого типа реализации) не открывается после разворачивания

Если вы с подобным не сталкивались то поздравляю

"Если вы с подобным не сталкивались то поздравляю" спасибо, не сталкивался, никто из знакомых не сталкивался и не слышал чтобы кто-либо вообще с подобным сталкивался, поскольку механизм бэкапа скуля исключает указанные проблемы. ну если конечно только сама конфа не кривая в усмерть и не делает без транзакции связанные логически операции и бэкап в аккурат в средине такого бутерброда случился.

(34) "механизм бэкапа скуля исключает указанные проблемы"

Для начала какого именно скуля? IBM DB2, Oracle, PostgreSQL?
Во вторых хорошо когда запись осуществляется в одной транзакции например для доп.реквизитов.
А вот для доп.сведений это уже не так и запросто бэкап может срезать захватив только часть общей сущности 1С.

У нас PostgreSQL и ни в коем случае опытным путем выяснили что нельзя делать бэкап средствами SQL в момент реструктуризации (например при обновлении конфы) - сбой 100%
И нежелательно делать бэкап средствами sql если в базе работающие пользователи или фоновые, которые в этот момент пишут - тут бывают сбои вероятность ~20%

(36)+ Причем бэкап средствами sql в момент реструктуризации чреват ее сбоем-незавершением и битой-нерабочей базой
Хорошо хоть сам бэкап обычно рабочий

с постгри не работал.
ну и делать бэкапы в момент реструктуризации базы... несколько странно. если только не ставить целью выявить потенциальный сбой.

(38) Бэкапы средствами sql делаются автоматически по расписанию ежедневно
Обновления с реструктуризацией когда в голову взбредет и человек делающий обновления даже может не знать про время sql бэкапов

(33) А почему фирма 1С не знает что DT бекапы - самые надежные и рекомендует их использовать только для переноса?

(39) Даже в этом случае бекапы делаются без всяких проблем и разворачиваются.

(40) Какая именно часть фирмы 1С? Ты в курсе сколько там подразделений/отделов и сотрудников?
В какой год и для каких конкретно версий платформы и sql рекомендует?

ЗЫ Все франчи с которыми работал просят только DT

(41) Разворачиваются не всегда, и не всегда после разворачивания они полностью работоспособны и содержат правильные данные

(42) официальный сайт ИТС об этом сообщает. А по поводу франчей - так это не удивительно. У клиента может быть постгрес, или разные версии скуля, а дт в этом плане универсально.

(43) ни разу не сталкивался с подобной проблемой, а вот с корявым ДТ очень даже сталкивался

(45) Корявость DT видна сразу
Корявость же бэкапа средствами sql или копирования файловой можно обнаружить слишком поздно

(46) "Корявость DT видна сразу" - а вот нифига, ты делаешь бекапы, думая, что они тебя выручат, а когда случается задница он тупо не разворачивается.

(44) Ты про https://its.1c.ru/db/metod8dev/content/2922/hdoc ?


там "можно рекомендовать" иные кроме DT
и DT не запрещают а просто говорят о недостатках его

а что делать будете, когда одна из таблиц станет больше 4гигов?

при этом бекап будет делаться, а вот загружаться нет, если мне не изменяет память

Корявость ДТ - это гарантированные проблемы в базе, которые рано или поздно необходимо найти и устранить. Корявость базы при наличии скл-бакапа позволяет жить достаточно долго.

Но когда-то приходится сделать попытку обновления релиза конфы или релиза платформы и в этом момент оказывается, что с базой проблемы, о которых никто ничего не знал.

(49) У нас бэкапы делаются и средствами sql и в dt ))

Например, я делаю выгрузку в ДТ периодически чтобы протестировать, что такая возможность существует и она рабочая.
Если оказывается, что выгрузку в ДТ внезапно невозможно сделать или восстановить базу из ДТ невозможно
- объявляется о необходимости поиска проблем и устранения неполадок в базе.

Но регулярные бакапы идут в скульном режиме.

(53) ++

(53) "поиска проблем и устранения неполадок в базе" - таблицу режете, когда пухнуть начинает?) Часто возникает такой косяк, когда картинки хранятся в базе, по крайней мере в старых конфах.

(53) Только не забыть о регулярных тестированиях скульных бэкапов, путем их разворачивания на тестовых базах и хотя бы глазками

(50) в скуль будет загружаться

(56) ну так активируемые скульные бакапы у разработчика в работе. Разраб актуальные копии базы именно так и получает. И выгрузку ДТ для тестирования из скульной копии тоже делает.
Затем на копии и диагностику делает. Если затем потребуется, то и на рабочую уже в особом режиме.

интересно, а с базами 500гигов и более, так же с дтшкой любаетесь?)

(59) А какая разница?

(60) ограничение размера таблиц для ДТ и время выгрузки/загрузки как минимум, а так же если контора работает 24/7 как вы планируете ДТ делать?

жаль саперов. они не придумали собственной уникальной выгрузки в проприетарный мега-формат многотерабайтных баз, а доверяют ненадежным SQL бэкапам.

(61) ну так речь о том, что выгрузка в ДТ не делается с рабочей базы.
Ясное дело, что выпоняется на скульной копии для диагностики и/или решения каких-то вопросов с переводом базы в другой режим и т.д.

интересно было бы с моей рабочей базы 7.7 сделать выгрузку-бэкап))
если бы не ограничения на размер платформы, в результате чего это технически уже давно невозможно..
просто любопытно сколько это времени бы заняло. неделю? две?

Ожидаемо это опять вылилось в "бекапо-срач".
DT vs sql-Backup

Я вот долгое время считал что дт-выгрузка это и есть бекап для файловых пока тут пару раз не натолкнулся на такую ветку спор.
После этого пересмотрел свои взгляды на это.

(64) после того как база перестала штатно выгружаться в dt пора что то делать давно
или свертку базы или админов-1сников менять
ибо это первые признаки "говнорешений" и "говнокода"

ваша база/конфа тупо превысила возможности платформы 1С
надо или туда ее укладывать (обрезка, разделение на несколько) или переходить с платформы 1С на нечто большое

(66) "ваша база/конфа тупо превысила возможности платформы 1С" -превысила возможности штатной выгрузки/загрузки ДТ, не более того.

и это не значит, что есть "признаки "говнорешений" и "говнокода"" - а лишь, то что много данных в одной таблице, иногда это необходимость.

при этом база вообще может быть на замке, типовая

(68) Нет такой необходимости.
Ибо это архитектура (метаданные) конфы кривые что одна таблица превысила.
Или регистры не закрываются или файлы/картинки в базе вместо того чтобы на тома их или еще что.

Если это реально данных столько (при правильной их организации в БД) то пора с 1С уходить на нечто иное.

(70) это возможность типовой конфы, хранить двоичные данные в базе, в том числе сканы и т.д. Так же появляется возможность штатными методами скуля бекапить все это дело.

(39)>>когда в голову взбредет и человек делающий обновления
Административно упорядочить его/их работу вообще не представляется возможным?

(72) А смысл?
Просто ввели в правило что перед обновлением, после выгона/выхода всех сначала сделай выгрузку в DT
И уже затем обновляй конфу

Многопоточная загрузка из dt в ИБ ощутимо ускоряет процесс, начиная с 8.3.19.
То есть, от технологии dt вендор не отказывается, наоборот, развивает, может и выгрузку тоже ускорят.

(73) Я про это и говорю. Чтобы человек имел представление о своей ответственности.

(75) не, ну понятно, что выгрузка в ДТ может и не единственно возможный и правильный способ диагностики здоровься базы, но он достаточно универсальные, особенно, если это базы не по 500 гиг ;-)

+(74) Правда, в определенных случаях тоже может быть не все так радужно https://infostart.ru/1c/articles/1595040/
Особенно с PostgreSQL под Windows и (предположительно) при нехватке вычислительных ресурсов.
(76) В этой статье именно такими размерами базы и оперируют )

(61) Где об этом почитать, а то первый раз слышу и свою базу 150+ гигов спокойно в dt выгружаю

(78) Вот про эту ошибку пишут, можете погуглить на тему https://forum.infostart.ru/forum81/topic49539/

(79) Для вас действительно нет разницы между 1CD файлом и dt?

Для DT нет никакой информации что у нее есть ограничения внутренних таблиц (ну разве ограничения ОС). По крайне мере я не свстречал

в *.bat не должно быть номера версии 1с

(80) вот пожалуйста https://infostart.ru/1c/articles/200268/
Для меня есть разница, прикол в том, что если у вас скульная база, то внутренняя таблица может быть более 4гигов, а когда вы ее пытаетесь загрузить в файловую, то о боже, создается файл 1CD который вас пошлет на 3 буквы образно при загрузке.

(81) в общем это проблема при разворачивании ДТшки в файловую базу

(83) ?

(84) а причем тут разворачивания в файловую?

Речь вроде о том что нельзя скульную базу в 500Гиг выгрузить в DT, так как - "ограничение размера таблиц для ДТ "

Вот я и спрашиваю где почитать про эти ограничения
Причем тут файловая?

(86) ну а смысл делать ДТ, если не планируется переход на другой скуль (на тот же постгес, или даунгрейд скуля), или использование файловой базы?

(87) смысл в том, что битая база в ДТ без ошибок не выгрузится. А если попыток выгрузить в ДТ не делается, то можно даже и не узнать о том, что база битая, своевременно.

(88) о том и речь, это не инструмент для бекапирования рабочей базы. А лишь дополнительный вариант тестирования базы и инструмент для перехода на файловую, или иной скуль не поддерживающий скульный бекап.

(70) ну вы то разумеется лучше знаете о необходимостях неизвестной вам организации неизвестного профиля с неизвестными требованиями руководства и регуляторов ))

в общем, дело ваше, как хотите, так и грузите, хоть акронисом зеркало сервака делайте с базами данных, тут вся ответственность на вас, любайтесь как хотите)

(91) тут вопрос только в том: должна рабочая база без проблем выгружаться в ДТ файл или всем должно быть безразлично, что ДТ выгрузка сломалась и больше не работает

некоторые полагают, что ДТ выгрузка должна быть работоспособной и это является признаком, что критичных повреждений у базы нет.

(93) а разве ТИИ не решает эту проблему? У скуля так же есть возможность делать CHECKDB штатными методами

я имею в виду проверку базы на критические повреждения. Зачем именно ДТ для этого использовать?

(95) Просто люди к этому привыкают.
Представляешь они сразу решают 3 проблемы ))
1. Делают бекап
2. Узнают что база "условно" нормальная.
3. Экономят место на диске.

А еще в случае чего всегда можно развернуть копию или отправить спецу по почте.

Исходя из наших тут рассуждений получается такие случаи.

1. База файловая  и пока есть возможность выгружать в ДТ.
2. База скульная и пока есть возможность выгружать в ДТ, хотя в скуль-бакап тоже модно и нужно.
3. База скульная и уже нельзя выгружать в ДТ, хотя база цельная без ошибок но увы уже ограничения есть.

И большинство 1сников выбирают 1-2 пункты. потому что этого во первых позволяет база и во вторых они просто привыкли.

* модно = МоЖно...

(97) ограничение в 3ем случае при попытки разворачивания файловой базы из этой ДТ

При некотором размере sql базы выгрузка в DT уже не пашет
Ибо хрен дождешься в отличие от средствами sql

но сам факт, если нужно делать бекапы быстро, не выгоняя юзверов, так же с возможностью полного резервного копирования, то ДТшки уходят на второй план. Если же использовать только ради тестирования, то для этого есть и другие штатные инструменты 1с и скуля. ДТ можно использовать, когда базы файловые и частые бекапы не нужны. Потеря данных не такая дорогая для конторы. Либо для перехода на скуль/файловая.

(100) "Ибо хрен дождешься в отличие от средствами sql" - о том и речь, еще и монопольный доступ нужен.

(95) Были моменты, не знаю насколько это актуально на текущих релизах платформы, но раньше такие моменты были, что никакие другие способы не показывали, что проблемы есть.
А ДТ показывала.

Мало того, был период, когда ТИИ даже повреждала базу, но ДТ нет повреждала.

И само собой понятно, что когда база файловая, то никакого ДТ не требуется именно для архивации. Но вот некоторые глюки выгрузка загрузка вылечить позволяла.
Но повторюсь, что так было на старых платформах. Что там в новых, которых параллельно ведут несколько веток - х.з.

(0) а версия винды не изменялась?

У клиента на серваке подгорела планка памяти (то ли 16 гигов, то ли 32 из 128, не  ECC), админы делали копии средствами скуля. То что база убита узнали спустя полтора месяца, когда все внезапно встало колом (в рознице). В итоге, бекапы есть но бесполезны. Отрубили контроль остатков, нашли живой бекап и с рабочей перетаскивали недостающие данные или восстанавливали доки по клиент банкам/бумагам и т д. Выгрузка в ДТ с рабочей базы сразу не проходила, вываливалась с ошибками. Но ее никогда не делали, база то большая, 200 гигов, "скулем же удобно делать, можно никого не выгонять"

(105) А что ты мне посоветуешь делать? У меня база розницы 2. Объем почти 250 ГБ.
В Дт вряд ли выгрузится и загрузится.

(106) выгрузится, только долго.
360 гигов как-то в дт выгружал и обратно

(106) Посоветую понять что там в этих 250 ГБ?
Оно точно надо? Нельзя ли это выкинуть совсем или просто отдельно хранить а не внутри СУБД?

(108) я ему это просто писать не стал) сам он парень взрослый, разберется.
Добавлю только что постоянно делать автоматические бекапы это очень хорошо, а вот периодически их проверять что они рабочие (и по хрену как создавались) - это должен быть один из ИТ регламентов

(108) (109) Я то знаю что там внутри. Я как раз чистил мусор там.
База с 250 ГБ теперь стала  95 ГБ

+ (110) Просто я не замарачиваюсь на выгрузке в ДТ уже давно.