Стратегия резервного копирования и восстановления из копии для репликации слиянием
Область применения: 
SQL Server
Для репликации слиянием регулярно создавайте резервные копии следующих баз данных:
База данных публикаций на издателе.
База данных распространителя на распространителе.
База данных подписок на каждом подписчике.
Системные базы данных master и msdb на издателе, распространителе и на всех подписчиках. Резервные копии этих баз данных и копия соответствующей базы данных репликации должны быть сделаны одновременно. Например, создавайте резервную копию баз данных master и msdb на издателе одновременно с резервной копией базы данных публикаций. Если база данных публикаций восстановлена, убедитесь, что базы данных master и msdb согласованы с базой данных публикаций по настройке и конфигурации репликации.
Если резервное копирование журналов выполняется регулярно, любые изменения, касающиеся репликации, будут заноситься в резервные копии журнала. Если резервные копии журналов не создаются, резервное копирование следует выполнять при каждом изменении параметров репликации. Дополнительные сведения см. в статье Common Actions Requiring an Updated Backup.
Выберите один из описываемых далее подходов к резервному копированию и восстановлению базы данных публикаций, затем следуйте рекомендациям, приведенным для базы данных распространителя и базы данных подписок.
Резервное копирование и восстановление базы данных публикаций
Существует два подхода к восстановлению базы данных публикаций слиянием. После восстановления базы данных публикаций из резервной копии следует:
Либо синхронизировать базу данных публикаций с базой данных подписок.
Либо повторно инициализировать все подписки на публикации в базе данных публикаций.
Применение любого их этих методов гарантирует, что после восстановления издатель и все подписчики будут синхронизированы.
Примечание.
Если какие-либо таблицы содержат столбцы идентификаторов, следует обеспечить после восстановления назначение правильных диапазонов идентификаторов. Дополнительные сведения см. в статье Репликация столбцов идентификаторов.
Синхронизация базы данных публикаций
Синхронизация базы данных публикаций с базой данных подписок позволяет загружать из одной или нескольких баз данных подписок те изменения, которые были сделаны ранее в базе данных публикаций, но не были представлены в восстановленной резервной копии. Передаваемые данные зависят от того, как отфильтрованы публикации:
Если публикации не отфильтрованы, должна существовать возможность обновления базы данных публикаций посредством синхронизации с самым обновленным подписчиком.
Если же публикация отфильтрована, то базу данных публикации, возможно, не удастся обновить. Продумайте таблицу, которая разделена так, что каждая подписка получает данные клиентов только из одного региона: север, восток, юг и запад. Если существует по крайней мере один подписчик из каждой секции данных, синхронизация с подписчиком из каждой секции должна обновить базу данных публикаций. Однако если данные в западной секции, например не были реплицированы на какие-либо подписчики, эти данные на издателе невозможно будет обновить.
Внимание
Результатом синхронизации базы данных публикаций с базой данных подписок может быть восстановление опубликованных таблиц до более современного состояния, чем состояние других неопубликованных таблиц, восстановленных из резервной копии.
Если вы синхронизируете с подписчиком, выполняющим версию Microsoft SQL Server до Microsoft SQL Server 2005 (9.x), подписка не может быть анонимной; она должна быть клиентской подпиской или подпиской сервера (например, локальными подписками и глобальными подписками в предыдущих выпусках).
Чтобы синхронизировать подписку, см. разделы Synchronize a Push Subscription и Synchronize a Pull Subscription.
Повторная инициализация всех подписок
Повторная инициализация всех подписок гарантирует, что все подписчики находятся в состоянии, согласованном с восстановленной базой данных публикаций. Такой подход следует применять, если требуется вернуть всю топологию в предыдущее состояние, представленное резервной копией базы данных публикаций. Например, повторная инициализация всех подписок может потребоваться, если восстановление базы данных публикаций до более ранней точки используется в качестве механизма возврата из ошибочно выполненной пакетной операции.
Если выбран данный вариант, создайте новый моментальный снимок для его доставки на повторно инициализированные подписчики сразу после восстановления базы данных публикаций.
Чтобы повторно инициализировать подписку, см. раздел Reinitialize a Subscription.
Чтобы создать и применить моментальный снимок, см. разделы Создание и применение исходного моментального снимка и Создание моментального снимка для публикации слиянием с параметризованными фильтрами.
Резервное копирование и восстановление базы данных распространителя
При репликации слиянием база данных распространителя должна регулярно подвергаться резервному копированию, и она может быть восстановлена без дополнительных условий до тех пор, пока время, истекшее с момента создания используемой резервной копии, не превышает кратчайший срок хранения всех публикаций, использующих распространитель. Например, если есть три публикации со сроками хранения 10, 20 и 30 дней соответственно, то используемая резервная копия не должна быть старше 10 дней. База данных распространителя играет ограниченную роль в репликации слиянием: она не хранит данных, используемых для отслеживания изменений, и не служит временным хранилищем изменений репликации слиянием, которые должны пересылаться в базы данных подписок (как это делается при репликации транзакций).
Резервное копирование и восстановление базы данных подписок
Чтобы гарантировать успешное восстановление базы данных подписок, подписчики должны синхронизироваться с издателем до резервного копирования базы данных подписок; подписчики также должны синхронизироваться после восстановления базы данных подписок.
Синхронизация с издателем до резервного копирования базы данных подписок гарантирует, что если подписчик восстанавливается из резервной копии, подписки все равно будут находиться в пределах срока хранения публикации. Например, предположим, что срок хранения публикации равен 10 дням. Последняя синхронизация была 8 дней назад, а теперь выполняется резервное копирование. Если через 4 дня будет произведено восстановление из резервной копии, то последняя синхронизация окажется 12-дневной давности, то есть за пределами срока хранения публикации. В этом случае потребуется повторная инициализация подписчика. Если подписчик был синхронизован перед резервным копированием, база данных подписок будет находиться в пределах срока хранения публикации.
Время с момента создания резервной копии не должна превышать кратчайший срок хранения всех публикаций, на которые подписывается подписчик. Например, если подписчик подписывается на три публикации со сроками хранения 10, 20 и 30 дней соответственно, то резервная копия, используемая для восстановления, не должна быть старше 10 дней.
Синхронизация базы данных подписок с каждой из ее публикаций после восстановления гарантирует, что подписчик обновлен в соответствии со всеми изменениями издателя.
Чтобы установить срок хранения публикации, выполните действия из статьи Установка срока действия подписок.
Чтобы синхронизировать подписку, см. разделы Synchronize a Push Subscription и Synchronize a Pull Subscription.
Резервное копирование и восстановление переиздаваемой базы данных
Когда база данных подписывается на данные издателя и в свою очередь публикует те же самые данные для других баз данных подписок, ее называют переиздающей базой данных. При восстановлении переиздающей базы данных следуйте инструкциям, описанным в подразделах «Резервное копирование и восстановление базы данных публикаций» и «Резервное копирование и восстановление базы данных подписок» этого раздела.