Добрый день!
Есть у кого-то готовая строка ibcmd чтобы выгнать всех пользователей и выполнить выгрузку *.dt?
База клиент-серверная.
Благодарю.

(0) зависит от конфы и что значит выгнать

Сейчас я выгоняю так: "C:\%$EXEPath%" ENTERPRISE /S"%$1CServer%\%$BaseName%" /N%$1CUser% /P%$1CPassw% /DisableStartupMessages /C ЗавершитьРаботуПользователей
Выгружаю так: "C:\%$EXEPath%" CONFIG /S"%$1CServer%\%$BaseName%" /N%$1CUser% /P%$1CPassw% /DumpIB %$BackUpPath%%$FileName%

Мне сказали, что с помощью IBCMD все это можно сделать. Я почитал примеры, там нет такого, нашел только создать ИБ, загрузить ИБ и т. п.

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

ibcmd infobase dump --config="%tmp%\sb_demo.yml" "%tmp%\sb_demo_2.dt"

Не знаю можно ли ссылка на ИС статья про Автономный сервер. Часть 2 - утилита управления

(3) Вариант, кстати...
(4) Благодарю! *.yml сформировал, запустил строку - все сработало. А есть такое же выкинуть всех пользователей?

(5) >>А есть такое же выкинуть всех пользователей?
неа. и не будет. это ж служебная утилька для манипуляции базами и конфигами вне продуктива, когда у вас конфигов и баз дофигища и управление ведется пакетными командами, где нужна утилька ibcmd.

ibcmd help infobase > c:\ibcmd_help_infobase.txt

можно напрямую извращаться

в случае файловой 1Cv8.cdn

в случае серверной файлики .lst в
C:\Program Files\1cv8\srvinfo\reg_1541

Нашлось https://infostart.ru/public/202805/
Можно еще через ras/rac завершить сеансы.

(0) А бекап все же лучше делать средствами СУБД (если не файловая, конечно, да и ей тоже, копированием) - это мнение вендора!

(10) не перевирай плиз
мнение вендора дословно совсем не так и другой смысл

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

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

(11)
Использование резервного копирования в режиме 1С:Предприятия предусмотрено только для файлового варианта работы.
В файловом варианте не производится резервное копирование и восстановление журнала регистрации. Для работы с резервными копиями используется роль Администратор системы.
Администратор, от имени которого выполняется резервное копирование, должен иметь аутентификацию 1С:Предприятия.
Внимание! Не рекомендуется использовать в качестве резервного копирования выгрузку в файл .dt. Подробнее см. документацию по платформе:
https://its.1c.ru/db/v83doc#bookmark:adm:TI000000137.
И все-таки, вы ошибаетесь!

(13) Ты разницу между "лучше делать средствами СУБД" и "не рекомендуется в dt" + "рекомендуется средствами СУБД" ощущаешь?

(14)+ подробностями почему "лучше" и почему "(не)рекомендуется"

Выгрузка в dt она всегда консистентная.
Т.е. очень-очень редко бэкап из dt не восстанавливается.

А байка про админов и бэкапы в случае средств СУБД она совершенно не байка.
И самые грамотные/опытные не только делают бэкапы но и проверяют их на восстанавливаемость и работоспособность!

И вот в случае средств СУБД это нифига не лучше ибо читай (12)

(16)+ Например довольно часта картина когда бэкап sql он конечно восстанавливается на типовой БП3
Только вот журналы документов открываться не хотят в режиме предприятия, зависают с колесиком.

(11) стараюсь, не перевирать https://its.1c.ru/db/metod8dev#content:2922:hdoc
1С много раз высказывалось что dt нужно использовать только при смене формата базы, с файловой на серверную, с mssql на postgres. Про это можно почитать и на партнерском форуме.
(12) Никого выгонять не надо, sql сам следит за целостностью бэкапа. То что не надо его делать в момент реструктуризации - другой.
(14)(15) давайте без нюансов понимания, а ссылками на документацию?
(16) я имел дело с обратным, много раз видел битые dt и гораздо реже битые архивы Sql (и то проблемы, как правило, были с оборудованием)

(18) >Никого выгонять не надо, sql сам следит за целостностью бэкапа. То что не надо его делать в момент реструктуризации - другой.

Это не так.
Например 1С ТЧ для объектов хранит в отдельных таблицах и еще куча разных моментов, когда единый с точки зрения 1С объект хранится в нескольких записях sql в разных таблицах.
Конечно запись обязана происходить в одной транзакции, но есть разные особенности разных СУБД.
И да в этом mssql заметно надежней чем postgresql.

(18) > я имел дело с обратным, много раз видел битые dt и гораздо реже битые архивы Sql (и то проблемы, как правило, были с оборудованием)

я тоже много раз видел битые dt, но по ним сразу понятно что он битый
а вот битый или неконсистентный sql бэкап как проверить? он бывает даже восстанавливается но 1С не стартует, или стартует но внутри херняс

Все сделал, но столкнулся с тем, что при запуске IBCMD получаю: "не возможно запустить это приложение на вашем ПК"...
Кто-нибудь сталкивался?

Почему не запускался - не знаю, взял и скопировал файлик с другого сервера - все заработало. Итоговая строка выгрузки такая:
:: ~Основные параметры
SET $DBServer=<имя MSSQL сервера>
SET $EXEPath=Program Files\1cv8\8.3.20.1789\bin\ibcmd.exe
::это каталог, куда складывать *.dt
SET $BackUpPath=L:\1CDumps\83\
::это протсо какой-то каталог, который нужен утилите для работы
SET $DataPath=L:\1CDumps\StandAloneSrv\
SET $1CUser=<пользователь 1С>
SET $1CPassw=<пароль пользователя 1С>
SET $DBUser="sa"
SET $DBPassw=<пароль пользователя sa MSSQL сервера>

:: ~Создаем бэкап
SET $BaseName=<имя ИБ в кластере>
SET $FileName=%$BaseName%.dt
"C:\%$EXEPath%" infobase dump --db-server=%$DBServer% --dbms=MSSQLServer --db-user=%$DBUser% --db-pwd=%$DBPassw% --db-name=%$BaseName% --user=%$1CUser% --password=%$1CPassw% --data=%$DataPath% %$BackUpPath%%$FileName%