Речь пойдёт вот об этой настройке (она находится в свойствах базы на закладке "Архивация"):

Подсказка #1 (откажитесь от dt)

Если у вас есть возможность настроить SQL-архивы в обновляторе для серверных баз - откажитесь от dt-архивов.

И если вы настроили SQL-архивы не ставьте галку "Делать ещё и DT-архив" без необходимости.

SQL архивы будут создаваться "моментально" и без блокировки базы (если только не требуется монопольный доступ для операции, которая последует за архивацией).

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

Подсказка #2 (настройте права учетной записи sql-сервера)

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

Прежде всего обратим внимание на то, что служба SQL-сервера (речь пойдёт об MS SQL) работает от имени некоторой учётной записи.

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

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

Права на временную папку обновлятора (по умолчанию это папка Data\Temp внутри обновлятора) могут понадобиться, когда архив сначала записывается во временную папку, а уже затем переносится в основную папку архивов. Такое поведение возможно, если мы настроили запись архивов в конечную папку от имени другого пользователя.

А что если sql-сервер находится на другой машине?

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

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

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

При этом использование сетевых дисков недопустимо, ведь в сеансе SQL-сервера на другом компьютере никто не будет подключать этот же сетевой диск (если вы только сами не позаботились об этом специальными средствами). Указывать нужно полный сетевой путь.

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

Подсказка #3 (copy-only)

Начиная с версии от 3 июля 2018 года обновлятор помечает создаваемые sql-копии как copy-only.

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

Такие копии являются изолированными от обычной последовательности резервных копий SQL Server.

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

При этом резервные sql-копии, созданные обновлятором, могут быть восстановлены из него же вот так. Это является альтернативой прямому восстановлению резервной копии, например, через SQL Server Management Studio.

Вывод: резервные sql-копии, которые создаёт обновлятор (начиная с 3 июля 2018 года) помечаются как copy-only, а значит не нарушают возможную цепочку архивов, которые могут включать в себя разностные копии. Это значит, что когда вы создаёте разностную копию базы, sql-сервер в качестве опорной точки (базы) никогда не возьмёт копию, созданную обновлятором, так как она copy-only. Вместо этого он обратиться к предыдущей полной копии базы, которая создавалась не как copy-only.

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

Подсказка #4 (восстановление sql-копий через обновлятор)

Вы всегда можете сами восстановить базу из её резервной sql-копии. Для этого нажмите на ней правой кнопкой и выберите следующий пункт:

При этом теперь обновлятор умеет восстанавливать в том числе серверные базы из копий, сделанных sql-сервером. Такие копии имеют метку full-SQL в своём имени.

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