Евгений Грибков

посмотрите в сторону темпоральных таблиц: https://docs.microsoft.com/ru-ru/sql/relational-da...

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

можно так:
1) создать резервную копию
2) скопировать в шару, дав доступ полный пользователям, под которыми обе службы скульные работают
3) восстановить на втором сервере
Это все можно автоматизировать-лучше делать через планировщик винды с помощью задания, а там PowerShell-скрипт впихнуть, т к п.2 без CMD сложно сделать.
Также можно вообще свой сервис написать, который будет все это делать с настройками в отдельном конфигурационном файле. Если есть время и желание, то можно и морду сделать настройкам и индикатор выполнения

Зависит от того, сколько в среднем в секунду проходит запросов и сколько памяти потребляет каждый запрос. Можно отталкиваться от следующей конфигурации:
1) 8 ядер под скуль-16/32 ГБ ОЗУ скулю+4 ГБ оставьте ОС
2) 16 ядер под скуль-32/64 ГБ ОЗУ скулю+8 ГБ осиавьте ОС
Для 1С выключите многопоточность в свойствах скуля (max dop=1), т к 1С с многопоточностью не дружит
И напомню, что лицензия Standard скуля больше 16 ядер и 128 ГБ ОЗУ не распознает.
Также можно в системных представлениях глянуть потребление памяти скулем. В свойствах скуля есть мин и макс для ОЗУ, выше привел макс, а вот мин сначала выставите в два раза меньше, чем макс, но не менее 8 ГБ (осторожно-там указывается в мб, а не в гб!).
По опыту скажу, что если 1С жрет больше 64 ГБ ОЗУ и 16 ядер мало, а пользователей не 1000+, то проблема в запросах.
П.1 приведенный выше подойдет под количество пользователей до 100 штук, при оптимизации можно конечно и до 500 штук
Меньше 16 ГБ ОЗУ под скуль боевой не советую, т к всякое бывает и пусть будет если что в запас, т к сейчас 16ГБ ОЗУ-это ничто как было 2 года назад 8 ГБ ОЗУ-ничто. Аналогично и про 8 ядер-также минимум советую.
А дальше уже смотрите из ситуации.
Если среда виртуальная, то проблем в расщирении вообще не будет. Если нет, то советую в будущем перейти на виртуальные среды

Выключите многопоточность в настройках скуля-эдванс и в свойстве max dop выставите 1, и всегда один запрос будет потреблять только один поток, а не запрашивать порой по 8 и более потоков, нагружая ЦП по максимуму