Чтобы если один вылетит, можно было перейти на второй в течении 1-2 часов.
MS SQL Express 2019 умеет в репликацию?
1С поддерживает репликацию?
Как вариант можно делать бэкапы и копировать их на другой сервак, по идее.
Разностные в течении дня.
MS SQL Express 2019 в бэкапы уж точно умеет.
Кто делал что-то подобное?

А в чём проблема? Средствами скуля сделать репликацию - час работы...

Есть варианты: можно репликацию SQL, репликацию виртуальных машин.

Хм. Вот зачем это одинэснику?

(0) Делать бэкапы и потом поднимать их - это не репликация. Изучи матчасть.

(0) за 1-2 часа можно развернуть заново сервер и поднять бэкап БД
Давно смотрел в эту сторону, если правильно помню, как средство резервирования репликация не сильно подходит т.к. если упадёт основной, то адресата специально придётся выводить в самостоятельную работу

В результате выработалась примерно следующая схема:
Основной: SQL+1С полностью рабочие
  утром (около 4:00) - полная копия
  каждый час (с 5:00 до 23:00) - разностная копия

Запасной: SQL работает, Сервис 1С спит
  утром (например в 4:40) - копируем с основного полную копию и скриптом грузим в БД SQL (если что посмотреть, то есть вчерашняя копия и её быстро можно восстановить)
  каждый час (5:30 - 23:30) - копируем разностные копии

+ на обеих серверах ограничиваем глубину хранения данных на основном 2-3 дня, на запасном около 14 (на случай посмотреть что творилось в БД, например, в прошлый понедельник)

Если упал основной сервер, то у нас теряется по максимуму последний час работы, восстановление работоспособности 1С - примерно 20-30 минут, при удачном стечении обстоятельств - около 15 минут

Если критичен лаг потери данных, то можешь организовать разностную копию через 30 минут ну и копирование через каждые 15 минут.

При копировании сбрасывай флаг Архивный у файлов, тогда не будет гоняться по сети весь объём копии, а только последние изменённые файлы (в идеале 1 последняя копия)

(0) Postgre поставь, он это умеет (WAL).

(5) "за 1-2 часа можно развернуть заново сервер и поднять бэкап БД"
И какого у вас размера ДБ, что за час-два разворачивается из бэкапа с подъёмом сервера?

(0) Самый простой в настройке вариант, это AlwaysON. Позволяет иметь всегда актуальную копию базы на другом сервере. Можно настроить автоматическую отработку отказа, когда при выходе одного сервера из строя всё автоматом переключается на другой.
Только говорят, что по быстродействию не самый хороший вариант. Гилёвцы для 1С рекомендовали репликацию Log shipping.

Express никакой репликации и тем более AlwaysOn не умеет. С ним, по моему, только через backup/restore. Можно днём перегонять только журналы транзакций, днём полный бэкап.

(7) +1 за  Log shipping, но версия MS SQL должна быть выше Express редакции.

(7) в развёрнутом виде 30 Гиг, в бэкапе 5.7
Если есть резевный комп, готовый образ винды и выгрузки (бэкапы), ничего не мешает поднять новый сервер за 1 час
Если озаботиться сохранением выгрузок на внешний диск, то и доставать с поломанной машины ничего не понадобится, просто подключаем и забираем недостающие бэкапы (если диск не долбануло при выходе из строя основного сервера, для того и нужно копирование на запасной сервер)

(10) "в развёрнутом виде 30 Гиг, в бэкапе 5.7"
С учетом того, что ТС помянул express, соглашусь с вами. Но в общем подобные оценки времени выглядят очень оптимистично. Вот у меня более 3Тб нужных баз. И это совсем не 1-2 часа на поднятие из бэкапа.

(0) https://docs.microsoft.com/ru-ru/sql/linux/sql-server-linux-editions-and-components-2019?view=sql-server-ver15
Вот тут пишут, что express не имеет никаких возможностей репликации. Так что только через backup/restore.

(11) Тут всё зависит от требований к времени восстановления, в Вашем раскладе я бы разбросал по нескольким серверам критичные БД и прописал в регламенте восстановления БД1/Сервер1 - Резервный Сервер2, БД2/Сервер2 - резервный Сервер3, БД3/Сервер3 - резервный Сервер1. Вероятность поломаться одновременно 3-м компам не очень большая, а если их ещё разнести по разным помещениям или хотя-бы стойкам ещё меньше.

Т.е. если что-то сломалось идём на указанный сервер и поднимаем из копии БД (копии туда уже сложены или загружены средствами SQL), в штатном режиме блокируем работу с резервной БД или чистим оную (что-бы не получить "А я случайно не туда данные внесла").

У такой схемы есть преимущество - не нужно думать чем занять резервные сервера на время штатной работы основного

База 10 ГБ (база и лог) в модели Симпл.
Ну да, там Экспресс.
Придется, видимо, через бэкап.

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

Кластер серверов.
http://catalog.mista.ru/public/907443/

(13) с таким объемом я бы не о репликации думал, а о редакции SQL. В итоге встанут колом оба сервера.

(13) >> База 10 ГБ (база и лог) в модели Симпл.
Посмотрите размер самой базы. Без лога. Как бы не влететь в проблемы неожиданно.
МС пишет (ссылку я давал выше):
Максимальный размер реляционной базы данных    10 ГБ

А чем лучше бы синхронизировать FTP на серваке с IIS кто подскажет?

(16) говорю же - с логом вместе

(18) лог может и 100мб весить, тогда час Х придет очень быстро

(19) не, лог там намного выше базы, смотрел

(16) посмотрел 3 и 3.5 базы там.

Причем это где-то за 3 года эксплуатации такие объемы.

А чем клиенту/автору РИБ не нравится?

(23) это же его кто-то должен попробовать. Наверное, еще не пробовал.

(23) Проблема в 2-х одновременно работающих серверах, велика вероятность события "Ой, не туда внесла", либо делать ДМЗ и прятать туда вторую БД

(25) Все пользователи работают только в одной базе. Это легко организовать.

(22) сколько же средний чек у него, за три года такие объемы - накладная в сутки чтоли?

(23) гм, это идея. Но типовые в РИБ разве гоняют все данные? Там вечно забывают какой-нибудь объект включить в план обмена. Не, усложнение на пустом месте.

(27) думаю, чеков 20 за день, на сумму 50к в день.

(28) нет, конечно. Первичный образ можно устроить из копии базы - данные будут абсолютно идентичные, а дальше нужно просто посмотреть абсолютно все будут обмениваться данные или нет.
Как правило, в конфигурации Полный РИБ есть.

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

Поставить PostgreSQL и настроить реплику

(0)План обмена в фоне средствами 1с.

(17) rsync

(31) > ставим в базу подписку на запись
О, еще один любитель общаться с внешними системами из транзакций.
А потом следующая подписка отменяет транзакцию и ты можешь засунуть всю "релмикацию" именно вот туда.

^"репликацию"

Давно было.
1. база 1с77 на скуле 2000
2. Полный бекап ночью в 3 часа
3. Днем каждые 15 мин разностный бекап.
4. Бекапы делались сразу на два сервера.
5. основной сервер имел диски с горячей заменой и был с избытком в один диск. (Hot Swap и Hot Sрear) так вроде звались.
6. Что бы не переименовывать имена на сервере использовал псевдонимы имен  DFS.
В тесовых переходах успевали перейти на новый сервер в 40 минут с потерей данных в 15 минут.

Но реальный аварийный переход я устроил за большее время. Ошибка в том что в спешке я указывал старый сервак в место нового или на старую базу не помню.
Тут нужно быть очень собранным и внимательным!

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

Я не фанат РИБ, но... имхо:
Бэкапирование/репликация средствами SQL информационных баз 1С увеличивает вероятность возникновения недостоверных / противоречивых / разрушенных данных с точки зрения 1С при воссоздании копии базы. Чем чаще используются механизмы SQL (по расписанию) - тем выше вероятность. Например, документы без движений или движения без документов; записи справочников или документов без табличных частей; объекты, не включенные в журналы; неверно индексированные, битые служебные данные и т.д.

С этой точки зрения (получение непротиворечивых данных в базе) механизм РИБ платформы - более предпочтителен. Этот механизм платформы всё-таки функционирует в парадигме 1С и с учётом её правил работы с объектами. Низкая вероятность возникновения противоречивых/разрушенных данных доказана многолетней практикой использования РИБ в 1С.

(0) Чтобы если один вылетит, можно было перейти на второй в течении 1-2 часов

Вылетит по какой причине? Может всё-таки лучше тщательнее проработать вопрос бэкапирования? Сервер понадёжнее там, RAID, положить БД, журнал транзакций и архивы БД на отдельные физические диски, и вот это вот всё

(38) Не может. Согласно документации вендора, порядок выполнения подписок неопределен.
См, например, https://its.1c.ru/db/v8313doc#bookmark:dev:TI000000212 : третий пункт после "При наступлении указанного события выполняется следующая последовательность действий"

Возражения "а вот на практике, у меня" можешь сразу отбросить. Потому как расширения разных типов (исправление/адаптация) и т.п.