У нас на сервере находятся MS SQL базы 1С. Данные хранятся в файлах MDF и LDF. Настроил второй резервный сервак, там установлена MS SQL. Сделана синхронихация баз на определенное число. Так вот вопрос как сделать синхронную копию баз не достающих данных? в файлы MDF и LDF данные сбрасываются и копируются тока после функции Detach Database. Но я не могу отцеплять базы во время работы. Т.к. работа ведется в этих базах почти 24 ч. в сутки. Мне нужно полное резервное сохранение данных, с последующим оперативным сменой сервака. Суть проблемы такова: что нужно будет оперативно переключится на другой MS SQL сервак, в случае полного умерания первого (с невозможностью восстановить базы на первом серваке). Подскажите как настроить репликацию данных или подскажите прогу по спасению этих файлов. Выгрузка не подходит, т.к. это очень долго. Можно ли восстановить базу с других транзакций, одинаковой структуры?
За ранее спасибо!

а разве backup/restore уже отменили ? это самый простой и дешевый способ:
по расписанию - backup на рабочем сервере и restore на резервном, но в этом случае переключение на другой сервер, естественно, будет ручное...
а вот для полной "автоматики" нужен совершенно иной подход... где-то на sql.ru был цикл статей по отказоустойчивым системам...
з.ы. ссылку могу дать только в понедельник :)

(1) backup/restore для рабочей базы, а разве можно backup слить в пустую (созданную) SQL базу на другой сервер MS SQL?
Буду следить в понедельник за ссылкой))

рабочий сервер делает backup на свой диск (для ускорения) в зашаренную папку, а резервный из этой зашареной папки делает restore у себя.
вот и все... :))

(3) Полной реплики не получится . Нужен перерывчик в работе баз .

(3) значить файл *.trn можно слить в пустую базу. Так? Т.е. на 2 серваке можно создать новую базу и сделать restore и указать данный файл *.trn?

(3) мне нужен полный архив с данными))) т.е. сначала нужна детач баз, чтоб данные слились в файл mdf, а потом лучше его методом копирования перенести на другой сервер SQL и подключить базу. Но это не удобно, может есть иной нормальный вариант. С полным переносом данных, а не транзакции базы. Так как их влить в пустую явно нельзя, так как должен быть первоисточник.)))

Чистая теория:
Возможна репликация средствами SQL, но при внесении изменеие в базу 1С снесет все служебные поля. Есть стандартные средства - УРБД и не парить мозг.

(7) Вот и я про тоже))) конфируции текущее у меня сохранены в другом месте. Вот в чем и вопрос, что нужно сохранение файлов mdf и ldf с изменениями.
Суть процесса: 1. Отцепляю базу от сиквела. 2. копирую эти файлы на другой комп. 3. Прицепляю обратно. А мне нужен более менее ИМЕННО такой процесс сохранения. Чтоб я потом эти файлы зацепил на другой сервер MS SQL. Бэкап не подходит, так как он сохраняет транзакции. А что такое транзакции без базы))) УРБД позволяет делать операцию в конфигураторе и опять же в одиночном режиме((( А еще знаю, как перевести распределенную базу в центральную в DBF версии, а в сиквеле, даж и не знаю что надо удалить, чтоб она потом стала центральной(((( т.е. получится так что на той копии, я не смогу сделать изменения в базе, так как это делается в центральной базе и при омене все синхронизируется

Для начала сделай перерыв в работе с базами часа в три ночи

(9) Да это и так понятно, я сиквел приостанавливает работу в обед, чтоб обновились mdf, потом я их копирую на другой сервак. Мля так уже запарился делать все это вручную(((((( а хочется автоматики))))

Что за прога Хранитель V для сервера + SQL. Кто нить ведает инфой, по данной фенечки? Может стоит её приобрести, да не мучатся? позволяет ли данная фишка, восстанавливать архив MS SQL базы НА ДРУГОЙ СЕРВЕР MS SQL? И вообще не понятно, почему 1С использует данный сиквел, нет полноты управления с платформы. Блин сиквел там тока для хранилища данных. Тогда бы они сделали на MySQL все равно тока данные там парятся, а MySQL - бесплатный)))) С точки зрения формата, нет ни какой разницы.

(8) Создай отдельно ЦБ, а на Скулях поставь Распределенки с полной миграцией. Настрой автообмен планировщиком (хоть 5-10 минут) и у тебя на двух скулях ВСЕГДА будут рабочИИ базы (с полной синхронизацией) и используй любую из них.
PS только не забудь использовать префиксы баз, коды в доках и справочниках дожны быть текстовыми, этак более 8 символов. Чтоб не получить одинаковые номера документов.

(12) В каком режиме происходит обмен? в конфигураторе? может ли такая операция выполнятся, когда в БД находятся звери?

(12) какие префиксы? работа ведется в одной базе!!!! мне нужно спасение данных! Я конечно понял, что архив центральная база, а рабочая распределенная и ни что не мешает потом создать распределенную базу с полной миграцией. Но автообмен возможен в режиме конфигуратора и отсутсвия зверей в программе!

(13) В конфигураторе в пакетном режиме. (на Мисте есть инструкция использования УРИБ). От зверей обмен не зависит. Без зверей вносится ТОЛЬКО обмен конфигурации (МД), если его правил. УРИБ автоматически меняет конф-ии на всех база. Если Конву не правиши - файлики обмена в районе до ста кбайт (если обмен, не реже часа). время обмена 5-30 сек. Зверей выгонять не нужно. Плюс, можеш разгрузить Скули.

(14) вроде ответил все в (15). Префиксы нужны, что-бы не было одинаковых номеров документов/справочников. Если твои звери перейдут на второй Скуль, у них нумерация, пойдет опять с "1". А припрефиксах: на одном, к примеру: К0-000001,К0-000002,... , на втором - К1-000001,... , а на ЦБ - ЦБ-000001,...

+16 пребиксы можно и так задать база1- 100000001,... база2- 200000001,... т.е. без букв, одни цифры.

(17) Юзай планировщик nnCron (www.nnCron.ru) - он на форте много чего может. Там хелп и документашка есть.

ALL, поясните пожалуйста, что имел ввиду (6) и (8):
"С полным переносом данных, а не транзакции базы. Так как их влить в пустую явно нельзя, так как должен быть первоисточник" - зачем первоисточник?
"Бэкап не подходит, так как он сохраняет транзакции. А что такое транзакции без базы"
Backup базы можно развернуть на другом сервере. Бакапить можно как лог, так и базу. Зачем все эти извраты с копированием файлов mdf ?
Или backup средствами SQL долго работает? Так ведь он бывает differential.
Или я чего-то недопонял?

20 - Просто Reanimator28 не помешало бы разобраться, хотя бы примерно, как работает СКЛ, где хранится база, что такое журнал транзакций, модели восстановления, бакап и т.п. На sql.ru и в ихней рассылке "MS-SQL Server - дело тонкое" куча статей про все это.
17 - зачем копировать файлы когда в SQL есть свой бакап. Который будет работать всегда, если конечно база не в single user или offline. Не хотите бакапить базу во время активной работы - бакапьте логи (транзакции), только не забудьте поставить нужную модель восстановления. А базу бакапить можно и утром, пока нет никого. В результате потом на другом серваке рестор базы + накатка на неё логов на соотв. время. (ессно при бакапе не надо делать shrink и trunkate).

(20) согласен !!! - backup/restore рулит !!! просто и со вкусом
з.ы.
это кто ж надоумил такое делать - копировать файлы БД ???

Что за извращенцы, копировать архивы, еще в 7 писал про урбд, как слепые блин.

23 - Почему слепые?
Не слепые. ИМХО - зачем делать гемморой самому себе, когда можно тоже самое сделать и стандартными средствами?
Вообще - я не очень понимаю - как можно периодическими бакапами чего-либо сделать что-то синхронное?

Основной сервер не дохнет каждый день, зачем КАЖДЫЙ день восстанавливать backup в другую базу?! (тем более деаттачем)
А вообще читай документацию к SQL ибо в (8) описана не суть процесса, а бред какой-то. Извини за правду.

25 - А еще есть такая штука как кластер :) Но это, в данном случае, из области систем высокой готовности, жалкое подобие которой и хочет создать автор :)

(26) Ты займись целью и посчитай стоимость этого кластера...

То 0. Для начала книгу какую нибудь купите по администрированию. Там есть глава посвященнная вашенй проблеме. Вы для начала разберитесь что такое дифференциальный бэкап и что такое транзакционный , как их можно снимать и востанавливать на другом сервере. Это самое эллементарное что можно сделать. А то ведь сразу репликация:)
Если это вам не по силам то вызывайте спеца - вам схему за час настроят. Кроме этого учтите что неправильно настроенная схема бекапирования может сильно понизить производительность системы.
А вообщем такие вопросы нельзя давать решать дилетантам. Или если уж новичек берется за такое дело - рекомендую тщательно все изучить и потренироватся сначала на тестовых базах.

Оффопик:
27 - а какое это имеет значение? Ведь средства выделяемые на защиту информации, считаются от стоимости этой сомой информации, и от убытков нанесенных недоступностью данной информации (информационных ресурсов) за отрезок времени. Так что весьма может получиться так, что стоимость составит копейки по сравнению с убытками.

(1) (3) И мы так делали три года.
(2) (5) Просто ещё не попробовал.
(6) Я делаю для усечения log. Но до сих пор опасаюсь и вначале:
    a) 1c выгрузка(на всякий случай) c копированием dd и usrdef.
    b) backup/restore на другой сервер с проверкой.
(8) Тоже метод, значит знает и умеет пользоваться Query Analyzer со
    встроенным helpом.
(11) Может купишь и расскажешь как она на практике.
(14) Оптимальное спасение: mdf на зеркале, ldf на соседнем SCSI винте;
     ночью средствами SQL backup/restore на другой сервер;
     bat_xcopy весь каталог с md, usrdef...;
     подмена dba(usrdef) из другого сервера для работоспособности 1с.
(25) Дохнет каждай год или два, а может железо, а не сервак.
(28) Во время осваивания P3-двухпроцессорный просто лежал - так и не
     освоил репликацию, а так интересно, из-за этого программеру
     знакомому порекомендовал кластер, а он взял да купил - везёт.

(0) Кстати для полного копирования можно настроить dts
чтобы таблички в приемной базе дропались и заново создовались

Если нужна практич. online копия базы, то оптимальный вариант - УРБД.
Если раз/два в день - то backup/restore.
Оба варианта без проблем полностью автоматизируются.