Клиент-серверная 1С (8.3.10.2650)
Каждый день в 00:01 виндовый планировщик запускает cmd:

echo off

set dd=%DATE:~0,2%
set mm=%DATE:~3,2%
set yyyy=%DATE:~6,4%

set LogFile1C=D:\Anton\CMD\LOG\1c_%yyyy%%mm%%dd%.log
set LogFile=D:\Anton\CMD\LOG\umc_backup.log
set ArchivePath=E:\BackUp\1C\umc

echo --------------------------------------------- 1>>%LogFile% 2>&1
echo %date% %time:~0,8% Start CMD 1>>%LogFile% 2>&1
echo --- shutting down users --- 1>>%LogFile% 2>&1
"C:\Program Files (x86)\1cv8\common\1cestart.exe" ENTERPRISE /S "127.0.0.1\umc" /N "backup" /P "123" /AU- /DisableStartupMessages /CShuttingDownUsers
"C:\Windows\System32\choice.exe" /n /t 180 /d y
echo %date% %time:~0,8% --- restar services --- 1>>%LogFile% 2>&1
net stop "1C:Enterprise 8.3 Server Agent" 1>>%LogFile% 2>&1
net stop "SQLAgent$SQLSERVER" 1>>%LogFile% 2>&1
net stop "MSSQL$SQLSERVER" 1>>%LogFile% 2>&1
"C:\Windows\System32\choice.exe" /n /t 60 /d y
net start "MSSQL$SQLSERVER" 1>>%LogFile% 2>&1
net start "SQLAgent$SQLSERVER" 1>>%LogFile% 2>&1
net start "1C:Enterprise 8.3 Server Agent" 1>>%LogFile% 2>&1
echo %date% %time:~0,8% delete old files 1>>%LogFile% 2>&1
del %ArchivePath%\*.* /Q 1>>%LogFile% 2>&1
echo %date% %time:~0,8% start 1C backup 1>>%LogFile% 2>&1
"C:\Program Files (x86)\1cv8\common\1cestart.exe" CONFIG /S "127.0.0.1\umc" /N "backup" /P "123" /DumpIB "%ArchivePath%\umc_%yyyy%%mm%%dd%.dt" /AU- /DisableStartupMessages /Out %LogFile1C%

echo %date% %time:~0,8% Stop CMD 1>>%LogFile% 2>&1

Все прекрасно работало с ноября прошлого года. На днях увидел, что с 12/01/2018 бэкапов нет. Вечером 22го запустил cmd руками, все отработало, бэкап создался. 3 дня все работало на автомате, сегодня ночью бэкапа опять нет.
Смотрю ЖР: backup зашел в 1С, завершил работы всех "висячих" пользователей, вышел, зашел в конфигуратор и тут же вышел. Никаких сообщений об ошибках нет. В 1С log-файле, который создает конфигуратор - пусто.

В какую сторону копнуть, что то ума не приложу?

(0) феерический п...ц

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

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

и все предыдущие, так же битые из=за какой-нить ошибки в иб.

(2) скулю перезапускается исключительно из за его привычки жрать память
(3) с чего вдруг выгрузка базы средствами конфигуратора теперь стало битыми бэкапами?

(5) даже 1с официально заявляла неоднократно, что выгрузка - это не бэкап.
При наличии скуля - это просто выше всякого понимания, как говорится-
"вон из профессии!"

"виндовый планировщик запускает cmd: " - у пользователя под кем запускается пароль не меняли?

(7) нет, и после ручного запуска 3 ночи бэкапы на автомате же делались. А сегодня ночью опять пусто.

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

настройте бекап на скуле, как Вам уже советовали. DT это не бекап. Не стреляйте себе в коленку.

(9) есть много случаев когда скульный бэкап не грузиться обратно в скуль.
Давайте по существу, а не философию

(8) запусти вручную виндовый планировщик, а не cmd

(0) Про "феерический" уже сказали. И правильно.
По теме: возможно, мешают фоновые задания.
(11) "есть много случаев когда скульный бэкап не грузиться обратно в скуль." - где такие сказки пишут?

(12) И что мне это даст? Я же в ЖР вижу что служебный пользователь зашел в конфигуратор (логично что cmd работает)
(13) Тогда бы в 1С log файле было бы:
"Ошибка исключительной блокировки информационной базы.
Активные сеансы и соединения:", а он пустой.

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

выгрузка в dt это средство транспорта бд между разными СУБД. то что вам понравилось в ней бекапить - не освобождает вас от всех грехов этой методики.

ну а планнер? ну заходит он в
"C:\Program Files (x86)\1cv8\common\1cestart.exe" CONFIG /S "127.0.0.1\umc" /N "backup" /P "123" /DumpIB "%ArchivePath%\umc_%yyyy%%mm%%dd%.dt" /AU- /DisableStartupMessages /Out %LogFile1C%

в LogFile1C то что пишется?

(5) 1С заявило.
Читать до прояснения http://catalog.mista.ru/public/173494/
Где то на просторах сама 1С это признала.

Выгрузка в dt - ПЛОХО - Долго формируется, требует монопольного доступа, не сохраняет часть малозначительных данных (таких как настройки пользователей в ранних версиях), долго разворачивается.

(15) В те дня когда dt создается в нем: Выгрузка информационной базы успешно завершена
Когда dt не создается - в нем пустой от слова совсем. сам log файл создается

+ Порой dt теряет и не малозначимые данные... :)

Все ругают выгрузку в .dt, но не понятно, а каким ещё способом можно мигрировать между файловой/локальной копией и sql версией. И если .dt так ужасен, то почему собственно миграция между ними не считается фатальной?
У нас бэкапится и так и так - SQL ежедневно и лог транзакций каждые 15 минут, а .dt еженедельно и на длительный период хранения. Захотелось бухам посмотреть что было в базе два квартала назад - запросто.

(19) Если есть SQL, то средствами SQL.
Бекап SQL тоже разный, есть :)

(0) Может стоит паузу организовать? Что-то там не до конца стартовало?

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

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

(21) ну а как он тогда зашел в конфигуратор?

(24) Возможно какая-то служба(скуль или 1С) перезапускается в момент выгрузки dt? Другим заданием например.

(16) https://its.1c.ru/db/metod8dev/content/2922/hdoc
Это не признание, а рекомендация. Настоятельная )

(24) прочел кэш, на запуск и логон хватило. а дальше шиш.

(19) > Захотелось бухам посмотреть что было в базе два квартала назад - запросто

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

(25) ну если только у админов, что то там твориться о чем я не в теме. В ЖР:
25.01.2018 0:05:32    backup        Сеанс. Начало        
    MirServer                
    Конфигуратор    1            
25.01.2018 0:05:32    backup        Сеанс. Аутентификация        
    MirServer                Имя: backup, ...
    Конфигуратор    1            
25.01.2018 0:05:33    backup        Сеанс. Завершение        
    MirServer                
    Конфигуратор    1            

Зашел и тут же вышел...

(29) перед входом в бд поставь строчку
ping -n 1 -w 10000 127.0.0.1 >nul
или sleep 10, если есть такой утиль.

+(30) дай отработать по графику. потом приходи с результатами.

(0) Под каким юзером запускается планировщик? Галочка есть что без логина запускаться?

Нормальный скрипт, че пристали к человеку. На большее он не способен.

Опять же, есть журнал работы планировщика. Там все зеленое?

1. лично сталкивался НЕСКОЛЬКО раз когда DT не загружается
2. SQL бекап дает возможность настроить модель восстановления на любое время (до секунды), это очень удобно когда нужно откатить на на сутки а всего на 10 минут
3. SQL бекап делается и восстанавливается НА МНОГО быстрее чем DT
4. SQL бекап настраивается проще чем DT

короче я не вижу ни одной причины быть автором САБЖА...

(3) бэкап Шрёдингера