Выгрузка базы в DT резко замедлилась в последних версиях платформы - причём, резко: вчера было терпимо по времени, а сегодня вдруг в 2-3 раза дольше.
Почему-то это касается только базы УТ11. Никто не знает ли - может, 1С в последних версиях что-то вкорячили в процедуру выгрузки базы в файл? Что-нибудь, наподобие предварительного тестирования/исправления? Может, появился новый ключик командной строки (в дополнение к /DumpIB) для отключения этих дополнительных операций, чтобы она не тупила часами?
PS
Только не надо опять про то, что "сама 1С не считает файлы DT тем-то и тем-то" - плииз!!!

Выгрузка базы в DT не является бэкапом.

(0) Попробуйте параллелизм в скуле включить

(2) Полагаете, что он отсутствует по умолчанию? Имхо, странно это было бы - но проверю.

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

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

(4) Если dt не бэкап "по словам вендора" = накой он нужен ващще?

(6) для создания подопытного пёсика

(6) dt - Data Transer
Файл переноса
(0) имеются вложенные двоичные данные в базе? типа файлов в хранилище? Там что-то с блочным хранилищем какие-то приколы были.

(6) Для переноса базы между файловой версией и разными версиями разных скулей

(2) Да, включён - стоит 5.

(10) Везде посмотрел? И в настройках скуля и в настройках ИБ?

(11) В настройках баз стоит 0. Но не 1.

(0) А как в DT выгружаете из конфигуратора? или ibcmd?

(13) Конфигуратор с ключиком /DumpIB.

(8) Судя по размерам таблиц (смотрели мы), двоичные данные существуют и много, но в базе нет никаких хранилищ двоичных данных. Но что даёт сие знание? - Мы же не можем их выкинуть из базы.

Запускайте выгрузку под профайлером sql, и смотрите, какие запросы тормозят. Может, там просто индексы плохие и их надо перестроить?

(16) Пробовали на копии сделать тестирование/исправление - на копии процентов 25%, вроде, выиграли, но это не то, чего бы хотелось.
Кроме того, что мы можем сделать, даже если найдём тормозящий запрос? Мы же на него повлиять не можем. И не понятно как индексы могут влиять на выгрузку? - Не дело выгрузки что-то там высчитывать - она же должна тупо брать таблицы as is, жать их как-то и кидать в файл.
Собственно, вопрос в том, не вкорячила ли 1С в последних(!) версиях какую-то лишнюю хрень в процесс выгрузки, и нельзя ли её отключить?

(17) >> не вкорячила ли 1С в последних(!) версиях какую-то лишнюю хрень в процесс выгрузки...

Вряд ли.
Но даже если и "да", то это никак не решает вам не поможет, т.к. никаких опций настройки параметров выгрузки в DT не существует.

>> , и нельзя ли её отключить?

Нет.

По сути вопроса ветки
Вероятнее всего неверны исходные данные.
Либо изменения были не такими быстрыми, как Вам кажется (вчера терпимо, а завтра ужас-ужас).
Либо изменения не были столь драматическими (не в 2-3 раза).
Либо изменилось что-то ещё, чего вы не видите. Например, есть какие-то проблемы со скоростью работы дисков, куда пишется бекап, или скоростью сети (если вдруг выгрузка делается по сети), или работает антивирус или фаервол (забыли настроить исключения или вдруг включили), и... ещё миллион разных причин, очень косвенно связанных с 1С, которые не видны на базах данных малых объёмов, но появляются на вашей УТ.
Для чистоты эксперимента разверните на этом же сервере архив вашей УТ недельной давности и посмотрите сколько займёт времени выгрузка в DT. Так же разверните отдельный инстанс платформы предыдущей версии и попробуйте ею сделать выгрузку из рабочей базы (лучше копии), а также из архивной копии базы.

Ну и "сама 1С не считает файлы DT тем-то и тем-то"... Чем угодно, но не бекапом.
Сможешь не благодарить.