v7: Как организовать репликацию баз и таблиц 7.7 ? #711144

Подскажите, как лучше организовать. На каких технологиях и где почитать подробности. 1. Требуется сделать полное зеркало кучки баз 1С (для повышения надёжности и скорости восстановления после сбоев). SQL2012. Приглядываюсь к AlwaysOn availability Groups. 2. Хочется реализовать распространение отдельных справочников в несколько SQL-баз. SQL2012 и SQL2005. Возможно подойдёт SSIS.

никак.

юзай УРБД для всех своих целей

Репликация для 77 не подойдёт. Используй или зеркалирование или лог шиппинг

УРБД у меня и так есть. Для надёжности работы распределенной базы и требуется. Иначе слишком долго восстанавливать базы после потенциальных сбоев SQL-сервера. Да и обслуживание сервера временами хочется делать, а страшно даже обновления накатывать - вдруг не заведётся? Размер центральной БД уже за сто гигов, общий размер распределенной базы 240 гигов. Это без учета логов. Всего sql баз 7.7 с логами на одном SQL более 900 гигов. Если что серьёзное произойдёт, я ж это всё восстанавливать из бэкапов буду как минимум рабочий день.

Зеркалирование, на сколько вычитал в инетах, для SQL2012 считается устаревшей технологией, которая собирается исчезать в следующих версиях. Log shipping возможен. Но может кто даст наводку, где почитать вменяемую инструкцию в идеале в применении к 1С. По тому, что пока нашлось в инете, с наскоку настроить не удалось. Отдельно интересует толковое описание, как бы настроить распространение отдельного справочника по ряду SQL-баз.

странные желания ... ну юзайте внешнюю SQL таблицу и подключение к оной

логи прибивать. они не нужны.

репликация на сколько я знаю 1с не поднимает корректно. пробвали. где-то целое обоснование почему это невозможно есть

слишком долго это сколько по вашему?? из УРБД ЦБ можно сделать  в течении 10 минут неспешно

из ПБ пардон сделать ЦБ и любую ПБ из ЦБ . в любом варианте

10 минут? Пардон, а на что там тратить 9 из этих 10? :-)

это вместе с чаем. и получение пиз..лей от руководства.

А что мешает делать бэкап-ресторе планировщиком периодически?

Это ко хотелке про распространение отдельного справочника? Этот справочник будет иметь множество ссылок на другие, относительно редко меняемые справочники в базе. Но для него отдельно нужно устроить обмен не реже раз в пять минут. А желательно даже быстрее. Вот и хочу отключить для него штатный обмен УРБД и поднять средствами sql. Старые обоснования, связанные с тем, что SQL добавлял поля в таблицы для работы репликации, я помню. Но сейчас, вроде, есть другие решения. ПБ не имеет внутри всей информации ЦБ. В случае гибели базы ПБ можно поднять её ночной бэкап, но непонятно, как синхронизировать изменения за полдня с ЦБ. Почкование ПБ из ЦБ штатными средствами делается где-то сутки. Проверено. А если предположить, что физически вышел из строя SQL-сервер, приётся поднимать из бэкапов огромное количество баз из ночных бэкапов и журналов транзакций. Это часы простоя.

По центральной базе, например, за день выгружается порядка гига журналов транзакций. И это с учетом того, что SQL2012 их архивирует раз эдак в пять. Восстановление бэкапа на произвольный момент времени дня занимает два-три часа. Это, конечно, самая большая база, но и остальные тоже восстанавливать придётся. Опять таки прихожу к тому, что время простоя от полудня до рабочего дня.

Прибивай логи, не прибивай... У меня одних mdf более семисот гигов.

У тебя стоит полный лог на базах скл?? зачем?

вообще то SQL поддерживает подключение к множеству баз ... кто мешает создать отдельный , еще раз повторюсь , внешний (не 1С) справочник БД и оттуда забирать/писать ? ЗЫ базы 1С бэкапировать стандартными средствами (хоть каждые 30 минут) SQL

Варианты с выносом баз на отдельное проблемоустойчивое хранилище и доступом к нему по какому-нибудь iSCSI не проходит по бюджету. А как? У меня более десятка филиалов в единой распределенной базе. Более 20 тысяч документов в месяц. Если при сбое SQL помимо нескольких часов простоя на восстановление я потеряю еще и документы за полдня, меня руководство убьёт в особо извращенной форме.

почкование SQL делается где то ниразу не сутки - средствами SQL

создание ПБ в SQL

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

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

Сбой SQL, это когда, например, на SQL сдыхает диск. Или мать. Или дохнет БП, унося с собой половину железа. Нет, конечно, железо у меня хорошее. И зеркало в рэйде. И дисков пачка... Но всё равно руководству нужны регламенты для разных случаев.

"кто мешает делать быкап ресторе постоянно на резервный сервер" А чем это принципиально отличается от Log shipping ? :)

тересный вариант , а по методу объединения и минимизации данных - идти не пробовали ? например стандартная УРБД с объединением в центр где (в центре) никто не работает , а данные передаются в отдельную базу с схлопыванием аналитики, опять же - отчеты на прямые запросы + 1с++ включить ... вот и псевдо репликация ЗЫ опять же - есть вариант хранить цепочку обмена для загрузки... а смысл делать полную программную репликацию средствами SQL как то ниале - проще забирать MDF и атачить

походу тут не совет нужен а человеку просто хочется похвастаться, вы ему советы даете а он отказывается.

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

Не-не-не. Именно совет, но не просто. Дать абстрактный совет и сам могу, начитался за последнее время терминов. Очень хочется найти собрата, который бы имел опыт. Ну вот буду поднимать я, предположим, AlwaysOn availability Groups. Но как он работает с нагруженными базами 1С, в которых постоянно то в одном, то в другом месте эксклюзивная блокировка наложена. А какую дополнительную нагрузку на базу (вопрос быстродействия ни кто не отменял) оно создаёт? Или пробую SSIS. Как он будет работать с 1С справочником с любимыми 1С блокировками? А удастся ли им подружить 2012 и 2005 сервера? Много вопросов, ответы на которые обычно только на опыте появляются.

"проще забирать MDF и атачить" Так и было, пока баз не стало слишком много. 900 гигов баз даже с учетом десятигигабитной сетки небыстро забирать. Если они еще будут доступны после потенциальной гибели SQL. Рэйд далеко не всегда так просто выдернуть из одного сервера и переставить в другой. Руководство стало требовать гарантий получаса-часа простоя в случае аппаратных форс-мажоров. Вот тут и встала потребность во всяких репликациях. А я в SQL разбираюсь как типичный средний 1Сник - то есть дуб дубом.

пусть руководство бабло готовит на "полчаса час". Стучись в софтпоинт к Бекетову - у них есть решение репликации для нагруженных баз.

с такими объемами да - за 15-ть минут до канадской границы (с) ;)) все равно не взлетит SQL + 1С 7.7 своеобразная весч - чистые скульные методы в основном не работают, так что "чистая" репликация не прокатит

SQL cервер один? И все базы на нем?

Бабло уже вложено. Есть второй приличный сервер, который выделяется под SQL, и на котором нужно поднимать "зеркала" рабочих баз. С чем, что бы в случае форс-мажора просто перенастроить базы на другой SQL.

Сейчас все базы на одном сервере. В дальнейшем планируется, для увеличения быстродействия, распределить рабочие базы по двум серверам. С "перекрёстным опылением". В стиле: база1 работает на сервер1 и зеркалируется на сервер2, а база2 наоборот, работает на сервер2 и зеркалируется на сервер1.

Смотря какие цели для репликации: - Если резервирование или распределение нагрузки, то решение Softpoint Data Cluster на базе AlwaysOn по ссылке: - Если двухсторонний обмен то это решение "Репликация информационных баз данных", ссылка: Решения внедрены у многих клиентов, в том числе на 1С77, можно провести референсы для демонстрации. Связывайтесь

Не стоит класть все яйца в одну корзину. Я бы разделил: часть баз - на один сервак. Часть - на другой. Плюсы: 1. Уменьшится нагрузка на железо. 2. Повысится надежность. Упал один - хотя бы часть баз работает. 3. Легче проводить технические работы на сервере. Минусы: тут сам подумай.

SQL не делит потоки на уровне баз ... у вас там при проведении документов в одной базе - затыков не наблюдается ? :))) случаем в других

Спасибо за предложение. Подумаем. Быстродействие - больной вопрос. Особенно во время закрытия месяца, когда главбухи начинают баловаться перепроведениями. Вялотекущего перевода на прямые запросы хватает только для поддержания приемлимого быстродействия.

vcv, вам нужно в другом месте поискать совета и собрата )) в крупных компаниях все что связано конкретно с серверами и sql повешено на сис. админов   и они вам гораздо лучше смогут подсказать как такой объем лучше перелапатить и наладить, уверен что кто-то и без мзды даст дельный совет ;)

1) посмотреть проведение на 1сpp.dll 2) настроить автоматические проведения в не рабочее время 3) подумать в сторону разделения серверов SQL (несколько) 4) подумать о том что УРБД переносит движения из базы в базу "как есть" 5)подумать в использование прямых запросов к таблицам

1. RAID-10 вам в помощь. Более эффективного и надежного на данный момент нет. 2. УРБД. Кастомизация УРБД путем создания нестандартных маршрутов миграции. Хотя если честно то до конца так и непонял чего вы хотите.

240 гб  это за какой период И что показывает select  count(*) from _1cjourn Как бы иметь разные  данные в разных пб Это очень проблематично Да и сопровождать практически нереально Ну и  опиши базу это что бух опер учет  или комплексная

23  тии на твоих базах  делать протипоказано Да и с общей концепцией что то не так "От одной базы зависит работа дюжина баз"  извини Но очень неустойчивая неправильная  конструкция у тебя

Вообще в лоб. На втором SQL-сервере создаем копию всех баз. И ежедневно INSERT IN _Table123 FROM dbo._бла-бла-бла_Table123. Для регистров можно добавить WHERE data BETWEEN @Date1 AND Date2. Написать скрипт и запускать для каждой базы, разнеся по времени, чтобы нагрузку снизить. Скрипт запулить в мэйнтенс-план

А лучше так: второй независимый сервер SQL. Дублируем все базы. В этих базах никто не работает. Пишем для каждой базы хранимую процедуру, которая читает и инсертит из боевых баз в копии. На самой 1С пишем коннектор, который вызывает хранимую процедуру. Настраиваем в каждой базе запуск коннектора например 1 раз в час. Чтение транзакциям СУБД никак не помешает. Итого, на втором сервере будет ежечасная актуальная копия. Может бестолково объяснил, но как вариант

Непонятно по у тебя одна база то их много Если филиалы то сервера должны быть в филиалах Т.е. чтобы дать совет должно быть Хорошое описание того что есть м как это работает

да все базы у них на одном сервере, а филиалы по ходу через телнет работают...

Народ! А вам не кажется что тут что-то не так база 240 Гб! По началу пусть разберется от кель такие размеры! размеры ldf и mdf в студию. По ходу у него не сама база а размер журнала расперло по самое не хочу.

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

только не select  count(*) from _1cjourn а select  count(*) from _1sjourn а так вполне согласен. И что за конфа тоже.

Ну у меня есть рабочая база 300+ Гиг. И ничего удивительного там нет. Документы за прошлый и этот год. Т.е. база обрезана. Половину размера занимают справочники. Что связано со спецификой конторы. При этом картинки хранятся не в скуле. Если хранить их в скуле то думаю размер подопрет 2 ТБ, а может и больше. Но я ж не мазохист.

RAID-10 тоже панацея. И не спасает от, например, выхода из строя материнской платы. На отдельное СХД приличных фирм денег не дают. 240 гигов за период с 2009 года. Всего документов три с хвостивом миллиона. >Как бы иметь разные  данные в разных пб Это очень >проблематично Да и сопровождать практически нереально ПБ представляют собой юридически независимые фирмы в разных городах. На тему "разделения песочниц" начальство имеет твёрдую позицию. >Ну и  опиши базу это что бух опер учет  или комплексная Была когда-то торговля лет десять назад. Сейчас уже всячески переписанный монстр с опер и бух учетом. >тии на твоих базах  делать протипоказано За исключением одной подсистемы, которая была когда-то неправильно спроектирована, ТИИ проходит нормально. >"От одной базы зависит работа дюжина баз" извини >Но очень неустойчивая неправильная  конструкция у тебя У меня централизированная подсистема размещения заказов. ПБ принимает заявки от покупателей, подписывает договора и спецификации, информация из которых стекается в центр, обрабатывается отделом закупа и размещается на заводах. Если база с закупом будет одна централизованная на всех, то выписка спецификаций на ПБ потенциально может быть нарушена при недоступности этой базы. А отдел закупок давит и требует обеспечить надёжность и скорость работы. Потому что весь месячный закуп формируется буквально в несколько дней и в эти дни им и десять минут простоя много. Я хочу сделать реплицируемый средствами SQL справочник в каждой 1С базе, но не знаю толком как это реализовать. Сейчас тут работает штатный обмен УРБД, но он не устраивает по оперативности обмена. Он делается раз в полчаса, притом сеанс обмена может быть пропущен при ошибке транзакции.

С помощью этого врад-ли удастся обеспечить копию по более актуальную, чем по состоянию на утро. Вариант рассматривался. К сожалению у меня одна ПБ работает на своём SQL-сервере. Потому что находятся в промзоне, со связью там полный швах, обычно просто хреновая, несколько раз в год пропадает полностью на срок от нескольких часов до нескольких дней. Найти пристойное по цене решение проблем связи не удалось. Поэтому хранимка не устраивает, а хочется более надёжного решения, разработанного более умными людьми, чем я :) "Обреж базу" Обрезал в 2009 году. Пока снова обрезать не дают. >Непонятно по у тебя одна база то их много >Если филиалы то сервера должны быть в филиалах Сервера в филиалах были убраны из соображения минимизации затрат и дуракоустойчивости. За последние пять лет потеряли два сервера с частичной потерей информации. Плюс отдельные сервера имеют меньшую защиту от злоупотреблений, чем собственный выделенный "ЦОД". Так как ПБ юридически независимые компании, это руководству важно. Сейчас практически все филиалы работают в виртуальных серверах с базами, размещенными на одном SQL-сервере. Угу. Работа по RDP через VPN. Незакрытых регистров нет (разве что по мелочи что-то). Самые большие таблицы у меня с данным закупа (этот кусок буду полностью переделывать после того, как решу вопрос с обменом данными между SQL-базами) и данными документооборота. Куча сохранённых исходящих документов, связанных с объектами базы 1С. Входящие документы, к счастью, хранятся отдельно, там своя сотня гигов. Во-то. У каждого своя специфика.

Не хочешь писать свое резервирование с блэкджеком и шл..., тогда настрой зеркалирование, будь мужиком!

Подозрение внушает "В будущей версии Microsoft SQL Server этот компонент будет удален. Избегайте использования этого компонента в новых разработках и запланируйте изменение существующих приложений, в которых он применяется." И главное, совершенно непонятно, как оно работает с базами 1С. Поэтому я и задавал вопрос. А информацию о чуть ли не десятке возможных методов организации обмена между SQL-базами и сам нашел.

Главная проблема, мне кажется, в любви 1С приводить в соответствие базу своим ожиданиям. Поэтому, как писали в инете про SQL200 и старее, репликацию использовать нельзя. Потому что она реализовывалась с помощью триггеров и служебных полей, которые 1С радостно убивала при первой же реструктуризации. В более новых версиях MSSQL ситуация, вроде бы, изменилась. Но где бы найти толковую информацию про это? В худшем случае, если ни кто не имеет опыта, которым согласен поделиться, придётся устраивать долгую серию экспериментов. Но хочется, то ложечку манны небесной нахаляву :)

Ну если у вас умирает мамка то работать вы с железкой никак несможете. Вынимаете диски и в резервный сервер. Или я чего непонимаю?.. У нас по крайней мере так. стоит боевой сервак с 4 процами, и резервный такой же но с 1 процом. На резервном гоняю тесты перед внесением изменений в боевую базу. Но в случае чего - из боевого сервака вынимаются диски и ставятся в резервный. 10 минут и все зажужжало. Конечно производительность будет не та, но нужным людям доступ к базе будет и никто не умрет. То у вас локально базы на филиалах, то по RDP к вам коннектятся. Вы уж определитесь что там на самом деле. Но так или иначе УРБД вполне справляется с задачей. Все так и есть. В клюшках ничего неизменилось. Но если вы не планируете изменять конфигурацию (в чем я сильно сомневаюсь), то можете попробовать. Еще раз - задача решается на уровне железа. Да, вы можете хоть 100 раз настраивать репликацию. Но железячное решение будет самым оптимальным.

УРБД на полторагиговой SQL ной базе.. аминь

"Вынимаете диски и в резервный сервер" Админ утверждает, что если используется RAID посложнее банального зеркала, с этим проблема. Нельзя диски просто переставить в другой сервак. И другой рэйд-контроллер из скорее всего не поймёт. "То у вас локально базы на филиалах, то по RDP к вам коннектятся" Большиство баз конектятся по RDP. На данный момент есть только одна, работающая локально на своём сервере. "Все так и есть. В клюшках ничего неизменилось" В клюшках ничего, а в SQL, по слухам, изменилось. Вот только не знаю, где можно было бы нарыть конкретную информацию. В ссылках как в информация практически на пользовательском уровне, без технических аспектов, которые тут интересны. "Еще раз - задача решается на уровне железа. Да, вы можете хоть 100 раз настраивать репликацию. Но железячное решение будет самым оптимальным." Хотелось бы иметь нормальное СХД, с ним поднять failover cluster и уже на этом кластере заработают AlwaysOn Availability Groups. Самое современное решение от Microsoft. Но у меня пока нет СХД и в ближайший год не предвидится.

А что тут такого? на 40 Гб-шной с 30 ПБ танцует мама не горюй!

Ваш админ правильно говорит. У нас 2 сервака братья близнецы. различие только в количестве процов. Поэтому у нас возможна перестановка дисков между машинами. Почему так? Ну все по тому же - из варианта СХД и дополнительного сервера, было принято решение взять второе. И я считаю это правильным. Это не слухи. Возможность появилась еще в 2008 скуле. Но для этого вам необходимо соорудить кластер, на котором уже и поднимать зеркало базы. По сути это как RAID-1 будет работать (ну если провести аналогию). Т.е. абсолютно идентичные базы. Если какая падает то работа продолжается незаметно для пользователей. У мелкомягких достаточно подробный мануал - читайте.

т.е. у тебя и опер учет и бухгалтерии в одной базе? Если это так  то я считаю что надо оставлять одну базу оперучета И столько бухгалтерий сколько организаций

заказы  -  грамотно проектируешь и выносишь в отдельную Sql базу  (не 1с)  из 1c к ней только обращаешься 1срр Только не понятно что делать с базой которая в промзоне.

про виртуальные сервера и sql сервер  это один Физический сервер или разные?

>>>  восстанавливать базы после потенциальных сбоев SQL-сервера Бесперебойники поставьте новые или батареи обновите и бекап SQL, хоть раз в неделю, средствами SQL. ...И будет вам счастье... :)

Да, в одной базе. В оперативной базе ведётся черновой бухучет. Это позволяет почти все работы по сведению учета делать в этой базе, правя сразу и оперативный и бухгалтерский учет. Притом не в спешке, когда данные выгружены в бух и на днях уже сдавать баланс, а в текущем режиме. Гораздо меньше возникает расхождений между оперативной и бухгалтерской базами. В конце концов делается выгрузка в типовую бухгалтерию, закрытие месяца и регламентированная отчетность. Не хочется получить одну точку, от которой зависит текущая работа по заключению договоров и спецификаций с покупателями с размещением заказов поставщикам. Ну и с промзоной непонятно. Самый надёжный вариант, отдельная таблица или база на каждом сервере. Если она будет в составе базы 1с, будет работать ссылочная целостность, несколько удобней работать с типами данных типа справочник и документ. виртуальные сервера работают на отдельном железе. На ProxMox, или как оно называется. Там, по утверждениям админа, уже задублировано, два сервера работают параллельно, в случае смерти одного за несколько минут можно переключить на другой, на котором всегда актуальная копия виртуальных машин. А я вот отстаю, ни как не подниму "программный кластер" для SQL серверов ;)

А знаете ли вы, как я называю админов, которые поднимают SQL-сервера на виртуальных машинах? И не узнаете, ибо матофильтр не пропустит... А вот у меня в конторе они уже это знают...

Бесперебойники стоят хорошие, стоечные. Вопрос не в наличии бэкапов. Они есть еженочные и по всем оперативным базам раз в полчаса выгрузка журналов транзакций. Проблема в том, что дожили до таких объёмов, которые слишком долго поднимать из бэкапов. Руководство не согласно на такие сроки простоя. Требуют не больше часа, а за час не подниму порядка 300 гигов самых нужных баз. Проверял, не спасает сервак с SSD и почти сотней гигов оперативы. Не укладываюсь в требования. Поэтому и требуется какое-то зеркало на другом сервере. Может быть тупо грузить скриптом bak и trn, выгружаемые на первом сервере. Может быть пробовать зеркалирование. Может быть один из нескольких вариантов репликации. Может быть SSIS. Может быть новомодный AlwaysOn... Проблема выбора, чтоб её...

какое макс число субконт? Сколько проводок а базе ? Это насколько я понимаю относиться к базегде 3 милиона документов И сколько весит эта база Вообще ничего не понятно в твоих ответах С одной стороны пишешь что в одной базе и опер учет (на проводках) И бух  учет с другой тут же пишешь что делается выгрузка  в типовую бухгалтерию И таких нестыковок очень много Непонятно какие советы ты хочешь услышать здесь Опять  пишешь что тебе чтото надо восстанавливать из бекапов. Сколько раз за последний год востанавливал баз? По 67  что ты написал по поводу 64 Если нужен то вот  тебе еще совет - изучи 1cpp

> Проблема в том, что дожили до таких объёмов, которые слишком долго поднимать из бэкапов. Ну так AlwaysOn... никаким боком вам непоможет. У вас просто клон текущей базы в текущем состоянии будет. А если вы захотите поднять бекап то это или наращивать мощность железа, или обрезать базу. И зачем вы поднимаете бекапы?.. У вас все в рабочей базе есть. А если кому-то хочется посмотреть что неделю назад в документе была одна цифра а сейчас другая - это аудит системы.

> какое макс число субконт? Стандартно три. > Сколько проводок а базе ?" select count(*) from _1SENTRY даёт около 4.3 миллиона. > И сколько весит эта база сто гигов > С одной стороны пишешь что в одной базе и опер учет (на проводках) > И бух  учет с другой тут же пишешь что делается выгрузка  в типовую бухгалтерию Получился удобный вариант. С одной стороны в базе есть бухгалтерский учет и удобно бухам, с другой стороны, я не занимаюсь поддержкой работы регламентированной отчетности, всяких там книг покупок-продаж... Для этого имеющиеся проводки, касса и счета-фактуры выгружаются в типовую бухгалтерию. > Непонятно какие советы ты хочешь услышать здесь Советы по организации копии базы 1С средствами SQL с односторонней миграцией данных. И советы по организации двухсторонней миграции таблицы базы 1С на несколько серверов. > Опять  пишешь что тебе чтото надо восстанавливать из бекапов > Сколько раз за последний год востанавливал баз? Я рассматриваю гипотетический вариант выхода из строя сервера SQL. По любой причине, включая пожар в серверной и маски-шоу. Делаю это по требованию руководства. Один из простейших вариантов, это делать бэкапы на удаленный сервер, потом, при гибели основного сервера, поднимать базы из бэкапов. С таким сценарием отработки катастроф мы жили последние десять лет. И за эти годы да, пригождалась возможность восстановления. Но сейчас, с постепеным ростом размеров баз, этот сценарий руководство не удовлетворяет. Приходится искать средства поддержки копий рабочих баз в актуальном состоянии. Копия "по состоянию на утро" опять таки руководство не удовлетворяет. > Если нужен то вот  тебе еще совет - изучи 1cpp А какое отношение он имеет к теме?

>И зачем вы поднимаете бекапы?.. У вас все в рабочей базе есть. Рассматриваются сценарии гибели баз, выхода из строя серверов, пожаров в серверной, террактов в здании... Не суть важна причина, отрабатывается ситуация "сервер с дисками погиб и восстановлению не подлежит".

RAR-архив. Разрешаю запаролить. Современные технологии 8.х не предлагаю. От репликации к DBF упал в осадок немножко. Простите меня. "Теперь питание можно выключить" :(

Гм. А где вы увидели в ветке DBF? Тут SQL, SQL и SQL чуть ли не через пост звучит рефреном...

Странный подход - восстанавливать после сбоев. Какая разница реплицировать - копировать или восстанавливать из бэкапов? Это все равно долго. Если уж нужна бесперебойность - то сбоев практически не должно быть. Резервные диски и резервный сервер в другом здании - вот ваш выбор.

Ну тогда тянете оптику в соседнее здание. Ставите там еще пару серверов. Поднимаете кластер. Ну и получаете копию текущей базы в другом здании. И раз такая песня то копируйте не только базу но и другое важное (свежее порно к примеру). Надеюсь сразу 2 здания у вас никто не взорвет. Но если есть вероятность то поднимайте широкий канал в датацентр и поставьте там ящик.

+77 Кстати говоря кластеры можно было делать еще до 2008 скуля. Но думаю что вам это ниочем.

Я, конечно, сопля зеленая со своими базешками по сравнению со здешними монстрами. Но идея вести бухучет на крупных базах совместно с оперучетом не кажется правильной. Понимаю, что решение було принято ...цать лет назад - так они прошли уже. И такие монстры без прямых запросов - как оно работает вообще?

"резервный сервер в другом здании" Вот я и вопрошаю общественность, как правильно делать зеркало нужных баз на этот резервный сервер. Что бы нормально работало. "Поднимаете кластер" На сколько я понимаю, для кластера нужно СХД. А его нет, есть два отдельных сервера. Если знаете, как организовать кластер на двух разных серверах без СХД, поделитесь. Буду очень признателен. "Но идея вести бухучет на крупных базах совместно с оперучетом не кажется правильной" С точки зрения быстродействия да, формирование проводок, включая ОчиститьДвижения("Операция"), занимает процентов двадцать времени проведения некоторых документов. С другой стороны, идея делить единый учет на две базы (по туманному критерию торговая/бухгалтерская операция) тоже не сахар. "И такие монстры без прямых запросов - как оно работает вообще?" Не все узкие места пока переведены на прямые, но процесс идёт. В части мест прямые запросы вполне заменяет кеширование. И даже лучше справляется. Например, в формировании проводок. Зачем каждый раз лезть к базе, даже прямым запросом, если заранее загруженные в индексированную таблицу хоз.операции работают всё равно быстрее.

Ставишь еще одну ПБ скажем она VVV ( можно ей присвоить только чтение ). Во всех документах и справочниках в свойствах миграция поле дополнительно дополнительно пишешь VVV Пишешь скрипт ночного обмена с этой базой имеешь  копию на утро( каждый день ).

Такая ПБ уже есть. Но она обеспечивает только дублирование ЦБ. С ПБ вопрос остаётся открытым. И вопрос двухсторонней синхронизации определенного справочника средствами SQL тоже открыт.

Неправильно вы понимаете. Озадачьте этим вопросом админа. Если у вас 2008 сервер то используйте Microsoft Cluster Server (MSCS). Забудьте об этом. Почему - смотрите выше.