Есть база, выткнута в интернет работает там около 100 юзверей.
Подключаются к ней они тонким клиентом через веб сервер.
Стоит задача сделать второй, резервный сервер у другого провайдера, что бы там была копия с актуальность в час, лучше меньше.

Какие есть варианты(Пока на ум приходит, распределенка с основной базой и таскание sql бекапов с сервера на сервер)?

распределенка и скл бекапы как  то не вяжется

(1) там одно из двух, или одно или другое

Репликация sql лучше. РИБ проще.

(3) Именно репликация? Все он-лайн или есть возможность делать с определенной периодичностью? И какой ей катал нужен?

РИБ разумеется. Сеансы обмена с нужной периодичностью.
А зачем "таскание sql бекапов с сервера на сервер"?
Можно сделать подчинённый узел специально для "архива", без подключения пользователей к нему.

(5) Бекапы таскать что бы актуальную базу в копии иметь. бекапы разностные конечно.

По РИБ сильного падения производительности не будет?

репликация живет до первого апдейта структурного - отвалятся служебные поля и надо восстанавливать

>По РИБ сильного падения производительности не будет?

там есть узкие места

(8) На что обратить внимание?

Копия базы по одной организации с обновлением раз в неделю

(10) Круто, я правильно понял, что бы все это хорошо работало, желателен вебсервис, с мгновенным ответом о том что изменения в копии приняты?

мы делать его не стали, пока так обходимся

(0) Реплика круче.

(13) (3) Какой вид репликации? При использовании проблем с регистрам замечено не было? Как конфигурацию обновляете?

(6) Падения производительности в РИБ - это не актуальный вопрос. Проблемное место - блокировки во время сеанса обмена. Причём закономерность: чем реже обмен - тем больше "проблем" с блокировками.

Если, например, выбирать между частотой обмена каждые 10-15 минут или каждые час-два, то я бы отдал предпочтение более регулярному обмену. Впрочем, имхо, частота обмена подбирается опытным путём между потребностью актуальных данных приемлемым количеством критичных блокировок.
Как-то вот так.

(13) РИБ гибче.

(14) Обновлением
(15) - спасибо, видимо буду делать обновление каждые 15 минут по web сервису

(17) Что происходит с кешом сервера 1С, на скуль которого прилетело обновление через 15 мин?

(18) туда обновление должно прилететь с данными

(17) Ок. В принципе, не критично сразу "угадать" с частотой проведения сеансов обмена. Ещё раз повторю: она подбирается по мере накопления статистики.

Кстати: в начала эксплуатации РИБ довольно быстро данные базы начинают "самоопределяться" на два "типа", конкурирующих между собой по праву актуальности.
Сложно сказал?
В базе всегда есть одни данные, для которых необходимо поддерживать высокий уровень актуальности и есть другие данные, поддержание актуальности которых непринципиально.
Вот в конфликте между ними и происходит определение "оптимальной" частоты сеансов обмена.

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

(0)
База 1 нужна только?
Размер базы какой?
Интернет трафик является ограниченным ресурсом?

(19) Обновление то прилетит, а кеш сервера 1С(тот что в папке reg_1541) сам не обновится. И как будет настроена репликация для таблиц без первичных ключей?

Я к тому что средствами sql репликацию для базы 1с не поднять.

(21) - база одна, размер за два года 12 гб, трафик не ограниченный ресурс
(22) Ага, спасибо.